Ir para conteúdo
  • Cadastre-se

Ana Laura

Membros
  • Total de ítens

    1
  • Registro em

  • Última visita

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

Ana Laura's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter
  • One Month Later
  • Week One Done

Recent Badges

0

Reputação

  1. 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. 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. 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. 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: Isolar ou bloquear automaticamente NFC-e em status “pendente de retorno”, de modo que não possam ser reaproveitadas em novas vendas? Garantir que, assim que a NFC-e seja autorizada (cStat 100/150), seu <chNFe> e <nProt> sejam gravados imediatamente no banco, evitando inconsistências? 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.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...