EMBarbosa

Se conseguir resolver, dê um retorno por favor.

Então não é separado por venda como eu perguntei.

Não poderia separar as vendas em itens da nota?

Esse erro existe realmente. Foi mencionado na QC (Quality Central) sob o número 7089. veja o link: http://qc.embarcadero.com/wc/qcmain.aspx?d=7089 Nos comentários você encontra um patch e sugestões para correção. Mas eu particularmente não sei se funciona. Talvez precise alguns ajustes. Finalmente, e mais importante. Fuja do BDE o quanto antes. Ele foi tornado deprecated em 2002!! Se quiser utilizar algo parecido passe para dbExpress como foi sugerido nessa época, nesse artigo aqui.

Sem problemas Guilherme. Na verdade eu já tinha vontade de fazer isso há algum tempo. Mas infelizmente, essa a correria é bem generalizada.

Pronto, aqui pelos meus testes está tudo bem.

Também adicionei parte dessas sugestões na revisão 3427 para as Classes ACBrECF, ACBrECFClass e ACBrECFBematech. Vou tentar fazer para as outras impressoras também.

Obrigado Daniel. Até agora está tudo perfeito.

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) ;

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

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.

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

Acho que corrigi agora. Revisão 3414. Favor verificar se era isso mesmo.

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.

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?

Olá, Obrigado pelo report. Corrigi na revisão 3412. Favor testar.

Valeu pelo retorno. Isso é NFe certo?

Tenho uma dúvida paralela aqui. Que emulador antigo você estava usando?

Também conhecida como CNIEECF.

É que já há outros tópicos explicando o motivo disso. Se você atualizou mesmo o código, então você está enganado em pensar que não está ajustado. O contrário é o que acontece. O PVA 1.0.7 é que não está apto a validar. Veja por favor:

Só sei que dá pra validar conferindo nessa lista. Se existe outra maneira, eu desconheço. Talvez outro usuário saiba.

Parabéns. Quando puder, vá lá nesse post:

Como é que 5,050 * 3,20 está sendo calculado como 16,15? Não tem nem sentido! Acho que seu software está enviando um valor um pouco diferente para o ECF. Por exemplo: Se fosse 5,0499999 *3.20 daria algo como 16,1599968 e aí sim faria sentido. Sugiro partir sua verificação daí.

Chegou a pesquisar esse assunto aqui no fórum?

Chegou a pesquisar aqui no fórum?