El código de barras escanea pero el sistema lo rechaza: por qué

Escaneas un código de barras, el escáner pita, aparece un número en pantalla — y el sistema dice "artículo no encontrado". O peor, coincide discretamente con el registro equivocado y nadie lo nota hasta que se envía el producto incorrecto. Un pitido del escáner se siente como una confirmación, así que este es el fallo más peligroso de todos: parece que ha funcionado mientras está siendo erróneo.

"Escanea pero se rechaza" es un problema distinto de "no escanea en absoluto". La impresora, la zona de silencio y la simbología están bien. El fallo está en los propios datos. Esta guía separa lo que hace el escáner de lo que hace el sistema y recorre después las formas concretas en que el valor codificado puede desviarse del valor que espera tu base de datos — y cómo encontrar rápidamente la discrepancia.

El trabajo del escáner termina en la lectura

Conviene ser precisos sobre lo que hace un escáner, porque la mayor parte de la confusión empieza aquí. Un escáner de código de barras es un teclado. Convierte el patrón de claro y oscuro en una cadena de caracteres y envía esa cadena a lo que tenga el foco, exactamente como si la hubieras tecleado. No "busca" nada, no valida nada y no sabe si la cadena es la correcta.

Un escáner tiene una única condición de éxito: haber decodificado una cadena. Que esa cadena coincida con el SKU de tu inventario, con el GTIN del pedido o con el registro que quiere el sistema de almacén — nada de eso es trabajo del escáner.

Esa distinción importa porque te dice dónde mirar. Cuando un escaneo se rechaza, estás depurando una de dos cosas:

1. El valor codificado es incorrecto — la cadena dentro del código de barras no es la cadena que querías poner ahí.
2. La expectativa del sistema es incorrecta — el código de barras está bien, pero no coincide con el campo, el formato o el registro contra el que el sistema lo compara.

La mayoría de los escaneos rechazados son del tipo 1, y la mayoría de los fallos del tipo 1 se reducen a un pequeño conjunto de errores de higiene de datos.

Las cuatro capas donde un escaneo "correcto" sale mal

Piensa en un código de barras como cuatro capas apiladas, cada una de las cuales puede romperse de forma independiente:

Esta guía trata de las capas uno, dos y cuatro. La capa tres — el símbolo físico — se cubre en las 12 causas de un código de barras que no escanea, porque un fallo a nivel de símbolo normalmente significa ninguna lectura. Un escaneo rechazado significa que las tres primeras capas hicieron su trabajo y la discrepancia está en el valor.

Ceros iniciales: el asesino silencioso clásico

La causa más común de un escaneo-rechazo es un cero inicial perdido , y casi siempre es culpa de Excel.

Un UPC-A tiene 12 dígitos. Un EAN-13 tiene 13. Un SKU interno puede tener 8 o 9. Si cualquiera de esos vive en una hoja de cálculo como número, Excel trata los ceros iniciales como carentes de significado y los elimina. El valor 00123456 se convierte en 123456, y 000123456789 en 123456789. Cuando generas un código de barras a partir de ese valor recortado, el código de barras codifica el número incorrecto, más corto.

La solución es mantener los identificadores como texto en todas las etapas — en la hoja de cálculo (un apóstrofo inicial o una columna con formato Texto), en la exportación y en el generador de códigos de barras. Cubrimos la mecánica completa, incluida la corrupción por notación científica de los números largos, en la guía dedicada a los ceros iniciales en Excel y CSV.

Un buen hábito de diagnóstico: compara la longitud. Si la base de datos espera un GTIN de 13 dígitos y el valor escaneado tiene 11 o 12 caracteres, un cero inicial eliminado es lo primero que hay que sospechar.

Deriva del dígito de control: cuando el número "parece" correcto

Todo GTIN termina con un dígito de control — un único dígito calculado a partir de los anteriores mediante una fórmula fija. Su función es detectar un dígito transpuesto o mal tecleado. La trampa es que el dígito de control forma parte de la codificación , no es un campo aparte.

