El infierno de los códigos de barras

Con motivo del día de Satán, también conocido como nuestro arranque con SAP B1, hemos tenido un fin de semana horroroso de preparativos que se alargó un día más de lo previsto, como colofón a una semana horrorosa y preludio a otra igual de terrible. Una de las cosas que más guerra nos ha dado la impresión de etiquetas de códigos de barra que antes las hacíamos con un programa y ahora teníamos pensado emplear informes de Crystal Reports. No había manera de conseguir imprimir un EAN14 válido. El problema añadido es que en Internet no encontrábamos mucha ayuda.

Al final, la solución vino de un foro del venerable Visual FoxPro, solución que resumo aquí como aviso para navegantes:

El EAN/DUN14 es un churro de números. Información sobre cómo componer un número válido es fácil de encontrar: que debe tener un número par de cifras, cómo se calcula el dígito de control, la norma para su composición… Pero averiguar cómo imprimir eso en un código de barras es harina de otro costal.

Para el código de barras se usa una codificación Interleaved 2 of 5, que representa dos números como un grupo de cinco líneas y espacios. Aquí viene nuestro problema, porque con una fuente de texto sola no hacemos nada: cada carácter de nuestro código de barras se corresponde con dos números de nuestro DUN14. O sea, nuestro código de barras tendrá la mitad de caracteres que nuestro DUN14. Esto nos obliga a usar un algoritmo que nos convierta nuestro chorro de números en esa cadena. Esta cadena, con un tipo de letra Interleaved 2 of 5, será nuestro código de barras.

Y aquí es donde se nos presenta el problema, porque el algoritmo depende de la fuente empleada (o al revés, vamos). De nada nos vale una fuente I2o5 si no tenemos el algoritmo. ¿Por qué? Porque los casos que he visto funcionan del siguiente modo:

Vamos recorriendo nuestro DUN14, cogiendo cada par de números. Al número que representan (por ejemplo, 58) se le suma un valor dado (digamos 52). Se obtiene el carácter correspondiente a ese código numérico (110) y ése, en nuestra fuente I2o5, se corresponderá con las cinco barras-espacios que necesitamos. Como se ve, si nuestra fuente no es la correspondiente a nuestro algoritmo, el carácter representado no tiene por qué coincidir (y no lo hará) con el buscado.

Al final, debemos tener una cadena de caracteres formada por un carácter de apertura, la cadena tratada y un carácter de fin, que nuestro lector será capaz de entender.

En el artículo que menciono antes encontramos código para generar una representación de nuestro DUN14 para una fuente I2o5 y, además, nos da la fuente. El código, pese a los nombres de las variables, es muy simple: la mayor parte de la función se dedica en calcular el dígito de control y en asegurarse que la longitud sea correcta. Si ya tenemos nuestro código válido, todo se reduce a lo siguiente:

1) Tomamos cada par de números de nuestro código (para 14 cifras tendremos, pues, 7 pares).

2) Si el número de dos cifras que componen es menor de 50, le sumamos 48. Si es mayor, 142.

3) Sacamos el carácter correspondiente a ese código.

4) Formamos una nueva cadena de caracteres con los que hemos obtenido, en orden.

5) Como cabecera le añadimos el carácter 40 y como cierre, el 41 (los paréntesis)

6) Aplicamos la fuente I2o5 que acompaña al ejemplo y listo.

La primera aplicación de esto la hice a mano, en Excel, para un código dado y la alegría de ver cómo el lector entendía el puñetero código después de tan horroroso y desesperante fin de semana es difícil de explicar.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.