Integración telemática con ERP: SAP e Odoo

Unha plataforma de xestión de frota que non fala co ERP xera traballo manual duplicado: alguén copia quilometraxes para as amortizacións, outra persoa pasa eventos de mantemento ao módulo de activos, alguén factura servizos ao cliente con datos que chegan tarde. En frotas medianas isto pode sumar facilmente entre 15 e 30 horas semanais de administración evitable.

A integración entre telemática e ERP non é un proxecto pequeno, pero tampouco é o pesadelo que venden algúns consultores. Cunha arquitectura razoable, unha API REST ben deseñada e uns cantos webhooks, faise en semanas, non en meses.

Arquitectura típica dunha integración de telemática con ERP

O patrón que funciona na maioría dos casos é API REST con eventos por webhook, non a sincronización por base de datos directa nin as colas propietarias. Os motivos son tres: a API REST é estándar e enténdea calquera desenvolvedor, o webhook evita o polling constante (que satura os sistemas e degrada o rendemento) e a combinación permite escalar sen redespregar nada.

O esquema típico ten tres compoñentes:

1. Plataforma de telemática (orixe dos datos): expón unha API REST autenticada e emite webhooks cando ocorren eventos relevantes (avaría detectada, fin de servizo, entrada nunha geofence)
2. Capa de integración (middleware ou conector nativo): traduce o modelo de datos da plataforma ao modelo do ERP e xestiona reintentos, autenticación e erros
3. ERP (destino): recibe os datos mapeados ao obxecto correcto (orde de traballo, rexistro de activo, liña de factura)

En proxectos con varios sistemas de destino (ERP + BI + CRM, por exemplo) o razoable é montar a capa de integración como hub central, e non integracións punto a punto que se volven imposibles de manter aos seis meses.

Que datos viaxan entre a telemática e o ERP

Non todos os datos de telemática teñen que estar no ERP. A selección importa porque cada fluxo activo é un punto de fallo máis que manter. Os catro fluxos que si achegan valor na maioría das empresas:

Quilometraxe para a amortización e o valor contable

A quilometraxe de cada vehículo, exportada mensual ou trimestralmente ao módulo de activos do ERP, permite calcular a amortización real por uso en lugar dunha amortización lineal xenérica. Para frotas grandes, isto cambia o valor neto contable da frota de forma significativa.

Implementación: unha chamada batch desde o ERP ao endpoint /vehicles/{id}/odometer ao peche do mes, ou un webhook mensual programado.

Eventos de mantemento como ordes de traballo

Cando a telemática detecta unha alerta preditiva (batería degradada, presión de aceite anómala, código DTC relevante), o fluxo correcto é xerar automaticamente unha orde de traballo no módulo de mantemento do ERP, asignada ao taller responsable e co código de avaría precargado.

Isto evita o habitual desfase entre o momento en que a alerta aparece no panel da frota e o momento en que alguén a traslada manualmente ao sistema onde se xestiona o traballo do taller. A diferenza entre detectar e actuar pasa de días a horas.

O módulo de mantemento preditivo descríbese en detalle na páxina de mantemento, e a integración co ERP móntase sobre os endpoints documentados no apartado de integracións.

Tempos no cliente para a facturación de servizos

En empresas que facturan servizos por tempo ou por presenza (instalación no cliente, servizo técnico, mantemento industrial in situ), a telemática combinada co geofencing do cliente dá o tempo exacto de presenza: entrada do vehículo na zona do cliente, saída e duración total.

Ese dato exportado ao ERP xera liñas de factura precargadas, que o responsable só ten que validar antes de pechar. O aforro de tempo administrativo é directo e o cliente recibe unha factura con datos verificables.

Combustible: telemática + tarxetas

O consumo medido pola telemática (lectura do CAN-bus) contrastado co abastecemento declarado polas tarxetas de combustible (Solred, Galp Frota, Cepsa Star Direct e similares) detecta dúas cousas: fraude (abastecementos que non se reflicten no depósito) e vehículos cun consumo anómalo (filtro saturado, condución agresiva, problema mecánico).

O cruzamento faise normalmente en BI ou no propio ERP, se ten módulo de xestión de combustible. A telemática achega o consumo real, a tarxeta achega o gasto real, e a diferenza analizada por vehículo e por condutor revela patróns.

Patróns por ERP

Cada ERP ten a súa propia forma de absorber datos externos. O que mellor funciona en cada un:

SAP (S/4HANA, ECC)

SAP ten varios camiños segundo o módulo de destino e a versión. Os máis limpos:

• SAP Integration Suite (antes CPI): bus de integración nativo de SAP, con adaptadores para REST, OData e SOAP. A opción correcta para volumes serios e empresas que xa pagan licenza de SAP BTP.
• Servizos OData personalizados: para empresas que queren expoñer endpoints de SAP directamente e consumilos desde a plataforma de telemática.
• iDocs: o formato histórico de SAP. Funciona, pero hoxe considérase legacy e non paga a pena comezar un proxecto novo con iDocs se hai alternativa REST.

