Daniel Simoes

No discado algumas informações são retornadas... Acho que a Rede (010-000) e Tipo de Transação (011-00) são, retornados... Veja o Demo do ACBrTEFD para saber como ler esses valores em: procedure TForm1.ACBrTEFD1DepoisConfirmarTransacoes Veja o manual do Pay&Go 1 - (PGWPP - Interface com a Automacão Comercial - ) ou o manual do Gerenciador Padrão, para saber todos os campos retornados pelo TEF O componente ACBrTEFD tenta "mapear" rodos os campos retornados, em propriedades, para facilitar a recuperação dos valores... Veja: procedure TACBrTEFDRespTXT.ConteudoToProperty; da unit ACBrTEFDClass.pas lendo ela dá pra compreender quais campos retornados pelo TEF são salvos nos propriedades

Não sei... me parece um Bug da Sweda... Eles deveriam considerar todas as casas decimais existentes... senão, fatalmente o resultado é afetado... Tentou entrar em contato com o Fabricante ?

Muito provavelmente porque o ECF não retornou a data... Analise o Log gerado pelos ACBrECF

Atualize seus fontes novamente, já foi corrigido

Por favor detalhe melhor o problema...

Se deseja correção é só anexar os fontes modificados para a analise...

Se não me engano já existe método para envio de e-mails no ACBrBoleto... ACBrBoleto1.EnviarEmail(); Porém, sugiro ver o Demo do ACBrMail... Assim você poderá criar uma rotina genérica para envio de e-mails no seu sistema

O Correto é 21,37 Na ACBrUtil.pas, temos o método RoundABNT(const AValue: Double; const Digits: SmallInt): Double; No cabeçalho desse métodos tem links com a explicação da lógica. http://www.sofazquemsabe.com/2011/01/como-fazer-arredondamento-da-numeracao.html http://partners.bematech.com.br/2011/12/edicao-98-entendendo-o-truncamento-e-arredondamento-no-ecf/ Você usou a classe ecfSwedaSTX ?

Por favor não poste varias vezes o mesmo tópico: Leia as Regras do Fórum

Eu tenho trabalhado apenas no Demo em Lazarus... Pode ser que comparando os fontes de Lazarus e Delphi você consiga encontrar o problema e corrigi-lo...

Quando há alguma chamada as funções *_DLL... é a DLL do fabricante que assume o comando... Parece que o problema inicia nesse ponto... e quando a DLL libera o controle da Serial pro ACBr, o ECF está ainda retornando dados do comando de leitura da MFD... ( RX <- [233][208]||t{{zx|td{zx|td{zx|td{zx|td{z ) Veja no Log da DLL da Bematech qual foi o erro na chamada a esse comando.

Acho que o mais simples, seria programar novas formas de pagamento sem os caracteres acentuados... Isso sempre causa dificuldades... Mas veja que o seu erro é outro: Provavelmente essas formas de pagamento foram programadas SEM a possibilidade de associar um vinculado a elas... Isso pode ser comprovado pela existência da letra "V" ao lado delas na Leitura X.... Nesse caso, você realmente precisa programar novas formas de pagamento...

Não creio que seja algo que seja possível de ser "corrigido" do nosso lado... Como você disse... parece ser um problema do driver...

Já testou verificar se é ago que ocorre apenas nessa máquina, ou com esse ECF ?? Veja: Centenas de programadores usam a Classe da Bematech como ela está hoje...

Corrigido no SVN...

Provavelmente seus fontes ou versão do ACBrMonitor estão desatualizadas... Esse comando já existe nos fontes do ACBrMonitor: else if Cmd.Metodo = 'datahoraultimareducaoz' then Cmd.Resposta := FormatDateTime('dd/mm/yy hh:nn:ss', DataHoraUltimaReducaoZ )

CAPICOM ??? O ACBrECF não usa nada de CAPICOM... E Sim, está implementado: function TACBrECFDaruma.GetDataHoraUltimaReducaoZ : TDateTime ; var RetCmd : String ; begin if fpMFD then begin RetCmd := RetornaInfoECF('154'); Result := StringToDateTime( copy(RetCmd, 1,2) + DateSeparator + copy(RetCmd, 3,2) + DateSeparator + copy(RetCmd, 5,4) + ' ' + copy(RetCmd, 9,2) + TimeSeparator + copy(RetCmd,11,2) + TimeSeparator + copy(RetCmd,13,2), 'dd/mm/yyyy hh:nn:ss' ) ; end else Result := 0; end ;

ACBrECF.DataHoraUltimaReducaoZ

Já está no SVN, a chamada a CompareValue, com o Delta ou Epsilon, definido, com 0.01

Notei que você está usando algumas características incompatível com o Cielo Premia - AutoFinalizarCupom, e AbreVendeSubtotaliza Com o Cielo premia, você não deve subtotalizar o cupom antes de obter a resposta do CRT, pois ele pode vir com desconto...

Analisei com calma os fontes de ACBrTEFDClass.pas, e realmente estava confuso, e com propensão a erro no calculo da 2a via... Apliquei algumas modificações nos fontes do SVN, favor atualizar e testar...

Atualmente, a CERTIFIED, empresa que é responsável pela homologação da bandeira CIELO, está fazendo uma exigência confusa para o CliSiTEF... Eles solicitam para o Programador, que a mensagem de aprovação como por exemplo: "TRANSACAO OK" ou "APROVADO", permaneçam na tela por pelo menos 5 segundos... A solicitação faz sentido, porém é importante lembrar, que no caso de uso da CliSiTef, quem comanda as mensagens para a aplicação, é a própria CliSiTef32.dll Ou seja, ela envia os comandos 1, 2 ou 3 quando deseja enviar mensagens para a tela do Operador ou Cliente. O problema ocorre em algumas transações apenas... notei o problema na transação de débito... O mesmo ocorre, porque a CliSiTef, após exibir a mensagem "TRANSACAO OK", rapidamente envia um comando para limpar a mensagem e na sequencia envia a mensagem "Retire o Cartão" Conclusão, o problema, está na CliSiTef, e o que a CERTIFIED está nos solicitando, é que nós, modifiquemos o comportamento da CliSiTef. Veja esse tópico para uma melhor compreensão: Entrei em contato com a CERTIFIED e com a Sw.Express... e após várias trocas de e-mail, com vários envolvidos... a Sw.Express apresentou uma configuração para a CliSiTef.ini que pode resolver o problema... Habilitando a chave: [Geral] IdentificaMensagens=1 O SiTEF passa a devolver "Tipos" para as mensagens enviadas... e a mensagem de confirmação, pode ser achada com o Tipo 5005 Portanto... de posse dessa informação, apliquei as seguintes modificações no SVN

Você SEMPRE precisa entrar em contato com a homologadora... afinal são eles que fazem os testes e fornecem o laudo de homologação...

Jaime, Seus fontes estão atualizados corretamente ? Você fez modificações nos fontes do componente ? Na dúvida... apague a pasta do ACBrTEFD e baixe tudo novamente... Veja: Nenhum outro usuário está reportando problemas com esse teste... e vários já reportaram que homologaram com sucesso... Pode ser que o Pay&Go retorne uma resposta errada (e não prevista) quando não está corretamente configurado ou em uma versão antiga... Mesmo após as instruções da Juliana, você ainda sim, não obteve o comportamento esperado ?

Elton, Obrigado pela ótima explicação... modifiquei a Unit ACBrTEFDClass.pas para fazer uso do método CompareValue