Rejeição 397: como reconciliar o QR Code com os dados da nota

A rejeição 397 informa que um parâmetro do QR Code diverge do dado correspondente na nota enviada para autorização. O caminho mais seguro é comparar o QR com o XML final transmitido, usando o parâmetro indicado na mensagem. A tela de venda pode mostrar uma informação correta enquanto a integração envia outra versão do arquivo.

Esse problema merece atenção especial em contingência e retransmissões. Uma alteração na nota depois da montagem do QR pode deixar chave, total ou informação de assinatura desatualizados. O objetivo da correção é recuperar a coerência entre os componentes do mesmo documento, preservando os dados verdadeiros da operação.

O que o código realmente compara

Na NFC-e com QR v2 ou v3, a chave de acesso ocupa a primeira posição e o ambiente, a terceira. As regras ZX02-228 e ZX02-244 relacionam esses valores à chave e ao tpAmb da nota. Esses identificadores organizam a documentação; o resultado de rejeição é 397. NT 2025.001 v1.03, páginas 11–12

Na emissão offline, tpEmis=9, também são comparados o dia da emissão e o total, respectivamente na quarta e quinta posições. O dia deve corresponder ao componente de dia de dhEmi; o total deve corresponder a vNF, campo W16. O parâmetro de total não deve ser preenchido com uma soma paralela feita pelo módulo de impressão.

Esses dois parâmetros não existem no QR de emissão normal. Comparar posições sem identificar a forma de emissão é um erro importante: a quarta posição do QR v2 normal é o identificador do CSC, enquanto no v2 offline ela contém o dia.

Versão 2 e versão 3 têm verificações diferentes

No QR v2 offline, a sexta posição contém a representação prevista do DigestValue da nota. A regra ZX02-296 vincula sua divergência ao código 397. Se o XML foi regenerado ou assinado novamente e o QR conservou o resultado anterior, a comparação pode falhar. O problema está na consistência da geração, mesmo que todos os caracteres tenham formato válido. MOC 7.0, página 132

No v3 offline, a sexta e a sétima posições tratam do tipo e da identificação do destinatário. A regra ZX02-328 prevê 397 quando não há correspondência com a nota. Também exige coerência quanto à ausência: não se deve levar uma identificação ao QR quando ela não foi informada na NFC-e, ou fazer o contrário.

O manual prevê a preservação de separadores quando o destinatário não é identificado e tratamento específico para estrangeiro. Não preencha espaços vazios com documentos inventados nem remova posições por uma função de limpeza. Na emissão normal v3, esses parâmetros de destinatário não existem. Manual DANFE-NFC-e e QR Code v6.0, páginas 29–30

No v3 também não há parâmetros de CSC, hash ou DigestValue. Sua assinatura offline tem validações próprias, inclusive 583 quando diverge do cálculo. Um programa não deve chamar toda inconsistência criptográfica de “erro 397” sem preservar o retorno verdadeiro.

Por que comparar arquivos, além dos cadastros

Considere uma venda offline cujo total foi corrigido antes da transmissão, mas cujo QR permaneceu guardado em cache. A tela mostra o total novo; o XML final também. O QR, porém, carrega o valor antigo. A solução é regenerar os elementos dependentes a partir da versão correta, seguindo o fluxo do emissor, e não alterar o total fiscal para fazê-lo caber no QR antigo.

Em um caso de retransmissão documentado pela TOTVS, a investigação comparou os XMLs do ERP e do TSS para localizar a origem de um DigestValue divergente. Esse exemplo é útil ao QR v2 offline e não transforma DigestValue em parâmetro do v3.

A orientação geral de comparar o parâmetro apontado com seu campo de origem também aparece em Oobj e TecnoSpeed. A ordem e o conjunto de campos devem ser confirmados nas tabelas oficiais da versão, evitando reproduzir listas antigas integralmente.

Um procedimento de diagnóstico para a empresa

1. Preserve o retorno completo e identifique qual componente recebeu a resposta da SEFAZ

2. Separe o XML efetivamente enviado, a versão que originou o QR e o DANFE correspondente

3. Registre modelo, tpEmis, tpAmb e versão do QR antes de contar suas posições

4. Compare apenas os parâmetros aplicáveis, incluindo a transformação prevista para o DigestValue quando houver

5. Localize onde ocorreu a diferença: edição posterior, cache, configuração de ambiente ou geração independente em dois componentes

6. Corrija a origem, gere o documento pelo fluxo regular e verifique sua situação antes de retransmitir

Uma mudança de ambiente merece cuidado: não basta trocar o endereço do portal e conservar tpAmb ou componentes de outra configuração. Da mesma forma, copiar QR de outra nota para uma impressão não corrige o documento e pode expor informações de terceiros.

O alcance na NF-e e os limites do diagnóstico

A NT 2026.002 v1.11 inclui modelos 55/65 nas regras de comparação. Para a NF-e com DANFE Simplificado Tipo 2, tpImp=6, exige QR v3; o offline do modelo 55 está limitado a esse formato. O bloco tem cronograma próprio, com produção prevista em 03/08/2026, sem adiamento universal para dezembro. NT 2026.002 v1.11, páginas 20–23

Para outros formatos do DANFE modelo 55, a NT 2026.010 remete as condições de QR a alteração específica futura. Isso impede generalizar a configuração Tipo 2 a toda NF-e.

Na consulta pública, códigos como 219, 221 e 227 pertencem à tabela daquele serviço e devem ser interpretados separadamente. Um aviso ao ler o QR não comprova que houve rejeição 397 na autorização. Depois da correção, confira tanto o protocolo quanto o conteúdo consultável, sem modificar silenciosamente um XML já autorizado.