Daniel Simoes

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

Acho que consegui reproduzir o problema... estou analisando...

Não estou compreendo... os pagamentos registrados no ECF tb tem que contemplar o Acréscimo... e um mata o outro... É possível reproduzir o problema usando o Demo do TEFD ? pode me fornecer um passo a passo ?

Por favor forneça um passo a passo usando o Demo do ACBrTEFD

Você programou o evento OnComandaECFSubtotaliza ? Se SIM, nele você deve somar o seu acréscimo quando for efetuar a SubTotalização. if Est = estNaoFiscal then ACBrECF1.SubtotalizaNaoFiscal( DescAcre + SeuAcrescimo, 'Projeto ACBr|http://acbr.sf.net' ) else ACBrECF1.SubtotalizaCupom( DescAcre + SeuAcrescimo, 'Projeto ACBr|http://acbr.sf.net' ); [/code]

Humm... perdoe-me... como os nomes dos métodos são parecidos, achei que eram do ACBrTEFD...

O ineSubTotal deve conter o Acréscimo... Qual o problema no Fechamento ? (Anexe o Log)

Não é melhor fazer ajustes nas Units do Projeto TI2TI ? O ideal é evitar mudanças nos fontes do ACBr, isso pode causar problemas quando for necessário atualiza-lo... E comprometer o funcionamento do componente

Tópico confuso... pelo que compreendi ele está em Loop no FinalizarCupom... verifique como você está informando o Estado do ECF para o componente... provavelmente você está informando errado Certifique-se se você está com a última versão dos fontes... Se o problema persistir, por favor adicione o LOG

Notei que o problema da não confirmação foi um bug introduzido na versão 3.3.0 do componente... Apliquei uma possível correção...

O Bug só ocorrerá em design, pois a Exception é tratada nos fontes... Para evitar que seu Delphi pare em erros como esse, desabilite "Stop On Delphi Exceptions" Por favor tente confirmar com a Sw.Express se isso é realmente um Bug reconhecido e se o formato será mantido... Podemos fazer uma correção, mas acho que é importante saber se eles irão corrigir ou se as versões anteriores igualmente retornam este campo neste formato

Oi Elton, Em qual situação poderiamos ter duas Reduções Z no mesmo dia ? Ela não deve se basear na Data de Movimento ? Em relação a modificação... agora é necessário liberar manualmente alguns Objetos ? eles não são eliminados quando o componente ACBrSintegra é destruído ou em LimparRegistros ?

Pelo que li dos fontes o protocolo é parecido com o da Toledo... Qual a principal diferença ? Há algum manual para deixarmos na pasta Tools ? https://acbr.svn.sourceforge.net/svnroot/acbr/tools/

Use o método "ATV"

Até onde sei, é importante deixar o dialeto do FireBird no mínimo em 3, caso contrário várias funcionalidades não são ativadas Acho que o ideal seria você ir migrando alguns módulos, uma tela de cadastro, um relatório, etc...quando estiver confiante, migre todo o sistema...

Você poderia tentar usar um aplicativo fornecido pelo Fabricante do ECF... por favor anexe o LOG para que eu possa verificar se o erro é "contornável"

Obrigado pelo FeedBack... Porque será que a Daruma já não deixa essa informação bem clara no manual da DLL ?

A regra é simples... Uma vez que o Total Pago seja igual ou superior ao SubTotal do Cupom novos pagamentos não serão aceitos...