Cómo integrar una aplicación con un ERP: datos y decisiones antes de empezar

Para integrar una aplicación con un ERP no basta con conectar dos sistemas. Antes de programar hay que acordar qué proceso se quiere resolver, qué datos se intercambiarán, qué sistema será responsable de cada dato y cómo se tratarán los errores. Esa preparación reduce ambigüedades y evita que una conexión técnica cree registros duplicados o estados incoherentes.

Por ejemplo, una aplicación comercial hipotética puede necesitar consultar clientes, productos y disponibilidad, crear pedidos en el ERP y recibir después su estado de validación o expedición. El alcance no sería «conectar la app al ERP», sino definir con precisión ese flujo y sus excepciones.

1. Delimita el proceso antes de elegir tecnología

Empieza por un único proceso concreto. Describe qué lo inicia, quién interviene y qué resultado debe producirse en cada sistema. No decidas primero si usarás una API, ficheros o webhooks: esas opciones solo tienen sentido cuando el flujo está claro.

• Evento de inicio: ¿un usuario confirma un pedido, cambia un cliente o se actualiza un artículo?
• Acción esperada: ¿la aplicación consulta información, crea un registro, modifica uno existente o solo recibe un estado?
• Sistemas implicados: ERP, aplicación nueva y, si procede, otros sistemas como CRM, almacén o plataforma de integración.
• Responsables funcionales: personas de negocio, administración, operaciones, tecnología y proveedor del ERP.
• Límites del alcance: deja por escrito qué flujos, datos y excepciones no se cubrirán en esta fase.

Esta definición debe incluir lo que sucede si el ERP rechaza una operación, si falta un dato obligatorio o si el registro ya existe. No conviene convertir el ERP en una copia de la aplicación ni al revés sin haber decidido dónde se gobierna cada información.

2. Qué datos intercambiar al integrar una aplicación con un ERP

La lista de datos necesaria depende del proceso, de la configuración y del modelo de datos de la versión concreta del ERP. Como orientación, clientes, proveedores, artículos o servicios, pedidos, facturas y estados son entidades habituales en integraciones empresariales. La documentación de la API externa de Odoo ilustra operaciones y modelos de ese ERP, pero su disponibilidad puede depender de la versión, los módulos instalados, la configuración y los permisos. No debe utilizarse como una lista universal de campos o capacidades para otros ERP.

La clasificación es orientativa. Un mismo objeto puede gestionarse de manera distinta según el ERP, su configuración y el proceso que se quiere integrar. Intercambia únicamente los campos necesarios para la finalidad definida.

Si intervienen facturas, pagos, datos bancarios, empleados o información personal, el análisis debe ser más cuidadoso: permisos, finalidad, conservación y configuración del ERP pueden condicionar el diseño.

3. Crea una matriz de responsabilidades sobre los datos

Antes de desarrollar, prepara una matriz para cada entidad y campo relevante. Es el documento que transforma las decisiones de negocio en reglas implementables.

Completa la matriz con frecuencia de actualización, permisos de lectura y escritura, campos obligatorios, formatos de fecha y moneda, unidades, impuestos y estados válidos. También debe indicar qué pasa ante altas, bajas, cambios, duplicados y conflictos.

Como plantilla mínima, puedes documentar cada intercambio con estas columnas:

Una regla especialmente importante es decidir la fuente maestra. Si dos sistemas pueden modificar el mismo precio, cliente o pedido sin una regla de prioridad, aparecerán conflictos. La documentación técnica de cada ERP debe confirmarse para conocer sus modelos, permisos y mecanismos disponibles.

Ejemplo hipotético: pedido creado desde una aplicación comercial

Supongamos que un comercial confirma un pedido en una aplicación. La matriz podría establecer que la aplicación envía una solicitud de creación al ERP con una referencia externa única; el ERP valida el cliente, los artículos y los datos obligatorios, y devuelve su identificador interno y el estado inicial del pedido. Si el envío se repite por un error temporal, la referencia externa permite comprobar si el pedido ya fue creado antes de generar otro.

En este ejemplo, operaciones o administración sería el propietario funcional del pedido. Si el ERP rechaza la solicitud por un dato inválido, la aplicación debe mostrar un estado comprensible para el usuario y registrar el motivo para que el responsable pueda revisarlo. Es un ejemplo de diseño, no una integración real ni una regla universal para todos los ERP.

4. Elige una arquitectura acorde al flujo

No existe una arquitectura mejor para todas las empresas. La elección depende de la criticidad del proceso, frecuencia de intercambio, volumen, capacidades del ERP, seguridad, mantenimiento y dependencia que se acepta asumir.

Un webhook suele enviar información a una URL mediante una petición HTTP POST cuando ocurre un evento. Es útil para notificar cambios, pero no garantiza por sí solo entrega única, orden global, consistencia inmediata ni recuperación automática. La documentación de webhooks de Odoo recomienda probarlos en un entorno no productivo y conservar registros para diagnosticar las llamadas.

5. Diseña la sincronización para los casos que fallan

Una integración operativa necesita reglas para los escenarios normales y también para los fallos. Decide primero si la sincronización será unidireccional o bidireccional. La segunda opción exige definir con más rigor qué sistema prevalece y cómo evitar bucles entre actualizaciones.

