Sourcing- en importbedrijven leven tussen twee werelden: fabrikanten in Azië, en veeleisende retailers in Europa. Daartussen zit een keten van RFQ’s, samples, inspecties, compliance, artikeldata en facturatie. Onlangs maakten we een solution assessment voor zo’n bedrijf, en één cijfer bleef hangen: één artikelregel telde 173 kolommen, in 13 veldgroepen, elk met een aanleverende partij en een verantwoordelijke rol. Dat is een compleet PIM-model dat toevallig in Excel woont. Dit is hoe Odoo die keten op één platform brengt, hoe PIM, EDI en portalen samenwerken, en hoe we het hart ervan met Updoo bouwen.
Het sourcing-model stelt eigen eisen
Een sourcing- of inkoopbegeleidingsbedrijf werkt anders dan een standaard groothandel. Het helpt retailers en online spelers om rechtstreeks bij de fabrikant in Azië in te kopen - OEM en private label - en verdient aan begeleiding, kwaliteit en marge. Het verdienmodel bepaalt wat het systeem moet kunnen. In de praktijk zien we twee varianten, vaak naast elkaar:
- Begeleiden tegen fee: je brengt de klant naar de juiste fabrikant, regelt kwaliteit, compliance en logistiek, en verdient een fee of marge. Je houdt zelf geen voorraad.
- Zelf inkopen en doorverkopen: je koopt op order in, laat je vooraf betalen, en regelt de import. Ook hier gaan de goederen rechtstreeks van de fabriek naar de klant.
Beide vragen om een systeem dat de keten aankan, van offerteaanvraag bij de fabrikant tot levering bij de retailer, zonder dat je een magazijn beheert. Dat is een ander vraagstuk dan “voorraadbeheer voor een groothandel”, en precies daar lopen generieke tools op vast.
Elke productintroductie in een nieuw Excel-bestand
Het proces staat bij dit soort bedrijven vaak uitstekend op papier. Wat ontbreekt is één systeem. Alles loopt via Excel, Teams, e-mail en een ERP met beperkingen. Elke productintroductie doorloopt dezelfde reeks mijlpalen - in het assessment ruim 25, van shopping list tot productevaluatie - maar elke keer in een nieuw Excel-bestand. Dat kost tijd, geeft fouten, en maakt sturen op de status onmogelijk. Je ziet niet in één oogopslag welke producten waar in het traject zitten, welke inspectie gepland staat, of welk certificaat bijna verloopt.
Dit is dezelfde dynamiek die we beschreven in van Excel naar Odoo. Deze bedrijven zijn volwassen. Ze zitten vast in losse bestanden. Het huiswerk is prima gedaan; het mist een plek.
Drie bouwstenen: PIM, EDI en portaal
B2B-groothandel en import draaien op drie dingen die moeten kloppen. Elk is een bouwsteen met een eigen taak:
- PIM: de productdata. Specificaties, varianten, prijzen, afbeeldingen, compliance en documenten uit één bron. Dit is het fundament: de catalogus voor retailers, de webshop, de offertes en het portaal putten er allemaal uit. Klopt de productdata niet, dan verkoop je verkeerde specificaties, mis je een certificaat of toont het portaal een prijs die niet meer geldt.
- EDI: de orderstroom met grote afnemers. Orders, orderbevestigingen, pakbonnen en facturen gaan elektronisch. Een kleine klant mailt een bestellijst; een grote retailer verwacht automatisering, en maakt het steeds vaker een voorwaarde om überhaupt leverancier te zijn.
- Portaal: zelfbediening. Klanten bekijken orderhistorie, plaatsen herhaalorders, halen documenten en facturen op. Leveranciers uploaden certificaten, foto’s en verpakkingsdata. Allebei ontlasten ze je team.
Los werkt elk half. Samen op één datamodel vormen ze de ruggengraat, met de productdata als bron.
De architectuur: van RFQ tot retailer op één datamodel
Waar het om draait is samenhang. In Odoo komen de schakels van de sourcing-keten op één datamodel samen. Uit het assessment, met een heldere indeling van wat standaard kan en wat gebouwd wordt:
| Domein | Aanpak | Kort |
|---|---|---|
| CRM & contacten | Standaard | Klanten, leveranciers, leads, bezoekverslagen |
| Verkoop & inkoop | Configuratie | SO/PO met aanbetalingen, Incoterms, commissie |
| Projectmanagement (NPI) | Configuratie | De 25+ mijlpalen als projecttemplate met fasen, deadlines en RACI |
| Boekhouding | Configuratie | Multi-company over entiteiten, met bankkoppelingen als aandachtspunt |
| PIM / artikelcreatie | Maatwerk (Updoo-schil) | Het hart van het systeem - zie hieronder |
| EDI retailer | Maatwerk | Automatische orderintake in plaats van handmatig downloaden |
| Leveranciersportaal | Maatwerk (Updoo) | Leveranciers uploaden zelf certificaten, foto’s, verpakkingsdata |
| Inspecties & kwaliteit | Configuratie | PSI-rapporten, sample-goedkeuring, formele akkoorden |
| Compliance-bewaking | Maatwerk | Aflopende certificaten signaleren, pro-actief |
| Voorraad / POS | Later | Geen eigen voorraad; bewust buiten scope |
Die indeling is het halve werk. Ze laat zien wat je aanzet, wat je inricht, wat je bouwt, en wat je bewust naar een latere fase schuift. Geen holle “Odoo kan alles”.
PIM: het hart van het systeem
Terug naar die 173 kolommen. Ze vallen uiteen in 13 veldgroepen - van algemene productinfo en prijshistorie (FOB, landed cost, verkoopprijs per land, marge) tot logistiek, verpakkingsconvenant (grammen per materiaal voor PPWR), artwork-eisen met tientallen compliance-markeringen, certificering (BOM, TCF, REACH, RoHS, DPP), testrapporten per sample-fase, en tien productfoto-posities. Elk veld heeft een eigenaar: de leverancier, de compliance-afdeling of de merchandiser.
Dit is dus een compleet PIM-model, inclusief wie wat aanlevert. Standaard Odoo volstaat hier niet, om drie redenen:
- Prijshistorie met datums. FOB-prijs 1, 2 en 3 mét datum, plus landed costs en verkoopprijzen per land. Odoo bewaart de actuele prijs. Een gestructureerde historie met marge-doorrekening ontbreekt.
- Eigenaarschap per veldgroep. De leverancier vult logistiek en verpakking, compliance de certificeringen, de merchandiser de basis. Dat vraagt schrijfrechten per veldgroep. Standaard Odoo regelt rechten per model.
- Compliance als levend dossier. Certificaten en markeringen verlopen en bepalen of een product de inspectie in mag. Het systeem moet een certificaat signaleren voordat het verloopt.
Ons voorstel: PIM als Updoo-schil om Odoo
Hier maken we een bewuste architectuurkeuze. Twee opties vallen af. Externe PIM-pakketten zijn gebouwd voor retail-catalogi (veel SKU’s, weinig proces), terwijl dit model omgekeerd is: elk artikel draagt een compleet dossier met eigenaarschap per veldgroep en een goedkeurflow. Een zware maatwerkmodule ín Odoo vecht tegen het framework en bindt je hosting.
Wat we bouwen is een Updoo-product als schil om Odoo. De schil is de bron voor het volledige 173-velden-model. Odoo krijgt alleen de transactionele subset die orders, facturen en marges nodig hebben - artikelnummer, EAN, omschrijving, kostprijs, HS-code, colli, zo’n 15 tot 20 velden. En de sync gaat één richting: van de schil naar Odoo. Dat is een principe. Heen-en-weer synchroniseren bouwt de Excel-chaos opnieuw op, maar dan duurder. Eén bron van waarheid betekent ook echt één. Dat principe, en waar de grens ligt, werken we uit in PIM als schil om Odoo.
Datzelfde patroon gebruiken we voor het leveranciersportaal: een eigen portaallaag bovenop Odoo waar leveranciers zelf certificaten, foto’s en verpakkingsdata aanleveren, met Odoo als datalaag. Sneller, flexibeler en beter beheersbaar dan het standaard Odoo-portaal openbreken. Portaal en PIM worden zo één omgeving voor de leverancier.
Wat de data doet ná aanmaak
Artikelcreatie is één moment. Het echte werk begint daarna, en daarom moet dit een levend systeem zijn. De data doet vier dingen:
- Ze voedt transacties. De subset in Odoo komt terug op elke PO- en SO-regel, factuur en margeberekening. Bij een herhaalorder checkt het systeem automatisch of de data nog klopt: certificaten geldig, laatste artwork en manual gekoppeld.
- Ze muteert. Nieuwe FOB-prijzen, gewijzigde verpakkingen, nieuwe manual-versies, artikelen van New naar Active naar EOL - elke mutatie met datum en verantwoordelijke. De historie die Excel niet vasthoudt.
- Ze verloopt. Certificaten hebben een houdbaarheidsdatum. De schil bewaakt die en triggert de vernieuwing bij de leverancier via het portaal, met de mailsignalen die je nodig hebt.
- Ze rapporteert. Verpakkingsdata wordt PPWR-rapportage, DPP komt eraan, vendor-scorecards en marge-dashboards trekken uit dezelfde bron. En een klantcatalogus of website in een latere fase wordt eenvoudig: de data bestáát dan al.
De druk van grote retailers: EDI en portalen
Een aparte trigger dwingt de hand. Grote retailers werken niet met bestellijsten per e-mail. Ze verwachten EDI-koppelingen, orderstatussen, een leveranciersportaal en nette artikeldata. In het assessment kwamen de orders nog binnen op een mailbox en werden ze handmatig gedownload. Dat werkt tot een bepaald volume; daarna wordt het een flessenhals en een foutbron.
Een EDI-koppeling maakt van binnenkomende orders automatisch verkooporders in Odoo, met de juiste artikeldata uit de PIM en statussen terug naar de afnemer. Je hebt wel de EDI-specificaties van de retailer nodig; dat is altijd de eerste stap. Hoe dat uitpakt bij een grote supermarktketen, lees je in EDI-koppeling met een grote retailer.
Aan de klantkant geeft een B2B-klantenportaal afnemers een eigen omgeving: orderhistorie, snel herhaalorders plaatsen, offertes, documenten en facturen. Minder mails en telefoontjes voor de binnendienst, betere service voor de klant. Je bouwt het op het standaard Odoo-portaal, met een uitbreiding waar je proces uniek is. Meer in B2B-klantenportaal in Odoo. Verkoop je daarnaast zelf online, dan is een webshop het vierde kanaal; zie Shopify koppelen aan Odoo.
Hoe het samenkomt, en waar het misgaat
Op één datamodel voeden de bouwstenen elkaar:
- De productdata voedt de webshop, de EDI-catalogus en de portalen. Eén bron, geen vijf.
- Orders uit EDI en het portaal worden verkooporders in Odoo, met dezelfde artikelen en prijzen.
- De beschikbaarheid die de kanalen tonen komt uit hetzelfde systeem, en de boekhouding loopt automatisch mee.
Een wijziging op één plek klopt dan overal. De valkuilen zijn telkens dezelfde:
- PIM als bijzaak. Is de productdata een sluitpost, dan lekt het probleem door naar elk kanaal. Begin bij de data.
- EDI onderschatten. Elke retailer heeft eigen specificaties. “Een EDI-koppeling” bestaat alleen per afnemer.
- Een portaal dat alleen een login is. Zonder echte zelfbediening (herhaalorders, documenten, status) ontlast een portaal niemand.
- Losse systemen. Een apart PIM-pakket, een aparte EDI-tool en een apart portaal die je handmatig gelijk houdt, bouwen de Excel-chaos opnieuw op, tegen een hogere prijs.
Meerdere entiteiten, China en Europa
Sourcing-bedrijven combineren bijna altijd meerdere landen en entiteiten: sales in Nederland (en soms Polen), back-office in China, een aparte entiteit in Hongkong. Dat stapelt complexiteit, en drie dingen regel je vooraf:
- Bankkoppelingen. Voor Europese banken is een automatische koppeling standaard; voor Chinese en Hongkongse banken toets je dit per bank. Kan het niet automatisch, dan is een dagelijkse bankimport het alternatief.
- Hosting en performance vanuit China. Toegang tot een cloudomgeving vanuit China is een bekend aandachtspunt. De vraag “Singapore versus Europa” wordt urgent als het merendeel van je gebruikers in China zit. We werken die keuze uit in de hosting-gids.
- Communicatie. WeChat met fabrieken is dagelijkse realiteit in China, maar geen standaard Odoo-integratie. Verwacht e-mail en portaal in het systeem, WeChat ernaast.
Odoo draait de entiteiten als multi-company met geconsolideerde rapportage. De lokale boekhouding (bijvoorbeeld de Chinese) houd je vaak lokaal en koppel je aan de groep; de afweging staat in internationale boekhouding koppelen aan Odoo. Meer over meertalige, internationale inzet in Odoo voor internationale rollouts.
De belangrijkste architectuurvraag
Eén vraag bepaalt de hele opzet, en die stel je in de fit-gap: is het productmodel van jou, of van jou-voor-een-specifieke-retailer? Als veel veldgroepen nu de eisen van een grote afnemer dragen, en er komt een tweede retailer bij, dan moet het model klantspecifieke lagen aankunnen - eigen artikelnummers, eigen compliance-eisen, eigen artwork. Dat bepaalt of je per klant een dataset bouwt of één generiek model met klantprofielen. Het is de belangrijkste architectuurkeuze van het hele project, en je maakt hem het beste vooraf.
Hoe je het aanpakt
- Fit-gap op de zwaarste onderdelen. De PIM-architectuur (de klantvraag hierboven), de EDI-specificaties en het gebruikerslandschap over entiteiten heen.
- Bepaal de bron van waarheid. Er is één productmodel. Sync in één richting.
- Faseer in heldere stappen. Fase 1 = PIM, projectmanagement, orders en finance. Dashboards groeien mee. Website, e-mailmarketing en events komen daarna.
- Toets de aannames. Aantal echte gebruikers versus portaalgebruikers, bankkoppelingen, hostinglocatie. Dat raakt zowel de licenties als de kosten. We rekenen het voor in wat een Odoo-implementatie kost.
Kort samengevat
Een sourcing- of importbedrijf heeft een ketenprobleem: van fabrikant in Azië tot retailer in Europa moet alles kloppen, in meerdere talen, valuta en entiteiten. De winst zit in één productmodel dat het hele proces draagt, met PIM als bron en EDI en portalen die eruit putten. Odoo brengt inkoop, verkoop, projectmanagement, EDI, inspecties en boekhouding samen; met Updoo bouwen we de PIM-schil en portalen waar jouw proces uniek is. Standaard waar het kan, een slimme schil waar het moet.
Herken je dit in jouw handels- of importbedrijf? Plan een vrijblijvende Quickscan en we brengen je keten, je productdata, je orderstromen en je grootste risico’s in kaart - inclusief een heldere indeling van wat standaard kan en wat maatwerk wordt.
Meer lezen: Van Excel naar Odoo · PIM als schil om Odoo · EDI-koppeling met een grote retailer · B2B-klantenportaal in Odoo · Verkopen zonder eigen magazijn · Odoo voor lease- en verhuurbedrijven · Odoo voor internationale rollouts · Odoo hosting en datalocatie internationaal · Shopify koppelen aan Odoo · Wat kost een Odoo-implementatie? · Updoo: uitbreidingen op Odoo