Daniel Simoes

Fiz várias correções no código, que podem corrigir o problema de String x AnsiString... Favor atualizar os fontes e testar... ( Lembre-se de renomear a Unit que você alterou, caso contrário haverá conflitos no Merge )

Correção aplicada:

Acredito que todas as Impressoras Térmicas Epson, atuais, devem ser compatíveis com ESC P/2 e QRCode Nos testes usamos uma TM-T88

Apliquei recentemente várias correções para o componente ACBrSAT

Não tenho solução para isso no momento... provavelmente é algo fora do meu controle, na DLL...

Por favor poste o Log original... (zip e anexe) Você está informando que o ACBr está Transmitindo um Valor diferente da resposta selecionada ? Vá com o Debug e veja como esse valor poderia ter sido mudado...

O primeiro passo é obter a documentação do Fabricante com o protocolo Serial do Equipamento... após estuda-lo, verificar se o equipamento é compatível com algum dos modelos já escritos...

Pensei nisso... mas veja que as homologadoras não podem exigir algo que o próprio roteiro delas não seja capaz de validar... Portanto no TEF dedicado, eles testam Formas de Pagamento em Dinheiro, de forma a voltar o Troco... E no TEF dedicado, eles testam apenas o Troco em Cartão... Ou seja, o teste deles não valida as duas situações simultaneamente.... mas mesmo que algum dia o fizessem, com essa implementação funcionaria...

Ao invés de: prefira ACBrTEFD1.FinalizarCupom pois esse método tem toda uma lógica de Tentativa e Erro e controle da sub-totalização, pagamentos, finalização do cupom e abertura do CCD ou Gerenciais

Fiz vários testes e não consegui reproduzir o problema... Consegue reproduzir o problema em outra máquina ?

Algumas dicas... se você utilizar ACBrTEFD.FinalizarCupom O ACBrTEFD pode controlar as formas de pagamento Cartão... agrupando-as... O Evento OnComandaPagamentos deve ser programado corretamente... O Evento OnComandaECF tem uma nova opção chamada: opeImprimePagamentos : que permite que você a utilize para efetuar os pagamentos em dinheiro ou demais... (não TEF) O TEFDDemo procura demonstrar o funcionamento desse mecanismo...

O valor do InfoECF é você que calcula e passa... (provavelmente na resposta a ele que você está errando) Tudo que o componente está dizendo é que você está tentando fazer um pagamento com o valor inferior ao valor que vc mesmo informou como sendo o Total... Estude os fontes do Demo com atenção... existem muitos comentários nos fontes com esclarecimentos...

O que faço na minha aplicação é calcular se o total em Cartão (TEF) é maior do que os demais pagamentos (Ex: dinheiro)... Deixando os maiores pagamentos sempre para o final... Pois assim não há risco do ECF fechar o total do cupom, e o ultimo pagamento (por ser maior que o total restante) gera o troco...

Acho que vc deve pelo menos ler o manual do Gerenciador... Lá deve dizer o que ele espera.... Ajuste os diretórios em: ACBrTEFD.TEFDial.Arq*

Realmente uma resposta muito confusa... se a aplicação não fizer o controle de Confirmações e Cancelamentos provavelmente o Gerenciador Padrão não seja capaz de fazer mutilas transações (herança do antigo Gerenciador Padrão) A questão do cielo premia também mudou todo o operacional de pagamento (que agora deve ser bufferizado)... Eles estão começando agora com essa "encrenca" de homologação... acho que logo logo vão rever os testes...

Use o Debug e estude os fontes... é fundamental ter domínio dos fontes para conseguir passar na homologação... O componente está fazendo o que ele foi programado para fazer... A classe TACBrTEFDAuttar herda de TACBrTEFDClassTXT, que herda de TACBrTEFDClass... E veja que no final de TACBrTEFDClass.Inicializar... há uma chamada a: CancelarTransacoesPendentesClass ; Provavelmente poucas pessoas usam a classe TACBrTEFDAuttar, ou eles mudaram os testes... Você poderia fazer um override do método Inicializar na classe TACBrTEFDAuttar e escrever o novo comportamento esperado...

Pelo que notei, é um problema do Equipamento (emulador)... ou o mesmo está usando uma quebra de linha diferente do especificado pela Lei, que determina o uso do "LF" como quebra de linha. http://www.fazenda.mg.gov.br/empresas/ecf/informacoes/ac1609.pdf O ACBrECF está enviando os caracteres acentuados e a quebra de linha... mas o equipamento está suprimindo os mesmos... Para evitar problema com os caracteres acentuados, use a página de código igual a 0

Para que eu tenha uma compreensão melhor do problema... Dada a redução Z acima, qual foi o retorno que o ACBrECF deu para ela ? No papel consta a Red.Z de R$ 6546,66... qual foi o valor demonstrado pelo ACBrECF ?

Acho que o primeiro passo é fazer o programa do próprio fabricante funcionar... Isso irá garantir que as Bibliotecas estão instaladas de forma correta...

Geralmente esse tipo de equipamento usa um cabo bem simples de 3 pinos, ligando RX do Host com TX do PC, e o terra de ambos.. Veja esse link: http://az-world.no.comunidades.net/index.php?pagina=1778350145

Você está usando uma chamada a AcharPorta(), sem especificar o modelo do ECF... Isso não é bom... Alguns ECFs não gostam de receber caracteres fora do padrão do protocolo que estão programados... e chegam até mesmo a travar... Ou seja, o método AcharPorta( )... nunca funcionou direito... Repare no final do Log que ele tenta abrir como uma Sweda e não como Daruma.... Veja nos fontes o método AcharPorta( )... tudo que ele faz é setar um modelo por vez e tentar abrir ativar o ECF... no caso da Bematech, ela é o primeiro modelo da lista do ACBrECF

Provavelmente esse modelo tem as suas peculiaridades... Você poderia ler o manual do fabricante e fazer um "De/Para" com as funções do PPLA ou ZPL...

Esse tipo de informação varia muito entre cada Fabricante, e as vezes até mesmo por modelo, do mesmo fabricante... Como o Elton disse, Somente consultando o manual você pode chegar a um valor exato... Mas é normal que todo ECF aceite até 8 linhas de observação no rodapé do cupom... ( o numero de caracteres depende da largura das colunas )

O protocolo não é simples... e pode ser configurado de muitas maneiras no equipamento... A tarefa tem um certo grau de dificuldade... Talvez seja melhor usar uma DLL do fabricante

Mais uma vez você está correta... Obrigado pelo excelente bug report.. ( Acho que o problema ocorreu após um refactoring ) Rev: 6385