Cómo conectar la planta con el ERP sin duplicar datos.

Una conexión entre planta y ERP debe resolver un intercambio de negocio: recibir una orden, comunicar una cantidad o registrar un consumo. Mover un mensaje no basta; hay que saber si fue recibido, validado y aplicado, y poder explicar qué ocurrió si la respuesta no llegó.

Empieza, por ejemplo, por comunicar la producción de una orden. Describe qué inicia el envío, qué sistema identifica la orden y qué significa «registrada». Aclara si se comunica una cantidad parcial, el cierre de una operación o una corrección posterior. Son hechos distintos y conviene tratarlos de forma explícita.

En sentido inverso, enviar una orden desde el ERP a una aplicación de planta no implica autorizar una acción automática sobre una máquina. El alcance debe separar planificación, ejecución, supervisión y control. La integración de sistemas industriales define esas responsabilidades antes de construir el conector.

Define qué sistema mantiene artículos, unidades, órdenes, operaciones, lotes y ubicaciones. Documenta cómo se relacionan sus identificadores y qué ocurre si falta una correspondencia. Un conector puede transportar correctamente un mensaje que el negocio no puede aplicar.

Especifica también quién puede corregir una cantidad, cómo se autorizan los cambios y qué se conserva para auditoría. Evita resolver un error de catálogo sustituyendo un identificador por un valor genérico: es preferible dejar el registro pendiente y explicar el motivo.

Revisa las API o interfaces de integración soportadas por el ERP y sus condiciones de autenticación, permisos, versiones y límites de uso. Una escritura directa en tablas puede saltarse validaciones y crear dependencias difíciles de mantener; no debe ser la opción asumida para una integración nueva.

Como ejemplo de documentación de fabricante, Microsoft presenta las API REST de Business Central como su vía preferida de integración. Dispone de API estándar y permite crear API propias: hay que comprobar si el intercambio de producción requiere una extensión y qué validaciones ejecuta. El diseño de otro ERP debe contrastarse con su propia documentación. En la parte de planta, las soluciones IT/OT determinan cómo obtener y transportar el dato hasta el componente de intercambio.

Incluye un identificador de evento que se conserve si es necesario reenviar el mismo hecho. Acompáñalo del identificador de orden, operación, equipo, instante de origen, cantidad y unidad que requiera el proceso. La clave de deduplicación debe corresponder al hecho de negocio; no basta con generar un identificador distinto en cada intento.

Si el ERP aplica un registro pero se pierde la respuesta, el emisor no sabe todavía si debe reenviarlo. Diseña una forma de consultar o conciliar ese resultado mediante la referencia estable del evento. La deduplicación debe comprobarse en el punto donde se aplica la operación o mediante un mecanismo equivalente; una cola, por sí sola, no garantiza que el efecto de negocio ocurra una única vez.

Separa los errores temporales de comunicación de los rechazos que necesitan una corrección. Define límites de reintento, espera, capacidad de pendientes y un circuito de revisión. Un registro confirmado no debe volver a contabilizarse por reiniciar el servicio.

El equipo necesita consultar cuántos eventos siguen pendientes, qué antigüedad tienen y por qué se han rechazado. Relaciona los registros del conector con sus referencias de planta y ERP. La vista operativa debe ayudar a resolver una incidencia sin obligar a reconstruir todo el intercambio desde archivos dispersos.

Si hace falta una interfaz específica para revisar discrepancias o autorizar correcciones, puede formar parte de una aplicación industrial a medida. Conserva la distinción entre visualizar un error y disponer de permisos para modificar el resultado.

El piloto debe incluir mensajes repetidos, una respuesta perdida, un maestro inexistente, eventos fuera de orden y un reinicio con registros pendientes. Compara el resultado final entre ambos sistemas y documenta cómo se corrigen las diferencias. El criterio de aceptación es un registro de negocio coherente y explicable.

Antes de ampliar a más líneas u operaciones, revisa la arquitectura IT/OT, las capacidades del ERP y la responsabilidad de soporte. No existe un conector universal que elimine la necesidad de acordar esas reglas.