Geen eigen productie, geen eigen magazijn. Je koopt in bij je leverancier, een logistiek dienstverlener slaat op en verstuurt, en jij verkoopt. Dat is een prima model, en voor een startend merk vaak het enige verstandige. Maar er zit een misverstand in dat model dat pas pijn doet als het te laat is: geen eigen magazijn betekent niet geen voorraadadministratie. Dit is wat je in Odoo houdt, wat je koppelt, en waarom een koppeling zelden je eerste stap is.
Het magazijn is uitbesteed, de administratie niet
De pallets staan bij iemand anders, de heftruck is niet van jou, en de mensen die pakken staan niet op je loonlijst. Toch is die voorraad van jou. Hij staat op jouw balans, jij hebt hem ingekocht en betaald, jij factureert hem straks, en jij bent verantwoordelijk voor de waardering aan het eind van het jaar. Als je accountant vraagt wat er op 31 december in dat magazijn lag en wat het waard was, is “dat weet mijn logistiek dienstverlener” geen antwoord.
Dus voer je die voorraad gewoon in Odoo, als een eigen locatie die toevallig ergens anders staat. Inkopen komen binnen op die locatie, verkopen gaan eraf, en je ziet in je eigen systeem wat je hebt. Dat je die goederen nooit zelf aanraakt, verandert daar niets aan.
Dat klinkt vanzelfsprekend, maar de praktijk is dat veel startende merken hun voorraad alleen in het portal van hun dienstverlener zien. Dat werkt tot het moment dat je wilt weten wat je marge is, of tot je accountant belt.
De vraag die je scope bepaalt
Als je gaat koppelen, is er precies één vraag die eerst beantwoord moet worden: wat kan die partij, en via welke interface? In de praktijk zie je drie smaken.
Een moderne API is het prettigst: realtime, tweerichtingsverkeer, goed gedocumenteerd. Je stuurt orders door en haalt statussen en voorraadstanden op zodra ze veranderen.
EDI kom je ook tegen, vooral bij partijen die zelf veel met retail werken. Dat is prima, en heeft als voordeel dat de berichtenstructuur al vastligt.
En dan is er de flat-file: een CSV die op een SFTP wordt gezet, een paar keer per dag. Ouderwets, maar het werkt, en meer partijen doen dit dan je zou denken. Het verschil zit in de actualiteit van je data en in wat je moet bouwen om het betrouwbaar te maken.
Alle drie kunnen. Maar ze verschillen fors in bouwtijd, in onderhoud en in wat je erover moet afspreken. Daarom is dit de vraag die je stelt vóórdat iemand een uurschatting maakt. Wie een fulfilment-koppeling inschat zonder te weten welke van de drie het wordt, gokt - en samen met je EDI-traject bepaalt dit vaak het merendeel van je scope.
Begin met het portal, koppel als het pijn doet
Hier gaan we in tegen wat je van een systeempartij verwacht te horen. Bijna elke fulfilmentpartij heeft een portal: je geeft orders door, je ziet voorraadstanden, je downloadt een overzicht. Bij lage volumes is dat prima. Een koppeling is dan vooral een rekening.
Je koppelt op het moment dat het handwerk je pijn gaat doen. Dat moment herken je: het aantal orders per dag stijgt tot overtikken een dagtaak wordt, er sluipen fouten in, of een retailer stelt eisen aan doorlooptijd die je handmatig simpelweg niet haalt. Dán verdient een koppeling zich terug, en geen dag eerder.
Dat is ook gewoon goed projectmanagement. Als je een harde livedatum hebt, is de vraag niet “wat willen we uiteindelijk” maar “wat moet er staan om te kunnen leveren”. Een portal-eerst-aanpak haalt een risicovolle koppeling van je kritieke pad af en schuift hem naar het moment dat je bedrijf ervoor betaalt.
De pakbon komt niet van jou
Er is één plek waar dit alles samenkomt, en die verdient aparte aandacht. Lever je aan een grote retailer, dan verwacht die een elektronische pakbon - de DESADV - vaak binnen een strak tijdvenster vóórdat de vrachtwagen bij de losplaats staat.
Dat bericht ontstaat niet bij jou. Het ontstaat bij je logistiek dienstverlener, want die weet wanneer er daadwerkelijk een pallet klaarstaat en wat erop ligt. Jij zit er wel tussen: het moet in het juiste formaat en op tijd bij de retailer aankomen.
Dus het bericht met de strakste deadline in de hele keten is het bericht dat een derde partij maakt. Dat is geen ramp, maar het is wel de reden dat de afspraken met je fulfilmentpartij onderdeel zijn van je EDI-traject en niet iets wat je daarna regelt. Hoe die driehoek werkt, staat in EDI-koppeling met een grote retailer.
Wat het kost, en waarom je dat wilt zien
Fulfilment is bijna altijd variabel geprijsd: een tarief per order, per orderregel, per pallet, per opslagplek per week. Precies omdat het variabel is, hoor je die kosten toe te rekenen aan waar ze vandaan komen.
Met analytische boekhouding in Odoo hang je fulfilmentkosten aan de klant en de productgroep die ze veroorzaakt. Dan zie je dat de retailer met de grote pallets je weinig kost per euro omzet, en dat het kanaal met veel kleine losse orders je marge opeet. Zonder die toerekening blijft het één logistieke klomp in je resultatenrekening en weet je alleen dat het duur was, niet waardoor. Dat is dezelfde redenering als bij actiekortingen en jaarafspraken: kosten die bij je omzet horen, hoor je ook bij die omzet te zien.
Kort samengevat
Fulfilment uitbesteden is verstandig, maar het besteedt je magazijn uit, niet je administratie. Voer je voorraad in Odoo als een eigen locatie die elders staat. Stel vóór elke inschatting de vraag wat je dienstverlener kan - API, EDI of flat-file - want dat bepaalt je scope. Begin met hun portal en koppel als het volume erom vraagt, niet eerder. Houd er rekening mee dat de pakbon met de strakste deadline bij een ander ontstaat. En reken je fulfilmentkosten analytisch toe, zodat je ziet welk kanaal je marge opeet.
Verkoop je zonder eigen magazijn en wil je weten wat je moet koppelen? Plan een vrijblijvende Quickscan en we bekijken samen je fulfilmentpartij, je voorraadadministratie en wat er wel en niet op je kritieke pad hoort.
Meer lezen: EDI-koppeling met een grote retailer · Actiekortingen en jaarafspraken in je P&L · PIM, EDI en klantenportaal voor groothandel · Shopify koppelen aan Odoo · Wat kost een Odoo-implementatie?