Productdata: één keer goed vastleggen, overal kloppend in je webshop

Welk systeem is leidend voor wat?

Productdata komt bijna nooit uit één systeem. Het artikelnummer en de EAN staan in het ERP, de verkooptekst en de afbeeldingen in het PIM, de technische kenmerken in het bestand van de leverancier. De regel van alle koppelingen, één eigenaar per gegeven, wordt hier per veld ingevuld:

Achter die tabel zit een verschil in doel. Een ERP beschrijft een artikel voor inkoop, magazijn en facturatie. Een webshop beschrijft hetzelfde artikel voor iemand die het wil kopen. In Exact Online heeft een artikel een Description van 60 tekens en een ExtraDescription van 255. Daar staat WERKBR STR BLK 48, en dat is voor een pakbon genoeg. Op de productpagina hoort "Werkbroek Stretch, zwart, maat 48" met een tekst, vijf foto's en een maattabel.

De fout die deze afspraak voorkomt: het ERP stuurt 's nachts de artikelstam door en zet over de titel die marketing heeft geschreven weer WERKBR STR BLK 48. Daarom krijgt elk veld een van drie schrijfwijzen: altijd overschrijven, alleen vullen als het leeg is, of nooit aanraken. Welke bron bij welk veld hoort leg je vast in de veldmapping.

Wat er precies over de lijn gaat

Een product bestaat in de koppeling uit zeven groepen velden. Niet elke bron levert ze allemaal, en niet elke webshop heeft er een plek voor.

Bij kenmerken is er één onderscheid dat de opbouw in de webshop bepaalt. Een attribuut maakt een variant uniek: maat 48, kleur zwart. Een eigenschap geldt voor alle varianten van een model: materiaal, land van herkomst. Het eerste wordt een keuze op de productpagina, het tweede een regel in de specificaties.

Zo ziet één variant eruit in de API van Akeneo:

{
  "uuid": "3f2a9c1e-5b7d-4e8a-9c0f-1d2e3a4b5c6d",
  "family": "werkkleding",
  "parent": "10482-BLK",
  "values": {
    "sku": [{"locale": null, "scope": null, "data": "10482-BLK-048"}],
    "name": [
      {"locale": "nl_NL", "scope": null, "data": "Werkbroek Stretch zwart"},
      {"locale": "de_DE", "scope": null, "data": "Arbeitshose Stretch schwarz"}
    ],
    "description": [
      {"locale": "nl_NL", "scope": "ecommerce", "data": "<p>Stretchbroek met kniezakken.</p>"}
    ]
  }
}

Elke waarde heeft een locale en een scope. De sku is voor alle talen gelijk, de name bestaat in twee talen en de description alleen in het Nederlands voor het kanaal ecommerce. Voor de Duitse webshop ontbreekt de omschrijving dus. Wat er dan gebeurt is een regel per taal: terugvallen op het Nederlands, leeg laten of niet publiceren. Meer over deze route staat in een PIM koppelen aan je webshop.

Varianten: waar de meeste dagen verloren gaan

Vier kleuren keer zes maten is 24 combinaties voor één werkbroek. Een assortiment van 4.000 producten met gemiddeld 3,6 varianten is 14.400 varianten. Elk systeem bouwt die anders op:

De onderste regel kost de meeste tijd. Een ERP zonder variantmodel kent de werkbroek als 24 losse artikelen: 10482-BLK-048, 10482-BLK-050 en zo verder. Zet je die een op een door, dan staan er 24 producten in de webshop. Voor het magazijn klopt dat. Voor de klant niet: hij ziet 24 zoekresultaten en kan op de productpagina geen maat kiezen.

De koppeling heeft dus een veld nodig dat het model aangeeft, en velden voor de assen. Exact Online heeft daarvoor per artikel tien vrije tekstvelden, FreeTextField_01 tot en met FreeTextField_10. Staat het model in het eerste en staan kleur en maat in het tweede en derde, dan groepeert de koppeling op model en maakt hij van elk artikel een variant.

Bij de assen komen drie dingen terug:

• Interne codes. Het ERP zegt BLK en 048, de klant leest Zwart en 48. De vertaaltabel daartussen heeft een eigenaar nodig. Een nieuwe kleurcode NVY zonder regel in de tabel gaat naar de controlelijst en komt niet als NVY op de productpagina.
• Volgorde. Maten die als tekst gesorteerd worden staan op L, M, S, XL. De volgorde komt uit een eigen veld of uit de tabel.
• Een nieuwe as. Krijgt een model met kleur en maat ook een lengtemaat, dan zijn het 4 keer 6 keer 3 is 72 varianten. Het aantal opties is in Shopify op 3 begrensd, dus een vierde as past daar niet in.

Hoe dit per platform wordt opgelost staat bij kleuren en maten als varianten.

Wat er stil misgaat

Fouten in productdata geven zelden een foutmelding. De run slaagt en de webshop toont iets anders dan je bedoelde.

De eerste regel in een voorbeeld. De letter ë is in UTF-8 twee bytes, C3 AB. Een programma dat Windows-1252 verwacht leest ze als twee losse tekens:

In het bestand (UTF-8):     Koppelstuk 22 mm, geëloxeerd
Gelezen als Windows-1252:   Koppelstuk 22 mm, geëloxeerd

De laatste regel van de tabel geldt voor Exact Online: een artikel heeft daar één afbeeldingsveld, Picture, met een PictureUrl. De andere vier foto's van de productpagina komen uit een andere bron.

Bij 14.400 varianten kijk je dit niet meer met het oog na. De controle bestaat uit regels die elke run over de hele set gaan: elke variant heeft een EAN van 13 cijfers met een kloppend controlecijfer, elk product heeft een hoofdafbeelding, geen titel bevat Ã, elke kleurcode staat in de vertaaltabel. Wat een regel niet haalt gaat naar de controlelijst. De achtergrond staat in tekencodering en UTF-8, SKU of EAN en CSV en Excel van leveranciers.

Doorvoer en limieten

Productdata verandert minder vaak dan voorraad, maar één record is veel groter: tientallen velden, meerdere talen en afbeeldingen. De limieten, op 3 oktober 2026 nagelezen in de documentatie van Akeneo, Shopify, WooCommerce en Exact Online:

De eerste lading van 4.000 producten, 14.400 varianten en 20.000 afbeeldingen, uitgerekend:

• Lezen uit Exact Online. 14.400 gedeeld door 60 records per verzoek is 240 verzoeken. Bij 60 verzoeken per minuut duurt dat 4 minuten en kost het 240 van de 5.000 verzoeken van die dag. Via het bulk-endpoint zijn het 15 verzoeken.
• Schrijven naar WooCommerce. 4.000 producten in batches van 100 is 40 verzoeken. De variations gaan per product in een eigen batch: 4.000 verzoeken. Samen 4.040. Verwerkt de server van de webshop er twee per seconde, dan is dat 2.020 seconden: bijna 34 minuten.
• Afbeeldingen. 20.000 foto's van gemiddeld 1,5 MB zijn 30.000 MB, dus 30 GB. Dit deel bepaalt hoe lang de eerste lading duurt.

Daarna gaat alleen mee wat gewijzigd is. Akeneo filtert daarvoor op de datum van de laatste wijziging:

GET /api/rest/v1/products-uuid?search={"updated":[{"operator":">","value":"2026-10-02 22:00:00"}]}&limit=100

Bij 300 gewijzigde producten zijn dat 3 verzoeken in plaats van 144. Voor afbeeldingen werkt hetzelfde met een controlegetal per bestand: 40 nieuwe foto's op een dag zijn 60 MB in plaats van 30 GB. Het tijdstip in het filter is UTC bij de cloudversie van Akeneo. Een run die om 00:00 Nederlandse tijd vraagt om "alles sinds gisteren" en de tijdzone niet omrekent, mist de wijzigingen van een of twee uur. De som voor je eigen aantallen maak je met doorvoer berekenen.

Classificatie: ETIM, GS1 en DICO

In de bouw en de installatietechniek vragen groothandels en hun afnemers om geclassificeerde productdata: een artikel met een ETIM-klasse en ingevulde kenmerken is te filteren en te vergelijken, een artikel met alleen een omschrijving niet. Drie standaarden komen steeds terug.

ETIM deelt technische producten in klassen in en legt per klasse de kenmerken vast. Een klasse heeft een code van EC en zes cijfers, een kenmerk EF en zes cijfers, een waarde EV en zes cijfers. Klasse EC001375 is bijvoorbeeld de accu-excenterschuurmachine. Een kenmerk heeft een van vier typen, en elk type wordt in de webshop een ander soort filter:

