Integració telemàtica amb ERP: SAP i Odoo

Una plataforma de gestió de flotes que no parla amb l’ERP genera feina manual duplicada: algú copia quilometratges per a les amortitzacions, una altra persona passa esdeveniments de manteniment al mòdul d’actius, algú factura serveis al client amb dades que arriben tard. En flotes mitjanes, això pot sumar fàcilment entre 15 i 30 hores setmanals d’administració evitable.

La integració entre telemàtica i ERP no és un projecte petit, però tampoc no és el malson que venen alguns consultors. Amb una arquitectura raonable, una API REST ben dissenyada i uns quants webhooks, es fa en setmanes, no en mesos.

Arquitectura típica d’una integració de telemàtica amb l’ERP

El patró que funciona en la majoria de casos és API REST amb esdeveniments per webhook, no la sincronització directa per base de dades ni les cues propietàries. Els motius són tres: l’API REST és estàndard i l’entén qualsevol desenvolupador, el webhook evita el polling constant (que satura els sistemes i en degrada el rendiment) i la combinació permet escalar sense tornar a desplegar res.

L’esquema típic té tres components:

1. Plataforma de telemàtica (origen de dades): exposa una API REST autenticada i emet webhooks quan es produeixen esdeveniments rellevants (avaria detectada, fi de servei, entrada en una geofence)
2. Capa d’integració (middleware o connector natiu): tradueix el model de dades de la plataforma al model de l’ERP, gestiona els reintents, l’autenticació i els errors
3. ERP (destinació): rep les dades mapades a l’objecte correcte (ordre de treball, registre d’actiu, línia de factura)

En projectes amb diversos sistemes de destinació (ERP + BI + CRM, per exemple), el més raonable és muntar la capa d’integració com un hub central, no integracions punt a punt que es tornen impossibles de mantenir al cap de sis mesos.

Quines dades circulen entre la telemàtica i l’ERP

No totes les dades de telemàtica han de ser a l’ERP. La selecció importa perquè cada flux actiu és un punt de fallada més que cal mantenir. Els quatre fluxos que sí que aporten valor a la majoria d’empreses:

Quilometratge per a l’amortització i el valor comptable

El quilometratge de cada vehicle, exportat mensualment o trimestralment al mòdul d’actius de l’ERP, permet calcular l’amortització real per ús en lloc d’una amortització lineal genèrica. En flotes grans, això canvia de manera significativa el valor net comptable de la flota.

Implementació: una crida batch des de l’ERP a l’endpoint /vehicles/{id}/odometer al tancament de mes, o un webhook mensual programat.

Esdeveniments de manteniment com a ordres de treball

Quan la telemàtica detecta una alerta predictiva (bateria degradada, pressió d’oli anòmala, codi DTC rellevant), el flux correcte és generar automàticament una ordre de treball al mòdul de manteniment de l’ERP, assignada al taller responsable i amb el codi d’avaria precarregat.

Això evita el desfasament habitual entre el moment en què l’alerta apareix al tauler de flota i el moment en què algú la trasllada manualment al sistema on es gestiona la feina del taller. La diferència entre detectar i actuar passa de dies a hores.

El mòdul de manteniment predictiu es descriu en detall a la pàgina de manteniment, i la integració amb l’ERP es munta sobre els endpoints documentats a l’apartat d’integracions.

Temps al client per a la facturació de serveis

En empreses que facturen serveis per temps o per presència (instal·lació al client, servei tècnic, manteniment industrial in situ), la telemàtica combinada amb el geofencing del client dona el temps exacte de presència: entrada del vehicle a la zona del client, sortida, durada total.

Aquesta dada exportada a l’ERP genera línies de factura precarregades, que el responsable només ha de validar abans de tancar. L’estalvi de temps administratiu és directe i el client rep una factura amb dades verificables.

Combustible: telemàtica + targetes

El consum mesurat per la telemàtica (lectura del CAN-bus) contrastat amb el proveïment declarat per les targetes de combustible (Solred, Galp Frota, Cepsa Star Direct i similars) detecta dues coses: frau (proveïments que no es reflecteixen al dipòsit) i vehicles amb un consum anòmal (filtre saturat, conducció agressiva, problema mecànic).

L’encreuament es fa normalment en el BI o en el mateix ERP si té un mòdul de gestió de combustible. La telemàtica aporta el consum real, la targeta aporta la despesa real, i la diferència analitzada per vehicle i conductor revela patrons.

Patrons per ERP

Cada ERP té la seva manera d’absorbir dades externes. El que funciona millor en cadascun:

SAP (S/4HANA, ECC)

SAP té diversos camins segons el mòdul de destinació i la versió. Els més nets:

• SAP Integration Suite (abans CPI): bus d’integració natiu de SAP, amb adaptadors per a REST, OData i SOAP. L’opció correcta per a volums seriosos i empreses que ja paguen la llicència de SAP BTP.
• Serveis OData personalitzats: per a empreses que volen exposar endpoints de SAP directament i consumir-los des de la plataforma de telemàtica.
• iDocs: el format històric de SAP. Funciona, però avui es considera legacy i no val la pena començar un projecte nou amb iDocs si hi ha una alternativa REST.

