Formatear, validar y transformar datos de etiquetas con Python antes de imprimir

Una etiqueta de precio que imprime 35.00 en lugar de 3.50 no es un problema de diseño. Es un problema de datos, y es el tipo de problema que sobrevive a todas las revisiones visuales porque la etiqueta se ve bien.

Este artículo trata sobre la capa que la mayoría de los flujos de trabajo de etiquetas omite: qué le sucede al valor de un campo entre “la hoja de cálculo tiene un valor” y “la impresora lo pone en el papel”.

La freelancer que casi envía una etiqueta de precio incorrecta

Imagina a una desarrolladora independiente —llamémosla Mara— que acepta un pequeño cliente minorista: una tienda, cuarenta SKU, una hoja de cálculo que la dueña mantiene ella misma. Mara crea una plantilla de etiqueta, conecta la hoja de cálculo como fuente de datos, imprime una hoja de prueba y la primera etiqueta muestra un paquete de café de 250 g a 35.00.

La hoja de cálculo decía 3,50. Una coma decimal. El diseño de la etiqueta esperaba un punto, y nadie lo notó hasta que la prueba regresó de parte de la dueña de la tienda.

El resto de la columna no está mejor:

• Precios como 3.5, 3,50, € 3.50 y algunas celdas vacías.
• SKU que Excel convirtió silenciosamente en números, devorando los ceros iniciales que necesita un código de barras.
• Fechas de caducidad en tres formatos a lo largo de cuarenta filas.
• Códigos de proveedor con un prefijo SUP- que la dueña quiere eliminar para una etiqueta más limpia.

El primer instinto de Mara es el estándar: escribir un script de exportación que limpie el CSV y luego alimentar el archivo limpio a la herramienta de impresión. Eso funciona, hasta que la dueña de la tienda edita la hoja de cálculo la semana siguiente, el script de exportación vive en el portátil de Mara, sin documentar, y nadie recuerda ejecutarlo.

Así que la verdadera pregunta es esta: ¿cómo limpias y das forma a los valores de los campos antes de que lleguen a la impresora, sin montar y mantener un segundo pipeline de datos?

La respuesta en RSJ LPSNG es la API de scripts de campo de Python: bloques de script que se adjuntan a campos individuales de la etiqueta y que acceden y modifican los valores de los campos antes de imprimir. El script viaja con la etiqueta en lugar de vivir junto a ella.

Para dejar claro el alcance: esto no trata sobre el diseño de la etiqueta. Si buscas el lado del diseño —colocar texto, códigos de barras e imágenes en el editor del navegador— eso está cubierto en Cómo diseñar etiquetas de código de barras en un editor de diseño de navegador. Este artículo trata sobre los valores que fluyen hacia ese diseño.

Por qué el control de datos a nivel de campo importa para desarrolladores y usuarios finales

La mayoría de los defectos en etiquetas son defectos de datos disfrazados de diseño. Decimales incorrectos, fechas sin formato, ceros iniciales ausentes en códigos de barras, un nombre de producto truncado que ya no cabe: el diseño está haciendo exactamente lo que se le indicó. La entrada era incorrecta.

El control a nivel de campo importa para dos audiencias muy diferentes, por la misma razón de fondo.

Para los desarrolladores, elimina toda una clase de infraestructura paralela. No escribes ni mantienes un script de preprocesamiento externo, un trabajo programado que reescribe archivos CSV, ni código de pegamento que se sitúa entre la fuente de datos y el motor de impresión. El formateo y la validación viven en la definición de la etiqueta, que es el artefacto que realmente los necesita.

Para los usuarios finales y los equipos pequeños, produce una salida consistente sin requerir que nadie entienda los datos de origen. La dueña de la tienda sigue rellenando su hoja de cálculo como siempre lo ha hecho. La etiqueta decide cómo se muestra un precio.

La API de scripts de campo de Python es la capa intermedia entre esos dos mundos:

• Se ejecuta en el campo, no en el archivo.
• Puede leer y modificar el valor antes de imprimir.
• Vive dentro de la misma plataforma que renderiza la etiqueta, así que no hay desfase de versiones entre “el limpiador” y “la plantilla”.

La referencia de la API está en lpsng.rsj.de/api.html.

Un manual práctico: formatear, validar y transformar en tres pasadas

Trata cada script de campo como tres pasadas sobre el valor, en este orden: formatéalo, demuéstralo y luego deriva de él. Los fragmentos a continuación son Python ilustrativo; lo importante es la forma de la lógica, no los nombres exactos de las funciones auxiliares.

Pasada 1: Formatear

