Rejeição 573 — Duplicidade de Evento

O que é esta rejeição?#

A Rejeição 573 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a número sequencial da NF-e, série de numeração da NF-e. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Duplicidade de Evento.

Os campos afetados estão na seção de chave de acesso, dados do emitente, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• Uma NF-e com o mesmo número, série e CNPJ do emitente já foi autorizada pela SEFAZ
• Houve reenvio acidental de uma NF-e que já foi processada com sucesso
• Falha de comunicação fez com que a resposta de autorização não chegasse, levando ao reenvio
• O sistema emissor está gerando numeração duplicada por erro de configuração

Como resolver#

1. Consulte a situação da NF-e pela chave de acesso — se já está autorizada, utilize-a normalmente
2. Se a NF-e original foi autorizada mas a resposta não chegou, faça uma consulta de protocolo
3. Caso precise emitir uma nova nota, utilize o próximo número sequencial disponível na série
4. Revise a configuração de numeração automática do seu sistema emissor para evitar duplicidades

Verificações analíticas#

• Se o campo nNF do XML reenviado é idêntico ao nNF de uma NF-e já autorizada para o mesmo CNPJ emitente (emit/CNPJ) e mesma série (serie), mas o campo dhEmi do reenvio é posterior ao dhRecbto do protocolo original, então o sistema emissor gerou uma segunda nota com numeração já consumida após confirmação de autorização: incremente nNF para o próximo número sequencial disponível e verifique o controle de numeração no banco de dados do emissor.
• Se tpEmis indica emissão em contingência (valores 2, 3, 4, 5, 6 ou 7) e o intervalo entre dhEmi e dhSaiEnt supera 24 horas sem que haja registro de transmissão do evento de cancelamento ou de autorização de uso do DPEC/SVC, então a nota contingente pode ter sido retransmitida fora do prazo regulatório gerando duplicidade com uma versão já autorizada pela SEFAZ de contingência: consulte a chave de acesso na SEFAZ de origem e na SEFAZ de contingência antes de qualquer reenvio.
• Se o campo chNFe calculado a partir de cUF, AAMM de dhEmi, CNPJ, mod, serie, nNF, tpEmis e cNF já retorna protocolo de autorização em uma consulta à SEFAZ (cStat 100), mas o sistema continua reenviando o mesmo XML sem alteração de cNF ou de nNF, então o algoritmo de geração do código numérico aleatório (cNF) não está sendo renovado a cada tentativa, perpetuando a chave duplicada: force a geração de novo cNF aleatório de 8 dígitos e recalcule o cDV antes de qualquer nova transmissão.
• Se finNFe é igual a 1 (NF-e normal) e o par (nNF, serie, CNPJ) duplicado possui valores de vNF, dhEmi e destinatário (dest/CNPJ ou dest/CPF) idênticos ao da nota já autorizada, então a duplicidade não é resultado de erro de numeração mas de reenvio automático por timeout sem consulta prévia de protocolo: implemente verificação obrigatória de consulta pelo número do protocolo (nProt) antes de qualquer retransmissão no fluxo de envio.
• Se o XML reenviado apresenta alteração em qualquer campo de conteúdo (ex.: vProd, qCom, xNome do destinatário) em relação à nota já autorizada com a mesma chave, mas mantém nNF, serie e CNPJ emitente inalterados, então houve tentativa de reemissão com dados corrigidos sobre um número já consumido, configurando adulteração de numeração fiscal: cancele a NF-e original caso ainda dentro do prazo (evento 110111), emita nota com nNF seguinte e, se aplicável, referencie a nota cancelada via NFref no grupo de notas referenciadas.