Daniel Simoes

Primeiro atualize o seu emulador... Veja esse post: Certifique-se também de ter a última versão dos fontes do ACBrSAT

Em relação a Impressão do QRCode, estou apenas aguardando uma resposta do autor dessa biblioteca... http://www.debenu.com/open-source/delphizxingqrcode/ Com ela poderíamos usar qualquer Gerador de Relatórios para imprimir o Cupom do SAT, pois o QRCode seria tratado como uma imagem a ser impressa... ( embora eu prefira usar soluções nativas, como os comandos ESC P/2 da Epson... pois é muito mais rápido )

Obrigado por mais esta correção Larissa... já está no SVN...

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...

Eu não consigo reproduzir o seu problema com essa descrição... Tudo que temos em comum é o código fonte do ACBr... Portanto, é necessário que você mostre com um passo a passo usando o TEFDDemo, como eu poderia reproduzir este erro aqui...

Tente no nosso repositório... nesse endereço: https://svn.code.sf.net/p/acbr/code/tools/Bancos/

O Log anexado é o do ACBrMonitor, e não do ACBrECF... o que não dá tantos detalhes sobre a comunicação com o ECF... Porém é possível notar que você está enviando um caractere de Negrito, na linha de fechamento do cupom... Você não deve usar esse comando sem o CPF/CNPJ, pois ele não funciona

Suas informações são insuficientes para qualquer analise... Por favor forneça um passo a passo, e descreva o ambiente utilizando de maneira que possamos reproduzir o mesmo erro no projeto demo TEFDDemo

Provavelmente você está enviando algum caractere especial que não é aceito pelo ECF... por favor anexe o Log do ACBrECF para analise...

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