Het korte antwoord
Ja, een bedrijf kan duizenden Digitale Productpaspoorten aanmaken zonder handmatig duizenden volledig verschillende documenten te schrijven. Het schaalbare patroon bestaat uit het aanmaken van één goedgekeurd product- of modeltemplate, het importeren van de variabele gegevens van elk geproduceerd artikel, het creëren of valideren van een unieke identificator voor elk artikel, het genereren van de bijbehorende QR-bestemming, het afdrukken of bevestigen van de juiste code en het vastleggen van de volledige uitgifte- en ingebruiknametracering.
Het belangrijke onderscheid is dat tussen de paspoortstructuur hergebruiken en de identiteit van een artikel hergebruiken. U kunt de gemeenschappelijke technische en duurzaamheidsgegevens van het model hergebruiken. U mag dezelfde identificator op artikelniveau en dezelfde QR-bestemming niet hergebruiken wanneer de toepasselijke regels een individueel productrecord vereisen. Voor batterijen is dit onderscheid essentieel: Verordening (EU) 2023/1542 vereist vanaf 18 februari 2027 een batterijpaspoort voor elke relevante LMT-batterij, industriële batterij van meer dan 2 kWh en elektrische-autobatterij. De verordening vereist ook dat het paspoort toegankelijk is via een QR-code die aan een unieke, aan de batterij toegewezen identificator is gekoppeld, en dat het paspoort informatie bevat die specifiek is voor de afzonderlijke batterij. Lees artikel 77 van de Batterijenverordening op EUR-Lex.
Dit betekent niet dat elk toekomstig DPP in elke productcategorie altijd op artikelniveau wordt opgesteld. Binnen de ESPR kan de toepasselijke gedelegeerde handeling bepalen of een paspoort op model-, batch- of artikelniveau wordt aangemaakt. Artikel 9 van Verordening (EU) 2024/1781 maakt dat niveau tot een productspecifieke vereiste. Behandel batterijen als de huidige, vaste deadline-case op artikelniveau en controleer voor elke andere categorie de gedelegeerde handeling.
Wat verandert er wanneer u van één DPP naar 10.000 gaat?
Bij kleine volumes denkt een team meestal aan velden: materialen, koolstofvoetafdruk, fabrikant, reparatie-informatie en instructies voor het einde van de levensduur. Op schaal wordt de moeilijke vraag de relatie tussen gemeenschappelijke gegevens, variabele gegevens en fysieke identiteit.
| Laag | Herbruikbaar voor een model | Variabel per artikel | Controlevraag |
|---|---|---|---|
| Productdefinitie | Productnaam, specificatie, materialen, goedgekeurd leveranciersbewijs | Meestal weinig of niets | Is de juiste modelrevisie goedgekeurd? |
| Productierecord | Proces- en validatieregels | Serienummer, productiedatum, fabriek, testresultaten | Kan dit exacte artikel aan zijn productiebewijs worden gekoppeld? |
| Paspoortidentiteit | Template en toegangsbeleid | Unieke productidentificator en artikelrecord | Verwijst één identificator naar precies één beoogd artikel? |
| Fysieke drager | Labelopmaak, printinstellingen, mensleesbare velden | De werkelijke QR-payload per artikel | Is het juiste label op de juiste eenheid aangebracht? |
| Levenscyclusstatus | Workflow en auditschema | Status: in gebruik genomen, verzonden, gerepareerd, opnieuw toegepast of gerecycled | Kan een latere wijziging worden bewezen zonder de geschiedenis te wissen? |
De verkeerde snelkoppeling is één QR-code voor een model te genereren, die op elke eenheid te kopiëren en het resultaat een paspoort op artikelniveau te noemen. Dat kan alleen passend zijn wanneer de toepasselijke regel het paspoort op model- of batchniveau definieert. Wanneer het paspoort op artikelniveau vereist is, vernietigt deze snelkoppeling de koppeling tussen het fysieke product en zijn record.
De schaalbare DPP-workflow
De onderstaande workflow scheidt beslissingen die één keer moeten worden genomen van gebeurtenissen die voor elke eenheid moeten plaatsvinden.
1. Definieer het productmodel en het toepasselijke niveau
Begin met het vaststellen van de juridische en operationele scope. Leg de productcategorie vast, de toepasselijke verordening of gedelegeerde handeling, de marktdeelnemer die voor het paspoort verantwoordelijk is, de vereiste gegevensvelden, de toegangslagen en het vereiste niveau: model, batch of artikel.
Bouw het proces voor batterijen rond de vaste vereisten in artikel 77 en artikel 13 van Verordening (EU) 2023/1542. Neem voor andere DPP-categorieën niet aan dat het batterijpatroon automatisch van toepassing is. De ESPR vereist dat de relevante gedelegeerde handeling het niveau en de inrichting van de gegevensdrager specificeert.
De output van deze stap is een goedgekeurd paspoorttemplate, geen QR-code. Het template moet de gemeenschappelijke velden, velddefinities, bronsystemen, bewijsvereisten, validatieregels en het versienummer bevatten.
2. Bereid een schoon batchimportbestand voor
Begin niet met duizenden keren gegevens in een paspoortformulier te plakken. Bereid een gecontroleerd importbestand of integratiepayload voor met één rij per fysieke eenheid wanneer het paspoort op artikelniveau wordt opgesteld.
Een praktisch minimum voor een import van geserialiseerde batterijen kan het volgende bevatten:
| Veldgroep | Voorbeeldvelden | Waarom dit belangrijk is |
|---|---|---|
| Productidentiteit | GTIN of andere goedgekeurde productidentificator, modelcode, productrevisie | Verbindt de eenheid met het juiste template |
| Identiteit van de instantie | Serienummer of toegewezen serienummerreeks | Onderscheidt de ene fysieke eenheid van de andere |
| Productiecontext | Productiedatum, productielocatie, productielijn | Ondersteunt traceerbaarheid en onderzoek |
| Compliancebewijs | Testreferentie, conformiteitsrecord, referentie naar materiaal- of koolstofbewijs | Voorkomt niet-onderbouwde claims in het paspoort |
| Levenscyclusgegevens | Initiële prestatiewaarden, status, datum van ingebruikname | Ondersteunt artikelspecifieke en dynamische informatie |
| Publicatiecontrole | Doelmarkt, taal, toegangsprofiel, publicatiestatus | Voorkomt voortijdige of te brede publicatie |
De exacte velden hangen af van de toepasselijke regels en het product. Een CSV kan een verstandig pilotformaat zijn, maar het bestand moet worden behandeld als een gecontroleerde gegevensuitwisseling, niet als een informeel spreadsheet. Valideer kolomnamen, gegevenstypen, eenheden, vereiste waarden, dubbele identificatoren en bewijsreferenties voordat een paspoort wordt gepubliceerd.
3. Creëer of valideer de unieke identificator
Een schaalbaar systeem moet expliciet antwoord geven op de vraag: wie beheert de toewijzing van identificatoren en hoe wordt uniciteit gegarandeerd? Mogelijke patronen zijn serienummers toewijzen in het productiesysteem, een vooraf uitgegeven serienummerreeks importeren of identificatoren genereren binnen een gecontroleerde DPP-workflow. Ongeacht het patroon moet het DPP-systeem duplicaten afwijzen en het oorspronkelijke toewijzingsrecord bewaren.
Wanneer een GS1-identiteitsmodel wordt gebruikt, kan een geserialiseerd handelsartikel worden uitgedrukt als GTIN plus serienummer. GS1 beschrijft de combinatie van GTIN en serienummer als een manier om een individuele productinstantie uniek te identificeren. De Digital Link-syntaxis kan die identiteit weergeven in een web-URI zoals /01/{GTIN}/21/{serial}. Zie de GS1 Digital Link-standaard en de GS1-Conformant Resolver Standard.
Verzin geen GTIN, beweer niet dat een willekeurige UUID automatisch een conforme GS1-identificator is en beschouw een URL-slug niet als bewijs van wereldwijde uniciteit. Bevestig de identificatiestandaard, de uitgevende instantie, de bedrijfs prefix, het beleid voor serienummertoewijzing en eventuele vereiste registratie- of verificatieprocedures. De DPP-implementatie moet voor elke identificator de bron, het tijdstip, de operator en het validatieresultaat opslaan.
4. Genereer de resolverbestemming en QR-payload
De QR-code moet een stabiele, oplosbare bestemming bevatten die de unieke productidentiteit omvat of daar betrouwbaar naar verwijst. Een resolver gebruikt die identiteit vervolgens om de juiste paspoortweergave, API-representatie of andere geautoriseerde bron terug te geven.
De QR-code is niet het paspoort zelf. Het is de fysieke gegevensdrager die een persoon of systeem een route naar het paspoort geeft. De resolverlaag is belangrijk omdat u mogelijk de bestemming, het toegangsbeleid, de presentatietaal of de gekoppelde bron moet wijzigen zonder de afgedrukte identiteit te wijzigen. De identificator moet persistent blijven, ook wanneer de paspoortinhoud wordt bijgewerkt.
Bij een GS1 Digital Link-patroon kan een payload er conceptueel als volgt uitzien:
https://id.example.com/01/09506000151519/21/12345678p901
Dit is een illustratief syntaxvoorbeeld, geen productie-identificator. Elke productiepayload moet worden gegenereerd vanuit uw geverifieerde identificatortoewijzing en resolverdomein. Test vóór het afdrukken of de payload syntactisch geldig is, via HTTPS wordt opgelost naar het bedoelde artikel en geen gegevens blootstelt aan een onbevoegd publiek.
Zie voor achtergrond over hoe DPP-gegevensdragers verbinding maken met persistente, unieke productidentificatoren artikel 10 van de ESPR. De verordening vereist ook dat de gegevensdrager fysiek aanwezig is op het product, de verpakking of de begeleidende documentatie, zoals bepaald in de toepasselijke gedelegeerde handeling.
5. Render, print and apply the right code
Bulkgeneratie van QR-codes is slechts de helft van het fysieke proces. De andere helft is associatiecontrole: bewijzen dat het label dat voor serienummer A is gegenereerd, ook aan serienummer A is bevestigd.
Gebruik een printdataset waarin de artikelidentificator, QR-payload, voor mensen leesbare serienummer, modelcode en labelversie bij elkaar blijven. De printworkflow moet ten minste het volgende ondersteunen:
- een deterministische rij- of taakidentificator voor elk label;
- een preview of preflightcontrole vóór de printopdracht;
- een duidelijke scheiding tussen goedgekeurde, geprinte, aangebrachte en afgewezen labels;
- afstemming van aangevraagde labels tegenover succesvol geprinte labels;
- scanverificatie na het aanbrengen; en
- quarantaine- en vernietigingsregistraties voor verkeerd geprinte, dubbele en ongebruikte labels.
Voor batterijen vereist artikel 13 de QR-code vanaf 18 februari 2027 en bepaalt het dat de QR-code en labels zichtbaar, leesbaar en onuitwisbaar op de batterij moeten staan, of op de verpakking en begeleidende documenten wanneer plaatsing op de batterij niet mogelijk of vanwege de aard of grootte ervan niet gerechtvaardigd is. Zie artikel 13 van de Batterijenverordening. De exacte productiemethode, symboolindeling en plaatsing moeten voldoen aan de definitieve toepasselijke vereisten en uw gevalideerde verpakkingsproces.
6. Neem het paspoort bij de juiste productiegebeurtenis in gebruik
Een identificator uitgeven is niet hetzelfde als een paspoort in gebruik nemen. Definieer de gebeurtenis die een record van gereserveerd of concept naar actief laat gaan. Dat kan een geslaagde eindelijntest, een kwaliteitsvrijgave, een verpakkingsgebeurtenis of het op de markt brengen van de batterij zijn, afhankelijk van uw proces en juridische verantwoordelijkheid.
De ingebruiknamegebeurtenis moet het volgende vastleggen:
- de artikelidentificator en modelrevisie;
- de productie- of kwaliteitsgebeurtenis die publicatie heeft toegestaan;
- de bronbatch en bewijsreferenties;
- de gebruiker, het systeem of de lijn die de actie heeft uitgevoerd;
- het tijdstempel en de vrijgavestatus;
- de QR-payload en resolverrespons die bij vrijgave zijn waargenomen.
Dit voorkomt een veelvoorkomende fout: duizenden QR-codes worden geprint voordat de onderliggende records compleet zijn, waarna de productie eenheden verzendt waarvan de scans naar een concept, een lege pagina of een ander product verwijzen.
7. Valideer in lagen, niet alleen aan het einde
Een DPP-programma met hoge volumes heeft geautomatiseerde validatie nodig vóór, tijdens en na de uitgifte.
| Validatielaag | Controles | Actie bij fout |
|---|---|---|
| Bestandsvalidatie | Verplichte kolommen, codering, eenheden, datumformaten, aantal rijen | Wijs de import af met een uitvoerbaar foutenrapport |
| Identiteitsvalidatie | Dubbele GTIN- en serienummercombinaties, ongeldige reeksen, hergebruikte identificatoren | Blokkeer uitgifte en plaats de betrokken rijen in quarantaine |
| Inhoudsvalidatie | Verplichte velden, toegestane waarden, bewijsreferenties, toegangsclassificatie | Houd het record in concept- of beoordelingsstatus |
| Resolvervalidatie | HTTPS-respons, juiste artikelkoppeling, verwachte status en toegang | Blokkeer vrijgave totdat de resolver slaagt |
| QR-validatie | Decodeerpercentage, gelijkheid van payload, printcontrast, quiet zone en fysieke leesbaarheid | Print de labeltaak opnieuw of plaats haar in quarantaine |
| Lijnassociatie | Scan artikel en label op het punt van aanbrengen | Stop of leid de lijn om bij een mismatch |
| Monitoring na vrijgave | Gebroken links, onverwachte toegangsproblemen, verouderde gegevens, ingetrokken records | Open een incident en bewaar de audittrail |
Meet succes niet aan het aantal gegenereerde QR-afbeeldingen. Meet het aantal juiste, actieve en traceerbare artikelrecords die een scan op het echte product doorstaan.
Hoe ERP-, PIM- en productiesystemen samenkomen
De DPP-laag moet duidelijke grenzen tussen bronnen van waarheid hebben. De ERP kan de commerciële identiteit, orders en leveranciersrelaties beheren. De PIM kan beschrijvende productinhoud en vertalingen beheren. MES, QMS of een batterijbeheersysteem kan productiegebeurtenissen en prestatiemetingen beheren. Het DPP-systeem stelt de geautoriseerde weergave samen, valideert deze en stelt haar beschikbaar via de vereiste drager en toegangscontroles.
Het integratiepatroon kan gefaseerd worden opgebouwd:
- Pilot: gecontroleerde CSV-import voor één model en een kleine serienummerreeks.
- Geplande synchronisatie: periodieke uitwisseling voor stabiele model- en leveranciersgegevens.
- Gebeurtenisgestuurde synchronisatie: publiceer wijzigingen vanuit ERP, PIM, MES of QMS wanneer een kwalificerende gebeurtenis plaatsvindt.
- Afstemming: vergelijk bronrecords, paspoortrecords, labelaantallen en verzendaantallen.
Laat niet toe dat twee systemen stilletjes serienummers aanmaken voor dezelfde productfamilie. Kies één autoriteit voor toewijzing en zorg ervoor dat alle downstreamsystemen die identiteit gebruiken of valideren. De DPPAutomate-gids voor ERP- en PIM-integratie legt het bredere probleem van mapping en synchronisatie uit, terwijl het integratieoverzicht de juiste plek is om verbindingsopties te beoordelen. Deze links beschrijven het integratieprobleem en het beschikbare productoppervlak; ze claimen niet dat elke connector of integratie met een productiesysteem al beschikbaar is.
Updates, vervangingen en nabewerking
Een DPP op schaal is een levenscyclusrecord, geen statische landingspagina. Verordening (EU) 2024/1781 vereist dat DPP-gegevens juist, volledig en actueel zijn, beperkt updaterechten per toegangsniveau en vereist authenticatie, betrouwbaarheid en integriteit van gegevens. De verordening bepaalt ook dat wanneer een nieuw DPP wordt aangemaakt voor een product dat al een DPP heeft, het nieuwe paspoort aan het oorspronkelijke paspoort of de oorspronkelijke paspoorten moet worden gekoppeld. Zie artikelen 9 tot en met 11 van de ESPR.
Voor batterijen is de verordening nog explicieter over statuswijzigingen. Een batterij die is voorbereid voor hergebruik, voorbereid voor een nieuwe toepassing, opnieuw is toegepast of is gerefabriceerd, moet een nieuw batterijpaspoort krijgen dat aan het oorspronkelijke paspoort of de oorspronkelijke paspoorten is gekoppeld. De oorspronkelijke identiteit en geschiedenis mogen niet worden overschreven om de huidige status als de oorspronkelijke status te laten lijken. Zie artikel 77(7) van de Batterijenverordening.
Ontwerp de workflow rond onveranderlijke gebeurtenissen en een gecontroleerde actuele status:
- Correctie: werk een feitelijk veld bij met reden, goedkeurder en bewijs.
- Nabewerking: leg de nabewerkingsgebeurtenis, betrokken velden en nieuwe kwaliteitsvrijgave vast.
- Vervanging: maak de nieuwe identiteit aan of koppel haar volgens de toepasselijke regels en bewaar de relatie met het oude record.
- Terugroeping of intrekking: wijzig beschikbaarheid of status zonder het historische record te verwijderen.
- Nieuwe toepassing of refabricage: maak het vereiste nieuwe paspoort aan en koppel het aan het origineel.
- Recycling: bewaar de vereiste geschiedenis en sluit het paspoort alleen wanneer de toepasselijke regel bepaalt dat het ophoudt te bestaan.
De QR-code moet naar de stabiele identiteit blijven verwijzen. De resolver kan de actuele geautoriseerde status tonen terwijl het auditsysteem de versiegeschiedenis bewaart.
Ingebruiknamechecklist voor uw eerste 10.000 eenheden
Bevestig elk onderstaande punt voordat u verder opschaalt dan een pilot:
- De toepasselijke productregel bepaalt of het paspoort op model-, batch- of artikelniveau staat.
- Het producttemplate heeft een eigenaar, versie en goedkeuringsstatus.
- Elk vereist veld heeft een benoemde bron en bewijsregel.
- Eén systeem beheert de toewijzing van identificatoren; alle andere systemen valideren deze.
- Tests op duplicaten en botsingen worden vóór de uitgifte uitgevoerd.
- Elke QR-payload verwijst naar precies één beoogd record.
- De printgegevens koppelen serienummer, payload, modelrevisie en taak-ID.
- Op het punt waar het label wordt aangebracht, wordt een fysieke scantest uitgevoerd.
- Verkeerd geprinte en ongebruikte labels worden in quarantaine geplaatst en afgestemd.
- Concept-, goedgekeurde, actieve, ingetrokken en gerecyclede statussen zijn onderscheiden.
- Updates creëren een auditgebeurtenis in plaats van de vorige waarde te wissen.
- Regels voor nabewerking, nieuwe toepassing en vervanging zijn vóór het eerste incident vastgelegd.
- Toegangslagen worden getest met representatieve gebruikersrollen.
- Eigenaarschapsgrenzen van ERP, PIM, MES of QMS zijn gedocumenteerd.
- Het team kan de paspoortgegevens en de uitgifte-audittrail exporteren.
Als het antwoord op een van deze punten « nog niet » is, is het programma niet klaar voor een printopdracht op volledige schaal. Gebruik de DPP-readinesscheck om het gesprek over hiaten te structureren en vergelijk het vereiste implementatiewerk vervolgens met de DPP-kostengids.
Waarop letten bij een DPP-platform of QR-codebatchgenerator
De term « bulk-QR-generator » kan zowel een eenvoudig afbeeldingsscript als een gereguleerde productieworkflow aanduiden. Vergelijk platforms op de controles rond de generator, niet alleen op de snelheid waarmee ze PNG-bestanden maken.
Vraag leveranciers om het volgende te demonstreren:
- hergebruik van templates zonder onbedoeld delen van artikelspecifieke gegevens;
- een gedocumenteerd identificatiemodel en afhandeling van botsingen;
- batchimport met fouten per rij en herhaalbare nieuwe runs;
- resolvermonitoring en verificatie op scanniveau;
- afstemming van printtaken en quarantaine van labels;
- rolgebaseerde toegang en goedkeuringsworkflows;
- versiegeschiedenis, auditexports en statusovergangen;
- integraties of API’s die aansluiten bij uw bronsystemen;
- een duidelijk beleid voor gegevensexport en bedrijfscontinuïteit;
- een praktisch pilotpad vóór uitrol over de volledige catalogus.
De DPPAutomate-platformpagina, de API-documentatie en de gratis registratie zijn geverifieerde DPPAutomate-routes om het bredere platform en technische startpunten te beoordelen. De juiste keuze hangt af van uw productscope, datamaturiteit, productieproces en vereiste identificatieniveau.
Conclusie
Duizenden DPP’s zijn beheersbaar wanneer het werk juist wordt verdeeld: definieer het model één keer, wijs één identiteit toe per vereiste productinstantie, importeer de variabele gegevens, genereer een resolverpayload, druk de bijbehorende QR-code af en breng haar aan, valideer elke overdracht en bewaar de levenscyclusgeschiedenis. De QR-afbeelding is het zichtbare deel van het systeem, maar identiteitsbeheer en productieafstemming maken het resultaat betrouwbaar.
Bereid u voor batterijen nu voor op de verplichting van 18 februari 2027. Bouw het proces op artikelniveau rond artikel 77, controleer de QR- en labelvereisten volgens artikel 13 en test het volledige traject van brongegevens tot fysieke scan. Volg voor elke andere productcategorie de toepasselijke gedelegeerde handeling in plaats van ervan uit te gaan dat alle DPP’s dezelfde granulariteit vereisen.
Klaar om uw eerste geserialiseerde DPP-pilot in kaart te brengen? Begin met de DPP-readinesscheck, bekijk de integratieopties of maak een account aan.
Ga verder binnen het cluster
Als de granulariteit nog niet is vastgesteld, begin dan met de vraag of u voor elk product een afzonderlijk DPP nodig hebt. Batterijteams moeten ook de QR-codeverplichting, de identificatorhiërarchie en de gegevensarchitectuur van model tot artikel bekijken.
