Integración telemática con ERP: SAP, Dynamics y Odoo

Una plataforma de gestión de flota que no habla con el ERP genera trabajo manual duplicado: alguien copia kilometrajes para amortizaciones, otra persona pasa eventos de mantenimiento al módulo de activos, alguien factura servicios a cliente con datos que llegan tarde. En flotas medianas esto puede sumar fácilmente entre 15 y 30 horas semanales de administración evitable.

La integración entre telemática y ERP no es un proyecto pequeño, pero tampoco es la pesadilla que algunos consultores venden. Con arquitectura razonable, API REST bien diseñada y unos cuantos webhooks, se hace en semanas, no meses.

Arquitectura típica de una integración telemática a ERP

El patrón que funciona en la mayoría de casos es API REST con eventos por webhook, no sincronización por base de datos directa ni colas propietarias. Los motivos son tres: la API REST es estándar y la entiende cualquier desarrollador, el webhook evita el polling constante (que satura sistemas y degrada el rendimiento) y la combinación permite escalar sin redesplegar nada.

El esquema típico tiene tres componentes:

1. Plataforma de telemática (origen de datos): expone API REST autenticada y emite webhooks cuando ocurren eventos relevantes (avería detectada, fin de servicio, entrada en geofence)
2. Capa de integración (middleware o conector nativo): traduce el modelo de datos de la plataforma al modelo del ERP, gestiona reintentos, autenticación y errores
3. ERP (destino): recibe los datos mapeados al objeto correcto (orden de trabajo, registro de activo, línea de factura)

En proyectos con varios sistemas destino (ERP + BI + CRM, por ejemplo) lo razonable es montar la capa de integración como hub central, no integraciones punto a punto que se vuelven inmantenibles a los seis meses.

Qué datos viajan entre telemática y ERP

No todos los datos de telemática tienen que estar en el ERP. La selección importa porque cada flujo activo es un punto de fallo más a mantener. Los cuatro flujos que sí aportan valor en la mayoría de empresas:

Kilometraje para amortización y valor contable

El kilometraje de cada vehículo, exportado mensualmente o trimestralmente al módulo de activos del ERP, permite calcular amortización real por uso en lugar de amortización lineal genérica. Para flotas grandes esto cambia el valor neto contable de la flota de forma significativa.

Implementación: una llamada batch desde el ERP al endpoint /vehicles/{id}/odometer al cierre de mes, o un webhook mensual programado.

Eventos de mantenimiento como órdenes de trabajo

Cuando la telemática detecta una alerta predictiva (batería degradada, presión de aceite anómala, código DTC relevante) el flujo correcto es generar automáticamente una orden de trabajo en el módulo de mantenimiento del ERP, asignada al taller responsable y con el código de avería precargado.

Esto evita el habitual desfase entre que la alerta aparece en el dashboard de flota y que alguien la traslada manualmente al sistema donde se gestiona el trabajo del taller. La diferencia entre detectar y actuar pasa de días a horas.

El módulo de mantenimiento predictivo está descrito en detalle en la página de mantenimiento, y la integración con ERP se monta sobre los endpoints documentados en el apartado de integraciones.

Tiempos de cliente para facturación de servicios

En empresas que facturan servicios por tiempo o por presencia (instalación a cliente, servicio técnico, mantenimiento industrial in situ) la telemática combinada con geofencing del cliente da tiempo exacto de presencia: entrada del vehículo en zona del cliente, salida, duración total.

Ese dato exportado al ERP genera líneas de factura precargadas, que el responsable solo tiene que validar antes de cerrar. El ahorro de tiempo administrativo es directo y el cliente recibe factura con datos verificables.

Combustible: telemática + tarjetas

El consumo medido por telemática (lectura del CAN-bus) contrastado con el repostaje declarado por las tarjetas de combustible (Solred, Galp Frota, Cepsa Star Direct y similares) detecta dos cosas: fraude (repostajes que no se reflejan en depósito) y vehículos con consumo anómalo (filtro saturado, conducción agresiva, problema mecánico).

El cruce se hace típicamente en BI o en el propio ERP si tiene módulo de gestión de combustible. La telemática aporta el consumo real, la tarjeta aporta el gasto real, y la diferencia analizada por vehículo y conductor revela patrones.

Patrones por ERP

Cada ERP tiene su propia forma de absorber datos externos. Lo que mejor funciona en cada uno:

SAP (S/4HANA, ECC)

SAP tiene varios caminos según el módulo destino y la versión. Los más limpios:

• SAP Integration Suite (antes CPI): bus de integración nativo de SAP, con adaptadores para REST, OData, SOAP. La opción correcta para volúmenes serios y empresas que ya pagan licencia SAP BTP.
• OData services personalizados: para empresas que quieren exponer endpoints SAP directamente y consumir desde la plataforma de telemática.
• iDocs: el formato histórico de SAP. Funciona pero hoy se considera legacy y no merece la pena empezar un proyecto nuevo con iDocs si hay alternativa REST.

El error típico en SAP es asumir que cualquier integración tiene que pasar por consultor SAP certificado. Para REST simple no es necesario; un equipo de integración estándar puede hacerlo si tiene acceso a documentación de los objetos destino.

