Integrar RFID con WMS o ERP: eventos, responsabilidades y pruebas

El error común: tratar cada lectura como una transacción

Un lector RFID UHF puede reportar la misma etiqueta muchas veces durante una lectura, además de etiquetas de tarimas vecinas que nunca se movieron. Si esas lecturas llegan tal cual a un WMS o ERP, el resultado típico son movimientos duplicados, existencias que suben sin motivo y un equipo de TI culpando al hardware. La causa rara vez es la antena: es una interfaz que mezcla observaciones físicas con hechos de negocio.

El estándar de GS1 para compartir eventos de trazabilidad separa ambas capas. En su descripción de la arquitectura, un nivel de filtrado y colección entrega listas de identificadores sin duplicados, y una capa de flujo de trabajo les da contexto de proceso antes de generar eventos; puedes verlo en el estándar EPCIS 2.0 de GS1. No necesitas adoptar EPCIS para aplicar la idea: el sistema transaccional debería recibir “se recibieron estos artículos contra esta orden”, no “la antena 3 vio el EPC X”.

Qué eventos sí merecen llegar al WMS o ERP

Antes de hablar de formato, decide qué hechos cambian el estado del negocio. Una regla útil: si nadie tomaría una decisión distinta con ese dato, no viaja al sistema transaccional; se queda en la capa de captura o en un registro técnico.

Observa que cada fila tiene un inicio y un fin lógicos. Un portal no “termina” solo: alguien o algo debe cerrar la sesión (el supervisor que confirma el embarque, un temporizador acordado, la lectura de la etiqueta de la tarima). Sin esa frontera, la integración no sabe cuándo emitir el evento.

Quién hace qué: capas y responsables

La mayoría de los fallos de integración son fallos de responsabilidad: todos asumen que otro deduplica. Escribe una matriz corta y fírmala entre operaciones, TI y proveedor de la solución.

• Captura (lector o PDA): lee etiquetas y entrega observaciones con hora y dispositivo. No decide inventario.
• Middleware o capa de aplicación: filtra lecturas ajenas, deduplica, agrupa por sesión y arma el evento. Ver el artículo sobre funciones de middleware.
• WMS o ERP: valida contra maestros, órdenes y reglas; acepta, rechaza o pone en cuarentena.
• Dueño de datos maestros: mantiene la relación entre EPC, GTIN y SKU interno.
• Operación: resuelve excepciones (artículo no esperado, falta de unidades) con un procedimiento, no con correos.

La relación entre el EPC codificado y los códigos GS1 está definida en el Tag Data Standard de GS1; ahí se apoya la traducción entre lo que dice la etiqueta y el SKU que entiende tu ERP, pero el mapeo interno sigue siendo responsabilidad tuya.

Contrato de datos mínimo para cada evento

Un contrato claro evita discusiones posteriores. Para un evento de recepción puede bastar con: identificador único del evento, tipo, momento en que ocurrió (con zona horaria), ubicación lógica, documento de referencia, lista de identificadores o cantidades por artículo, dispositivo o fuente y versión del contrato. Los campos de “qué, cuándo, dónde y por qué” que describe la especificación EPCIS son un buen punto de partida aunque no uses su formato.

Define también qué pasa con lo que llega mal: ¿el WMS responde con un código de error por línea o rechaza todo el lote? ¿Qué reintentos se permiten? La semántica de reintentos y de métodos idempotentes en HTTP se explica en RFC 9110; ayuda a entender por qué un reintento no debe duplicar el efecto si el contrato está bien diseñado.

Ejemplo hipotético: recepción de 40 cajas con una orden abierta

Ejemplo ilustrativo, no es un caso real. Un almacén espera 40 cajas etiquetadas contra una orden de compra. El operador abre la sesión de recepción desde su PDA, indicando el documento. El lector portátil registra 46 EPC distintos: 40 esperados, 4 que pertenecen a otra tarima cercana y 2 etiquetas sueltas de material de empaque que quedaron codificadas por error.

El middleware separa los 6 EPC que no corresponden a artículos con SKU conocido en esa orden y los envía como “no esperados” para revisión. El WMS recibe un evento con 40 líneas y 6 excepciones. Un supervisor confirma y el evento de recepción se cierra. Nota que el número de lecturas brutas no aparece en el ERP: solo importan artículos únicos y su estado.

Lo que este ejemplo no demuestra es la exactitud real de tu operación; eso se mide en piloto, con tus etiquetas y tu producto.

Pruebas que conviene exigir antes de arrancar

• Enviar el mismo evento dos veces y comprobar que el inventario cambia una sola vez.
• Cortar la red entre middleware y WMS durante una recepción y verificar que los eventos se conservan y se envían en orden al volver.
• Presentar un EPC sin SKU, un SKU inactivo y una orden cerrada; confirmar que el rechazo es explicable.
• Cambiar la hora del dispositivo y revisar qué ocurre con la hora del evento.
• Conciliar un conteo físico manual contra lo reportado por el sistema en una zona acotada y documentar la diferencia sin esconderla.

Una lista más completa de casos funcionales, sin conexión y de falla está en el artículo sobre pruebas de aceptación de este mismo bloque.

Límites y fallas previsibles

Una integración bien diseñada no corrige una lectura RFID deficiente: si las etiquetas están mal colocadas o hay material que interfiere, el evento será incompleto aunque el contrato sea perfecto. Tampoco hay una pila universal: ERP y WMS exponen interfaces distintas (API, archivos, colas) y cada una exige su propio manejo de errores. Pide al proveedor del WMS o ERP la documentación de su interfaz de entrada y confirma por escrito qué soporta tu versión, en lugar de suponerlo.

Siguiente paso

Escribe en una hoja los cuatro eventos de negocio más importantes de tu operación, su disparador y la validación que haría tu sistema. Con eso es posible conversar con TI y proveedores. Si quieres revisar el caso con ARKCOM, puedes escribir desde garkcom.com/contact.