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

Rejeição 396: versã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-32, é aqui explicada no contexto histórico do QR-Code 1 (nVersao=100) da NFC-e, modelo 65. A ZX02-32 descrevia ausência do parâmetro de versão 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.

O que nVersao identificava no formato antigo?

O parâmetro nomeado nVersao identificava o leiaute do QR-Code e era representado como 100 na versão 1. Ele não era a versão do XML da NFC-e nem a versão do aplicativo emissor. O MOC indica verificação estrutural pelo schema.

Em um histórico de rejeição, examine a URL original para separar parâmetro não enviado de versão presente com valor diferente. Não preencha registros arquivados retroativamente: o texto original é evidência da tentativa e deve permanecer preservado.

A descrição “se QR-Code versão 100” delimita a família de regras antigas; não significa que uma URL sem versão esteja apta a ser classificada apenas por sua aparência. A estrutura com parâmetros nomeados, a data e a mensagem completa ajudam a reconstituir o contexto.

Exemplo de leitura de um registro legado

Um log legado conserva a URL com os parâmetros nomeados, mas sem nVersao. O cadastro do emissor dizia “versão 1”; isso não demonstra que a informação chegou ao XML. Comparar configuração e texto enviado revela a omissão de serialização.

Já uma URL que contém nVersao=100 e um retorno 396 apontando outro parâmetro não sustenta diagnóstico de versão ausente. O código se repete, e a descrição específica do retorno precisa orientar a leitura.

Como distinguir as versões atuais?

Nas versões 2 e 3, a versão ocupa a segunda posição depois de ?p=. A ausência é 396/ZX02-232; a versão informada divergente é 398/ZX02-236. A versão 4.00 do XML continua sendo outro dado.

A migração exige uma estrutura completa compatível. Trocar 100 por 2 ou 3 em uma URL com parâmetros nomeados não produz o formato atual. O artigo histórico explica o registro, sem orientar reaproveitamento dessa URL em novas notas.

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