Rejeição 394: como verificar a falta do QR Code no XML

A rejeição 394 significa que o autorizador não recebeu o campo de QR Code exigido para aquele documento. A solução começa pelo arquivo transmitido: ter uma imagem de QR no DANFE ou um endereço cadastrado no sistema não prova que o campo qrCode foi incluído no XML final.

O cenário abrange a NFC-e modelo 65 e, conforme a NT 2026.002, a NF-e modelo 55 com DANFE Simplificado Tipo 2, tpImp=6. Antes de preencher o que falta, confirme modelo, ambiente, forma de emissão e versão do QR. Uma configuração correta para outro cenário pode continuar produzindo um arquivo inadequado.

O que falta quando a SEFAZ retorna 394

O campo qrCode pertence ao grupo infNFeSupl, de informações suplementares. Ele guarda o texto usado para gerar o QR de consulta. Já urlChave informa o endereço de consulta por chave de acesso e tem validações próprias. Preencher somente urlChave não substitui qrCode.

A regra de referência é ZX02-10. O identificador ZX02-10 organiza o manual técnico; 394 é o código de resultado da autorização. Se o problema apareceu após alguém ler o QR pelo celular, confirme primeiro a origem da mensagem: a consulta pública utiliza sua própria tabela de validações e não deve ser diagnosticada apenas pela coincidência de números. MOC 7.0, página 128

O efeito dessa resposta é rejeição. Para encerrar a ocorrência, será necessário receber e conferir a autorização após a correção; a existência de um DANFE gerado pelo programa não cumpre essa etapa.

Quando a exigência se aplica

Na NT 2026.002 v1.11, ZX02-10 alcança NFC-e e NF-e com Tipo 2. A regra preserva duas exceções: documentos com emissão anterior a 01/04/2016, em produção, e Nota Fiscal Fácil, identificada por tpEmis=3-NFF. A observação histórica também explica que, sem QR, as demais validações relacionadas ao campo não se aplicam naquele processamento. Isso não dispensa o QR de uma emissão atual comum. NT 2026.002 v1.11, página 20

Essas exceções devem corresponder aos fatos. Não se deve mudar a data ou selecionar NFF artificialmente para escapar da validação. Tampouco a exigência específica de Tipo 2 significa que toda NF-e, independentemente do formato de impressão, recebe o mesmo tratamento.

O cronograma documental do bloco ZX prevê testes em 01/07/2026 e produção em 03/08/2026. A mudança para 14/12/2026 da versão 1.11 refere-se a I08-180, BA02-35 e VC02-40. Ela não adia em bloco as exigências de QR. A implementação efetiva deve ser confirmada no ambiente da UF.

Um roteiro para localizar a falha

1. Separe o XML efetivamente enviado e seu retorno, com data, UF e ambiente. Evite comparar a rejeição com uma prévia ou com um arquivo gerado em outra tentativa

2. Confira mod, tpImp e tpEmis. Esses campos orientam se o QR é exigido e como deve ser formado

3. Verifique se infNFeSupl contém qrCode com conteúdo válido. Um grupo vazio, um campo sem conteúdo ou um endereço apenas na configuração não resolvem a ausência

4. Confira se o fluxo de geração do emissor foi concluído. Certos componentes montam o QR em uma etapa específica; uma integração pode ter enviado o XML antes dela

5. Ajuste o cadastro ou a rotina responsável e gere novamente o documento. Valide o XML final antes de retransmitir

Imagine um caixa hipotético que imprime o QR a partir de dados internos, mas envia um XML anterior à inclusão de infNFeSupl. Melhorar a qualidade da impressão não corrige 394. É necessário fazer o arquivo transmitido receber o conteúdo exigido.

A Tecnospeed descreve a geração do campo no fluxo de assinatura de seu componente. A Oobj informa que o preenchimento é automático em sua aplicação. São pistas para revisar a integração correspondente; não significam que todos os programas funcionam da mesma maneira.

Escolha o leiaute certo antes de gerar o conteúdo

Para NFC-e, a NT 2025.001 v1.03 documenta QR v2 e v3 e deixa a adoção exclusiva de v3 para o futuro, sem data definida. Para NF-e Tipo 2, a NT 2026.002 exige v3; a versão inadequada tem validação específica associada a 672.

Na v3 normal, os parâmetros são chave de acesso, versão e ambiente. Na v3 offline, entram também dia de emissão, valor total, tipo e identificação do destinatário conforme seu preenchimento aplicável e assinatura. Dia e total não devem ser acrescentados ao QR normal como se fossem obrigatórios em qualquer emissão. Na NF-e, a contingência offline tpEmis=9 está vinculada ao Tipo 2.

CSC, hash e DigestValue pertencem a outros tratamentos do leiaute, especialmente exemplos de v2, e não devem ser transportados para v3. O fato de uma tabela geral mencionar essas validações não modifica a composição da versão 3. NT 2025.001 v1.03, seção 04

O Bling orienta conferir CSC e seu identificador no cadastro em seu procedimento publicado. Essa pode ser uma causa de falta de geração no fluxo correspondente de v2; não é diagnóstico universal de 394 e não justifica cadastrar CSC para montar um QR v3.

Endereço, ambiente e conferência final

Use o endereço oficial da própria UF, para o ambiente e a versão aplicáveis. Na NF-e Tipo 2, a NT 2026.002 determina a mesma URL de consulta QR usada pela NFC-e daquela UF. Isso não autoriza copiar um endereço de outro estado ou transformar o endereço do Web Service de autorização em URL de consulta.

Depois de corrigir a ausência, podem aparecer problemas antes não avaliados: URL divergente, parâmetro ausente ou informação incompatível com a nota. Trate o novo retorno especificamente, sem acrescentar campos aleatórios até a mensagem mudar.

Finalize conferindo autorização, arquivo armazenado e leitura do QR no DANFE correto. Mantenha testes separados para normal e offline, homologação e produção, e preserve dados de clientes e credenciais quando acionar suporte.

Base documental: consulta em 10/10/2026 e PDFs oficiais preservados em 09/10/2026. Exemplos antigos de fornecedores servem para entender o defeito, não como modelos prontos de URL, dados fiscais ou versão atual.