Rejeição 394: nota fiscal sem a informação do QR-Code

A Rejeição 394, regra ZX02-10, ocorre quando falta o campo qrCode exigido nas informações suplementares da nota. Na regra atual, a exigência alcança a NFC-e e a NF-e com DANFE Simplificado Tipo 2, tpImp=6. Ela trata o conteúdo do XML transmitido, não a qualidade da imagem impressa no papel.

Onde deve estar o QR-Code?

O texto da URL fica em NFe/infNFeSupl/qrCode, irmão de infNFe; em arquivo processado, acrescente nfeProc ao início. O namespace é http://www.portalfiscal.inf.br/nfe. Não procure o campo em infAdic, que contém informações adicionais com outra função.

O grupo também contém urlChave, URL da consulta por chave de acesso a imprimir no documento auxiliar. Esse campo não substitui qrCode: a consulta por chave e a consulta via QR-Code têm destinos e usos próprios. O texto completo de qrCode tem de 60 a 1000 caracteres no schema PL_010f_v1.04; uma imagem desenhada pela impressão não preenche esse elemento no XML.

Quais condições e exceções precisam ser preservadas?

A NT 2026.002 v1.11, página 20, descreve a regra para NFC-e ou NF-e com DANFE Simplificado Tipo 2, tpImp=6, e registra duas exceções: em produção, documento com emissão anterior a 01/04/2016; e NFF, tpEmis=3. Se o QR-Code não foi informado na exceção temporal, não se aplicam as demais validações relacionadas ao campo.

A NT prevê a atualização das regras do Tipo 2 com testes em 01/07/2026 e produção em 03/08/2026. A postergação para 14/12/2026 na v1.11 é específica de outras três regras listadas no cronograma; não deve ser transportada automaticamente à ZX02-10. O cronograma tampouco comprova a implantação de cada autorizador.

Não mude a data ou o tipo de emissão para obter uma exceção. Para uma nota comum atual, a integração deve gerar o campo conforme o modelo e a modalidade verdadeiros.

Exemplos: imagem presente e informação ausente

Cenário sintético A: a prévia de impressão mostra um QR-Code, mas o XML transmitido não contém infNFeSupl. A imagem foi gerada por uma rotina independente, e a 394 é compatível com a falta no arquivo enviado. Compare os dois fluxos e corrija a serialização, sem supor que reimprimir altera a autorização.

Cenário sintético B: o XML contém urlChave, mas não qrCode. O emissor usou a URL de consulta por chave como se fosse suficiente para o grupo. O diagnóstico é completar corretamente a geração das informações suplementares aplicáveis, e não renomear um campo para o outro.

Um XML operacional depende da chave real, do endereço oficial e, conforme a versão, do CSC/hash ou da assinatura do QR-Code. Por isso os exemplos são textuais e exigem a comparação do original protegido; não fornecem uma URL fiscal fabricada.

Como conferir a geração e a autorização?

Identifique modelo, tpImp, tpEmis, tpAmb, UF e data no documento efetivamente enviado. Confira a ausência de qrCode, a versão de URL selecionada e o schema aplicável. QR-Code 2 e 3 têm estruturas diferentes; adotar versão 3 não significa apenas substituir um algarismo na URL antiga.

Corrija a origem comprovada e valide a geração local. Preserve o arquivo anterior e o resultado fiscal. A inexistência de erro no schema ou a impressão legível não provam autorização. Se a tentativa teve retorno incerto, confirme seu estado antes de novo envio; documento autorizado não deve ser editado manualmente.

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.