Ceros iniciales en Excel/CSV: por qué fallan tus códigos de barras

Pregunta a cualquiera que haya generado códigos de barras por lotes y te contará lo mismo: el archivo se veía bien, los códigos de barras se imprimieron, pero todos y cada uno escaneaban un número con un dígito de menos — o un número convertido en notación científica. El generador de códigos de barras no era el problema. La hoja de cálculo se comió los datos antes de que el generador los viera siquiera.

Este es el fallo de datos más común en la generación de códigos de barras, y casi siempre es invisible hasta que escaneas el resultado. Aquí tienes por qué ocurre, qué simbologías están en riesgo y cómo hacer que tus datos sobrevivan al viaje de la hoja de cálculo a la etiqueta.

Por qué Excel se come los ceros iniciales

El comportamiento por defecto de Excel es interpretar como número cualquier cosa que se parezca a un número, y los números no tienen ceros iniciales. Escribe 012345678905 en una celda y Excel guarda el valor numérico 12345678905; el 0 inicial desaparece en el instante en que pulsas Enter.

Para la mayoría de las hojas de cálculo esto es inofensivo. Para los datos de códigos de barras es fatal, porque un UPC-A tiene exactamente 12 dígitos, un EAN-13 exactamente 13, y un GTIN-14 o un SSCC-18 tienen 14 o 18. Si pierdes un cero inicial, habrás codificado un identificador distinto, más corto e inválido — que o bien fallará el dígito de control o escaneará el producto equivocado.

Lo mismo ocurre cuando abres un archivo CSV haciendo doble clic: Excel importa cada columna con su lógica de "adivinar el tipo", y un campo lleno de dígitos se convierte en número, eliminando los ceros.

Notación científica: el precipicio de los 11 dígitos

Excel tiene un segundo comportamiento, más traicionero. Un valor numérico de más de unos 11 dígitos se muestra (y a menudo se guarda) en notación científica — 12345678901234 se convierte en 1.23457E+13.

Para un UPC de 12 dígitos esto está en el límite; para un GTIN-14 de 14 dígitos o un SSCC de 18 es garantizado. En el momento en que el valor se reformatea a notación científica, los dígitos finales se redondean y el código queda destruido sin posible reparación. Ningún reformateo posterior de la celda recupera los dígitos perdidos, porque el número ya estaba redondeado.

El límite de precisión de 15 dígitos

Incluso si evitas la notación científica, Excel tiene un techo infranqueable: guarda los números como flotantes de doble precisión IEEE 754 , que solo son exactos hasta unos 15 dígitos significativos.

Cualquier identificador de más de 15 dígitos — y un SSCC-18 tiene 18 — verá sus dígitos finales redondeados silenciosamente. No puedes guardar un SSCC de 18 dígitos como celda numérica en Excel y mantenerlo intacto. Debe guardarse como texto. Esto no es un ajuste que puedas cambiar; es una propiedad del formato, documentada en las propias especificaciones y límites de Excel de Microsoft.

Qué simbologías están en riesgo

Cualquier código que empiece por cero — lo cual es habitual en los códigos EAN-13 emitidos en muchos países — entra en riesgo en el momento en que toca una celda de hoja de cálculo sin formato.

Cómo conservar los ceros

El principio básico: fuerza la columna a ser texto antes de que entren los datos. Aquí tienes los métodos fiables, por orden de preferencia.

Dos notas sobre las soluciones habituales:

• Dar formato de Texto a una celda después de que los ceros hayan desaparecido no los recupera. Los datos ya fueron eliminados. Tienes que volver a importarlos o a escribirlos, o rellenarlos con una fórmula de ancho fijo.
• El truco del apóstrofo solo funciona mientras escribes. Si vas a pegar una columna entera, preformatea antes la columna como Texto.

Si generas desde un CSV, abre el CSV en un editor de texto plano y confirma que el archivo sin procesar sigue teniendo los ceros. Si el propio CSV lo escribió un programa que los eliminó, ningún truco de hoja de cálculo servirá — debes arreglarlo en el origen que produjo el archivo.

El ángulo GS1: no son simples números

Los identificadores que corrompen las hojas de cálculo no son arbitrarios — son claves de identificación GS1 con una estructura definida y un dígito de control calculado. Un GTIN-14, un SSCC-18 y un código de barras GS1-128 llevan todos un prefijo de empresa GS1 seguido de una referencia y un dígito de control.

