Código de barras, SKU e catálogo impresso: como evitar pedido com produto errado

Pedido errado em papelaria raramente é erro de digitação de quantidade. Na maioria das vezes é o representante ou a loja escolhendo a referência errada dentro de uma família de produtos que compartilha o mesmo código base — e só percebe quando a mercadoria chega.

A saída óbvia parece ser "usar código de barras para tudo". Faz sentido em teoria: leia o código, o sistema identifica o produto, fim do erro. Na prática, o código de barras resolve só uma parte do problema, e é a parte mais fácil.

Onde o código de barras para de ajudar

Um código de barras identifica um item específico — uma caixa, uma embalagem, um SKU final. O problema é que, num catálogo impresso de papelaria, o que a página mostra costuma ser uma família de produto: um título, uma imagem, e uma faixa de variações dentro dela — cores diferentes, gramaturas diferentes, embalagens diferentes (unidade, blister, caixa fechada).

Cada uma dessas variações tem seu próprio código, mas elas aparecem juntas na página, agrupadas visualmente sob o mesmo produto. Se a interface de pedido não deixa claro qual código pertence a qual variação, a pessoa escolhe visualmente — "essa aqui, a azul" — e o sistema já assumiu outra coisa.

O caso clássico: a caneta que não é uma caneta só

Pense numa linha de canetas de um fabricante qualquer. O catálogo mostra um bloco só, com uma imagem, um nome de linha, e ao lado uma lista pequena de variações — cor da tinta, espessura da ponta, às vezes embalagem individual versus cartela. Visualmente é um produto. Comercialmente são referências diferentes, cada uma com seu próprio código de estoque no ERP do fornecedor.

Quando o pedido é feito a partir de uma lista solta de códigos — sem a imagem, sem a cor exibida ao lado do código — a chance de pedir a referência errada sobe bastante, principalmente quando o vendedor está confiando na memória em vez de conferir o código na hora.

Por que isso não é problema de tecnologia de leitura

Um leitor de código de barras físico, ou um scanner de câmera, resolve bem um caso: "tenho o produto físico na mão e quero saber o que é". Isso ajuda muito na conferência de estoque. Mas não ajuda na hora de montar um pedido novo, porque nesse momento não existe produto físico nenhum — existe uma página de catálogo e uma decisão de compra.

O problema, nesse momento, é de identificação visual e de contexto: a pessoa precisa ver a cor real (a cor da tinta impressa na ponta da caneta, por exemplo, não uma descrição em texto), ver a variação ao lado do código, e ter clareza de que aquele código específico corresponde àquela escolha específica — antes de confirmar.

O que reduz o erro de verdade

O que resolve isso é a página do catálogo e o código andarem juntos, sem intermediário. Quando o produto tem variação de cor, a cor deveria estar visível junto ao código, do jeito que o catálogo impresso já mostra — e não escondida atrás de uma sigla que só quem decorou a tabela do fornecedor entende.

Da mesma forma, quando um código está fora da tabela de preços vigente — descontinuado, por exemplo —, isso precisa aparecer sinalizado no momento da escolha, não só descoberto depois que o pedido já foi enviado. Um catálogo com milhares de referências sempre vai ter alguns códigos que saíram da linha; o problema não é isso existir, é isso ficar invisível até o pedido voltar recusado.

Nenhuma dessas soluções depende de leitor de código de barras. Dependem de a ferramenta de pedido preservar o contexto visual que o catálogo impresso já oferece — cor, imagem, variação — e amarrar isso ao código certo antes da pessoa confirmar a escolha. É uma questão de desenho da ferramenta, não de tecnologia de captura.