Rejeição 315 — Data de Emissão anterior ao início da autorização de Nota Fiscal na UF

O que é esta rejeição?#

A Rejeição 315 é 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 dhEmi contém offset de fuso horário diferente de -03:00 (ou -04:00 em horário de verão) enquanto cUF do emitente corresponde a uma UF brasileira do fuso de Brasília, então a nota foi gerada com timezone incorreto que causa deslocamento artificial da data para fora da janela aceita pela SEFAZ: corrija o offset para o fuso oficial da UF emissora no momento da emissão, considerando vigência do horário de verão.
• Se dhSaiEnt é anterior a dhEmi em qualquer combinação de data e hora, mesmo que os campos isoladamente pareçam válidos, então há inversão cronológica entre emissão e saída que pode agravar a rejeição 315 ao sinalizar data de emissão inconsistente com o fluxo da operação: ajuste dhSaiEnt para valor igual ou posterior a dhEmi.
• Se tpEmis for diferente de 1 (contingência SCAN, SVC-AN, SVC-RS, DPEC, FS-DA ou FS-IA) e dhEmi diverge em mais de 30 minutos do horário atual do servidor de transmissão, e não existe campo dhCont preenchido justificando o intervalo, então a nota foi provavelmente gerada off-line sem controle de contingência registrado, tornando a data de emissão inelegível para autorização retroativa: registre a contingência corretamente com dhCont e justificativa xJust antes de retransmitir ou reemita com dhEmi atualizado.
• Se finNFe é igual a 2 (NF-e complementar) ou 4 (NF-e de devolução) e o grupo NFref está ausente ou vazio, enquanto dhEmi da nota referenciada não pode ser inferido para confirmar que a nota de origem era contemporânea à janela de autorização vigente, então a ausência do vínculo com a nota original impede a SEFAZ de validar a cadeia temporal da operação, podendo coexistir com a rejeição 315 como causa secundária: inclua o grupo NFref com chave de acesso da NF-e originária antes de reenviar.
• Se mod é 55, tpEmis é 1 (emissão normal, sem contingência) e a diferença absoluta entre dhEmi e o timestamp de envio ao webservice SEFAZ — inferível por dhRecbto do lote anterior ou por log de transmissão — excede 30 minutos, ao mesmo tempo em que cMunFG difere do cMun do emitente sugerindo operação interestadual com possível conflito de fuso, então o município do fato gerador registrado pode estar introduzindo um offset de fuso implícito que distorce a validação temporal na UF autorizadora: confirme que cMunFG reflete o local real da operação e que dhEmi foi gerado com o fuso correto desse município.