Daniel Simoes

Analise o LOG, sua resposta de "ineSubTotal" deveria já estar subtraída do que já foi pago no ECF...

Cielo Premia é obrigatório... você não conseguirá homologar se não dar suporte a ele....

Por que você está imprimindo as Formas de Pagamento de Cartão ? geralmente o próprio componente que fará isso... e como eu disse antes, você não pode imprimir os pagamentos ou subtotalizar o cupom até ter o total dos pagamentos... isso porque qualquer uma das transações TEF podem conter Descontos do Cielo Premia, que devem ser aplicados na Subtotalização do cupom

teria que ser um Panel ou Form, seguido Application.ProcessMessages, e você desliga-lo no final da chamada do método... quando o controle passa para DLL, não temos mais como interagir

Não compreendi... você chama ACBrECF1.SubtotalizaCupom 2 vezes ?? além do mais, de acordo com o Cielo Premia, você não pode subtotalizar o cupom até ter todos os pagamentos definidos (em buffer)

Mas nos seus testes você está chamando SubTotalizar, antes do CRT... isso é incompatível com o Cielo Premia

DadosUltimaReducaoZ é bem mais limitada do que DadosReducaoZ .... e o conteúdo do Retorno pode variar, pois é "mapeado" apenas o que o ECF retorna, o que pode variar de um Modelo para outro

viewtopic.php?f=10&t=4588&hilit=argox+usb search.php?keywords=argox+usb&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Pesquisar

Você não detalhou como estão as propriedades (checkbox): AutoEfetuarPagamento, AutoFinalizarCupom, MultiplosCartoes Notas: Não precisa chamar ATV antes de CRT, o próprio componente faz isso (veja o LOG) AutoEfetuarPagamento é incompatível com o CieloPremia SubTotalizar antes de terminar todos os pagamentos é incompatível com CieloPremia

Para que eu possa investigar, forneça um passo a passo sobre como reproduzir o problema no Demo do ACBrTEFD

O problema é como você informa para o componente em "ineSubtotal" e "ineTotalAPagar"... Por favor estude detalhadamente o Demo... Notei que aparentemente você não está "buferizando" os pagamentos... isso não permitirá a implementação de Cielo Premia... leia as mudanças no ACBrTEFD-Change-Log.txt

Tópico movido para área pública, pois a mudança pode afetar todos usuários...

Acabei de enviar uma correção para o SVN... Ela obrigará a atualização da DLL da Bematech, pois torna o método incompatível com a versão antiga

Não consegui compreender a sua sequencia... Por favor descreva um passo a passo usando o Demo do ACBrTEFD, mas especifique tudo, valores, ECF, índices usados, etc...

Provavelmente você está informando o Índice da FPG errado quando chama o método ACBrTEFD.CRT

Ela retorna sozinha... Não lembro de existir comando para forçar o retorno... Se a sua impressora não está retornando... tente fazer um "reset" no equipamento

Vou baixar as novas DLLs e ajustar o ACBrECFBematech.pas

Nesse caso poderia inserir um exception (traduzindo o erro apresentado); Acho que fica bom... Não, o loop ocorre nas classes filhas; Mas o evento precisa ocorrer a cada Loop ?

Experimente mover a atual para outra pasta e atualizar novamente...

Pelo visto sua Unit AcbrUtil.pás esta desatualizada...

Caramba... quantas linhas esses caras acham que cabe no rodapé do Cupom... Será que eles sabem que o mesmo é limitado em 8 linhas ?

Algumas perguntas: Em ACBrECFNaoFiscal.pas... Por que precisamos proteger o método "Reset" em uma exceção muda ? Se ele falhar, o arquivo não será aberto, certo ? ou seja, o restante do código não funcionaria A chamada aos eventos criados para a CAT52 deveria ser aplicada em ACBrECF.pas, e não em cada classe filha... A propriedade Status não existiria em todos ECFs, na maioria o Status é enviado na composição do Frame do protocolo... Se a ideia é agilizar o tempo TimeOut...porque não reduzir o mesmo ? Isso poderia ser feito dentro da classe da Bematech... tente mudar em: try { espera ACK chegar na Porta por 4s } try fsACK := fpDevice.Serial.RecvByte( 4000 ) ; except end ; [/code]

Acabei de fazer um teste com o Demo do ACBrTEFD e tudo foi impresso corretamente... Verifique se seus fontes estão realmente atualizados... Pode ser que alguma unit sua esteja em conflito com a do SVN e por isso não tenha sido atualizada... (Se for o caso, renomeie a Unit e baixe do SVN novamente)

O problema começou com a versão 4.1.7, onde inseri o mapeamento para as propriedades da Resposta: DataHoraTransacaoLocal, DataHoraTransacaoCancelada, NSUTransacaoCancelada Estive analisando um arquivo de Log de alguns clientes meus... e notei que o campo 026 (DataHoraTransacaoCancelada) está correto... Será que o bug foi introduzido na última versão do G.P. ?

Enviei para o SVN modificações para o projeto Demo... Agora é possível informar Desconto ou Acréscimo do usuário no painel de pagamentos... Acho que o segredo era "zerar" o DescontoAcrescimo do usuário após a execução do evento OnComandaECFSubtotaliza, conforme descrevi nos fontes do Demo