Daniel Simoes

arielguareschi, Não consegui reproduzir o problema seguindo os passos... Porém notei que vc disse: Não seria o inverso ? Pois nesse caso o Cupom ainda está em meios de pagamento, ou seja, não foi finalizado...

Você poderia anexar no tópico todas as Units alteradas para eu comparar com os meus fontes ?

Notei que a modificação não afetou D7 e/ou Lazarus, portanto já subi para o SVN... obrigado pela correção

Acho que vc está usando um Memo simples ligado direto no ACBrECF, ao invés do Evento OnBobinaAdicionaLinhas, correto ? Use o evento que você terá mais controle...

Ou ainda chamar: ACBrTEFD1.FinalizarCupom; Que verificará o estado do documento e chamará os eventos necessários para Fechar o cupom, e tudo isso com o tratamento do TEF para desligamento ou falha de impressão...

No caso de Vinculado ou CDC eu salvo no BD a informação de: ACBrECF1.NumCDC No caso de ADM, será aberto um Relatório Gerencial... nesse caso salvando no BD: ACBrECF1.NumGRG

Lembre-se de que o ACBrTEFD exige que a propriedade ACBrECF.ReTentar seja igual a False

Você pode ler algumas informações da Transação efetuada, porém isso varia a cada Gerenciador TEF... Veja no Demo do ACBrTEFD a programação do evento: OnDepoisConfirmarTransacoes

Se não me engano o CNC é opcional para TEF discado... Não confunda cancelamento do TEF com cancelamento do Cupom... Para CNC ou cancelamento por ADM, o gerenciador TEF irá solicitar todos os dados da transação TEF, e imprimir um Relat.Gerencial com o comprovante de cancelamento

Qual TEF você está tentando homologar ? (discado) ? Já tentou rodar pelo Demo do ACBrTEFD ?

Guiuliano, A unica correção sugerida é a que está no post acima ? Em relação aos pontos levantados no inicio desse post, há mais alguma correção pendente nos fontes do SVN ?

Oi Giuliano, Qual é a versão do seu Delphi ?

Faz sentido... já que eles ganham por homologação... agora mais essa ainda..

Oi Juliomar, Subi suas correções para o SVN... muito obrigado

Tópico sobre o mesmo assunto com uma possível solução para o problema: viewtopic.php?f=10&t=5373

Tópico relacionado ao mesmo assunto com uma possível solução para o problema: www.djsystem.com.br/acbr/forum/viewtopi ... =10&t=5373

Acabei de subir... Já fiz uma mudança para que a leitura do GT e do Estado não se importassem com o erro de Fim de Papel, talvez seja necessário em outras propriedades tb...

Elton, Pela situação que você descreveu, o ACBrECF1.VendeItem foi aceito (sem exception) mas a leitura do GT foi barrada no Exception, certo ? Mas nesse caso, não haveria falha já no VendeItem ? Fiz uma ampla reforma no ACBrECF para introduzir introduzir um Exception específico de Fim de Papel (EACBrECFSemPapel), além de um Evento quando isso ocorrer (OnErrorSemPapel : TNotifyEvent )... Também adicionei uma propriedade publica ( IgnorarErroSemPapel ), que permitiria desabilitar a verificação desse erro. Ela deve ser Ligada antes de cada comando enviado, e é desligada após a execução do mesmo

Elton, Agora que me veio a mente... Se o ECF está com falha de papel.. ele não conseguirá Vender Item, certo ? Ou seja, não alteraria o Valor do GT...

pode ser um erro no mapeamento desse método nessa biblioteca... tente esse fórum: viewforum.php?f=19

copie o LOG do ACBrMonitor e do ACBrECF para analise

provavelmente é algo no sua programação... o estudo do LOG gerado pelo ACBrECF pode dar mais informações sobre o que foi realmente enviado para o ACBrECF e dele para o ECF

Parce ser uma limitação do Rave... fica dificil sabermos o que ele não gosta Uma dica seria deixar o RaveCB como padrão...

Teria que ser um Flag que ligamos antes de enviar o comando, e ele poderia se desligar após a execução do próximo comando... Se ele estiver ligado, a exceção de Fim de Papel não seria disparada...

E se usássemos um Try/Except quando o AAC tenta ler o GT ? Verificamos se a exceção é relacionada a Fim de Papel... Hum... resta saber se ele mesmo assim retornaria o GT atual...