Rejeição 396: falta o ambiente no terceiro parâmetro do QR-Code

A Rejeição 396, regra ZX02-240, indica ausência do parâmetro de ambiente no QR-Code. Nas versões 2 e 3, ele ocupa a terceira posição depois de ?p=, tanto online quanto offline. O ambiente deve vir de ide/tpAmb da própria nota: 1 para produção e 2 para homologação.

Como reconhecer ausência de tpAmb?

Leia as posições separadas por | sem descartar posições vazias. A sequência conceitual começa por chave, versão e ambiente. Se a terceira posição não foi produzida, houve ausência; se contém 1 e a nota informa 2, há divergência, tratada pela ZX02-244/código 397.

Não deduza o ambiente apenas do domínio: uma UF pode usar o mesmo endereço para produção e homologação. Não substitua a falta por 1 como valor padrão. Confira a configuração que originou ide/tpAmb e a passagem desse valor ao gerador do QR-Code. A indicação do MOC de que o schema faz a verificação não transforma um conteúdo ausente em valor zero.

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: o XML da nota informa homologação, mas o serializador omite o argumento de ambiente. A leitura posicional revela falta no terceiro lugar. É preciso corrigir a passagem do valor 2 ao gerador, sem alterar o XML para produção.

Cenário sintético B: o terceiro parâmetro está preenchido com 1, enquanto ide/tpAmb permanece 2. Acrescentar outro valor não resolve: agora há uma divergência, e o diagnóstico é conferir a seleção da configuração e a regra 397/ZX02-244. Os cenários distinguem presença de coerência.

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

• MOC 7.0 Anexo I — 7.00: pp. 65–66 leiaute ZD/ZX; pp. 128–133 regras ZD/ZX.
• NT 2025.001 — 1.03 corrigida: pp. 2–3 cronograma; p. 5 transição; pp. 8,11–14 QR-Code e rasuras.
• Manual de Padrões Técnicos DANFE NFC-e e QR Code — 6.0, março/2025: p. 5 fim QR 1; pp. 20–27 QR 2; pp. 28–32 QR 3.
• NT 2026.002 — 1.11: p. 3 cronograma; pp. 20–24 regras ZX e alterações Tipo 2.
• NT 2026.004 CNPJ alfanumérico — 1.01: pp. 3–4 cronograma e alcance da atualização de tipos.