• Idempotencia: repetir una operación no debe crear dos veces el mismo pedido o registro.
• Deduplicación: conserva identificadores de evento u operación para detectar envíos repetidos.
• Reintentos: distingue los fallos temporales de los errores funcionales que requieren revisión.
• Orden y respuestas parciales: prevé que los mensajes pueden llegar desordenados o que solo una parte de la operación termine correctamente.
• Colas y límites: adapta el ritmo de llamadas a las restricciones confirmadas del ERP.
• Trazabilidad: registra qué se intentó, cuándo, con qué identificadores, cuál fue la respuesta y cómo se resolvió.

Define alertas, una persona o equipo que atienda incidencias y un procedimiento de recuperación. La integración debe poder detenerse, revisarse y reanudarse de forma controlada cuando aparezca una incidencia que no pueda resolverse automáticamente.

6. Protege credenciales, accesos y datos

Las integraciones no deberían depender de cuentas personales. Siempre que el sistema lo permita, utiliza credenciales técnicas separadas, con permisos mínimos y posibilidad de revocación. Algunas APIs admiten claves dedicadas; otras pueden usar mecanismos como OAuth 2.0, que permite otorgar acceso limitado mediante tokens sin entregar directamente las credenciales del usuario a la aplicación cliente.

Guarda claves, tokens y otros secretos fuera del código y de los archivos compartidos. Define quién puede acceder a ellos, cómo se revocan o sustituyen y qué debe ocurrir si se sospecha una exposición. Los registros de trazabilidad no deben incluir tokens, contraseñas, datos bancarios ni otros datos sensibles que no sean necesarios para investigar una incidencia.

Separa los entornos de prueba y producción, protege secretos y comunicaciones, y limita el acceso a quienes lo necesitan. Si hay datos personales, el RGPD establece principios como limitación de la finalidad, minimización de datos, exactitud, conservación limitada e integridad y confidencialidad. También exige medidas de seguridad adecuadas al riesgo. Estos principios y medidas se recogen en los artículos 5 y 32 del RGPD; su aplicación concreta depende del tratamiento y no sustituye el asesoramiento jurídico especializado.

El Esquema Nacional de Seguridad establece principios y medidas para el ámbito previsto por su normativa, pero no es una obligación automática para cualquier pyme privada. Su aplicabilidad depende del sistema o servicio implicado. Cuando el flujo incluya información especialmente sensible o proveedores que traten datos, conviene revisar el caso con los responsables internos y el asesoramiento especializado que corresponda.

7. Prueba la integración y acuerda criterios de aceptación

No pases directamente a producción. Prepara un entorno de pruebas, una copia o mecanismos de restauración, y un procedimiento de vuelta atrás. Deben participar personas que conozcan tanto el proceso como el ERP.

Como mínimo, prueba estos escenarios:

• Altas, modificaciones, anulaciones y consulta de estados.
• Campos obligatorios ausentes, formatos inválidos y estados no permitidos.
• Registros duplicados y recepción repetida del mismo evento.
• Caída temporal de un sistema, tiempo de espera agotado, reintentos y respuesta parcial.
• Cambios simultáneos o conflictos entre los sistemas.
• Conciliación posterior: comprobar que los datos esperados coinciden en la aplicación y el ERP.
• Volumen y límites razonables para el caso de uso concreto.

Los criterios de aceptación deben ser observables. Por ejemplo: qué información debe quedar registrada, qué estado recibe el usuario si se rechaza un pedido y quién revisa los casos que no se puedan recuperar automáticamente. Evita prometer sincronización inmediata si la arquitectura, la red o el ERP no la garantizan.

8. Entregables que conviene cerrar antes de desarrollar

1. Mapa del proceso, sistemas implicados, eventos y excepciones.
2. Catálogo de datos que se consultan, crean, modifican o reciben.
3. Matriz de responsabilidades, sistema maestro e identificadores.
4. Mapa de campos, formatos, validaciones y estados permitidos.
5. Decisión de arquitectura y justificación según el flujo.
6. Contrato de integración: operaciones, modelos, errores, autenticación y versionado. Cuando proceda, una especificación estructurada como OpenAPI puede ayudar a compartir esas reglas entre equipos.
7. Plan de pruebas, criterios de aceptación, monitorización y procedimiento de recuperación.
8. Confirmación de la versión del ERP, permisos disponibles, documentación vigente y límites aplicables.

Checklist para completar los entregables

• Mapa de proceso: evento de inicio, pasos, sistemas, responsables, resultado esperado y excepciones.
• Catálogo de datos: finalidad, campos mínimos, origen, destino, sensibilidad y necesidad de conservación.
• Matriz de mapeo: identificadores, equivalencia entre campos, formato, obligatoriedad, validaciones y regla ante valores no válidos.
• Contrato de integración: operaciones disponibles, autenticación, mensajes de error, límites conocidos, versión y política de cambios.
• Criterios de aceptación: casos que deben funcionar, evidencia que debe quedar registrada, tratamiento de fallos y responsable de aprobar cada flujo.

Cómo decidir una integración con ERP que pueda mantenerse

Antes de encargar desarrollo, comprueba si el ERP o la aplicación ya cubren el flujo con una función estándar o un conector compatible. Puede ser suficiente si el proceso es común y las reglas encajan sin forzar los datos ni perder controles relevantes.

Una integración propia puede tener sentido cuando intervienen varios sistemas, hay transformaciones específicas, se necesitan reglas de negocio particulares o no existe un conector que resuelva el flujo con los controles necesarios. Una aplicación a medida debe valorarse después de definir proceso, datos y responsabilidades; no como sustituto de ese trabajo previo.

El objetivo no es elegir la tecnología más compleja, sino contar con un flujo entendido, datos gobernados y una forma realista de operar la integración cuando haya cambios o incidencias.