Normaliza el valor bruto exactamente a lo que espera el diseño de la etiqueta. Precios a un patrón decimal fijo, fechas a un único formato de visualización, texto al uso de mayúsculas y minúsculas en torno al cual se diseñó el diseño.

import re

CURRENCY = re.compile(r"[^\d,.\-]")

def format_price(raw):
    """'€ 3,50' -> '3.50'; returns None when nothing usable is left."""
    if raw is None:
        return None
    cleaned = CURRENCY.sub("", str(raw)).strip()
    if not cleaned:
        return None
    if "," in cleaned and "." in cleaned:
        cleaned = cleaned.replace(".", "").replace(",", ".")   # 1.234,56
    elif "," in cleaned:
        cleaned = cleaned.replace(",", ".")                    # 3,50
    return f"{float(cleaned):.2f}"

from datetime import datetime

DATE_FORMATS = ("%Y-%m-%d", "%d.%m.%Y", "%d/%m/%Y")

def format_date(raw, out="%d.%m.%Y"):
    text = str(raw or "").strip()
    for fmt in DATE_FORMATS:
        try:
            return datetime.strptime(text, fmt).strftime(out)
        except ValueError:
            continue
    return None   # unparseable beats guessed

def label_case(raw, style="upper"):
    text = " ".join(str(raw or "").split())   # collapse stray whitespace
    return text.upper() if style == "upper" else text.title()

Fíjate en los retornos deliberados de None. Un valor que no se puede formatear debería fallar de forma visible en la siguiente pasada, no convertirse en un 0.00 de aspecto plausible.

Pasada 2: Validar

La validación es lo que impide que un precio incorrecto llegue silenciosamente a la impresora. Comprueba que los campos de los que dependes existen y están bien formados, y haz que cada mensaje sea lo bastante específico como para localizar el registro.

def validate_record(record):
    """Return a list of 'field: reason' strings. Empty list means OK."""
    errors = []

    sku = (record.get("sku") or "").strip()
    if not sku:
        errors.append("sku: missing")
    elif len(sku) < 8:
        errors.append(f"sku: shorter than 8 characters ({sku!r})")

    price = record.get("price")
    if price is None:
        errors.append("price: not parseable")
    elif not (0.01 <= price <= 9999.99):
        errors.append(f"price: out of range ({price!r})")

    if record.get("best_before") is None:
        errors.append("best_before: unparseable date")

    return errors

Un mensaje como price: not parseable ('0,00') le dice a un operador qué campo mirar y qué valor lo causó. Un mensaje como invalid data le dice que te llame.

price: not parseable ('0,00')
sku: shorter than 8 characters ('4711')
best_before: unparseable date (row: Espresso 250g)

Pasada 3: Transformar

Solo después de que el valor esté formateado y validado deberías derivar de él valores de visualización: un código de producto combinado, un prefijo de proveedor recortado, un nombre corto para un campo estrecho.

def product_code(record, prefix="SUP-"):
    supplier = (record.get("supplier_code") or "").strip()
    if supplier.startswith(prefix):
        supplier = supplier[len(prefix):]
    sku = (record.get("sku") or "").strip()
    return f"{supplier}-{sku}".strip("-")

Dónde vive el script en el flujo de trabajo

En RSJ LPSNG adjuntas el bloque de script a un campo de la etiqueta en el diseño. La plataforma lo ejecuta como parte del trabajo normal de impresión o renderizado, la misma ejecución que también gestiona la salida en PDF o PNG y la impresión directa a través de la interfaz de servicio web. No hay ningún proceso auxiliar que iniciar ni ningún problema de ordenación que razonar.

Eso importa para el traspaso. La regla de formateo forma parte de la definición de la etiqueta, así que se mueve con la plantilla en lugar de quedarse en la máquina de quien la escribió.

La forma difícil frente a la forma gestionada

La forma difícil es la que Mara casi eligió: un script separado que reescribe archivos CSV o Excel antes de que se alimenten a una herramienta de impresión. Tiene su propia historia de despliegue, sus propios modos de fallo y su propia suposición silenciosa de que todo el mundo recuerda ejecutarlo antes de imprimir.

La forma gestionada coloca el bloque de script de Python en el propio campo en RSJ LPSNG. El formateo y la validación viajan con la etiqueta. La misma etiqueta se puede renderizar como PDF o PNG, o enviarse a impresión directa a través de la interfaz de servicio web, y la lógica del campo es la misma en todos los casos porque pertenece a la etiqueta, no a un paso externo.

Lista de comprobación para tu primer script de campo

