Rejeição 569 — Data de entrada em contingência muito atrasada
Motivo da rejeição
Data de entrada em contingência muito atrasada
O que é esta rejeição?#
A Rejeição 569 é 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.
Este código indica que rejeição: Data de entrada em contingência muito atrasada.
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:
| Campo | XPath no XML | Descrição |
|---|---|---|
| dhEmi | NFe/infNFe/ide/dhEmi | Data e hora de emissão |
| dhSaiEnt | NFe/infNFe/ide/dhSaiEnt | Data e hora de saída/entrada |
| tpAmb | NFe/infNFe/ide/tpAmb | Tipo de ambiente (1=Produção, 2=Homologação) |
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#
- Ajuste a data/hora de emissão para o momento atual, dentro do prazo aceito pela SEFAZ
- Use o formato correto com fuso horário: AAAA-MM-DDThh:mm:ss-03:00 (horário de Brasília)
- Verifique se o relógio do servidor/computador emissor está sincronizado (use NTP)
- A SEFAZ geralmente aceita NF-e com até 30 minutos de diferença do horário do servidor
Verificações analíticas#
- Se tpEmis for diferente de 1 (ou seja, contingência: 2, 3, 4, 5, 6 ou 7) e dhCont estiver ausente ou vazia, então a data de entrada em contingência é obrigatória para emissões fora do modo normal e sua ausência impede a validação do prazo pelo servidor SEFAZ: preencha dhCont com a data/hora exata em que o sistema entrou em contingência, no formato AAAA-MM-DDThh:mm:ss-03:00.
- Se tpEmis indicar contingência (valores 2 a 7) e o intervalo entre dhCont e dhEmi for superior a 30 minutos ou dhCont for posterior a dhEmi, então há inconsistência temporal entre o momento declarado de entrada em contingência e a emissão da nota, o que gera a rejeição 569: garanta que dhCont seja anterior ou igual a dhEmi e que ambas estejam dentro do prazo aceito pela SEFAZ.
- Se dhSaiEnt estiver preenchida e for anterior a dhEmi em qualquer cenário de contingência (tpEmis ≠ 1), então a data de saída/entrada de mercadoria antecede logicamente a própria emissão da nota, criando conflito temporal que agrava a rejeição: ajuste dhSaiEnt para ser igual ou posterior a dhEmi, respeitando a cronologia real da operação.
- Se o offset de fuso horário presente em dhEmi, dhSaiEnt ou dhCont não corresponder ao UTC-03:00 (ou UTC-04:00 no horário de verão conforme a UF do emitente em cUF), então o horário absoluto transmitido à SEFAZ difere do horário local real podendo ultrapassar o limite de tolerância de transmissão: padronize todos os campos de data/hora com o offset correto da UF emissora no momento da emissão.
- Se tpEmis indicar EPEC (valor 4) ou SVC (valores 5 ou 6) e o campo xJust estiver ausente, com menos de 15 caracteres ou com conteúdo genérico, então a justificativa de contingência é inválida ou insuficiente, o que compromete a aceitação do documento na retransmissão ao ambiente normal: preencha xJust com descrição clara e específica do motivo técnico que forçou a contingência, com no mínimo 15 caracteres significativos.
Consulte IEs e CNPJs antes de emitir NF-e
Muitas rejeições acontecem por dados cadastrais desatualizados. Com a FiscalAPI, consulte Inscrições Estaduais e CNPJs em tempo real direto da SEFAZ e Receita Federal.
Criar conta →