Esto significa que en la práctica fallan dos cosas:

• Editas un dígito y olvidas recalcular. Cambias el precio, el peso o un número de serie, luego editas a mano el GTIN en una hoja de cálculo y reutilizas el dígito de control antiguo. La línea legible impresa contiene ahora un número cuyo dígito de control no valida. Los escáneres lo seguirán leyendo — la mayoría no verifican el dígito de control — pero cualquier sistema que sí lo valide (TPV minorista, búsquedas conformes con GS1) lo rechazará.
• Las barras codificadas discrepan de los dígitos impresos. Si el código de barras se generó a partir de un valor pero el texto legible inferior se escribió por separado, los dos pueden divergir. La persona lee el texto y cree que el código es 123…5; el escáner lee las barras y obtiene 123…7.

Puedes confirmar el dígito correcto con la calculadora de dígitos de control de GS1. Las reglas de cómo se deriva el dígito están en las Especificaciones Generales de GS1, que es la fuente autorizada para toda longitud y estructura de GTIN.

La línea legible puede mentir

Justo debajo (o encima) de las barras suele haber una línea de texto que muestra los datos codificados: la interpretación legible por humanos (HRI). Existe para que una persona pueda teclear el valor si el escáner falla.

El problema: la HRI y las barras son dos cosas distintas en muchos flujos de trabajo. Si el software de etiquetas renderiza la HRI desde un campo diferente del que generó las barras, el texto puede mostrar ABC-12345 mientras las barras codifican ABC-12346. Un escáner lee las barras; un humano lee el texto; el sistema nunca ve el texto. El resultado es una etiqueta perfectamente escaneable que está mal, y un operario de almacén que insiste en que "el número está ahí mismo en la etiqueta".

La regla: confía en el escaneo, no en el texto. Al diagnosticar, compara siempre el valor escaneado contra la base de datos, nunca la HRI impresa. Y en el software de etiquetas, vincula la HRI a la misma fuente de datos que las barras para que no puedan divergir.

Espacios en blanco y caracteres invisibles

No todos los caracteres erróneos son visibles. Un código de barras puede codificar un espacio final, un tabulador, un espacio de no separación o un salto de línea, y el escaneo lo incluirá. El sistema compara entonces ABC123 contra ABC123 y lo rechaza — y en pantalla ambos se ven idénticos.

Estos caracteres suelen entrar por copiar y pegar. Un SKU copiado de una página web o de un PDF arrastra a menudo un salto de línea final o un espacio Unicode que sobrevive hasta el código de barras. Los culpables habituales:

• Espacios finales (ASCII 0x20)
• Espacios de no separación (U+00A0), a menudo pegados desde HTML o correo electrónico
• Tabuladores y retornos de carro
• Caracteres de anchura cero, ocasionalmente al copiar del navegador

Una prueba rápida de aislamiento: pega el valor escaneado en un editor de texto plano y cuenta su longitud, o revísalo carácter a carácter. Si la longitud es uno más de lo esperado, un carácter oculto es casi con certeza la causa.

Elegir la columna equivocada

En el trabajo por lotes, el error suele ser tan simple como exportar la columna equivocada. Una hoja de cálculo puede tener tres columnas adyacentes — SKU interno, código de proveedor y UPC — y el código de barras se genera a partir del código de proveedor cuando el sistema de almacén indexa por el SKU interno. El código de barras es válido, el escaneo es limpio y se rechazan todos y cada uno de los artículos.

Esto es un error de mapeo de datos, no un error del código de barras, y por eso sobrevive a las pruebas: un único escaneo de prueba contra el campo equivocado seguirá "funcionando", porque quien prueba está comparando el escaneo con la misma columna errónea de la que se generó. La solución es hacer el mapeo explícito — nombra el campo en la configuración del generador y valida contra un registro que funcione, no contra la hoja de cálculo de origen.

