PIM of ERP als bron voor je productdata: de technische verschillen

Het korte antwoord

Het ERP is de bron voor alles wat met geld en goederen te maken heeft: artikelnummer, EAN, eenheid, inkoop- en verkoopprijs, btw-code, voorraad. Het PIM is de bron voor alles wat een koper leest en ziet: titel en omschrijving per taal, kenmerken, afbeeldingen, en welke producten op welk kanaal staan. Een webshop haalt dus uit allebei, per veld.

Wat er misgaat zit op de grens. Een titel die in het ERP wordt aangepast en in het PIM niet. Een artikel dat in het PIM een ander nummer heeft dan in het ERP. Een product dat in de webshop verschijnt voordat de tekst klaar is. Wat een PIM is en wanneer het zich terugverdient, staat in wat is een PIM-systeem. Deze pagina zet de twee naast elkaar op de punten die voor een koppeling tellen.

PIM en ERP naast elkaar

Als voorbeeld Exact Online en Business Central als ERP en Akeneo als PIM, nagelezen in de API-documentatie van alle drie op 3 oktober 2026.

De rij met de productnaam is de reden dat bedrijven een PIM nemen. Exact heeft Description (60 tekens) en ExtraDescription (255), Business Central displayName en displayName2. In Exact staat WERKBR STR BLK 48 omdat er 60 tekens zijn en inkoop het zo leest. In het PIM staat "Werkbroek Stretch, zwart, maat 48" in het Nederlands, Duits en Engels, en een kortere versie voor een marktplaats.

Wie levert welk veld

De sleutel komt uit het ERP. De koppeling zet bij een nieuw artikel het artikelnummer, de EAN en de eenheid in het PIM, en het PIM neemt ze over zonder ze te wijzigen. Prijs en voorraad gaan niet via het PIM maar rechtstreeks van het ERP naar de webshop, omdat ze vaker wijzigen dan een producttekst en een omweg alleen vertraging toevoegt.

Een product gaat pas naar de webshop als het PIM het compleet noemt voor dat kanaal. De Akeneo-API heeft daarvoor een filter op completeness per kanaal. Zo komt een artikel dat inkoop vandaag aanmaakt niet vandaag met alleen WERKBR STR BLK 48 online, maar pas als de tekst en de afbeeldingen er zijn.

Wordt de titel toch in het ERP gewijzigd, dan negeert de koppeling dat veld voor de webshop: per veld ligt vast welk systeem leidend is. Zonder die regel schrijven twee systemen om de beurt hun versie in de webshop, en wint wie het laatst draaide.

Rekenvoorbeeld: een volledige catalogus inlezen

Een assortiment van 25.000 artikelen met gemiddeld 4 afbeeldingen per artikel.

Uit Exact Online haalt de koppeling de artikelgegevens via een sync-endpoint met tot 1.000 records per verzoek: 25.000 / 1.000 = 25 verzoeken. Dat is minder dan een minuut en 0,5% van het dagbudget van 5.000.

Uit Akeneo gaan de producten per 100: 25.000 / 100 = 250 verzoeken. Bij 100 verzoeken per seconde is dat geen probleem. De afbeeldingen wel: 25.000 × 4 = 100.000 downloads, elk een eigen verzoek. Met 4 verzoeken tegelijk per verbinding en een kwart seconde per download zijn dat 16 per seconde. 100.000 / 16 = 6.250 seconden, ruim 1 uur en 44 minuten, voordat de webshop zelf ook maar één afbeelding heeft ontvangen.

Daarom leest een koppeling de catalogus één keer volledig en daarna alleen wat is gewijzigd: Akeneo filtert op updated, en een afbeelding wordt alleen opnieuw opgehaald als het bestand is veranderd. Bij meer dan 10.000 producten moet dat bovendien met search_after: de gewone paginering geeft na het 10.000e product een foutmelding 422. Hoe je zo'n som zelf maakt, staat in doorvoer berekenen.

Waar elk van de twee ophoudt

Het ERP houdt op bij presentatie. Exact Online heeft per artikel één afbeelding en geen veld om varianten aan een hoofdartikel te hangen. Een broek in vier kleuren en zes maten zijn daar 24 losse artikelen. De koppeling moet ze voor de webshop weer samenvoegen tot één product met varianten, op basis van een regel in het artikelnummer of een vrij veld. Business Central v2.0 geeft in de standaard-API één displayName per artikel, zonder taal.

Het PIM houdt op bij geld en goederen. Akeneo bewaart geen voorraad en geen klantspecifieke prijzen. En het PIM accepteert wat er wordt ingevoerd: sinds november 2022 mag een product in Akeneo zonder identifier bestaan. Zo'n product heeft geen artikelnummer om aan het ERP te koppelen, en het endpoint /products geeft het niet terug. De koppeling vindt het alleen via /products-uuid en meldt het dan als product zonder sleutel, in plaats van het stil over te slaan.

Wat elk vraagt aan onderhoud

Het PIM vraagt het meeste onderhoud aan de koppeling, omdat het meegroeit. Een nieuw attribuut in een familie moet een plek krijgen in de webshop: een metafield, een filter, of niets. Een nieuwe taal in het PIM moet in de webshop bestaan voordat de waarden ergens heen kunnen. En wie nu op de Events API van Akeneo leunt om wijzigingen direct te zien, moet voor eind 2026 over op het Event Platform, dat alleen op de SaaS-edities draait.

Wat dit betekent voor je koppeling

Een koppeling tussen ERP, PIM en webshop is drie koppelingen met één afspraak: per veld één bron. Wij leggen die per veld vast, bouwen de koppeling op de API's van jouw systemen en houden de sleutel tussen ERP en PIM gelijk. Producten zonder sleutel of zonder volledige tekst komen op een lijst in het dashboard, niet ongemerkt in de webshop. Wij hosten en bewaken de koppeling en passen hem aan als Akeneo, Exact of je webshop iets wijzigt.

Hoe productdata naar de webshop gaat, staat op productdata koppelen, en voor Akeneo op de Akeneo koppeling. Vertel welk ERP en welk PIM je gebruikt, dan hoor je welke velden uit welk systeem komen.