O erro típico en SAP é dar por feito que calquera integración ten que pasar por un consultor SAP certificado. Para un REST simple non é necesario; un equipo de integración estándar pode facelo se ten acceso á documentación dos obxectos de destino.

Microsoft Dynamics 365

A pila de Microsoft ten o camiño máis amable dos tres para integracións modernas:

• Power Automate: ferramenta visual que permite montar fluxos entre Dynamics e API externas sen código. Válida para fluxos sinxelos e empresas con perfil low-code.
• Custom connectors: para fluxos repetitivos que merecen ter o seu propio connector reutilizable.
• Dataverse + API: para integracións serias con volume, Dataverse expón unha API REST e Dynamics conéctase de forma nativa.

Power Automate cobre a maioría dos casos de telemática en pemes e medianas empresas. Para frotas grandes cun volume alto de eventos, a combinación Dataverse + Azure Service Bus escala mellor.

Odoo

Odoo é o máis sinxelo dos tres por deseño:

• Módulo XML-RPC / JSON-RPC: API nativa que permite ler e escribir practicamente calquera obxecto de Odoo desde fóra cunha autenticación estándar.
• Módulos comunitarios de fleet management: existen varios que xa teñen un modelo de datos preparado para vehículos, condutores e eventos de mantemento. Convén revisar a versión de Odoo (a diferenza entre v15, v16 e v17 nestes módulos non é trivial).
• Webhooks: soporte nativo desde as versións recentes.

Para empresas que xa usan Odoo, o custo de integrar a telemática adoita ser o máis baixo dos tres ERP, normalmente entre 80 e 200 horas de desenvolvemento segundo o alcance.

Erros frecuentes nas integracións de telemática con ERP

Estes son os que custan tempo e diñeiro, ordenados pola frecuencia coa que aparecen en proxectos reais.

Polling salvaxe en lugar de webhooks

O erro número un. Equipos que montan a integración facendo que o ERP lle pregunte cada minuto «hai datos novos?» á API de telemática. Resultado: miles de chamadas innecesarias ao día, rate limit alcanzado e datos sempre con minutos de desfase.

O correcto é o webhook: a plataforma de telemática avisa o ERP cando algo cambia. O ERP procesa o evento e, se precisa máis contexto, fai unha chamada puntual á API. Baixo consumo, datos ao instante.

Sincronización en tempo real cando non achega nada

Cada fluxo en tempo real é un custo de infraestrutura e un punto de fallo. Para datos que só se usan en informes mensuais (quilometraxe para a amortización, consumo agregado) abonda cun batch diario ou semanal. Sincronizalo todo en tempo real porque «queda mellor» multiplica o custo da integración sen beneficio operativo real.

A regra práctica: en tempo real, só o que desencadea unha acción inmediata (avaría que xera unha orde de traballo, evento que avisa o cliente). O resto, en batch.

Mapeo de datos sen documentar

Equipos que montan a integración e deixan o mapeo entre os campos da telemática e os campos do ERP só no código. Seis meses despois ninguén lembra por que o campo engine_hours da API se está a mapear ao campo working_units_total do ERP nin que transformación se aplica.

Documentar o mapeo de campos antes de codificar e mantelo actualizado evita que a primeira revisión funcional se converta nun traballo de arqueoloxía.

Falta de xestión de erros e reintentos

As API caen, os webhooks chegan tarde, a rede dun cliente está saturada. A integración ten que asumilo desde o deseño: cola de reintentos con backoff exponencial, alerta ao equipo técnico cando un evento falla máis de N veces e log persistente de cada evento procesado para poder reprocesar se algo caeu pola noite.

As integracións que non contemplan os erros funcionan tres semanas e dan problemas ao cuarto mes, xusto cando o equipo de implantación xa marchou.

Atarse ao provedor con conectores propietarios

Aceptar que o provedor de telemática só te integre co teu ERP a cambio dun «conector propietario» que non expón documentación é perder soberanía. Se mañá cambias de plataforma de telemática, hai que refacer a integración desde cero.

A alternativa correcta é unha API REST estándar documentada publicamente, que poida usar calquera equipo de integración. Na comparativa con plataformas pechadas como Localiza, a falta dunha API aberta é un dos puntos máis relevantes.

Como planificar o proxecto de integración

Unha integración de telemática con ERP ben planificada ten catro fases:

Para frotas medianas, o rango total razoable é de 2 a 4 meses, segundo o ERP, o alcance e a madurez do equipo técnico interno. Os proxectos vendidos como «integración en 2 semanas chave na man» adoitan acabar con fluxos mínimos que non cobren os casos reais.

Se queres revisar a viabilidade para o teu caso concreto (que ERP usas, que fluxos che importan, que volume tes), avaliámolo sen custo desde o formulario de contacto. Dicímosche con honestidade se a integración ten sentido e que esforzo implica.