Microsoft Dynamics 365

El stack Microsoft tiene el camino más amable de los tres para integraciones modernas:

• Power Automate: herramienta visual que permite montar flujos entre Dynamics y APIs externas sin código. Bien para flujos sencillos y empresas con perfil low-code.
• Custom connectors: para flujos repetitivos que merecen tener su propio connector reutilizable.
• Dataverse + API: para integraciones serias con volumen, Dataverse expone API REST y Dynamics se conecta nativamente.

Power Automate cubre la mayoría de casos de telemática en pymes y medianas. Para flotas grandes con volumen alto de eventos, la combinación Dataverse + Azure Service Bus escala mejor.

Odoo

Odoo es el más sencillo de los tres por diseño:

• Módulo XML-RPC / JSON-RPC: API nativa que permite leer y escribir prácticamente cualquier objeto Odoo desde fuera con autenticación estándar.
• Módulos comunitarios de fleet management: existen varios que ya tienen modelo de datos preparado para vehículos, conductores, eventos de mantenimiento. Conviene revisar la versión de Odoo (la diferencia entre v15, v16 y v17 en estos módulos no es trivial).
• Webhooks: soporte nativo desde versiones recientes.

Para empresas que ya usan Odoo el coste de integrar telemática suele ser el más bajo de los tres ERP, típicamente entre 80 y 200 horas de desarrollo según alcance.

Errores frecuentes en integraciones telemática a ERP

Estos son los que cuestan tiempo y dinero, ordenados por frecuencia con la que aparecen en proyectos reales.

Polling salvaje en lugar de webhooks

El error número uno. Equipos que montan la integración haciendo que el ERP pregunte cada minuto “¿hay datos nuevos?” a la API de telemática. Resultado: miles de llamadas innecesarias al día, rate limit alcanzado, datos siempre con desfase de minutos.

Lo correcto es webhook: la plataforma de telemática avisa al ERP cuando algo cambia. El ERP procesa el evento y, si necesita más contexto, hace una llamada puntual a la API. Bajo consumo, datos al instante.

Sincronización en tiempo real cuando no aporta

Cada flujo en tiempo real es un coste de infraestructura y un punto de fallo. Para datos que solo se usan en reportes mensuales (kilometraje para amortización, consumo agregado) basta con batch diario o semanal. Sincronizar todo en tiempo real porque “queda mejor” multiplica el coste de la integración sin beneficio operativo real.

La regla práctica: en tiempo real solo lo que dispara una acción inmediata (avería que genera orden de trabajo, evento que avisa al cliente). El resto, batch.

Mapeo de datos sin documentar

Equipos que montan la integración y dejan el mapeo entre campos de telemática y campos del ERP solo en el código. Seis meses después nadie recuerda por qué el campo engine_hours de la API se está mapeando al campo working_units_total del ERP y qué transformación se aplica.

Documentar el mapeo de campos antes de codificar y mantenerlo actualizado evita que la primera revisión funcional sea una arqueología.

Falta de gestión de errores y reintentos

Las APIs caen, los webhooks llegan tarde, la red de un cliente está saturada. La integración tiene que asumir esto desde el diseño: cola de reintentos con backoff exponencial, alerta a equipo técnico cuando un evento falla más de N veces, log persistente de cada evento procesado para poder reprocesar si algo se cayó por la noche.

Integraciones que no contemplan errores funcionan tres semanas y dan problemas el cuarto mes, justo cuando el equipo de implantación ya se ha ido.

Atarse al proveedor con conectores propietarios

Aceptar que el proveedor de telemática solo te integre con tu ERP a cambio de un “conector propietario” que no expone documentación es perder soberanía. Si mañana cambias de plataforma de telemática, la integración hay que rehacerla desde cero.

La alternativa correcta es API REST estándar documentada públicamente, que cualquier equipo de integración pueda usar. En la comparativa con plataformas cerradas como Localiza la falta de API abierta es uno de los puntos más relevantes.

Cómo planificar el proyecto de integración

Una integración telemática a ERP bien planificada tiene cuatro fases:

Fase	Duración típica	Entregable
Análisis de flujos prioritarios	1-2 semanas	Documento con flujos a integrar, frecuencia y volumen estimado
Diseño de mapeo y arquitectura	1-2 semanas	Documento técnico con endpoints, eventos, transformación de datos
Desarrollo e integración	4-8 semanas	Integración funcional en entorno de pruebas
Pruebas, ajustes y paso a producción	2-4 semanas	Integración estable en producción + documentación

Para flotas medianas el rango total razonable es de 2 a 4 meses, según el ERP, el alcance y la madurez del equipo técnico interno. Proyectos vendidos como “integración en 2 semanas llave en mano” suelen acabar con flujos mínimos que no cubren los casos reales.

Si quieres revisar viabilidad para tu caso concreto (qué ERP usas, qué flujos te importan, qué volumen tienes), te lo evaluamos sin coste desde el formulario de contacto. Te decimos honestamente si la integración tiene sentido y qué esfuerzo implica.