daniel.simoes

Provavelmente é assim, mesmo por se tratar de um emulador.... o ACBrTEFD não faz nenhum tratamento no "espelho" do Comprovante a ser impresso, ou seja, ele manda imprimir exatamente o que foi enviado pelo G.P.... Em todo caso, ligue no suporte do G.P. e verifique se isso é realmente um problema

Você está enviando apenas "1" ou "1 " (com espaços)... Observei ainda que nenhuma das suas Formas de Pagamento permite vinculado, portanto experimente NAO marcar essa opção...

Apenas para complementar... Segue em anexo uma Imagem com um cupom efetuado com o Emulador da Epson

Com certeza é nessa linha... mas o que eu havia solicitado é para vc entrar nela com o F7... Observe no seu LOG, que o ACBrECF nem chega a gravar a tentativa desse comando no Log.. e isso é algo muito estranho... Experimente algo a "lá Microsoft"... apague e remova seu ACBr, baixe uma nova versão e faça uma nova instalação

Caramba... nunca vi um Delphi "falando" Italiano... Com certeza ele está achando a DLL errada, ou ainda o "par" das DLLs libeay32.dll e ssleay32.dll não são da mesma versão... por via das dúvidas, copie estas DLLs na mesma pasta do .EXE do Delphi

Todas as telas são comandos enviados pelo Gerenciador TEF, (veja o Log gerado pela classe ACBrTEFD) 1. Não há como pular as perguntas... 2. Na homologação vc precisa mostrar todas as telas... Depois, vc pode inserir um código para efetuar a resposta. automaticamente conforme o tipo do Campo

O estranho é que seu Log não consta o envio desse comando (EfetuaPagamento)... Algo está disparando o erro entes... Vá com o DEBUG (F7), e verifique onde o erro é disparado...

O mesmo erro ocorre com o emulador da Epson ? Não consigo reproduzir o problema aqui... Uso a Epson diariamente no meu desenvolvimento

Usando o programa Exemplo da Sweda obtemos o mesmo retorno que o do ACBrECF

Os índices estão corretos... Notei que no seu LOG não há nenhuma chamada ao método "EfetuaPagamento" do ACBrECF... Você enviou o Log correto ? Qual é o passo a passo para reproduzir o problema ?

Obrigado... Relendo os fontes da Epson, e o LOG, observei que o código do índice da Forma de Pagamento é atribuído por código, já que o ECF não retorna o mesmo em sua resposta... Pode ser que esse modelo use outra nomenclatura ao invés de 1 a 20.... Seria possível anexar uma captura Serial de LeituraX (ou uma imagem de uma X impressa) ? isso poderá mostrar qual o Índice que o ECF usa para as FPGs

Humm... infelizmente a imagem não ajudou muito... Por favor anexe o LOG do ACBrECF gerado para esses comandos

Reproduzi o comando com o Emulador e o resultado foi o mesmo... O estranho é que o comando não está se comportando de acordo com o manual... o Resultado da Msg de Erro deveria ser 110 110 Resultado: Leitura com êxito (fonte CMC7). O resultado está inserido na mensagem (campo: adicional) em forma de string termina em null O código da Sweda que vc colou, é uma rotina de leitura genérica, ou seja é o código que Lê o retorno do ECF (no caso da Sweda)... O interessante seria ver nos fontes da Sweda, qual é o conteúdo do método que chama a Leitura do CMC7 (cmd 24)

Usando o Demo do ACBrECF, ECFteste, capture as formas de pagamento e cole o resultado aqui...

Mas como poderíamos resolver isso ? A criação de um Package é quase obrigatório no Lazarus, já que ele nãos segue o conceito de "PathLib" do Delphi (o que acho muito bom) Mesmo que os Packages tenham nomes diferentes, a IDE achará os fontes com o mesmo nome, e dará um Warning no momento da compilação...

Parece ser algo na sua aplicação... Vc está tentando enviar pagamento após o Total do Cupom já ter sido totalmente pago...

Não precisa dessa alteração... no seu evento: ACBrTEFD.OnComandaECFSubtotaliza faça: if Est = estNaoFiscal then ACBrECF1.SubtotalizaNaoFiscal( DescAcre + OSeuDesconto, 'Projeto ACBr|http://acbr.sf.net' ) else ACBrECF1.SubtotalizaCupom( DescAcre + OSeuDesconto, 'Projeto ACBr|http://acbr.sf.net' ); [/code]

Sim... por enquanto sim... mas vou remover essa verificação hoje há um teste para cartão + Dinheiro que exige um lançamento inferior ao total, Exemplo: - Compra de 100,00 - pagar 50,00 no Cartão - pagar 100 no Dinheiro a aplicação deve voltar Troco de 50,00

Isso é uma implementação da sua aplicação... considerando que o ECF não suporta 2 subtotais, e que só no total vc pode informar o Desconto... Vc precisa ajustar seu fluxograma para isso.. Observe que é você quem informa para o ACBrTEFD o SubTotal restante... faça suas contas, e considere os seus pagamentos antes de responder para ele...

Sim, é algo na programação da aplicação... aparentemente há algum evento tentando ler o NumCupom.... e isso pode ocorrer quando o ECF está ocupado

Com a introdução do Cielo Premia, a única opção é não SubTotalizar o ECF antes de chamar o TEF... Quando vc chamar o CRT vc pode já considerar o seu desconto de aplicação, e na hora de impressão do SubTotal vc acumula o mesmo no enviado pelo G.P.

Não entendi a pergunta... o componente imprime a via exatamente como enviada... Leia o documento específico da NTG, sobre o Cielo PP, nele informa quando devemos imprimir quais comprovantes

Vc pode usar ACBrTEFD.FinalizarCupom... A grande vantagem é que ele fecha subtotaliza, imprime os pagamentos e fecha o cupom já usando o fluxo do TEF (de retentar no caso de falha)

Por favor leia o manual específico de Cielo PP... As informações de Identificação são necessárias para serem enviadas ao G.P., para informar ao GP que a aplicação suporta essa função

Usamos a versão do Synapse do SVN... verifico diariamente...