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

Rejeição 396: falta a versão no segundo parâmetro do QR-Code

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-232, indica que a versão não foi informada no segundo parâmetro do QR-Code. A posição é a mesma nas modalidades online e offline. A versão do QR-Code é distinta da versão 4.00 do XML da NF-e/NFC-e: colocar 4.00 nessa posição não identifica QR-Code 2 ou 3.

Como distinguir versão ausente de versão divergente?

Leia a segunda posição separada por | depois de ?p=. A NT 2025.001 descreve as versões 2 e 3; a regra 398/ZX02-236 trata versão informada que diverge do previsto. A falta da posição é 396/ZX02-232. Não retire posições vazias antes da análise, pois isso desloca ambiente e demais conteúdos e pode mascarar a causa.

A versão deve corresponder à estrutura inteira da URL. QR-Code 2 usa identificador CSC e hash; QR-Code 3 online usa somente chave, versão e ambiente, e offline possui assinatura e identificação do destinatário nas posições próprias. Substituir 2 por 3 em uma sequência antiga não executa essa mudança de estrutura.

Na NF-e com DANFE Simplificado Tipo 2, a NT 2026.002 exige QR-Code 3; isso não autoriza trocar o modelo da nota nem o tipo de impressão apenas para escapar de uma rejeição. Confira o contexto documental verdadeiro.

O que muda entre QR-Code 2, QR-Code 3 e DANFE Tipo 2?

A NT 2025.001 v1.03 estendeu esta regra às versões 2 e 3. Na NFC-e, ambas usam os três primeiros parâmetros na mesma ordem: chave de acesso, versão e ambiente. A versão 2 acrescenta identificador do CSC e hash; em contingência também inclui dia, total e DigestValue. A versão 3 online fica nos três primeiros; na contingência acrescenta dia, total, tipo/identificação do destinatário e assinatura.

A adoção exclusiva do QR-Code 3 e a eliminação geral do CSC estão previstas para o futuro, sem data definida na NT. Não interprete sua disponibilidade como extinção automática do QR-Code 2. Para emitente pessoa física, confira também a regra específica ZX02-222; a opção documentada para pessoa jurídica não deve ser transportada a outro contexto.

A NT 2026.002 v1.11 amplia as regras ZX aos modelos 55/65 quando qrCode é informado. Para NF-e modelo 55, o QR-Code é versão 3 no DANFE Simplificado Tipo 2; a contingência offline tpEmis=9 está restrita a esse DANFE, tpImp=6. As alterações do Tipo 2 têm cronograma de homologação 01/07/2026 e produção 03/08/2026, distinto das três validações postergadas para 14/12/2026. Cronograma não comprova implantação individual.

Exemplos de diagnóstico deste parâmetro

Cenário sintético A: a integração passou a usar QR-Code 3, mas não encaminhou o argumento de versão ao montador da URL. Chave e ambiente estão disponíveis; a segunda posição fica vazia. O diagnóstico é completar o contrato do gerador e validar a estrutura da versão selecionada.

Cenário sintético B: a segunda posição contém 4.00 porque a aplicação reutilizou a versão do XML. Há valor informado, mas ele não corresponde à versão prevista do QR-Code. O problema não é ausência: compare 398/ZX02-236 e a origem desse parâmetro, sem alterar a versão do documento fiscal.

Como conferir o resultado sem alterar a identidade da nota?

Localize NFe/infNFeSupl/qrCode, no namespace http://www.portalfiscal.inf.br/nfe, e preserve seu texto exato. Compare o XML enviado, os dados da própria nota e a versão do gerador. Corrija a origem comprovada antes de produzir e validar a geração adequada; não edite uma nota autorizada.

O exemplo operacional exigiria a chave real e, conforme a versão, CSC, hash ou assinatura. Por isso são usados cenários textuais: a confirmação depende do original protegido, sem inventar identificador ou credencial. Aprovação no XSD não comprova autorização. Confira a resposta fiscal correspondente à mesma nota e ambiente; tentativa incerta deve ser esclarecida antes de considerar novo envio.

Fontes oficiais