Daniel Simoes

A MP4200TH FI é um ECF completamente diferente da MP4000... Mas SIM, o ACBrECF já suporta ela... (vou atualizar a Lista) Veja esse post:

E o que devemos ver no LOG ? Até o momento não compreendi o problema... Por favor descreva um passo a passo usando o TEFDDemo

Por favor adicione o LOG do ACBrECF... provavelmente você está especificando o COO do Cupom original errado...

Sem o LOG não vejo como...

Não dá pra compreender o seu post... O que você quer dizer com ALT+R por exemplo ??? Se não há LOG gerado pelo SiTEF então todo o fluxo ocorreu dentro da sua aplicação, e não há o que possa ser feito...

Você não enviou o comando para SubTotalizar o Cupom...

Anexe o log gerado pelo ACBrECF

A mensagem vem do SiTEF...

Analise o LOG gerado pelo ACBrTEFD... se foi uma mensagem vinda da Operadora não há o que fazer...

Acho que você está certo... Você pode subir a correção ?

Se você está usando as DLLs para gerar o arquivo, certifique-se de que você tem as últimas versões das DLLs

Por favor anexe o LOG... se no LOG está chegando 84,10.. provavelmente é sua aplicação que está fazendo algum tipo de arredondamento... Quanto ao modo Debug, desabilite na sua IDE, "Stop on Delphi Exceptions"

Acho que o ACBrInstall não é compatível com o Delphi 6

Esse método tem 2 versões... primeiro ele tenta ler a Data e Hora do Sw.Básico pela captura da Leitura da Memória Fiscal, se isso falhar... ele tenta ler apenas a Data usando o comando nativo... Não há comando nativo que retorne a data e a hora... As correções do Elton estavam certas... foi um refactoring mal feito... Apliquei correções nos fontes do SVN...

Qual a exata msg de erro ??

Acabei de subir as correções para o SVN... basta atualizar seus fontes... (talvez seja necessário renomear as Units que vc alterou)

Não é bom amarrar ao "texto de retorno"... pois se eles mudarem a mensagem sua aplicação quebra... veja o meu tópico anterior...

Um WorkAround seria: 1543 // Amex retorna 101 e não FF 1544 if (pos(UpperCase(Resp.Conteudo.LeInformacao(9,0).AsString), 'FF|101') > 0) then 1545 ApagaEVerifica( ArqResp );

O problema é que o arquivo da AMEX não está sendo retornado no padrão correto... o ACBrTEFD tem um tratamento específico para essa situação... Veja a procedure Inicilizar abaixo, onde diz: { Verificando se o arquivo de Resposta é invalido ou seja, gerado quando clica-se em 9 - CANCELAR sem selecionar nenhuma Bandeira } procedure TACBrTEFDClass.Inicializar; begin if Inicializado then exit ; ApagaEVerifica( ArqTemp ); // Apagando Arquivo Temporario anterior // ApagaEVerifica( ArqReq ); // Apagando Arquivo de Requisicao anterior // ApagaEVerifica( ArqSTS ); // Apagando Arquivo de Status anterior // fpInicializado := True ; GravaLog( Name +' Inicializado' ); { Verificando se o arquivo de Resposta é invalido ou seja, gerado quando clica-se em 9 - CANCELAR sem selecionar nenhuma Bandeira } if FileExists( ArqResp ) then begin Resp.LeArquivo( ArqResp ); if UpperCase(Resp.Conteudo.LeInformacao(9,0).AsString) = 'FF' then ApagaEVerifica( ArqResp ); Resp.Clear; end ; CancelarTransacoesPendentesClass ; VerificaAtivo; end; A resposta do REDECARD: Ou seja, não tem FF na resposta do AMEX Não seria um BUG deles ??

Consegui reproduzir o problema... estou analisando...

Por favor envie o LOG gerado pelo G.P., geralmente fica na pasta C:\TEF_DIAL

Infelizmente não consigo instalar o simulador da AMEX no meu Windows 7 64... Tem algum novo link para download ?

Não estou compreendendo o que você que dizer... Se ele criou um ADM, já há uma transação pendente a ser processada... Por favor dê mais informações... Qual o Teste ? De qual roteiro ? Qual o Passo a passo para reprodução do problema usando o TEFDDemo ? Qual o Log do TEF dial ? Qual o Log do ACBrTEFD ?

Recompile os pacotes básicos do ACBr, como por exemplo a ACBrComum

Se o homologador desligou a aplicação antes dela exibir "Operação Cancelada" o fluxo está correto... temos uma transação pendente, que deve ser tratada no inicio da aplicação...