Het type R is het lastigst: de meeste webshopplatformen hebben geen attribuut dat twee getallen bevat. De koppeling splitst het in een minimum en een maximum. Een nieuwe release wijzigt klassen en kenmerken, ETIM 10.0 voegde 119 klassen toe. De mapping legt daarom vast op welke release hij gebaseerd is.

GS1 geeft de GTIN uit, het nummer achter de streepjescode. Een GTIN heeft 8, 12, 13 of 14 cijfers. GS1 raadt aan ze op te slaan in een tekstveld van 14 posities met nullen ervoor. 8712345678906 wordt 08712345678906, en een UPC van 12 cijfers en dezelfde code als EAN-13 komen dan op dezelfde waarde uit.

DICO is de berichtenstandaard van Ketenstandaard Bouw en Techniek voor de Nederlandse bouw- en technieksector. Naast orders en facturen kent DICO berichten voor artikelgegevens en productinformatie.

De uitwerking staat bij ETIM- en GS1-classificatie in je webshop en in de kennisbank bij wat is ETIM, wat is GS1 en GDSN en wat is DICO. Voor de branche zelf: bouw en installatietechniek.

Leveranciersdata als bron

Wie geen eigen PIM vult, krijgt productdata van leveranciers: een CSV per e-mail, een Excel met drie werkbladen, een XML op een SFTP-server of een databank zoals EZ-base, die leveranciersdata structureert volgens ETIM en GS1. Elke leverancier heeft eigen kolomnamen. De ene noemt het Artnr;EAN;Omschr, de andere item_no,gtin,description_nl, en bij de derde staat de eenheid in de omschrijving.

De koppeling brengt elk bestand naar één vaste indeling voordat er iets naar het PIM of de webshop gaat. Per leverancier staat vast welke kolom welk veld is, welke tekencodering het bestand heeft, of het een volledig bestand is of alleen de wijzigingen, en wat het betekent als een artikel ontbreekt. Bij een volledig bestand is een ontbrekend artikel uit het assortiment. Bij een bestand met wijzigingen is het onveranderd.

Wanneer een PIM het werk waard is, laat zich uitrekenen. 2.000 wijzigingen per jaar die elk in drie kanalen met de hand worden doorgevoerd, tegen vijf minuten per keer, zijn 30.000 minuten. Dat is 500 uur, ruim 62 werkdagen van acht uur. Met één bron en een koppeling naar de kanalen voer je de wijziging één keer in.

Levert de leverancier ook een adviesprijs of een inkoopprijs mee, dan hoort die bij de prijzenstroom. De voorraad en levertijd uit hetzelfde bestand horen bij voorraad en beschikbaarheid. Het verschil tussen een PIM en een ERP staat in wat is een PIM-systeem.

Jij houdt de controle

Een eerste lading van 4.000 producten zet je niet in één keer live. De koppeling draait eerst droog: hij leest de echte bronnen, past alle regels toe en schrijft niets naar de webshop. Het resultaat is een overzicht:

De 360 afgekeurde producten staan op een controlelijst met de reden per product. Ze worden niet stil overgeslagen. Na herstel in de bron gaan ze met de volgende run mee.

Daarna kies je per bron of wijzigingen op goedkeuring wachten of direct doorgaan. Producten met een tekst die je in de webshop zelf beheert, zet je op een uitsluitingslijst. Na elke run staat er per product en per veld wat er is gewijzigd: 10482-BLK-048, titel nl_NL, van "Werkbroek stretch" naar "Werkbroek Stretch zwart", bron Akeneo. Hoe dat werkt staat bij dry run en goedkeuring en audit trail.

Wij bouwen de koppeling voor een vaste prijs en hosten, draaien en bewaken hem daarna voor een vast bedrag per maand. Verandert een leverancier zijn kolommen of brengt een pakket een nieuwe API-versie uit, dan passen wij de koppeling aan. Vertel welke bronnen en welke webshop je hebt.

Systemen en platformen

Productdata loopt van een bron naar een of meer kanalen. Per systeem een eigen pagina met hoe het gegevens vrijgeeft en waar de mapping op vastloopt:

De andere stromen gebruiken de producten die deze stroom aanmaakt. Voorraad en prijzen worden per variant bijgewerkt, en een order verwijst naar de sku die hier is vastgelegd. Een artikelnummer dat in deze stroom niet matcht, krijgt in de andere drie ook geen update.