L’error típic amb SAP és donar per fet que qualsevol integració ha de passar per un consultor SAP certificat. Per a un REST senzill no cal; un equip d’integració estàndard ho pot fer si té accés a la documentació dels objectes de destinació.

Microsoft Dynamics 365

L’stack de Microsoft té el camí més amable dels tres per a integracions modernes:

• Power Automate: eina visual que permet muntar fluxos entre Dynamics i API externes sense codi. Va bé per a fluxos senzills i empreses amb perfil low-code.
• Custom connectors: per a fluxos repetitius que mereixen tenir el seu propi connector reutilitzable.
• Dataverse + API: per a integracions serioses amb volum, Dataverse exposa una API REST i Dynamics s’hi connecta de manera nativa.

Power Automate cobreix la majoria de casos de telemàtica en pimes i empreses mitjanes. Per a flotes grans amb un volum alt d’esdeveniments, la combinació Dataverse + Azure Service Bus escala millor.

Odoo

Odoo és el més senzill dels tres per disseny:

• Mòdul XML-RPC / JSON-RPC: API nativa que permet llegir i escriure pràcticament qualsevol objecte d’Odoo des de fora amb autenticació estàndard.
• Mòduls comunitaris de fleet management: n’hi ha diversos que ja tenen un model de dades preparat per a vehicles, conductors i esdeveniments de manteniment. Convé revisar la versió d’Odoo (la diferència entre la v15, la v16 i la v17 en aquests mòduls no és trivial).
• Webhooks: suport natiu des de les versions recents.

Per a empreses que ja fan servir Odoo, el cost d’integrar la telemàtica sol ser el més baix dels tres ERP, normalment entre 80 i 200 hores de desenvolupament segons l’abast.

Errors freqüents en integracions de telemàtica amb l’ERP

Aquests són els que costen temps i diners, ordenats per la freqüència amb què apareixen en projectes reals.

Polling descontrolat en lloc de webhooks

L’error número u. Equips que munten la integració fent que l’ERP pregunti cada minut «hi ha dades noves?» a l’API de telemàtica. Resultat: milers de crides innecessàries al dia, rate limit assolit, dades sempre amb minuts de retard.

El correcte és el webhook: la plataforma de telemàtica avisa l’ERP quan alguna cosa canvia. L’ERP processa l’esdeveniment i, si necessita més context, fa una crida puntual a l’API. Consum baix, dades a l’instant.

Sincronització en temps real quan no aporta res

Cada flux en temps real és un cost d’infraestructura i un punt de fallada. Per a dades que només es fan servir en informes mensuals (quilometratge per a l’amortització, consum agregat), n’hi ha prou amb un batch diari o setmanal. Sincronitzar-ho tot en temps real perquè «queda millor» multiplica el cost de la integració sense cap benefici operatiu real.

La regla pràctica: en temps real, només allò que dispara una acció immediata (avaria que genera una ordre de treball, esdeveniment que avisa el client). La resta, en batch.

Mapatge de dades sense documentar

Equips que munten la integració i deixen el mapatge entre els camps de telemàtica i els camps de l’ERP només al codi. Sis mesos després ningú no recorda per què el camp engine_hours de l’API es mapa al camp working_units_total de l’ERP ni quina transformació s’hi aplica.

Documentar el mapatge de camps abans de programar i mantenir-lo actualitzat evita que la primera revisió funcional sigui una feina d’arqueologia.

Manca de gestió d’errors i reintents

Les API cauen, els webhooks arriben tard, la xarxa d’un client està saturada. La integració ho ha d’assumir des del disseny: cua de reintents amb backoff exponencial, alerta a l’equip tècnic quan un esdeveniment falla més de N vegades, registre persistent de cada esdeveniment processat per poder-lo tornar a processar si alguna cosa va caure durant la nit.

Les integracions que no contemplen errors funcionen tres setmanes i donen problemes el quart mes, just quan l’equip d’implantació ja ha marxat.

Lligar-se al proveïdor amb connectors propietaris

Acceptar que el proveïdor de telemàtica només t’integri amb el teu ERP a canvi d’un «connector propietari» que no exposa documentació és perdre sobirania. Si demà canvies de plataforma de telemàtica, la integració s’ha de refer des de zero.

L’alternativa correcta és una API REST estàndard documentada públicament, que qualsevol equip d’integració pugui fer servir. En la comparativa amb plataformes tancades com Localiza, la manca d’una API oberta és un dels punts més rellevants.

Com planificar el projecte d’integració

Una integració de telemàtica amb l’ERP ben planificada té quatre fases:

Per a flotes mitjanes, el rang total raonable és de 2 a 4 mesos, segons l’ERP, l’abast i la maduresa de l’equip tècnic intern. Els projectes venuts com a «integració en 2 setmanes clau en mà» solen acabar amb fluxos mínims que no cobreixen els casos reals.

Si vols revisar la viabilitat per al teu cas concret (quin ERP fas servir, quins fluxos t’importen, quin volum tens), te l’avaluem sense cost des del formulari de contacte. Et diem amb honestedat si la integració té sentit i quin esforç implica.