Daniel Simoes

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

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"