Los lectores funcionan. Las etiquetas se leen al 98 %. Y tres meses después de la puesta en marcha el equipo financiero revisa ajustes de inventario que nadie puede explicar. Casi todos los fallos de RFID que no son de física son fallos de integración: eventos que llegan en orden incorrecto, el mismo palé contado dos veces, o un middleware que escribe en el ERP una cantidad que el ERP nunca podrá auditar.

Este artículo trata la capa entre el lector y el sistema de negocio: cómo diseñarla para que las cifras de Odoo, SAP o Yonyou se sostengan en el cierre de mes.

¿Qué debe asumir la integración y qué debe quedarse en el ERP?

Reparta responsabilidades por escrito y llévelo al alcance del contrato. La ambigüedad aquí es lo que produce dos sistemas que creen que el otro es la autoridad.

Capa de borde: conectividad de lectores, configuración de antenas, filtrado de lecturas, supresión de duplicados, resolución de etiqueta a SKU, marcas de tiempo e identificador de evento.
Middleware: orden, reintentos, cola de mensajes fallidos, enriquecimiento con contexto (muelle, operario, orden de trabajo) y el mapeo a un documento de negocio.
ERP: valoración, asignación, cálculo de disponibilidad, contabilización y pista de auditoría.

La regla que salva más proyectos: el middleware nunca escribe stock.quant directamente. Envía un documento —recepción, transferencia o ajuste de conteo— y deja que la lógica del propio ERP decida qué pasa con el stock. La escritura directa omite la auditoría, omite la valoración y se rompe el día de la actualización.

¿Qué patrón encaja con su volumen: fichero, API o flujo de eventos?

Elija con números medidos, no con preferencias del proveedor. Los tres patrones conviven sin problema.

Menos de 5.000 eventos por turno: el intercambio de ficheros cada hora o cada noche es suficiente y es lo más fácil de conciliar. Un fichero por sede, nombres deterministas, suma de control en el manifiesto.
De 5.000 a 50.000 eventos por hora: llamadas REST sincrónicas, en lotes de 100 a 500, cada una con clave de idempotencia.
Por encima de eso, o cuando la latencia decide el resultado del negocio (un muelle que debe confirmar en segundos): un flujo de eventos, MQTT del lector al borde y Kafka o RabbitMQ del borde al ERP.

La latencia importa más que el caudal. Una confirmación de recepción que llega veinte minutos tarde es un problema de negocio, no de informática. Mida el p95 en el muelle, no la media del laboratorio.

Odoo: cómo recibir eventos RFID sin corromper stock.quant

Odoo permite escribir casi cualquier cosa. Precisamente por eso la integración necesita disciplina.

Un tipo de operación dedicado por flujo: Recepción RFID, Transferencia interna RFID, Conteo RFID. Los informes y los permisos siguen al tipo de operación.
Para conteos, use el asistente de ajuste de inventario: escriba inventory_quantity en la fila del quant y luego llame a action_apply_inventory. Nunca escriba el campo quantity directamente; el asistente crea el movimiento auditable.
Asigne a cada evento un identificador externo estable en un campo personalizado con índice único, para que un reintento no genere una segunda línea de movimiento.
Procese de 200 a 500 líneas por transacción. Los lotes mayores bloquean filas de producto y bloquean a otros usuarios sin ningún beneficio.
Mantenga los campos específicos de RFID (rfid_epc, rfid_event_id, rfid_reader) en un modelo aparte o como campos calculados no almacenados. stock.quant se lee constantemente; engordarla penaliza todo el sistema.

SAP: IDoc, OData y la cuestión del middleware

SAP quiere documentos de material, no lecturas de etiqueta. Hay tres caminos realistas y cada uno tiene su caso.

IDoc (WMMBID02, MBGMCR, DESADV): maduro, orientado a lotes y la opción menos disruptiva si ya opera PI/PO.
OData y API REST en S/4HANA: mejor para contabilización casi en tiempo real y mucho más simple de versionar que las extensiones IDoc a medida.
Una capa MII o EWM dedicada: solo se justifica por encima de unos pocos millones de eventos diarios, o cuando EWM ya es el sistema de registro del almacén.

El error recurrente es elegir el tipo de movimiento por comodidad y no por su significado contable. 261 y 262 para consumo, 101 y 102 para recepción, 311 y 312 para traslado: cada uno tiene consecuencias en costes y en el cierre. Que el controller firme la tabla de mapeo antes de escribir la primera línea de código.

Yonyou, Kingdee y ERP locales: primero OpenAPI

Los ERP chinos —Yonyou U8+, Yonyou BIP y NC Cloud, Kingdee K/3 y Cloud— exponen OpenAPI REST y un bus de mensajes. Úselos, y úselos de forma asíncrona.

Extraiga una instantánea de inventario a diario y concíliéla con su propio conteo; envíe las transacciones como documentos de negocio completados.
La escritura directa en la base de datos de U8 es práctica habitual en el mercado local y es el atajo más caro disponible. Omite la auditoría, se rompe con los parches y convierte la conciliación de cierre en una negociación política.
Confirme el límite de peticiones y el mapeo de almacén, lote y número de serie antes de prometer tiempo real. Muchas implantaciones locales son en realidad casi reales, y prometer otra cosa es cómo un proyecto pierde credibilidad en la segunda semana.

Qué falla en producción y cómo diseñar para ello

Seis modos de fallo explican la mayoría de los incidentes, y cada uno tiene respuesta de diseño.

Desfase de reloj entre lectores: registre occurred_at (lector) y received_at (servidor) y no ordene solo por el primero.
EPC duplicados: dos etiquetas grabadas con el mismo identificador generan movimientos contradictorios. Detéctelo en el borde y rechace antes de que llegue al ERP.
Acumulación de lecturas offline: un lector que se reconecta tras dos horas no debe reproducir 40.000 lecturas obsoletas como eventos actuales. Limite la ventana y marque los eventos tardíos.
Entrega fuera de orden: un artículo no puede salir de una ubicación antes de haber llegado. Rechace o ponga en cuarentena, nunca acepte en silencio.
Zona horaria: guarde UTC, muestre hora local y pruebe un cambio de horario antes de salir a producción.
Fallo parcial silencioso: un lote de 500 donde fallan 3 filas debe informar 497 correctas y 3 pendientes, no un error genérico.

Lista de comprobación antes de firmar el SOW

¿Quién genera el identificador de evento y es único entre sedes y años?
¿Qué sistema tiene autoridad para convertir una lectura en un movimiento?
¿Es idempotente cada escritura y se ha probado con un mensaje duplicado a propósito?
¿Cuál es la latencia p95, medida en el muelle?
¿Cómo aparecen las excepciones y quién las cierra dentro de qué SLA?
¿Puede reproducir un día completo de eventos sin duplicar el stock?
¿Han firmado finanzas o controlling el mapeo de tipos de movimiento y de operación?

Si alguna respuesta es el nombre de una persona y no un documento, la integración aún no está especificada, y el coste de esa ambigüedad se pagará en ajustes de inventario.