Als het standaard productmodel van Odoo niet meer volstaat - duizenden artikelen, elk met een compleet dossier aan specificaties, compliance en artwork - dan is de reflex om het productscherm steeds verder uit te breiden. Dat is de verkeerde afslag. Bij die schaal bouw je PIM niet ín Odoo, maar als schil eromheen, met alleen de transactionele subset in Odoo zelf. En met één harde regel: de sync loopt maar één kant op. Dit is de architectuur, waarom heen-en-weer syncen de chaos opnieuw opbouwt, en waar de grens ligt.
Wanneer het standaard productmodel knelt
Voor de meeste bedrijven is het productmodel van Odoo ruim genoeg. Specificaties, varianten, prijzen, afbeeldingen: het staat er allemaal in, en je hebt geen extra systeem nodig. De vraag “kan Odoo als PIM dienen?” is voor hen simpelweg: ja.
Het knelt pas bij een specifiek profiel. Duizenden artikelen, en per artikel niet een handvol velden maar een compleet dossier: technische specificaties, compliance-documenten en certificaten, verpakkingsdata, artwork, meerdere talen, en tientallen tot honderden attributen die per afnemer of kanaal net anders uitgevraagd worden. We zagen dit bij een sourcing- en importbedrijf waar één artikelregel goed was voor 173 kolommen. Op dat punt wordt het productscherm in Odoo een verzamelbak, en elke uitbreiding maakt het trager en fragieler.
De schil-architectuur: wat waar hoort
De oplossing is niet “alles in Odoo persen”, maar de data verdelen naar waar hij thuishoort:
- Het PIM beheert de volledige productdata: alle specificaties, compliance, verpakking, artwork, vertalingen en varianten. Dit is de bron van waarheid voor het product.
- Odoo houdt de transactionele subset: precies de velden die je nodig hebt om te verkopen, in te kopen, voorraad te voeren en te factureren. Dit is de bron van waarheid voor de transactie.
De vuistregel om te bepalen wat waar hoort: hoort een veld bij de transactie, dan mag het in Odoo; hoort het bij het complete productdossier, dan blijft het in het PIM en komt alleen mee wat Odoo daadwerkelijk gebruikt. Een certificaat dat een afnemer opvraagt hoort in het PIM; de verkoopprijs en de voorraadeenheid horen in Odoo. Zo blijft het productscherm in Odoo schoon en snel, terwijl de rijkdom van de data volledig bewaard blijft in de laag die daarvoor gemaakt is.
Waarom de sync maar één kant op loopt
Hier zit het principe dat de hele opzet staande houdt: de sync loopt maar één kant op, van het PIM naar Odoo. Wijzig je een specificatie, een prijs of een certificaat, dan doe je dat in het PIM, en het stroomt naar Odoo. Nooit andersom.
De verleiding is om het “voor het gemak” twee kanten op te laten lopen - een prijs die je toevallig in Odoo aanpast weer terug naar het PIM. Doe dat niet. Zodra beide systemen denken de baas te zijn over dezelfde velden, krijg je conflicten: welke waarde wint, en wanneer? Je bouwt precies de situatie terug die je wilde oplossen - versies die uit elkaar lopen, niemand die nog weet wat klopt - maar nu verdeeld over twee systemen in plaats van tien Excel-tabbladen. Heen-en-weer syncen bouwt de Excel-chaos opnieuw op, maar dan duurder. Eén richting houdt de vraag “waar staat de waarheid?” altijd beantwoordbaar.
Twee bronnen van waarheid, elk voor hun domein
Eén richting betekent niet één systeem. Er zijn twee bronnen van waarheid, en dat is prima zolang de grens scherp is:
- Het PIM is de bron voor productdata. Alles wat het product beschrijft, ontstaat en verandert daar.
- Odoo is de bron voor de transactie. Orders, voorraad, leveringen en facturen ontstaan daar.
De grens loopt langs de vraag “beschrijft dit het product, of registreert dit een gebeurtenis?”. Een productattribuut beschrijft; een order registreert. Zolang je die twee niet door elkaar haalt, weet elk veld waar het thuishoort en blijft de sync eenvoudig en voorspelbaar.
Waar de grens ligt: niet iedereen heeft dit nodig
Dit is nadrukkelijk geen pleidooi om standaard een apart PIM naast Odoo te zetten. Voor het overgrote deel van de bedrijven is dat overkill - je voegt een systeem, een koppeling en beheer toe waar het standaard productmodel prima had volstaan. De schil-architectuur verdient zichzelf pas terug bij het profiel hierboven: veel artikelen, een rijk dossier per stuk, en meerdere afnemers of kanalen die elk hun eigen subset willen.
Twijfel je aan welke kant je zit? Kijk naar je artikelregel. Heeft die een handvol velden, dan is Odoo je PIM en ben je klaar. Loopt die richting tientallen of honderden velden waarvan het merendeel niets met de verkooptransactie te maken heeft, dan is de schil het overwegen waard. Die afweging maakt onderdeel uit van de bredere B2B-opzet die we beschreven in PIM, EDI en klantenportaal voor groothandel.
Kort samengevat
Bij duizenden artikelen met een compleet dossier per stuk hoort je productdata niet ín Odoo, maar in een PIM als schil eromheen - met alleen de transactionele subset in Odoo zelf. De sync loopt maar één kant op, van PIM naar Odoo, want twee kanten op syncen bouwt de chaos opnieuw op. Twee bronnen van waarheid, elk voor hun domein, met een scherpe grens: het PIM beschrijft het product, Odoo registreert de transactie. En voor de meeste bedrijven die niet op die schaal zitten: Odoo ís je PIM, en dat is precies genoeg.
Loopt je artikeldata tegen de grenzen van het standaard productmodel aan? Plan een vrijblijvende Quickscan en we bepalen samen of Odoo als PIM volstaat of dat een schil-architectuur zich terugverdient.
Meer lezen: PIM, EDI en klantenportaal voor groothandel · Odoo voor inkoop-, sourcing- en importbedrijven · Van Excel naar Odoo · Wat kost een Odoo-implementatie?