• Empieza con un campo y una regla. Formatea el precio, renderiza un PDF de muestra e inspecciónalo. Solo entonces pasa al siguiente campo.
• Haz que los fallos sean localizables. Cada mensaje de validación debería nombrar el campo y mostrar el valor problemático.
• Prueba con entradas deliberadamente desordenadas. Celdas vacías, espacios en blanco extra, formatos de fecha mixtos, un precio negativo, un precio de 0.00, un SKU con la longitud incorrecta.
• Decide entre transformar y buscar. Los archivos de Excel pueden servir tanto como archivos de datos como de búsqueda, así que un nombre de proveedor puede pertenecer a una hoja de referencia en lugar de derivarse en el script. El lado de la fuente de datos está cubierto en Cómo imprimir etiquetas con código de barras desde Excel.
• Renderiza antes de ejecutar. Una prueba en PDF de tres registros desordenados cuesta un minuto; una reimpresión de cuarenta etiquetas de estantería incorrectas cuesta una mañana.

Qué evitar

No entierres las reglas de negocio en el diseño. Mantén el formateo y la validación en el script de campo y las decisiones de diseño en el editor de diseño. Mezclarlos significa que un ajuste de diseño puede cambiar silenciosamente un formato de precio.

No conviertas silenciosamente datos incorrectos en un valor plausible. Una etiqueta que imprime con confianza el precio incorrecto es peor que un trabajo que falla de forma ruidosa. Devuelve None y deja que la validación lo detecte.

No dupliques la misma transformación en muchos campos. Si seis campos necesitan el mismo formato de precio, un enfoque compartido supera a seis bloques copiados y pegados que se desvían entre sí. La inconsistencia entre campos de la misma etiqueta es una de las fuentes de errores más comunes.

No adivines con entradas ambiguas. 03/04/2026 es el 4 de marzo o el 3 de abril. Fija el formato en el origen; un script que adivina se equivocará para alguien.

No trates el script como un sustituto de las pruebas. Renderiza etiquetas de muestra y míralas. Los scripts de campo reducen el número de sorpresas, no eliminan la necesidad de comprobar.

Preguntas frecuentes

¿Dónde se ejecutan los bloques de script de Python en RSJ LPSNG?

Los bloques de script de Python se adjuntan a los campos de la etiqueta y acceden y modifican los valores de los campos antes de imprimir, como parte de la definición de la etiqueta en la plataforma.

¿Necesito construir un pipeline separado de limpieza de datos?

No. El script de campo gestiona el formateo, la validación y la transformación dentro de la propia etiqueta, así que no necesitas un script auxiliar que reescriba tus archivos de datos antes de que lleguen al motor de impresión.

¿Puedo seguir enviando trabajos de forma programática?

Sí. La interfaz de servicio web te permite enviar trabajos de impresión y renderizar etiquetas individuales como PDF o PNG, y el modelo OAuth2 cubre la conexión de sistemas externos con una única URL de registro.

¿Se aplica la misma lógica de campo a PDF, PNG e impresión directa?

El renderizado de PDF/PNG y la impresión directa son rutas de salida documentadas de la interfaz de servicio web, y la lógica de campo pertenece a la definición de la etiqueta que usan esas rutas. Las etiquetas electrónicas de estantería son una vía separada con su propia interfaz JSON neutral respecto al proveedor (ESLSEND); consulta la documentación de la interfaz ESL en lugar de asumir que la ruta de impresión se aplica sin cambios.

¿Pueden los no desarrolladores usar una etiqueta que contiene scripts de campo?

Sí. Una vez que el script está adjunto al campo, imprimir la etiqueta no requiere escribir ni leer Python. Quien ejecuta el trabajo selecciona los datos e imprime; el formateo y la validación ocurren como parte de la etiqueta.

¿Esto reemplaza al editor de diseño?

No. El editor de diseño se encarga del diseño; los scripts de campo de Python se encargan de los datos que fluyen hacia cada campo. Son partes complementarias de la misma etiqueta.

Conclusión

La solución de Mara no fue un mejor script de exportación. Fue mover la regla a donde realmente se usa el valor: un campo de precio que formatea una coma decimal en 3.50, se niega a imprimir una celda vacía y elimina un prefijo de proveedor a la salida. La dueña de la tienda conservó su hoja de cálculo. Las etiquetas dejaron de estar mal.

Next Generation Label Printing System está construido en torno a exactamente esta separación: diseño en el editor de diseño, control de datos en los scripts de campo y una interfaz de servicio web cuando quieres dirigir trabajos de forma programática. Empieza con un campo, una regla y un PDF renderizado. Luego entrégalo.

Entradas relacionadas

• ¿Qué es la combinación de etiquetas y cómo funciona?
• Cómo diseñar etiquetas de código de barras en un editor de diseño de navegador
• El mejor software de impresión de etiquetas para desarrolladores: guía de compra