Quem projeta m\u00f3dulos fiscais em software houses e precisa manter a recep\u00e7\u00e3o de documentos em dia conhece a rotina: o ERP faz a sincroniza\u00e7\u00e3o de entrada, mas o mesmo documento fiscal aparece duplicado na fila de processamento, gerando inconsist\u00eancias no estoque, lan\u00e7amento repetido no contas a pagar e escritura\u00e7\u00e3o distorcida no fechamento fiscal. Quando uma empresa recebe centenas de opera\u00e7\u00f5es di\u00e1rias, o volume de eventos e XMLs transitando por diferentes pontas transforma o processo de entrada em um ponto cr\u00edtico de falha se o sistema n\u00e3o possuir uma estrat\u00e9gia refinada de deduplica\u00e7\u00e3o de documento fiscal.<\/p>\n
A duplica\u00e7\u00e3o raramente tem como origem uma nota autorizada duas vezes de forma id\u00eantica pela administra\u00e7\u00e3o tribut\u00e1ria. De acordo com o Manual de Orienta\u00e7\u00e3o do Contribuinte, o MOC 7.0 da NF-e, a pr\u00f3pria SEFAZ aplica travas imediatas no momento da emiss\u00e3o por meio da Regra de Valida\u00e7\u00e3o 2B08-20, que devolve o cStat 204 para rejeitar qualquer documento cuja chave de acesso j\u00e1 conste na base fazend\u00e1ria. O problema de recep\u00e7\u00e3o repetida, portanto, ocorre nas etapas subsequentes, provocadas por consultas concorrentes no Web Service de distribui\u00e7\u00e3o, m\u00faltiplos canais de captura paralelos (como caixa postal de e-mail e mensageria direta) e atualiza\u00e7\u00f5es sucessivas do mesmo documento que trazem novos eventos atrelados.<\/p>\n
A abordagem prim\u00e1ria adotada pela maioria dos desenvolvedores consiste em definir a chave de acesso de 44 d\u00edgitos num\u00e9ricos como \u00edndice \u00fanico no banco de dados. Essa chave, estruturada conforme o MOC 7.0 com UF, ano e m\u00eas, CNPJ emitente, modelo, s\u00e9rie, n\u00famero, tipo de emiss\u00e3o, c\u00f3digo num\u00e9rico e d\u00edgito verificador, parece suficiente \u00e0 primeira vista, mas essa unicidade falha quando o sistema precisa lidar com o ciclo de vida completo do documento fiscal.<\/p>\n
A primeira fragilidade surge na distin\u00e7\u00e3o entre o resumo do documento e o documento completo. Segundo a Nota T\u00e9cnica 2014.002, que padroniza o Web Service NFeDistribuicaoDFe, a SEFAZ disponibiliza inicialmente ao destinat\u00e1rio um evento de resumo (resNFe) contendo apenas informa\u00e7\u00f5es b\u00e1sicas, como valor total, data de emiss\u00e3o e digest value. Se o sistema receptor registrar a chave de 44 d\u00edgitos como chave prim\u00e1ria estrita e rejeitar qualquer payload subsequente sob a mesma chave, ele bloqueia a posterior chegada do XML completo da NF-e (procNFe), que s\u00f3 \u00e9 liberado pela SEFAZ ap\u00f3s a manifesta\u00e7\u00e3o do destinat\u00e1rio. O sistema acaba armazenando apenas o resumo financeiro, ficando sem o arquivo XML completo com o detalhamento dos itens e a tributa\u00e7\u00e3o por produto.<\/p>\n
A segunda fragilidade envolve a concorr\u00eancia entre emiss\u00f5es normais e em conting\u00eancia. Conforme previsto no MOC 7.0, a Regra de Valida\u00e7\u00e3o 2B08-10 gera o cStat 539 para rejei\u00e7\u00e3o por duplicidade com diferen\u00e7a na chave de acesso quando h\u00e1 coincid\u00eancia de CNPJ emitente, modelo, s\u00e9rie e n\u00famero, mas altera\u00e7\u00e3o no c\u00f3digo num\u00e9rico (cNF) ou no tipo de emiss\u00e3o. Se o fornecedor tentou emitir em conting\u00eancia e depois transmitiu a nota normal, ou vice-versa, o ERP receptor pode receber dois arquivos com chaves de 44 d\u00edgitos distintas para a mesm\u00edssima opera\u00e7\u00e3o mercantil, gerando duplicidade f\u00edsica nos cadastros internos mesmo com chaves tribut\u00e1rias diferentes.<\/p>\n
A consulta de documentos fiscais por destinat\u00e1rios opera de forma sequencial baseada no N\u00famero Sequencial \u00danico (NSU). Conforme estipula a Nota T\u00e9cnica 2014.002, cada consulta ao m\u00e9todo de distribui\u00e7\u00e3o pode retornar lotes de at\u00e9 50 documentos por requisi\u00e7\u00e3o. O que muitos desenvolvedores n\u00e3o preveem \u00e9 que o mesmo documento fiscal pode gerar m\u00faltiplos registros com NSUs distintos ao longo do tempo. Toda vez que uma carta de corre\u00e7\u00e3o eletr\u00f4nica \u00e9 registrada, um cancelamento \u00e9 homologado ou o destinat\u00e1rio registra um evento de manifesta\u00e7\u00e3o, a SEFAZ cria um novo NSU com aquele evento espec\u00edfico apontando para a mesma chave de acesso.<\/p>\n
Quando o software de mensageria n\u00e3o separa a camada de controle de NSU da camada de persist\u00eancia mercantil, cada novo NSU recebido \u00e9 interpretado como um novo documento a ser gravado, multiplicando a nota fiscal nas tabelas operacionais. Existe tamb\u00e9m a regra de neg\u00f3cio sobre a frequ\u00eancia de requisi\u00e7\u00e3o: conforme determina a Nota T\u00e9cnica 2014.002, quando a consulta retorna o cStat 137 indicando que n\u00e3o h\u00e1 novos documentos localizados, o sistema integrado deve aguardar obrigatoriamente o intervalo de 60 minutos antes de disparar nova requisi\u00e7\u00e3o com o mesmo NSU, sob pena de bloqueio tempor\u00e1rio do CNPJ pela SEFAZ por consumo indevido atrav\u00e9s do cStat 656.<\/p>\n
Aliado a isso, h\u00e1 o limite de cust\u00f3dia da pr\u00f3pria SEFAZ. De acordo com a Nota T\u00e9cnica 2014.002, os documentos fiscais eletr\u00f4nicos e seus resumos ficam dispon\u00edveis no Ambiente Nacional apenas pelo prazo de 90 dias a contar de sua recep\u00e7\u00e3o pela autoridade tribut\u00e1ria. Caso a software house ou a empresa destinat\u00e1ria enfrente instabilidades e permane\u00e7a mais de 60 dias sem realizar requisi\u00e7\u00f5es ao Web Service, a gera\u00e7\u00e3o de novos NSUs para aquele contribuinte entra em suspens\u00e3o, voltando a responder apenas ap\u00f3s o envio de uma nova solicita\u00e7\u00e3o.<\/p>\n
Para evitar lan\u00e7amentos repetidos sem impedir a chegada de atualiza\u00e7\u00f5es leg\u00edtimas, a software house precisa adotar uma estrutura de persist\u00eancia baseada em chave composta, desmembrando a chegada f\u00edsica do arquivo da grava\u00e7\u00e3o cont\u00e1bil do documento. Sistemas voltados \u00e0 gest\u00e3o e mensageria de DF-e, a exemplo do e-Malote, utilizam crit\u00e9rios estruturados de recep\u00e7\u00e3o para garantir que o fluxo de entrada conviva harmoniosamente com o reposit\u00f3rio fiscal do ERP.<\/p>\n
Uma arquitetura consistente de deduplica\u00e7\u00e3o deve considerar tr\u00eas eixos fundamentais:<\/p>\n
Al\u00e9m da estrutura\u00e7\u00e3o no banco de dados, o processo deve gerenciar o canal concorrente. Muitas empresas recebem o XML por e-mail enviado diretamente pelo fornecedor e, minutos depois, puxam o mesmo arquivo via Web Service de distribui\u00e7\u00e3o da SEFAZ. A rotina de ingest\u00e3o precisa checar a exist\u00eancia do digest value contido na assinatura digital do XML: se o hash do arquivo for id\u00eantico e o protocolo de autoriza\u00e7\u00e3o conferir com o registro j\u00e1 integrado, o segundo arquivo deve ser marcado como r\u00e9plica de mensageria e arquivado na cust\u00f3dia de seguran\u00e7a sem disparar os gatilhos de valida\u00e7\u00e3o do ERP.<\/p>\n
Para garantir que esse ciclo n\u00e3o seja descontinuado por prazos operacionais, o destinat\u00e1rio tamb\u00e9m deve observar as regras de valida\u00e7\u00e3o legal. Conforme o Ajuste SINIEF n\u00ba 07\/2005, atualizado pelo Ajuste SINIEF n\u00ba 43\/2023, o destinat\u00e1rio tem o prazo limite de 180 dias contados a partir da data de autoriza\u00e7\u00e3o da NF-e para efetuar a manifesta\u00e7\u00e3o conclusiva, como a Confirma\u00e7\u00e3o da Opera\u00e7\u00e3o, a Opera\u00e7\u00e3o n\u00e3o Realizada ou o Desconhecimento da Opera\u00e7\u00e3o. Implementar o ciclo completo de deduplica\u00e7\u00e3o protege a empresa contra erros operacionais e cumpre integralmente os requisitos normativos do SPED.<\/p>\n
Por que a SEFAZ autoriza notas com chaves diferentes para a mesma venda?<\/strong> O que causa o bloqueio por consumo indevido (cStat 656) no Web Service de distribui\u00e7\u00e3o?<\/strong> Qual a diferen\u00e7a entre deduplicar pelo hash do XML e pela chave de acesso?<\/strong> At\u00e9 quando um documento fiscal pode ser recuperado via Web Service pelo destinat\u00e1rio?<\/strong>
A SEFAZ n\u00e3o autoriza duas notas id\u00eanticas, mas quando o emissor inicia a gera\u00e7\u00e3o em conting\u00eancia e depois emite em modo normal devido a falhas de conex\u00e3o, os documentos ganham c\u00f3digos num\u00e9ricos (cNF) ou tipos de emiss\u00e3o distintos, gerando chaves de 44 d\u00edgitos diferentes para a mesma nota que podem passar nas travas b\u00e1sicas do ERP se o sistema n\u00e3o validar os campos CNPJ, s\u00e9rie e n\u00famero.<\/p>\n
O bloqueio ocorre quando o sistema continua consultando o Web Service repetidamente ap\u00f3s receber o retorno cStat 137, sem respeitar o intervalo obrigat\u00f3rio de 60 minutos determinado pela Nota T\u00e9cnica 2014.002.<\/p>\n
A chave de acesso identifica o documento tribut\u00e1rio formalmente, enquanto o hash (digest value) valida a integridade exata daquele arquivo espec\u00edfico assinado. Deduplicar pelo hash impede que c\u00f3pias id\u00eanticas vindas de canais diferentes (como e-mail e distribui\u00e7\u00e3o SEFAZ) sejam processadas duas vezes, mas n\u00e3o substitui a valida\u00e7\u00e3o dos campos fiscais.<\/p>\n
Segundo a Nota T\u00e9cnica 2014.002, os documentos fiscais eletr\u00f4nicos e resumos ficam dispon\u00edveis no Ambiente Nacional da SEFAZ para distribui\u00e7\u00e3o pelo prazo de 90 dias a partir da sua recep\u00e7\u00e3o.<\/p>\n
\n