nfce Emissão duplicada de NFC-e sem chave de acesso

[Ana Laura]

Olá a todos! 

Nas últimas semanas, nosso PDV em Delphi 10.3 (ACBr JEDI Firebird) apresenta um comportamento de emissão NFC-e sem chave de acesso no banco de dados. Ao investigar, percebemos que o sistema clona a última NFC-e emitida — sem motivo aparente — incrementa o número (nNF), monta um novo XML e tenta reenviá-la, mas nunca grava o campo <chNFe> no Firebird.

1. Fluxo atual de emissão:

   • O sistema dispara a NFC-e ao servidor da SEFAZ e aguarda retorno.

   • Se não recebe resposta (timeout, instabilidade de rede, etc.), exibe mensagem ao operador: reenviar ou não.

   • Na próxima venda, em vez de gerar uma NFC-e nova do zero, o PDV reaproveita o objeto pendente, apenas incrementando nNF e reenviando o XML.

   • O resultado é uma duplicata sem <chNFe> no BD e sem seu respectivo arquivo XML.

2. Comportamento imprevisível:

   • A ocorrência dessa emissão sem chave de acesso é aleatória e está se manifestando de forma não determinística, não há padrão aparente de quando isso acontece.

3. Observação adicional:

   • Em um dos casos, encontramos uma NFC-e sem chave registrada no BD, mas o XML autorizado, com <chNFe> e <nProt>, estava presente na pasta de emissão do Windows. Ou seja, gerou e salvou o arquivo corretamente, mas o sistema não atualizou o registro no Firebird.

Como vocês tratam situações em que uma NFC-e fica pendente e, de forma aleatória, é reaproveitada pelo sistema em vendas subsequentes, gerando duplicidade sem <chNFe> no banco? Que mecanismos ou controles vocês utilizam para:

1. Isolar ou bloquear automaticamente NFC-e em status “pendente de retorno”, de modo que não possam ser reaproveitadas em novas vendas?

2. Garantir que, assim que a NFC-e seja autorizada (cStat 100/150), seu <chNFe> e <nProt> sejam gravados imediatamente no banco, evitando inconsistências?

3. Implementar fluxos de contingência (tpEmis = teOffLine) ou consultas assíncronas automáticas, de forma que não existam notas “presas” no sistema sem atualização de status?

Agradeço imensamente por qualquer exemplo de trigger/gerador no Firebird, trecho de código Delphi/ACBr ou estratégia de fluxo que ajude a resolver esse comportamento aleatório de duplicidade e inconsistência de chave de acesso.

[William F. L.]

Aqui temos o seguinte fluxo de envio, não é 100% pois sempre somos surpreendidos com alguma novidade, mas no geral atende muito bem.

AUTORIZAÇÃO DA NFC-e

-> Ocorrem erros que mapeamos como Timeout:

- essa NFC-e é gravada como "PENDENTE" no banco de dados junto com o XML e fica travada

- operador recebe um aviso em tela que houve um erro ao enviar a NFC-e

- é habilitado envio OFFLINE das NFC-e

- o sistema duplica a NFC-e, sobe a numeração e envia como "OFFLINE" 

- imprime 2 vias do extrato

- existe uma flag no sistema "Emitir Online Automaticamente", se houver internet na próxima venda o sistema tenta autorizar direto a NFC-e, senão joga como OFFLINE

 

Á partir disso temos um monitor de NFC-e que fica monitorando NFC-e "OFFLINE" e "PENDENTE"

OFFLINE -> o monitor só envia e protocola a autorização no XML

PENDENTE -> aqui a coisa complica um pouco:

1 - monitor primeiro consulta se essa chave já existe na SEFAZ se existir ele cancela "por substituição" passando o número da NFC-e que foi gerada em contingência

2 - se a chave ainda não existir na SEFAZ ele automaticamente solicita a inutilização dessa numeração pendente

Editado 12 Maio, 2025 por William F. L.

[Juliomar Marchetti]

4 horas atrás, Ana Laura disse:

Olá a todos! 

Nas últimas semanas, nosso PDV em Delphi 10.3 (ACBr JEDI Firebird) apresenta um comportamento de emissão NFC-e sem chave de acesso no banco de dados. Ao investigar, percebemos que o sistema clona a última NFC-e emitida — sem motivo aparente — incrementa o número (nNF), monta um novo XML e tenta reenviá-la, mas nunca grava o campo <chNFe> no Firebird.

1. Fluxo atual de emissão:

   • O sistema dispara a NFC-e ao servidor da SEFAZ e aguarda retorno.

   • Se não recebe resposta (timeout, instabilidade de rede, etc.), exibe mensagem ao operador: reenviar ou não.

   • Na próxima venda, em vez de gerar uma NFC-e nova do zero, o PDV reaproveita o objeto pendente, apenas incrementando nNF e reenviando o XML.

   • O resultado é uma duplicata sem <chNFe> no BD e sem seu respectivo arquivo XML.

2. Comportamento imprevisível:

   • A ocorrência dessa emissão sem chave de acesso é aleatória e está se manifestando de forma não determinística, não há padrão aparente de quando isso acontece.

3. Observação adicional:

   • Em um dos casos, encontramos uma NFC-e sem chave registrada no BD, mas o XML autorizado, com <chNFe> e <nProt>, estava presente na pasta de emissão do Windows. Ou seja, gerou e salvou o arquivo corretamente, mas o sistema não atualizou o registro no Firebird.

Como vocês tratam situações em que uma NFC-e fica pendente e, de forma aleatória, é reaproveitada pelo sistema em vendas subsequentes, gerando duplicidade sem <chNFe> no banco? Que mecanismos ou controles vocês utilizam para:

1. Isolar ou bloquear automaticamente NFC-e em status “pendente de retorno”, de modo que não possam ser reaproveitadas em novas vendas?

2. Garantir que, assim que a NFC-e seja autorizada (cStat 100/150), seu <chNFe> e <nProt> sejam gravados imediatamente no banco, evitando inconsistências?

3. Implementar fluxos de contingência (tpEmis = teOffLine) ou consultas assíncronas automáticas, de forma que não existam notas “presas” no sistema sem atualização de status?

Agradeço imensamente por qualquer exemplo de trigger/gerador no Firebird, trecho de código Delphi/ACBr ou estratégia de fluxo que ajude a resolver esse comportamento aleatório de duplicidade e inconsistência de chave de acesso.

um cuidado que se deve ter é não misturar questão de registro de dados no banco da venda com a emissão do documento, pois ai tu só precisa ter isso bem separado em seu sistema e baseado em seus controles isso não deve acontecer.

sempre faça. registro da venda no banco. após pegar os dados e dai em seu processo preencher o componente para emissão. gerar o xml, assinar, validar,  efetue a consulta pois assim evita duplicidade e já sabe se tá funcionand ou não para emitir offline ou não. senão após faz a emissão. e pega o retorno e trata. conforme o cStat

se ocorrer timeout e demais. tu grava já as informações e se repetir o processo e o mesmo foi autorizado ele vai atualizar os dado e pronto sua emissão senão vai para o proximo