Esto importa por dos motivos:

• El dígito de control es la red de seguridad. Si se pierde un cero inicial, el número más corto resultante muy a menudo produce una discrepancia en el dígito de control. Esa es la buena noticia: el error se detecta en el momento del escaneo en lugar de propagarse en silencio. La mala noticia es que muchos operarios no se dan cuenta de que el dígito de control está mal, así que siguen reimprimiendo en lugar de corregir los datos. La lógica del dígito de control se explica en la entrada del glosario sobre el dígito de control.
• El portador de datos no es opcional. Un GTIN-14 debe codificarse en un código de barras ITF-14 o GS1-128 con el Application Identifier correcto (AI 01), y un SSCC-18 usa el AI 00. Una vez corrompido el valor de la hoja de cálculo, el código de barras codifica una clave GS1 de aspecto válido que simplemente apunta a otra cosa — un fallo mucho más difícil de depurar que un código de barras que no escanea en absoluto.

GS1 publica el conjunto completo de estándares para portadores de datos e identificadores, y las Especificaciones Generales rigen exactamente cómo se codifican. Mantener limpios los datos de origen es el requisito previo para todo ello.

Reparar datos ya corrompidos

Si los ceros ya han desaparecido, no te asustes — hay tres niveles de recuperación, y solo uno de ellos está garantizado.

• Nivel 1 — el dígito de control puede reconstruir un cero inicial. Para un UPC-A, un EAN-13 o una clave GS1-128, el dígito de control se calcula a partir de los demás dígitos. Si tu columna muestra 12 dígitos para un código que debería tener 13, el dígito ausente es casi siempre un cero inicial; a menudo puedes confirmar cuál es el primer dígito correcto calculando el dígito de control de cada candidato y viendo cuál coincide. Consulta la fórmula del dígito de control.
• Nivel 2 — rellenar hasta un ancho fijo. Si conoces la longitud prevista, una fórmula como =TEXT(A1,"000000000000") (12 ceros para un UPC-A, 13 para un EAN-13, 18 para un SSCC) te antepone los ceros. Esto funciona solo cuando conoces el ancho y el valor está intacto por lo demás; no puede recuperar un SSCC cuyos dígitos finales ya fueron redondeados por el límite de los 15 dígitos.
• Nivel 3 — volver al origen. Esta es la única solución garantizada. Vuelve a exportar los datos desde el ERP, el maestro de productos o el CSV original, y esta vez fuerza la columna a texto al importar. No intentes reparar un archivo corrupto hasta convertirlo en correcto — los dígitos perdidos se han ido de verdad, y adivinarlos es la forma de acabar enviando un código de barras que apunta al producto equivocado.

La distinción entre "escanea pero mal" y "no escanea" es el tema de escanea pero se rechaza: valor codificado frente a base de datos — merece la pena leerlo si tus códigos de barras se leen bien pero el sistema sigue rechazándolos.

Cómo comprobar tus datos antes de generar

Antes de introducir un lote en cualquier generador, haz una auditoría de dos segundos:

1. Cuenta los dígitos. Una columna de UPC-A debería tener 12 dígitos en todos los casos; EAN-13, 13; SSCC, 18. Si todos los valores tienen uno de menos, se perdió un cero inicial.
2. Busca E+ o E-. Toda celda que muestre notación científica ya está corrupta — los dígitos finales han desaparecido.
3. Ordena y mira los extremos. Los valores más grandes muestran primero el redondeo de 15 dígitos; un SSCC que termina en ...0000 cuando debería terminar en ...1234 ha sido redondeado.

La solución para un cero inicial perdido es rápida; la de un SSCC de 18 dígitos redondeado no lo es, porque los dígitos perdidos no se pueden recuperar desde la hoja de cálculo. En el momento en que guardas un identificador largo como texto, nunca tienes que hacer esa reparación.

Esta es la primera capa del diagnóstico de 12 causas de "no escanea" — y la que pilla desprevenida a más gente, porque el código de barras se imprime y se escanea , solo que con el valor equivocado. Para el caso estrechamente relacionado en el que el símbolo escanea correctamente pero el sistema lo rechaza, consulta escanea pero se rechaza: valor codificado frente a base de datos.

Lecturas relacionadas

• El código de barras se imprime pero no escanea: las 12 causas en orden
• SSCC-18: los 18 dígitos, el dígito de control y por qué no puedes reutilizar uno
• El dígito de control, explicado