SKU frente a UPC frente a FNSKU

Los vendedores en retail y marketplaces se topan con una versión concreta del problema de la columna equivocada: tres identificadores distintos para lo que parece el mismo producto.

• UPC / EAN / GTIN — el número global de artículo comercial que identifica el producto en todos los minoristas.
• SKU — un código interno, definido por el vendedor, para ese producto, único solo dentro de tu propio catálogo.
• FNSKU — el identificador de la red de distribución de Amazon, impreso en la etiqueta aplicada a una unidad para FBA.

No son intercambiables. Un código de barras que codifica el UPC no coincidirá con un sistema que espera el SKU, y una unidad de FBA etiquetada con el UPC en lugar del FNSKU será rechazada en el muelle de entrada de Amazon. El código de barras en sí está bien; lo que está mal es la elección del identificador.

La solución es saber qué número espera cada punto de escaneo y generar un código de barras exactamente desde ese campo. Amazon documenta qué etiqueta va en cada unidad en Seller Central.

Confusión con los Application Identifiers de GS1

Los códigos de barras GS1-128 (y GS1 DataBar) empaquetan los datos como una serie de Application Identifiers — prefijos numéricos cortos que dicen qué es el campo siguiente. 01 es un GTIN, 21 un número de serie, 00 un SSCC, 10 un lote, 17 una fecha de caducidad. La gracia es que un solo código de barras puede transportar varios campos, y el AI le dice al sistema receptor cómo analizarlos.

El modo de fallo: el AI es incorrecto, o el valor se colocó bajo el AI equivocado. Un número de serie colocado bajo el AI 01 (GTIN) decodificará como una cadena estructuralmente válida con forma de GTIN e incluso puede pasar una comprobación ingenua — pero son los datos equivocados en el hueco equivocado, y un sistema que analiza por AI lo enrutará mal o lo rechazará.

Este es un error de capa dos (codificación) fácil de cometer al ensamblar a mano datos GS1-128, especialmente en torno a los campos de longitud variable. El carácter FNC1 que termina un AI de longitud variable es el separador que más a menudo se omite, y omitirlo desplaza todos los campos siguientes a la posición incorrecta. Las definiciones autorizadas de los AI y las reglas de separadores están en las Especificaciones Generales de GS1.

Lista de comprobación para aislar el fallo

Cuando un escaneo se rechaza, recorre estos pasos en orden — primero los más baratos:

1. Captura el valor escaneado exacto. Escanea en un editor de texto plano, no directamente en el campo. Anota la longitud y cada carácter.
2. Compara primero la longitud. Un carácter de menos apunta a un cero inicial eliminado; un carácter de más apunta a un carácter oculto.
3. Compara contra la base de datos, no contra la etiqueta. La línea legible impresa puede discrepar de las barras.
4. Verifica el dígito de control con la calculadora si el valor termina en uno.
5. Confirma el tipo de identificador. UPC frente a SKU frente a FNSKU frente a AI de GS1 — ¿es este el campo que el sistema quiere realmente?
6. Revisa el mapeo de datos. ¿Qué columna de la hoja de cálculo alimentó el generador?

Cada uno de estos pasos es barato y la mayoría de los rechazos se resuelven en el paso dos o tres.

En resumen

Un escáner que pita solo ha demostrado que decodificó una cadena. El rechazo significa que la cadena no es lo que el sistema espera, y eso casi siempre es un problema de datos, no de impresión. Los ceros iniciales, un dígito de control obsoleto, un carácter invisible, la columna equivocada o el tipo de identificador equivocado explican la gran mayoría de los casos. Compara el valor escaneado — no el texto impreso — contra la base de datos, revisa la longitud y verifica el dígito de control, y normalmente encontrarás el fallo en menos de un minuto. Para los casos en que el código de barras no escanea en absoluto, empieza por las 12 causas habituales.