Kan ik het productpaspoort koppelen aan mijn ERP- of voorraadsysteem?

Wat u concreet moet doen

Wat er van u wordt verwacht

Het paspoort moet gegevens uit bronsystemen kunnen ontvangen

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) stelt eisen aan welke gegevens in een digitaal productpaspoort moeten staan en hoe die toegankelijk zijn. Die gegevens komen niet uit het niets: ze zitten al in bestaande systemen zoals een ERP-pakket, een PLM-systeem of een voorraadbeheerpakket — materiaalsamenstelling, leveranciersgegevens, batchnummers, zorginstructies. Voor een bedrijf van 10 tot 100 medewerkers betekent dit praktisch dat er een verbinding moet zijn tussen het systeem waar deze gegevens al staan en het systeem dat het paspoort samenstelt en publiceert. Dat kan een geautomatiseerde koppeling zijn, maar ook een periodieke export die handmatig wordt geüpload. Beide zijn in de basis mogelijk; welke vorm praktisch is, hangt af van hoeveel producten en varianten er zijn en hoe vaak gegevens wijzigen.

De technische werking moet aansluiten op vastgestelde standaarden

Artikel 11 van de ESPR (Verordening (EU) 2024/1781) beschrijft het technisch ontwerp en de werking van het paspoort, waaronder de manier waarop data-uitwisseling plaatsvindt. Dit raakt direct aan de vraag hoe een koppeling technisch wordt opgezet: niet elk exportformaat uit een willekeurig ERP-systeem sluit zonder bewerking aan op wat een paspoortsysteem verwacht. Voor een middelgroot bedrijf betekent dit dat er een vertaalslag nodig is tussen de eigen datastructuur en het format dat voor het paspoort wordt gebruikt. Dat is een technisch vraagstuk, geen juridisch — maar het raakt wel aan de vraag wat GS1 Digital Link is en of dat nodig is voor het productpaspoort, omdat een deel van de te verwachten standaardisatie via dat soort systemen loopt.

Elk product moet herleidbaar zijn tot de juiste paspoortgegevens

Een koppeling met een ERP- of voorraadsysteem werkt alleen als er een sluitende manier is om een fysiek product te matchen aan het juiste paspoort. Dat vraagt om een consistente sleutel tussen de systemen: hetzelfde artikelnummer, dezelfde batchcode of dezelfde variant-identificatie in het ERP-systeem als in het paspoort. Zonder die aansluiting ontstaat het risico dat een gekoppeld systeem wel gegevens doorstuurt, maar naar het verkeerde paspoort, of dat een wijziging in het ene systeem niet doorwerkt in het andere. Dit hangt nauw samen met de manier waarop elk product een unieke identificatiecode krijgt; zonder een heldere identificatielogica is een koppeling tussen systemen weinig waard.

Waar het misgaat in de praktijk

Een eerste situatie die vaak terugkomt: een bedrijf heeft een ERP-systeem waarin artikelen per stijl zijn vastgelegd, maar niet per kleur of maat. Het paspoort moet echter op variantniveau kloppen, en dan blijkt de koppeling gegevens door te sturen die voor de ene maat wel kloppen en voor de andere niet.

Een tweede situatie: gegevens worden één keer overgezet bij lancering van een collectie, maar een latere wijziging in het ERP-systeem — bijvoorbeeld een andere leverancier voor een deelpartij — wordt niet automatisch doorgezet naar het gepubliceerde paspoort. Het paspoort raakt zo los van de werkelijkheid zonder dat iemand dat merkt, tot iemand een fout ontdekt en zich afvraagt of een gepubliceerd productpaspoort nog aangepast kan worden.

Een derde situatie: een koppeling wordt technisch opgezet door een externe IT-partij, maar niemand binnen het bedrijf controleert achteraf of de gegevens die in het paspoort terechtkomen ook daadwerkelijk overeenkomen met wat op het etiket of de verpakking staat. Een technische koppeling die werkt, is niet automatisch een koppeling die klopt.

Een vierde situatie: het voorraadsysteem wordt gebruikt om automatisch paspoorten te laten vervallen zodra een product wordt uitverkocht, zonder rekening te houden met de vraag hoe lang een paspoort beschikbaar moet blijven. Dat kan tot een mismatch leiden tussen wat operationeel handig is voor de voorraadadministratie en wat er wordt verwacht met het oog op hoe lang een productpaspoort beschikbaar moet blijven.

Een vijfde situatie: bij een fusie, overname of stopzetting van een bedrijfsonderdeel wordt de koppeling losgekoppeld zonder dat is nagedacht over wie de gegevens daarna beheert, wat weer aansluit op de vraag wat er met het productpaspoort gebeurt als een bedrijf stopt.

Wat u kunt vastleggen

• Een overzicht van welke systemen welke paspoortgegevens leveren: ERP voor materiaal en herkomst, voorraadsysteem voor beschikbaarheid, PLM voor ontwerp- en samenstellingsdata.
• Een vastgelegde afspraak over de frequentie van synchronisatie: realtime koppeling, dagelijkse export, of handmatige update per collectie.
• Een document waarin de identificatiesleutel wordt beschreven die gebruikt wordt om een product in het ERP-systeem te matchen met het juiste paspoort — inclusief hoe dit werkt bij varianten in maat of kleur.
• Een verantwoordelijke functie of persoon die controleert of gegevens die via de koppeling binnenkomen, ook daadwerkelijk kloppen voordat een paspoort wordt gepubliceerd of bijgewerkt.
• Een procedure voor wat er gebeurt bij een wijziging in het bronsysteem: wie signaleert dit, en hoe wordt de wijziging doorgevoerd in het gepubliceerde paspoort.
• Afspraken met een IT-leverancier of interne IT-afdeling over het technisch format van de koppeling, inclusief wat er gebeurt bij een systeemwissel of migratie.
• Een overzicht van welke gegevens wél via een koppeling automatisch worden aangeleverd en welke nog handmatig worden aangevuld, zodat er geen gat ontstaat tussen wat het systeem denkt te versturen en wat werkelijk in het paspoort staat.