Rejeição 322 — NF de produtor referenciada com data de emissão inválida

O que é esta rejeição?#

A Rejeição 322 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a data e hora de emissão do documento fiscal, informação do documento fiscal. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Os campos afetados estão na seção de 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#

• A data/hora de emissão está fora do prazo permitido pela SEFAZ
• O fuso horário informado está incorreto (deve seguir o padrão UTC com offset, ex: -03:00)
• A data de emissão é futura ou muito antiga em relação ao momento da transmissão
• A data de saída/entrada é anterior à data de emissão

Como resolver#

1. Ajuste a data/hora de emissão para o momento atual, dentro do prazo aceito pela SEFAZ
2. Use o formato correto com fuso horário: AAAA-MM-DDThh:mm:ss-03:00 (horário de Brasília)
3. Verifique se o relógio do servidor/computador emissor está sincronizado (use NTP)
4. A SEFAZ geralmente aceita NF-e com até 30 minutos de diferença do horário do servidor

Verificações analíticas#

• Se dhSaiEnt < dhEmi (data de saída/entrada for anterior à data de emissão na NFref referenciada) então a sequência temporal da operação está invertida, indicando que a nota de produtor referenciada possui datas inconsistentes entre si: corrija dhSaiEnt para que seja igual ou posterior a dhEmi na nota referenciada.
• Se tpEmis = 2, 3, 4, 5, 6 ou 7 (contingência) e dhEmi registrada na NFref referenciada corresponder ao período de contingência sem que haja um evento de registro de saída de contingência (nfeProc/procEventoNFe) com dhRegEvento dentro da janela de 30 minutos aceita pela SEFAZ então a data de emissão em contingência pode estar deslocada do horário oficial: emita evento de EPECou CCe corrigindo o horário e referencie a nota com dhEmi já regularizada.
• Se o offset de fuso horário em dhEmi da NFref (ex: -04:00 em horário de verão sem vigência oficial ou +00:00 indicando UTC puro) divergir do offset esperado para a UF do emitente (cUF) conforme tabela de fusos brasileiros então a data pode ser interpretada pela SEFAZ como futura ou excessivamente antiga ao ser convertida para UTC: padronize o offset para -03:00 (Brasília) ou -04:00 apenas durante vigência oficial de horário de verão, confirmando o cUF do emitente.
• Se dhEmi da NFref referenciada, convertida para UTC, apresentar diferença superior a 30 minutos em relação ao dhRecbto do lote de transmissão (campo retornado pela SEFAZ no nfeProc) então o relógio do servidor emissor estava dessincronizado no momento da geração da nota de produtor: sincronize o servidor via NTP (pool.ntp.br) e regere a NFref com dhEmi atualizado antes de referenciar na NF-e.
• Se finNFe = 1 (nota normal) e o XML contém NFref com tpNF = 0 (entrada) enquanto o CFOP do item referenciado indica operação de saída (CFOP iniciado em 5 ou 6) então além da data inválida pode haver inconsistência de tpNF vs CFOP na nota referenciada que agrava a rejeição 322: valide que tpNF da NFref seja coerente com o CFOP declarado e que dhEmi esteja dentro do prazo antes de retransmitir.