ACBrECF não atualiza GT no AAC quando retorna "Fim de Papel"

[EMBarbosa]

Detectei a seguinte situação usando impressoras Bematech (no emulador também).

Quando estamos fazendo uma venda de um item e acaba o papel, o ACBrECF não consegue atualizar o AAC.

Isso acontece pois ao tentar puxar o GT, o ACBrECF apesar de receber o retorno correto, levanta uma exceção.

Assim o comando DoAtualizaGT não funciona.

Qual o problema disso? Se um usuário esquecer de trocar o papel, e ele acabar durante uma impressão do cupom, o ACBrAAC vai ficar diferente do valor do ECF. Normalmente, isso deveria travar o programa para vendas e etc...

A correção seria fazer o componente ignorar o sinal de SEM PAPEL, pelo menos durante o retorno do GT. Vocês podem ver como isso acontece se marcar o emulador como sem papel e tentar retornar o Grande Total.

Percebi que o código atual do TACBrECFBematech.EnviaComando_ECF já faz um tratamento similar:

  PediuStatus := ( cmd = #19 ) ; { quando pede Status nao deve disparar

                                   exceçao com erros "Pouco Papel" ou "Cupom Aberto" }[/code]


  Talvez pudéssemos fazer algo parecido para os comandos que são passados por causa do RetornaInfoECF?

[Daniel Simoes]

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...

[EMBarbosa]

Então, o retorno do comando está bom.

Mas se o TACBrECFBematech.EnviaComando_ECF levanta a exception, daí o valor recebido não é retornado.

Pelo que analisei aqui, isso acontece com todas as funções de retorno. Na verdade, mesmo pro comando 19 que mencionei anteriormente também é levantada a exception.

[Daniel Simoes]

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...

[Daniel Simoes]

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...

[Juliomar Marchetti]

Isso mesmo Daniel

Fora que tem a recomposição do GT, eu sei que tem que atender um requisito e dai ele é recomposto

e nesse caso ele poderia ocorrer recompondo o arquivo

[EMBarbosa]

O problema acontece que o flag/Sensor de fim de papel só é atualizado depois da venda do item. Deixa tentar colocar o algorítimo simplificado atual aqui:

-> ECF: Sensor marcando pouco papel mas ainda tem papel;

-> ACBrECF.VendeItem()

-> ECF: Sensor atualizado para FIM DE PAPEL

-> DoAtualizaGT -> ACBrECF.GetGrandeTotal ***EXCEPTION***

Outra coisa que precisa-se ver é que atualmente, pelo que testei, não se consegue retornar nenhuma leitura de variável enquanto está como FIM DE PAPEL. Por exemplo, só daria para recompor o GT depois de colocar o papel no ECF. Podem fazer o teste com o emulador, que acontece o mesmo com o ECF físico.

PS.: Só lembrando que isso é do ECF Bematech. Não testei com outros.

[Daniel Simoes]

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

[EMBarbosa]

Exatamente isso que acontece. Infelizmente não acontece a falha no vende item.

O ECF marca com FIM DE PAPEL só depois do VendeItem. Na verdade, isso só foi descoberto porque alguns clientes foram insistentes em continuar usando o papel até acabar e ele acabou justamente depois de uma venda de item.

Como pode ser testado, no entanto, isso prejudica qualquer leitura de variável que se tente fazer do ECF Bematech, visto que sempre é levantada a exception. Tudo bem, não fico imaginando alguém usando o ECF sem papel... mas...

Obrigado pela implementação. Vou testar e volto a postar.

[EMBarbosa]

Você vai subir pro SVN? Se quiser eu posso fazer alguns testes antes.

[Daniel Simoes]

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...

[EMBarbosa]

Daniel, já testei aqui e parece que o problema já não existe mais. No entanto, está dando um erro na compilação pelo Delphi do ACBrECFFiscNet.pas:

[DCC Error] ACBrECFFiscNET.pas(735): E1012 Constant expression violates subrange bounds

        if ( FiscNETResposta.CodRetorno in [ 7003, 7004, 15011 ] ) then

           DoOnErrorSemPapel

        else

           raise EACBrECFSemResposta.create(ErroMsg) ;[/code]




Isso acontece pois um conjunto no Delphi só aceita índices e valores até no máximo 255.

Teria que trocal por algo como:

[code]        if (FiscNETResposta.CodRetorno = 7003) or 

        (FiscNETResposta.CodRetorno = 7004) or

        (FiscNETResposta.CodRetorno = 15011 ) then

           DoOnErrorSemPapel

        else

           raise EACBrECFSemResposta.create(ErroMsg) ;

[Daniel Simoes]

Oi Elton...acabei de perceber quando testei no D7... já corrigi no SVN

[EMBarbosa]

Obrigado Daniel. Até agora está tudo perfeito.

[gobbo]

Aqui também tudo funcionando com esta nova atualização.

O erro no ECF com "FIM DE PAPEL" somente mostra a mensagem ao operador. Antes, na minha aplicação, isso resultava em mostrar a mensagem de erro e em "fechar a tela de venda", o que poderia ser constrangedor para o operador de caixa na frente do cliente.

Agora está perfeito.