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

Wat u concreet moet doen

Wat er van u wordt verwacht

Gegevens moeten machineleesbaar en overdraagbaar zijn

Artikel 10 van de ESPR (Verordening (EU) 2024/1781) schrijft voor dat de gegevens in het digitale productpaspoort in een gestructureerd, machineleesbaar formaat beschikbaar zijn. Dat is meteen het aanknopingspunt voor koppeling met een eigen systeem: gegevens die machineleesbaar zijn, zijn in principe ook geschikt om automatisch in of uit een ERP- of voorraadsysteem te laten lopen. Voor een bedrijf van 10 tot 100 medewerkers betekent dit vooral dat de vraag "kan dit gekoppeld worden" niet in de eerste plaats een juridische vraag is, maar een technische: welk formaat gebruikt het paspoort, en kan de eigen software dat formaat lezen of schrijven. Zie ook de pagina over in welk formaat moet ik de gegevens aanleveren voor het productpaspoort.

Het paspoort moet aansluiten op een uniforme technische structuur

Artikel 11 van de ESPR gaat over het technisch ontwerp en de werking van het paspoort, en verwijst naar technische specificaties die de Commissie nog verder uitwerkt. Voor de praktijk van koppelen betekent dit dat er niet zomaar "een eigen bestandje" kan worden aangeleverd of opgehaald: er ligt een gestandaardiseerde structuur onder, waarschijnlijk gebaseerd op bestaande identificatiesystemen. Wie nu al werkt met een systeem voor artikelcodering, doet er goed aan te bekijken hoe dat aansluit op de manier waarop straks unieke identificatiecodes worden toegekend — zie hoe geef ik elk product een unieke identificatiecode. Een ERP-systeem dat al met eenduidige, stabiele productcodes werkt, staat er voor de koppeling gunstiger voor dan een systeem waarin codes per order of per klant verschillen.

De koppeling loopt via een drager, niet via een directe databaseverbinding

Artikel 11 beschrijft ook dat het paspoort toegankelijk is via een datadrager op het product. Dat is een belangrijk punt voor de verwachting die een bedrijf mag hebben van "koppelen": het gaat niet om een rechtstreekse databasekoppeling tussen twee bedrijven, maar om een keten waarin de datadrager (doorgaans een QR-code) verwijst naar een opgeslagen paspoort. De koppeling met een ERP- of voorraadsysteem zit dus aan twee kanten: bij het aanleveren van productgegevens vanuit het eigen systeem naar de partij die het paspoort samenstelt, en bij het inlezen van paspoortgegevens (bijvoorbeeld bij inkoop van staal) in het eigen systeem. Meer over die drager staat op de pagina hoe komt de QR-code voor het productpaspoort op mijn staal.

Gegevens moeten actueel blijven zolang het paspoort bestaat

Uit artikel 10 volgt ook dat gegevens in het paspoort correct en actueel moeten zijn zolang het paspoort bestaat. Voor een koppeling met een voorraadsysteem betekent dit dat eenmalig aanleveren meestal niet volstaat: als eigenschappen van een partij staal wijzigen, of als een fout wordt ontdekt, moet er een manier zijn om dat door te geven aan de plek waar het paspoort wordt gehost. Bedrijven die hun ERP-systeem koppelen, doen er goed aan hierbij ook te kijken naar hoelang die actualiteit moet worden bijgehouden — zie hoe lang moet een productpaspoort beschikbaar blijven.

Waar het misgaat in de praktijk

Interne artikelcodes worden verward met de officiële productidentificatie. Een ERP-systeem kent een product onder een interne SKU, terwijl het paspoort een andere, unieke identificatiecode nodig heeft. Zonder een vertaaltabel tussen beide ontstaat verwarring bij het koppelen, vooral als één interne code meerdere partijen dekt.

Voorraadmutaties worden niet doorgezet naar de paspoortgegevens. Een voorraadsysteem registreert bijvoorbeeld dat een partij staal is omgesmolten, gesplitst of samengevoegd, maar die wijziging bereikt het paspoort niet automatisch. Dit speelt sterk mee bij de vraag of staal per batch of per stuk wordt geregistreerd — zie registreer ik staal per batch of per stuk — want de registratie-eenheid in het ERP-systeem moet aansluiten op de eenheid waarop het paspoort is gebaseerd.

Exportbestanden uit het ERP-systeem sluiten niet aan op het vereiste formaat. Veel ERP-pakketten exporteren standaard in Excel, CSV of een eigen XML-structuur. Zonder afstemming vooraf blijkt zo'n bestand niet compatibel met het formaat dat nodig is voor het paspoort, met vertraging en extra handwerk als gevolg.

Er wordt van uitgegaan dat de koppeling ook zonder internetverbinding werkt. Sommige voorraadsystemen op de werkvloer draaien deels offline, bijvoorbeeld op een magazijnterminal. Dat roept de vraag op of het paspoort zelf ook zonder verbinding raadpleegbaar moet zijn; dat is een aparte vraag die los staat van de koppeling met het ERP-systeem. Zie moet het productpaspoort ook werken zonder internetverbinding.

Toegangsrechten tussen systemen worden niet geregeld. Een koppeling betekent dat gegevens tussen twee of meer systemen stromen, vaak via een derde partij die het paspoort host. Als niet vastligt wie welke gegevens mag inzien, aanpassen of doorgeven, ontstaat onduidelijkheid over verantwoordelijkheid bij een fout — een vraag die raakt aan hoe de gegevens onderweg beveiligd zijn, zie hoe zorg ik dat de gegevens in het productpaspoort veilig zijn.

Wat u kunt vastleggen

• Een overzicht van welke velden in het ERP- of voorraadsysteem corresponderen met welke velden in het productpaspoort, inclusief een vertaaltabel tussen interne artikelcodes en de unieke identificatiecode van het product.
• Een beschrijving van het exportformaat dat het eigen systeem gebruikt, en een vergelijking met het formaat dat voor het paspoort nodig is.
• Afspraken met de partij die het paspoort samenstelt of host over de frequentie en manier van gegevensuitwisseling: eenmalig bij aanmaak, of doorlopend bij wijzigingen.
• Een procedure voor het doorgeven van wijzigingen in voorraad, partij-indeling of producteigenschappen aan de paspoortgegevens, inclusief wie daarvoor verantwoordelijk is.
• Een overzicht van wie binnen het bedrijf toegang heeft tot de koppeling tussen het eigen systeem en het paspoort, en welke rechten daarbij horen.
• Een vastgelegde afspraak over wat er gebeurt met de koppeling en de gegevensstroom als het paspoort voor een product wordt aangepast, ingetrokken of vervangen.