Rejeição 400: como corrigir o formato hexadecimal no QR Code v2

A rejeição 400 está associada a parâmetros do QR Code que deveriam estar em representação hexadecimal. No uso documentado do QR v2 da NFC-e, a verificação alcança o hash e, na contingência offline, o DigestValue. Isso não significa converter todo o endereço ou todos os parâmetros para hexadecimal.

A primeira providência é identificar o parâmetro citado no retorno e a versão do QR efetivamente enviada. O QR v3 tem estrutura diferente e usa assinatura offline em Base64; aplicar a ele uma correção de hexadecimal do v2 cria outro erro.

Quais campos são verificados na versão 2

Na emissão normal da NFC-e com QR v2, a quinta posição contém o hash. Na contingência offline, tpEmis=9, o DigestValue convertido ocupa a sexta posição e o hash ocupa a oitava. A regra ZX02-292 trata do formato do DigestValue offline; ZX02-316 trata do formato do hash nas duas formas de emissão. Ambas remetem ao código 400. MOC 7.0, páginas 132–133

Hexadecimal utiliza algarismos de 0 a 9 e letras de A a F, maiúsculas ou minúsculas. Espaços, quebras de linha ou letras fora desse conjunto não pertencem à representação exigida nesses parâmetros. A verificação do conjunto de caracteres, porém, é apenas uma etapa: um texto pode parecer hexadecimal e ainda representar um valor incorreto.

O identificador do CSC, presente na quarta posição do v2 normal e na sétima do offline, não é o segredo CSC. Tampouco deve ser transformado em hexadecimal por aparecer próximo aos campos examinados. Chave, ambiente, dia e total mantêm seus próprios formatos.

Formato válido não garante conteúdo correto

É importante separar três problemas:

• Parâmetro que falta: pode produzir 396, conforme a regra aplicável

• Parâmetro presente em representação inadequada: pode produzir 400 nos ramos de hexadecimal

• Parâmetro com conteúdo divergente: pode produzir outro resultado, como 397 para DigestValue divergente ou 464 para hash diferente do cálculo

Trocar caracteres até que a rejeição 400 desapareça não é correção. O valor precisa ser gerado a partir dos dados certos, na ordem correta e com a transformação descrita no manual. Um texto composto só de caracteres permitidos pode passar da primeira validação e falhar na seguinte.

O hash v2 resulta de SHA-1 sobre a sequência prevista, que inclui o CSC no cálculo. Sua representação final tem 40 caracteres hexadecimais. O segredo não deve aparecer como parâmetro da URL. No caso offline, o manual manda converter o valor do DigestValue para hexadecimal antes de compor a sequência usada no hash. Manual DANFE-NFC-e e QR Code v6.0, páginas 22–24

Onde o emissor costuma perder a consistência

Uma biblioteca pode entregar um resultado em Base64 quando a etapa seguinte espera hexadecimal. Também pode haver transformação duplicada, inclusão de espaços pela montagem do texto ou reutilização de dados gerados antes da assinatura final da nota. Essas são hipóteses para investigação; o retorno isolado não prova qual delas ocorreu.

Um caso didático é o DigestValue aparecer na URL diretamente na representação em que foi obtido do XML, sem a conversão prevista para o QR v2 offline. O formato precisa ser produzido pela rotina correta, mantendo correspondência com a nota. Alterar a assinatura do XML manualmente para acompanhar um QR defeituoso compromete o diagnóstico.

Os materiais de TecnoSpeed e Oobj ilustram o contexto v2. A orientação resumida da Webmania deve ser entendida com esse limite: são os parâmetros específicos que exigem a representação, não o QR inteiro.

O que não deve ser transportado para o QR v3

No QR v3 normal há apenas chave, versão e ambiente. No offline, acrescentam-se dia, total, tipo e identificação do destinatário e assinatura. CSC, identificador do CSC, hash e DigestValue não integram essa composição. A assinatura offline é documentada em Base64 e tem validações próprias, como falta da assinatura exigida e divergência em relação ao valor calculado. NT 2025.001 v1.03, páginas 13–14

A permanência de linhas sobre hash e DigestValue na tabela de consulta pública não altera a tabela de formação do QR v3. Para NFC-e emitida por CNPJ, a NT registra a adoção exclusiva de v3 como futura, sem data definida; por isso, ainda é útil diagnosticar corretamente o ramo v2, sem apresentá-lo como solução universal.

A NF-e modelo 55 com DANFE Simplificado Tipo 2 exige v3 na NT 2026.002. Logo, não se deve sugerir a inclusão de hash ou DigestValue v2 para corrigir esse documento. Para demais formatos de DANFE modelo 55, a NT 2026.010 remete as condições do QR a alteração específica futura.

Um procedimento seguro para corrigir e testar

1. Preserve o retorno completo, a identificação do parâmetro e uma cópia do arquivo realmente transmitido

2. Confirme QR v2 e forma de emissão antes de interpretar quinta, sexta ou oitava posição

3. Confira caracteres, tamanho aplicável, ausência de espaços e transformação usada, sem substituir dados por valores de exemplo

4. Verifique se o QR foi produzido a partir do XML e da assinatura corretos, sem conteúdo antigo em cache

5. Corrija a rotina geradora e valide a composição inteira, incluindo o cálculo de integridade

6. Consulte a situação do documento antes de retransmitir; depois, confirme autorização e leitura do QR correspondente

Não envie CSC, certificado, senha ou arquivos de clientes a conversores públicos para testar a representação. O diagnóstico pode ser reproduzido em ambiente controlado, com dados fictícios e sem segredos utilizáveis. Para discutir a falha, descreva posição, formato e etapa da geração, evitando divulgar o conteúdo integral da URL.

Quando a mensagem menciona data em hexadecimal

Há um ramo histórico do QR v1, identificado por 100, em que a data completa era tratada em hexadecimal. Ele não deve orientar o dia da emissão nos QR v2/v3 offline, que utiliza dois dígitos. O MOC relaciona o uso de QR100 após 30/09/2018 à rejeição 903.

Por fim, uma mensagem da consulta pública não deve ser confundida com cStat de autorização. Mantenha os registros de cada serviço separados e confirme o protocolo final. A correção estará demonstrada quando o documento e seu QR forem coerentes, não apenas quando um teste de caracteres deixar de acusar erro.