Español
English
Català
Deutsch
Français
Português
Italiano
Polski
Een native connector in Odoo 19 past wanneer Odoo de baas is over voorraad, bestellingen, verzendingen en facturen: elke status bestaat maar één keer, op het formulier waar het team werkt. Een middleware past wanneer je alleen gegevens hoeft te vervoeren zonder operationele beslissingen te nemen, of wanneer niemand code binnen Odoo gaat onderhouden. Een API één keer koppelen was nooit het probleem: het probleem is bestellingen, voorraad, fouten en traceerbaarheid onder controle houden naarmate de operatie groeit.
Kernidee: de vraag is niet "native" of "middleware", maar waar elke status leeft en wie die controleert als de cijfers niet kloppen.
Het echte verschil zit niet in de API
De API van Amazon, van Mirakl of van een vervoerder is dezelfde, wie haar ook aanroept. Wat verandert, is wie het resultaat bewaart en waar de persoon die de bestelling klaarmaakt het ziet: daar zit het verschil, niet in de API.
Als Odoo voorraad moet reserveren, bestellingen moet voorbereiden, leveringen moet aanmaken, labels moet genereren en de tracking naar het kanaal moet terugsturen, laat de native integratie de traceerbaarheid waar het team werkt. Met een tussenlaag bestaat elke stap tweemaal, en de twee kopieën komen alleen overeen als iemand het controleert.
Wanneer kies je een native connector in Odoo
Het is zinvol wanneer Odoo het hoofdsysteem is voor product, voorraad, bestellingen, logistiek en facturatie. Ook wanneer je eigen regels nodig hebt: meerdere magazijnen, validaties vóór verzending, nieuwe pogingen, een logboek van aanroepen per bestelling en fouten die de gebruiker op zijn eigen scherm ziet.
In onze marketplace-connectors is het logboek van elke aanroep een Odoo-model met methode, endpoint, parameters, verzonden body, code en body van het antwoord, poging en duur in milliseconden, met instelbare opschoning. Je filtert het zoals elke lijst in Odoo, zonder afhankelijk te zijn van een extern dashboard.
Wanneer een middleware kan volstaan
Als je alleen eenvoudige gegevens tussen twee systemen verplaatst, zonder complexe operationele beslissingen, kan een middleware de start versnellen. Ook als meerdere ERP-systemen op dezelfde kanalen verkopen en de gepubliceerde voorraad de som moet zijn. En vooral als niemand, intern noch partner van Odoo, code binnen de ERP gaat onderhouden.
Het risico ontstaat wanneer het team drie dashboards doorloopt om te weten of een bestelling verkocht, gereserveerd, verzonden of mislukt is: die dag is de middleware gestopt met vervoeren en begonnen met het bewaren van status.
Wat een middleware kost in het dagelijks werk
De rekening die telt is niet het maandbedrag: het zijn de taken die verschijnen zodra er een tussenlaag is en die niemand begroot. Het zijn er vier.
- De dubbele master. Het product wordt in Odoo aangemaakt en daarnaast in de middleware gemapt: SKU, kanaalcategorie, verplichte attributen. Elke nieuwe aanmaak, elke EAN-wijziging en elke nieuwe variant is twee keer bewerken. Met een native connector is de mapping naar het kanaal gewoon een extra veld op het product in Odoo.
- Het afstemmen van statussen. Een marketplacebestelling heeft drie waarheden: die van het kanaal, die van de middleware en die van Odoo. Als ze niet overeenkomen (een bestelling die op het kanaal is geannuleerd maar in Odoo nog voorraad reserveert), ontdekt iemand dat met de hand. Met de connector binnen Odoo blijven er twee over, en de status op afstand wordt precies zoals de API hem teruggeeft bij de verkooporder bewaard, met het tijdstip van de laatste synchronisatie.
- Wie kijkt in het log. De fout van een aanroep leeft in het dashboard van de leverancier, met zijn eigen gebruiker en bewaartermijn. Wie de vastgelopen bestelling in Odoo ziet, heeft meestal geen toegang tot dat dashboard. Als het log een Odoo-model is, ziet degene met het probleem het, op hetzelfde scherm.
- De versie-upgrade. Wanneer Odoo van 18 naar 19 gaat, belooft de middleware dat zijn kant niet verandert. Die van Odoo verandert wel: de brugmodule van de leverancier, de velden die hij leest en de webhooks die hij verwacht. Die migratie doe je hoe dan ook, in het tempo van de leverancier en niet in het jouwe; wij publiceren tegelijk voor 19, 18 en 17, zoals we vertellen in één module onderhouden in drie versies.
Als je al voor een tussenlaag betaalt en vermoedt dat je die niet nodig hebt, staat het afbouwplan per kanaal in van middleware naar een native verbinding in Odoo, verteld vanuit onze eigen Amazon-migratie in productie.
Waar de traceerbaarheid verloren gaat
Het exacte punt is de levering. In Odoo erft de levering (stock.picking) van mail.thread en haar status wordt gevolgd, dus elke overgang naar "klaar" wordt vastgelegd met datum en gebruiker. Met de leveringsmodule is het trackingnummer van de vervoerder een veld van de levering zelf (carrier_tracking_ref). Dat alles zit standaard in Odoo.
Wat Odoo standaard niet weet, is of die tracking de marketplace heeft bereikt. Met een middleware valt de keten bestelling → levering → tracking → bevestiging aan het kanaal in twee delen uiteen: de eerste twee schakels in Odoo, de laatste twee in het dashboard van de leverancier. De chatter van de levering zegt "klaar", en het bewijs dat de koper zijn nummer zag staat in een ander systeem.
Een native connector sluit de keten op dezelfde plek. In onze Mirakl-connector activeert het valideren van de levering het versturen van de tracking als de instantie dat heeft ingeschakeld, en het resultaat wordt in de chatter geschreven: een notitie als het verstuurd is, een andere met de fout als het mislukte, en weer een andere als de levering geen trackingnummer had en er niets is verstuurd. De aanroepen naar Mirakl lopen via de gateway van FlexigoTech Cloud, die niet bewaart of registreert wat ze bevatten, dus wat er met elke verzending gebeurde, blijft in jouw Odoo.
Native is ook geen magie: 32 fouten bij groene tests
Het ongemakkelijke deel is van ons: "native" betekent dat de code in Odoo leeft, niet dat ze werkt. We hebben een eigen marketplace-connector geaudit voordat we hem bij een echte verkoper neerzetten. De suite gaf 236 van 236 groen, op echte Odoo.sh-builds in 19, 18 en 17. Eronder zaten 32 echte fouten: 20 in het contract met de API en 12 in de Odoo-versie.
De contractfouten waren parameters die de API eiste en die niet werden meegestuurd, en velden in het antwoord die onder de verkeerde naam werden gelezen en None teruggeven zonder iets te laten ontsporen. Vier kwamen pas aan het licht door echt aan te roepen: de paginatieheader kwam relatief binnen en vanaf pagina één werd er geen enkele bestelling meer geïmporteerd; een 403 wegens quota kwam niet in het gedocumenteerde formaat en werd gelezen als ontbrekende rechten, waardoor de hele synchronisatie stopte. De versiefouten kwamen van Odoo zelf: een cron die in 17 één keer draait en zichzelf uitzet, een groepenveld dat vanaf 19 anders heet, een lijstweergave die 17 weigert. De helft gaf geen foutmelding: die gaf stilte.
Het volledige geval (inclusief een tweede connector met 163 van 163 groen die nog nooit een regel log had geschreven) staat in de tests waren groen en de connector werkte niet. De conclusie voor wie vergelijkt: vraag van de native connector hetzelfde als van de middleware. Dat hij echt in jouw versie is geïnstalleerd, niet alleen dat hij compileert; dat hij is getoetst aan de specificatie van de leverancier en niet aan zijn eigen mocks; en dat hij minstens één echte aanroep per endpointfamilie heeft gedaan. Als je hem van iemand anders erft, staat de lijst in een geërfde Odoo-connector auditen.
Beslischecklist
- Waar wordt de voorraad gereserveerd, en hoeveel systemen bewaren een kopie van de beschikbare voorraad?
- Wie maakt de levering en het label aan?
- Waar zie je de fout als een API faalt, en ziet dezelfde persoon die de bestelling ziet die ook?
- Gaat de tracking automatisch terug naar het kanaal, en wordt op de levering vastgelegd dat dit gebeurd is?
- Kun je opnieuw proberen zonder bestellingen of verzendingen te dupliceren?
- Wie migreert de connector zodra de volgende Odoo-versie uitkomt, en binnen welke termijn?
- Is hij echt in jouw versie geïnstalleerd en getest tegen de sandbox van de leverancier?
De volgorde waarin je meerdere kanalen koppelt, hangt af van welk kanaal de voorraad publiceert: dat behandelen we in verkopen op meerdere marketplaces vanuit één Odoo. De connectors die al met Amazon, Mirakl, ManoMano, AliExpress en de vervoerders praten, staan in de catalogus en in integraties en automatisering voor Odoo; als het voor je eigen software is: Odoo-connector voor je software.
Veelgestelde vragen
Is een native connector altijd beter?
Niet altijd. Hij is beter wanneer Odoo het operationele centrum is en je bedrijfsregels, traceerbaarheid en controle vanuit de ERP nodig hebt. Als Odoo alleen aan het eind van het proces een bestand ontvangt, of als niemand code binnen Odoo gaat onderhouden, is de middleware de redelijke keuze.
Kan ik beide aanpakken combineren?
Ja, maar bepaal dan welk systeem de baas is over voorraad, bestellingen, logistiek en fouten, en laat geen enkele status in beide systemen tegelijk bestaan zonder dagelijkse vergelijking.
Hoe controleer ik dat een native connector werkt voordat ik erop vertrouw?
Installeer hem echt in jouw versie, vergelijk wat hij verstuurt en leest met de specificatie van de leverancier en doe per endpointfamilie één echte aanroep naar de sandbox. Een connector van ons met 236 van 236 groene tests had 32 fouten die alleen zo aan het licht kwamen.
Wat gebeurt er met de native connector als er een nieuwe Odoo-versie uitkomt?
Hij moet gemigreerd worden, en het is verstandig te weten door wie voordat je beslist. In Odoo 17 krijgt een ir.cron zonder numbercall de waarde 1 en wordt na de eerste uitvoering gedeactiveerd; dat veld bestaat in 18 en 19 niet meer, en de wijziging geeft bij de installatie geen waarschuwing. Onze connectors worden gepubliceerd voor 19, 18 en 17.
Nuttige links binnen FlexigoTech
Wat wij hieraan doen
Wil je jouw situatie laten bekijken?
We kijken naar je kanalen, voorraad, vervoerders en Odoo-versie om je de schoonste route voor te stellen, en we zeggen je helder of de middleware moet blijven. Schrijf naar comercial@flexigobe.com of bel +34 616 809 504.