Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 396 · Regra ZX02-60

Rejeição 396: data de emissão ausente no QR-Code 1 (histórico)

Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.

A Rejeição 396, regra ZX02-60, é aqui explicada no contexto histórico do QR-Code 1 (nVersao=100) da NFC-e, modelo 65. A ZX02-60 apontava ausência do parâmetro dhEmi no QR-Code 100. Esse leiaute foi desativado em produção em 01/10/2018; a orientação abaixo serve à leitura de arquivos e retornos legados, sem apresentar essa regra como validação ativa de notas novas.

Qual é a vigência desta regra histórica?

O encerramento em produção está documentado no Manual DANFE NFC-e/QR-Code 6.0, página 5. O MOC 7.0 conserva a tabela da versão 100, e a NT 2025.001 v1.03 mantém sua descrição de preenchimento na página 14 ao lado das versões 2 e 3. Essa coexistência documental e a presença de um padrão legado no schema não demonstram reativação da versão 1 nem aceitação fiscal atual.

Para investigar uma mensagem recebida hoje, confira a versão real da URL, o parâmetro citado no retorno, a data da tentativa e o ambiente. O mesmo código numérico aparece em regras diferentes. Não converta automaticamente esta identidade histórica em uma regra de QR-Code 2 ou 3.

A data já existente no XML bastava para a URL?

Não. A regra histórica examinava a presença de dhEmi no QR-Code 100, separadamente da data-hora em ide/dhEmi, campo B09. O MOC registra que o schema fazia a verificação. O fato de a nota possuir data-hora não demonstrava que o gerador a havia representado na URL.

Na descrição histórica de preenchimento, a data-hora era representada em hexadecimal. A falta do parâmetro é diferente de formato não hexadecimal, regra 400/ZX02-64, e de valor que diverge da nota, regra 397/ZX02-68.

Para um retorno arquivado, conserve essas três perguntas: o parâmetro existe, sua representação corresponde ao formato histórico e seu conteúdo corresponde à data-hora da mesma nota? Mudar a data de emissão não é uma forma de diagnosticar omissão na geração.

Exemplo de leitura de um registro legado

Um registro legado mostra ide/dhEmi completo, mas a URL preservada não contém o parâmetro nomeado dhEmi. A hipótese técnica a investigar é a perda do argumento no montador da URL, não ausência de data na operação.

Se a URL possui dhEmi preenchido com uma data legível em texto, a informação não está ausente. O problema passa a ser representação, e o código 400/ZX02-64 deve ser distinguido da 396/ZX02-60. Nenhum dos cenários exige alterar retroativamente o arquivo assinado.

Como distinguir as versões atuais?

QR-Code 2 e 3 online não incluem data de emissão na sequência de parâmetros. Na modalidade offline, as versões atuais utilizam somente o dia da data de emissão na quarta posição, com regras 396/ZX02-260 e 397/ZX02-268.

Portanto, não há uma obrigação atual de copiar o dhEmi completo e hexadecimal da versão 1 para qualquer QR-Code. O leitor de um retorno recente deve reconhecer a modalidade verdadeira antes de interpretar a ausência de data na URL.

Como preservar a evidência e encerrar o diagnóstico?

Preserve o XML e o retorno originais, identifique a nota e compare somente os dados da mesma tentativa. A URL histórica é encontrada em NFe/infNFeSupl/qrCode, no namespace http://www.portalfiscal.inf.br/nfe; em arquivo processado, o caminho começa por nfeProc. A leitura do original deve ocorrer com acesso autorizado.

Se o emissor está gerando formato antigo, diagnostique a integração e o leiaute aplicável, preservando os dados verdadeiros e o resultado fiscal anterior. Não modifique documento autorizado nem reenvie uma tentativa incerta.

Não é apresentado XML operacional: a conferência fiel exige a chave, os dados e, conforme o parâmetro, a assinatura ou a credencial protegida da tentativa. Os cenários são textuais e não fabricam identificadores, CSC ou hashes. Conformidade no schema e consulta legível do QR-Code não equivalem à autorização da nota.

Fontes oficiais