Daniel Simoes

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

Apliquei suas modificações no SVN, obrigado pela colaboração

Subi uma nova versão para o Link:

É mais simples (e rápido) você ler o CRZ (contador de reduções Z)... e procurar por uma Redução Z eom ele no seu sistema... Se não houver... ai sim, vc lê os dados da última Redução Z

Notei nos fontes de ACBrECFDaruma.pas, que não estava implementado o método GetNumLoja Apliquei modificações no SVN com a implementação

Nos fontes atuais, do ACBrECFBematech.pas, já existe o procedimento de carregar e descarregar a DLL.... Isso ocorre sempre que o ACBr precisa chamá-la... Veja um trecho procedure TACBrECFBematech.FechaPortaSerialDLL(const OldAtivo: Boolean); begin GravaLog( ' xBematech_FI_FechaPortaSerial' ) ; xBematech_FI_FechaPortaSerial ; UnloadDLLFunctions; GravaLog( ' Ativar ACBr: '+ifthen(OldAtivo,'SIM','NAO') ) ; if OldAtivo then Ativo := OldAtivo; end;

Esse é o LOG do ACBrMonitor... precisamos analisar o Log gerado pelo ACBrECF (aba ECF)

Vou tentar achar um tempo (hoje) para compilar uma nova versão e subir para o site...

Por favor anexe o LOG

Veja esse post:

Cupom Adicional é uma aberração... não serve pra nada... Ele não é uma cópia do Cupom, apenas imprime o valor total do último cupom...

Jaime, Estou em analise sobre esse post... Homologamos NTK recentemente.. e não foi necessária nenhuma modificação... devemos ter uma resposta até amanhã

Isso é demonstrado no Projeto TEFDDemo, no evento: TForm1ACBrTEFD1AguardaResp

Essa exigência da mensagem "Transacao OK" ficar por 5 segundos na tela... nunca existiu para a CliSiTef... é algo novo, que apenas o pessoal da CERTIFIED está cobrando... Estamos em contato com eles... tentando explicar que isso não tem propósito no caso da CliSiTef pois: - Atualmente não há como saber se a Mensagem é a última que será enviada - Não há um "mapa" que determine quais os Tipos de mensagens devem permanecer por 5 seg - Não existe essa exigência em nenhum dos roteiros da Sw.Express ou Certified (isso era uma exigência do roteiro do TEF discado) Atualmente o pessoal da Certified está conversando com o pessoal da Sw.Express sobre essa "nova exigência"

Você está errando em algum ponto do seu fonte... Não há erro nesse ponto do componente, caso contrário isso impactaria todos os usuários do mesmo... Para simplificar... desabilite todas os GPs, e deixe Ativo apenas o correto... Vc pode fazer isso usando o ObjectInspector, mudando a propriedade "Habilitado" para False Você pode também, forçar o GP antes de chamar CRT, ADM, ATV, etc... ACBrTEFD1.GPAtual := gpCliSiTef;

Creio que o componente precise de ajustes... ele só faria isso, se AutoEfetuarPagamento estivesse ligado... e essa propriedade é incompatível com o Cielo Premia...

Geralmente isso é feito pelo programa do Fabricante.. pois a informação fica persistente na memória do ECF...

Estou adicionando propriedades de Margem no componente Extrato para Fortes... O ESCPos realmente parece precisar de muitos ajustes... a Bematech parece ter menos colunas, e não reconheceu o comando para geração de QRCode... talvez ela não seja compatível com esse tipo de Cod.Barras

Sim, está nos nossos planos... mas acho que ainda demoraria alguns meses...