Rejeição 393: confira quando o grupo de informações suplementares é indevido

Uma resposta de autorização com cStat 393 indica que o autorizador recusou a presença do grupo de informações suplementares naquele documento. Antes de mandar o sistema apagar esse grupo, confira o modelo, o tipo de impressão e a versão técnica utilizada. A orientação antiga de que nenhuma NF-e modelo 55 poderia ter QR Code precisa ser lida com cuidado: a NF-e com DANFE Simplificado Tipo 2 tem tratamento próprio para esse conteúdo.

Este artigo explica a rejeição no serviço de autorização de NF-e/NFC-e. O número da resposta, a identificação da regra no manual e as mensagens da consulta pública são coisas diferentes. Aqui, a referência documental de origem é ZX01-10; ela não precisa aparecer literalmente no retorno do sistema.

O que a regra original verificava

No MOC 7.0, a regra ZX01-10 associa o código 393 à presença de parâmetros suplementares na NF-e modelo 55. O grupo é infNFeSupl, que contém informações usadas na consulta do documento, como qrCode e urlChave. Essa é a base da orientação tradicional para remover um grupo acrescentado indevidamente pelo emissor. MOC 7.0, página 128

Não confunda esse grupo com as informações adicionais de texto livre. infAdic, infCpl e infAdFisco têm outras funções. Apagar observações comerciais ou fiscais para tentar resolver 393 pode eliminar informações úteis sem atingir o problema. O diagnóstico precisa localizar a estrutura efetivamente enviada, não apenas uma seção com nome parecido na tela.

Também não basta observar o papel impresso. O XML transmitido pode conter um grupo que o DANFE não mostra, ou a impressão pode usar um modelo de documento diferente do arquivo enviado.

O que mudou para a NF-e com DANFE Tipo 2

A NT 2026.002 v1.11 inclui, na regra ZX02-10, a exigência de QR Code para NFC-e e para NF-e com DANFE Simplificado Tipo 2, identificado por tpImp=6, observadas as exceções da regra: NFF com tpEmis=3 e emissão anterior a 01/04/2016, em produção. Para o modelo 55, o QR deve ser versão 3; a verificação específica consta de ZX02-220 e está associada à rejeição 672. Portanto, retirar infNFeSupl de uma NF-e Tipo 2 pode trocar um problema por outro. NT 2026.002 v1.11, página 20

Há uma limitação importante na documentação consultada: essa NT menciona ZX01-10 no cronograma, mas não apresenta uma nova linha completa dessa regra na seção ZX. Isso não permite afirmar que 393 desapareceu, nem reconstruir por conta própria uma proibição atual para todos os formatos de NF-e.

A NT 2026.010 v1.00 confirma que o grupo já está previsto em hipóteses do modelo 55 e anuncia alteração técnica específica para os demais formatos, inclusive retrato e paisagem. Esse anúncio não libera automaticamente o preenchimento em qualquer tpImp. NT 2026.010, item 4.5

Como investigar o retorno sem mudar a operação

Separe uma cópia do XML rejeitado e do retorno correspondente. Registre a data, a UF, o ambiente e a versão do emissor. Em seguida:

1. Confira mod. Uma operação configurada como NF-e deve estar coerente com o modelo 55 em todo o fluxo, incluindo a geração do arquivo e sua transmissão

2. Leia tpImp. O valor 6 merece o tratamento de DANFE Simplificado Tipo 2, não uma rotina genérica que elimina QR de toda NF-e

3. Identifique infNFeSupl no XML final. Verifique se uma configuração compartilhada com o caixa ou com a NFC-e acrescentou o grupo indevidamente

4. Compare a configuração com a documentação aplicável ao autorizador e à data da emissão. Se houver conflito com o tratamento de Tipo 2, peça análise da versão do componente antes de excluir campos

5. Faça a correção na origem do arquivo. Uma edição manual isolada pode ser desfeita quando o sistema montar novamente o XML

Considere um exemplo hipotético: uma empresa atualiza seu sistema de vendas e passa a gerar o mesmo bloco suplementar em documentos de modelos diferentes. Se o suporte confirmar que ele foi inserido indevidamente na NF-e do cenário efetivo, a correção é ajustar essa geração. Se a operação usa legitimamente Tipo 2, o caminho é investigar a compatibilidade do emissor e do autorizador, preservando o QR exigido.

Não altere modelo, UF, ambiente ou tipo de impressão apenas para conseguir uma resposta diferente. Esses campos devem representar o documento e a operação reais.

Versão do QR e contingência também importam

Na NFC-e modelo 65, a NT 2025.001 v1.03 documenta as versões 2 e 3. A adoção exclusiva da versão 3 é anunciada para o futuro, sem data definida. Esse cenário não afasta a exigência específica de v3 para a NF-e Tipo 2.

Na versão 3, a emissão normal usa chave de acesso, versão e ambiente. A contingência offline acrescenta dia, valor total, identificação do destinatário conforme as regras próprias e assinatura. Não se deve inserir CSC, hash ou DigestValue como parâmetros v3 porque aparecem em exemplos de outra versão. Para modelo 55, tpEmis=9 está documentado no contexto de Tipo 2. NT 2025.001 v1.03, seção 04

Como encerrar e prevenir a ocorrência

Depois do ajuste, confira o novo arquivo e a resposta de autorização. O desaparecimento de 393, sozinho, não comprova que o documento foi autorizado: outra rejeição pode surgir. Guarde os registros de antes e depois e valide também o DANFE correspondente. Se houver dúvida sobre uma tentativa anterior, consulte sua situação antes de repetir a emissão.

Os materiais de VINCO, Invoisys e Webmania ajudam a reconhecer a correção tradicional. Suas recomendações de remoção precisam dessa ressalva de modelo e formato; não cobrem, por si, as mudanças de 2026.

Para prevenir recorrência, mantenha testes separados por modelo, impressão, ambiente e forma de emissão. Proteja XMLs e dados de clientes ao compartilhar evidências com o suporte.

Base documental consultada em 10/10/2026, com PDFs oficiais preservados em 09/10/2026. O bloco ZX da NT 2026.002 registra testes em 01/07/2026 e produção em 03/08/2026; a postergação de três outras regras para 14/12/2026 não é uma postergação geral do QR. Datas documentais não certificam, isoladamente, a implementação em cada UF.