Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 400 · Regra ZX02-64

Rejeição 400: formato hexadecimal da data 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 400, regra ZX02-64, é aqui explicada no contexto histórico do QR-Code 1 (nVersao=100) da NFC-e, modelo 65. A regra histórica verificava se dhEmi no QR-Code 100 usava caracteres hexadecimais 0–9, a–f, A–F. 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.

Formato válido provava que a data estava correta?

Não. A ZX02-64 tratava o formato do parâmetro de data-hora no QR-Code 100. O MOC descreve os caracteres admitidos: 0-9, a-f e A-F, e informa verificação pelo schema. Data em formato legível comum, separadores ou outros caracteres não correspondiam a essa representação histórica.

Uma sequência de caracteres hexadecimais podia, ainda assim, representar uma data-hora diferente da nota. Essa comparação era 397/ZX02-68. Omissão era 396/ZX02-60. São verificações distintas de presença, formato e conteúdo.

O campo ide/dhEmi do XML não deve ser convertido em hexadecimal por causa desta mensagem: a transformação histórica dizia respeito ao parâmetro da URL. Alterar o campo da nota para o formato da URL confundiria duas representações com funções diferentes.

Exemplo de leitura de um registro legado

Em um registro histórico sintético, a data-hora foi passada em texto diretamente ao parâmetro da URL, sem a transformação prevista. O original permite identificar o erro de representação. A leitura não demonstra que a data-hora verdadeira estivesse errada.

Em outro arquivo, o parâmetro só contém caracteres hexadecimais, mas a comparação de seu conteúdo com ide/dhEmi revela horário diferente. Esse segundo caso não é confirmado como erro de formato pela 400: requer o exame da divergência histórica.

Como distinguir as versões atuais?

Na emissão offline das versões 2 e 3, a quarta posição contém o dia com dois algarismos, como documentado pelo Manual 6; no modelo online, esse parâmetro não existe. Não se exige hexadecimal para esse dia.

Assim, aplicar o diagnóstico 400/ZX02-64 a uma sequência atual apenas porque seu dia está em decimal seria incorreto. A regra antiga só pode explicar a representação da versão 100 em um registro legado.

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