Rejeição 400: Parâmetro do QR-Code não está no formato hexadecimal

A Rejeição 400 acontece quando um parâmetro do QR Code do cupom não está no formato hexadecimal exigido.

A mensagem informa qual parâmetro — data de emissão, hash, digest, entre outros.

Abrir PDV

Por que acontece a Rejeição 400

Vários parâmetros do QR Code são transmitidos em hexadecimal — a base que usa apenas os caracteres de 0 a 9 e de A a F. É um formato compacto e sem ambiguidade, adequado a um código que precisa caber em uma imagem impressa.

Qualquer caractere fora desse conjunto invalida o parâmetro.

As causas mais comuns:

Conversão não aplicada. É a causa principal. O valor foi colocado no QR Code no formato original — texto ou número decimal — sem a conversão.

Codificação parcial. Parte do valor foi convertida e parte não.

Caractere de preenchimento. Espaços, sinais ou separadores no meio do valor.

Montagem própria do QR Code. Sistema que constrói o código por concatenação de texto.

Essa rejeição é sempre do sistema emissor. Não há campo no cadastro que o usuário ajuste.

Como resolver a Rejeição 400

1. 1
   Confirme se a rejeição atinge todos os cupons. Sendo geral, é a montagem do QR Code.
2. 2
   Abra um chamado com o fornecedor do sistema, informando qual parâmetro a mensagem apontou.
3. 3
   No Berga o QR Code é gerado conforme a especificação, e essa rejeição não aparece na emissão normal.

Como evitar a Rejeição 400

Não há prevenção do lado do usuário. O que ajuda é manter o sistema atualizado: as regras do QR Code mudaram por nota técnica, e emissores antigos ficaram para trás.

Se a Rejeição 400 continuar

Rejeições vizinhas da mesma família: parâmetro ausente no QR Code, parâmetro divergente dos dados da nota, hash que não confere com o calculado e endereço de consulta errado.

Se a mensagem mudar para a de hash divergente, o formato já está certo e o problema passa a ser o CSC configurado — esse, sim, tem solução do lado do cliente.

Persistindo, abra um chamado informando o número do cupom e o parâmetro apontado.

Referência: MOC 7.0 — Anexo I, regras de validação ZX02-64 e seguintes (NT 2015.002 e NT 2016.002).