Daniel Simoes

Tente com o novo Emulador do Fisco... mas antes apegue todas as SAT.DLL existentes em diretórios do Path de sua máquina... Provavelmente este é o problema... ele está carregando uma SAT.DLL de outro lugar, como por exemplo: c:\windows\system32...

Apliquei algumas correções nos Demos em Delphi e Lazarus... (lembrando que o Demo em Lazarus atualmente é o mais completo) Por favor atualize seus fontes e tente novamente...

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

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