Español
English
Català
Deutsch
Français
Português
Italiano
Polski
Het loont om de middleware weg te halen wanneer die laag een status bijhoudt die Odoo zou moeten hebben: de voorraad die je publiceert, de echte status van elke order, de tracking die terug naar het kanaal gaat. Het loont niet wanneer ze alleen transporteert: ze ontvangt een bestand en zet het ergens anders neer zonder iets te beslissen. Dat is de hele regel. Wat volgt: wanneer het eerlijke antwoord "niet overstappen" is en hoe je de overstap maakt zonder op te houden orders te leveren, verteld vanuit onze eigen migratie naar connectoren die binnen Odoo leven, in productie.
Kernidee: de middleware kost je niet het abonnement. Hij kost je dat de waarheid van je operatie op twee plekken leeft. Elke status die zowel in de tussenlaag als in Odoo bestaat, is een afstemming die iemand met de hand doet of die niemand doet.
Wat de middleware je kost in dagelijks werk, niet in geld
Het argument om een laag weg te halen hebben we al gemaakt met de elektronische factuur in SERES vanuit Odoo, en de vergelijking in de diepte staat in Odoo 19 versus connectoren met middleware. Bij marketplaces en vervoerders is het hetzelfde, vermenigvuldigd met de orders van de dag: vier taken die niemand begroot.
| Taak | Met middleware | Met native koppeling |
|---|---|---|
| Productstamgegevens | Twee: Odoo en de mapping van de middleware | Eén. De mapping naar het kanaal is een veld op het product |
| Orderstatus | Drie waarheden: marketplace, middleware en Odoo | Twee: het kanaal en Odoo, met de externe status naast de order |
| Traceerbaarheid van een zending | Order in Odoo, tracking in de middleware, bevestiging in de marketplace | Order, levering, tracking en bevestiging op dezelfde kaart |
| Wie kijkt in het log | Het paneel van de leverancier, met zijn eigen gebruiker en bewaartermijn | Een Odoo-model met aanvraag en antwoord, filterbaar en met opschoning |
De logregel verdient een waarschuwing: "we hebben het in Odoo" betekent niet dat het ook wordt weggeschreven. Bij de audit van onze Mirakl-connector vroeg de functie die elke aanroep registreerde if not log_model, en de helper gaf een lege recordset terug wanneer alles goed ging; in Odoo is een lege recordset onwaar, dus het loggen was vanaf dag één een no-op. Het bewijs zat in productie: de sequentie van die tabel stond na maanden aan crons nog op NULL. Vandaag is de controle if log_model is False.
Wanneer je niet moet overstappen: de drie duidelijke gevallen
- Meerdere ERP's. Als Odoo de ene entiteit draait en een ander systeem de andere, en beide op dezelfde kanalen verkopen, is de middleware de enige plek waar de gepubliceerde voorraad de som van beide is.
- Orkestratie tussen derden. Als de keten marketplace → externe logistieke operator → vervoerder is en Odoo het pas aan het eind te weten komt, stuurt de laag systemen aan die niet van jou zijn.
- Niemand die Odoo onderhoudt. Een native connector is code binnen je ERP. Als niemand, intern of een partner van Odoo, dat werk gaat doen, is de middleware met zijn abonnement de goedkope optie.
Het migratieplan zonder de operatie stil te leggen
Vier stappen en één principe: de native koppeling begint met lezen en schrijft niet naar buiten totdat ze dagenlang hetzelfde leest als de middleware. We pasten het in juni 2026 toe toen we, in onze eigen productie op Odoo.sh, een oude Amazon-module vervingen door de connector die SP-API vanuit Odoo aanroept.
1. Inventaris van stromen, met richting
Eén rij per stroom: binnenkomende orders, uitgaande voorraad en prijzen, uitgaande tracking, binnenkomende annuleringen en retouren, opgestuurde facturen. Per stroom de richting, frequentie en trigger (cron, webhook of persoon). Een Mirakl-marketplace levert acht tot twaalf rijen op; een vervoerder drie of vier; een ondertekenplatform twee.
2. Volgorde: lezen vóór schrijven
De native connector wordt geïnstalleerd met alle schrijfacties naar de derde partij uitgeschakeld: bij ons een globale schakelaar plus een indicator per account voor elke uitgaande actie. Hij leest alleen orders, statussen en voorraad; de middleware blijft schrijven en niemand stopt met leveren. Hier kwam de eerste fout van de omschakeling naar boven: de nieuwe importer controleerde of een order bestond door naar zijn eigen, net aangemaakte en lege tabel te kijken, en niet naar de verkooporders die het vorige systeem al had aangemaakt. Resultaat: zeventien dubbele, bevestigde verkooporders, die elk opnieuw voorraad reserveerden. De oplossing was de referentie van de marketplace opzoeken in sale.order voordat er iets werd aangemaakt. De regel: dedupliceer tegen de bestemming, nooit tegen de tussentabel van de connector zelf.
3. Parallelle periode met dagelijkse vergelijking
Een of twee weken waarin beide systemen hetzelfde kanaal lezen en elke ochtend een korte lijst: orders die de een importeerde en de ander niet, statussen die niet overeenkomen, SKU's zonder match. Twee dagen op rij nul, en dan pas de eerste schrijfactie.
4. Omschakeling per kanaal, en schrijfacties alleen voorwaarts
Je schakelt één kanaal om, niet alle. En bij het inschakelen van schrijfacties alleen die welke door een overgang worden getriggerd: de zending bevestigen bij het valideren van een levering is veilig, want dat gebeurt één keer per order die echt vertrekt. Wat niet veilig is, is een cron die bestaande records doorloopt en opnieuw verstuurt. Bij onze omschakeling bleven er 534 historische leveringen over, afgerond en door de oude module als "pendiente de sincronizar" gemarkeerd; de herhaal-cron vond ze en stuurde in vier minuten 28 zendingsbevestigingen naar Amazon, voordat we hem uitzetten. De les: voordat je een cron inschakelt die alles doorloopt, breng je de historie die nog in de status staat waarnaar die cron zoekt, in overeenstemming.
De historische gegevens: wat je migreert en wat je alleen-lezen laat
Je migreert wat nog kan veranderen: openstaande orders, de mapping SKU ↔ referentie van het kanaal, zendingen waarvan de tracking nog niet terug is bij de marketplace en lopende retouren. Je migreert niet de aanroepgeschiedenis of afgesloten orders: je vraagt alleen-lezen toegang tot het paneel voor de duur van de reclamatietermijn. Bij onze omschakeling bleven de bedrijfsgegevens onaangeroerd: 1.838 verkooporders en 13.236 producten bleven waar ze waren.
Hoe je controleert dat de native koppeling werkt vóór de omschakeling
Met een echte Odoo-build en de sandbox van de derde partij, niet met mocks. We vertelden het met cijfers in de tests waren groen en de connector werkte niet: een connector met 236 van 236 groene tests op Odoo 19, 18 en 17 had eronder 32 echte fouten, en een andere met 163 van 163 had nooit één logregel geschreven. De drie controles die tellen:
- Het synchronisatievenster vraagt wat gewijzigd is, niet wat aangemaakt is. Dat deden we twee keer fout: de Mirakl-connector stuurde
start_date(aanmaak) in plaats vanstart_update_date, en die van AliExpress filterde op aanmaakdatum sinds de laatste ronde. In beide gevallen kwam een order die 's ochtends was aangemaakt en 's middags verzonden niet meer in het venster en bleef zijn status in Odoo bevroren. - Het log heeft rijen. Tel na de eerste import de records van het logmodel. Nul betekent dat er niet wordt geschreven, niet dat er geen fouten zijn.
- Het spoor staat op de kaart. Vanaf een geïmporteerde order moet je bij de verkooporder, de levering en de tracking kunnen komen zonder Odoo te verlaten.
Wat er daarna overblijft: wie de connector onderhoudt in de volgende Odoo-versie
Dit is het deel dat de middleware je bespaarde en nu van jou is. Elke Odoo-versie verandert iets waar een connector aan raakt: in 19 is read_group in de ORM zelf als verouderd gemarkeerd; in 18 gingen de lijstweergaven van <tree> naar <list>; in 17 draait een ir.cron zonder numbercall één keer en schakelt zichzelf uit. Geen van de drie geeft een fout bij de installatie. Onze connectoren worden tegelijk voor 19, 18 en 17 gepubliceerd en getest op echte builds van elke serie. Beslis vóór de overstap wie dat werk doet: je eigen team, een partner van Odoo, of de auteur van de connector als die hem voor meerdere versies publiceert en migreert zodra de nieuwe uit is.
Als de connector voor je eigen software is, leggen we in Odoo-connector voor jouw software uit hoe we dat doen met technologiepartners; in de catalogus staan de connectoren die al met Amazon, Mirakl, ManoMano, AliExpress en de vervoerders praten. Bij meerdere kanalen hangt de volgorde van omschakelen af van welk kanaal de voorraad publiceert: dat behandelen we in verkopen op meerdere marketplaces vanuit één Odoo en realtime voorraad voor marketplaces.
Beslischecklist
- Bewaart de middleware voorraad, orderstatus of tracking die Odoo niet heeft? Als hij alleen bestanden transporteert, stap dan niet over.
- Eén ERP, of meerdere die op dezelfde kanalen verkopen? Hoort Odoo van de order aan het begin van de keten of aan het eind?
- Wie zet de connector over naar de volgende Odoo-versie, en wanneer?
- Weet je hoeveel historische records er staan in de status waarnaar een herhaal-cron zoekt?
Als je wilt dat iemand je situatie met deze criteria bekijkt, staat in diensten en oplossingen hoe we werken.
Veelgestelde vragen
Hoe lang moeten beide systemen parallel draaien?
Totdat de dagelijkse vergelijking twee dagen op rij nul verschillen geeft, en nooit minder dan een week.
Kan ik één kanaal omzetten en de rest in de middleware laten?
Ja, en dat is aan te raden. Je hoeft alleen te beslissen wie vanaf de omschakeling de voorraad naar dat kanaal publiceert, en dat moet er maar één zijn.
Geldt hetzelfde voor EDI en elektronische handtekening als voor marketplaces?
De regel wel: als de laag de status van het document bewaart (geaccepteerd, afgewezen, ondertekend), loont het om hem te vervangen. Er zijn twee of drie stromen in plaats van tien, en de parallelle periode bestaat uit hetzelfde document langs beide wegen naar de testomgeving van de derde partij sturen.
Nuttige links binnen FlexigoTech
Wat wij hieraan doen
Betaal je voor een middleware en weet je niet of je hem nog nodig hebt?
Vertel ons welke kanalen je hebt, welke Odoo-versie en wie die onderhoudt. We zeggen je of overstappen de moeite waard is, in welke volgorde, en wat in de middleware moet blijven. Mail naar comercial@flexigobe.com of bel +34 616 809 504.