Rejeição 398: versão informada no QR-Code divergente

A Rejeição 398, regra ZX02-236, verifica o parâmetro de versão informado na URL do QR-Code. No leiaute posicional, ele é o segundo parâmetro, tanto na emissão online quanto offline. O texto antigo limitado ao valor 2 precisa ser lido com as alterações oficiais que também contemplam a versão 3.

Nesta página: Versão do QR-Code não é versão do XML · NFC-e, Tipo 2 e transição · Exemplos sem chave ou assinatura inventada · Como confirmar a causa e o resultado

Versão do QR-Code não é versão do XML

A URL está em NFe/infNFeSupl/qrCode, fora de infNFe. Na sequência posicional, o primeiro parâmetro é a chave de acesso, o segundo é a versão do QR-Code e o terceiro é o ambiente. Uma integração que coloca “4.00”, versão do XML da NF-e, no segundo parâmetro confunde dois contratos diferentes.

O Manual DANFE NFC-e/QR-Code 6.0, pp. 21–22, define 2 para QR 2 online e offline. Nas pp. 29–30, define 3 para QR 3. A NT 2025.001 v1.03 corrigida, p. 12, atualiza ZX02-236 para versões 2 ou 3. Essa aceitação na linha não é permissão universal: outras regras e o contexto documental também delimitam a versão aplicável.

NFC-e, Tipo 2 e transição

A NT 2026.002 v1.11, p. 21, apresenta a ZX02-236 para 55/65, com versão 2 ou 3 e segundo parâmetro. Para NF-e 55, contingência offline tpEmis=9 só é admitida no DANFE Simplificado Tipo 2, tpImp=6. A mesma NT, p. 20, tem regra específica ZX02-220, código 672, exigindo QR 3 nesse tipo de NF-e. Não conclua que QR 2 seja permitido no Tipo 2 apenas por constar na linha geral da 398.

A NT 2025.001, p. 5, registra eliminação futura do CSC sem data definida, no contexto da adoção exclusiva de QR 3. Isso não desativa genericamente QR 2 nem permite simplesmente trocar o número 2 por 3 em uma URL antiga. As composições e controles de autenticação são diferentes. Regras específicas de emitente CPF e UF precisam ser verificadas separadamente, sem inferir dispensa pela 398.

Exemplos sem chave ou assinatura inventada

Em um cenário sintético, o gerador monta uma URL posicional, mas põe a versão do XML no lugar da versão do QR-Code. Leia a cadeia original e compare a segunda posição com o leiaute adotado. Em outro, a configuração mudou para QR3, porém conserva parâmetros e hash do QR2. Alterar só o segundo campo não produz um QR 3 coerente.

Um XML sintético não comprova chave, CSC, hash nem assinatura do QR-Code original. Por isso, os exemplos são comparações textuais, sem credenciais ou chave inventadas. Use o XML original protegido e a configuração da versão para conferir posição, separadores e composição. Não publique a URL completa se ela expuser dados desnecessários.

Como confirmar a causa e o resultado

Confirme código 398, regra/contexto, modelo, ambiente, tpImp, tpEmis e versão adotada. Preserve a URL enviada antes de qualquer transformação de escape. Compare a segunda posição com o manual e a composição correspondente; não renumere os demais campos nem reconstrua chaves por tentativa.

A 396/ZX02-232 trata do parâmetro de versão ausente; a 398 trata do valor divergente. A 397/ZX02-244 compara ambiente, outro parâmetro. O código 398 isolado também não identifica todo contexto histórico do QR-Code; observe a regra e a mensagem reais.

A atualização Tipo 2 da ZX02-236 está no bloco de homologação em 01/07/2026 e produção em 03/08/2026, conforme a p. 3 da NT 2026.002. O adiamento de três outras regras para 14/12/2026 não é seu cronograma. Corrija o gerador segundo o contexto confirmado, gere a tentativa rejeitada novamente e confira a resposta individual. Preserve documento autorizado e esclareça resultado anterior incerto antes de um novo envio.

Fontes oficiais

• MOC 7.0 — Anexo I: p. 131 ZX02-236 contexto QR 2 original.
• NT 2025.001 v1.03 corrigida: pp. 2–3 cronograma; p. 5 transição CSC; pp. 11–12 ZX02-222/236.
• Manual DANFE NFC-e e QR-Code 6.0: pp. 21–22 segundo parâmetro QR 2; pp. 29–30 segundo parâmetro QR 3.
• NT 2026.002 v1.11: pp. 3,20–21 ZX02-220/236 e cronograma Tipo 2.