Waarom het bijwerken van een Digitaal Productpaspoort meer is dan het wijzigen van een databaseveld
Een Digitaal Productpaspoort (DPP) is geen statisch document. Het vergezelt een product gedurende de volledige levenscyclus — van productie via de detailhandel, verder naar reparatie en uiteindelijk recycling. Deze eis vloeit rechtstreeks voort uit de Ecodesign for Sustainable Products Regulation (ESPR), die sinds april 2024 van kracht is en gefaseerd over productcategorieën wordt ingevoerd.
Voor bedrijven betekent dit: een DPP eenmalig aanmaken is niet voldoende. Reparatiegegevens komen erbij, certificaten verlopen, supply chain-data verschuift. Tegelijkertijd mag de wijzigingsgeschiedenis nooit verloren gaan — auditors en markttoezichtautoriteiten moeten kunnen nagaan wie wat wanneer heeft gewijzigd.
Dit artikel doorloopt het technische en organisatorische proces van een DPP-update: welke velden kunnen wijzigen, welke niet, hoe de GS1 Digital Link in het plaatje past, en hoe je een bulk-update over een grote productcatalogus structureert.
Wat kan wijzigen — en wat niet
Onveranderlijke kerngegevens
Bepaalde identificatoren liggen na de initiële certificering vast. De GTIN (Global Trade Item Number) identificeert een product uniek binnen het GS1-systeem en kan achteraf niet worden vervangen. Net zo wordt een serienummer als onveranderlijk beschouwd zodra het aan een fysiek object is toegekend. Dit is geen vergissing — het is een bewuste keuze: de traceerbaarheid langs de supply chain hangt precies van deze stabiliteit af.
Ook de primaire resolver-vermelding van de QR-code — dat wil zeggen de URL waar een GS1 Digital Link naar verwijst — mag niet worden gewijzigd zodra deze op de verpakking is gedrukt. In plaats daarvan werk je de bestemming achter de resolver bij, niet de code zelf. Dit is het belangrijkste voordeel van dynamische QR-codes ten opzichte van statische: de gedrukte code blijft hetzelfde, terwijl de onderliggende data kan evolueren.
Bij te werken velden
De volgende datacategorieën zijn doorgaans bedoeld om bijgewerkt te worden:
- Reparatie- en onderhoudsgegevens: Welke componenten zijn vervangen, wanneer en door wie?
- Certificaten en conformiteitsdocumentatie: Vervaldatums, nieuwe testrapporten
- Recyclinginstructies: Kunnen wijzigen naarmate nieuwe end-of-life-infrastructuur beschikbaar komt
- Carbon footprint: Verfijnd in de loop van de supply chain (bijv. nadat daadwerkelijke transportgegevens beschikbaar zijn)
- Retailer- en distributiegegevens: Nieuwe markten, nieuwe distributiepartners
De ESPR vereist dat deze informatie "actueel, volledig en accuraat" is — zonder een concrete update-frequentie voor te schrijven. In de praktijk bevelen brancheverenigingen zoals EURATEX kwartaalbeoordelingen aan voor de textielsector, met name omdat supply chains onder de huidige omstandigheden snel verschuiven.
De technische update-workflow in detail
Stap 1: Documenteer het wijzigingsverzoek
Voordat er ook maar één databaseveld wordt aangeraakt, moet het wijzigingsverzoek in een ticketsysteem worden vastgelegd. Wie wijzigt wat, en op welke grond (nieuw certificaat, leverancierswissel, reparatie)? Dit is geen bureaucratie om de bureaucratie — het is de basis van de audit trail die markttoezichtautoriteiten kunnen vereisen.
Stap 2: API-aanroep of bulk-import
Voor individuele producten is een gerichte PATCH-aanvraag aan de DPP API de juiste aanpak. Een minimaal voorbeeld in TypeScript:
const response = await fetch(
`https://api.qr3.app/v1/passports/${passportId}`,
{
method: "PATCH",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${API_KEY}`,
},
body: JSON.stringify({
sustainability: {
carbonFootprintKgCO2e: 4.2,
updatedAt: new Date().toISOString(),
updatedBy: "supplier-audit-2025-q2",
},
}),
}
);
if (!response.ok) {
throw new Error(`Update fehlgeschlagen: ${response.status}`);
}
Voor het bijwerken van veel producten tegelijk is een bulk-import efficiënter. Je uploadt een CSV- of JSON-bestand dat alleen de te wijzigen velden bevat — niet het volledige paspoort. Dit minimaliseert foutbronnen en houdt de payload klein.
curl -X POST https://api.qr3.app/v1/passports/bulk-update \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: multipart/form-data" \
-F "file=@updates_q2_2025.csv" \
-F "dryRun=true"
De vlag dryRun=true is belangrijk: hij valideert het bestand zonder iets weg te schrijven. Pas na handmatige goedkeuring wordt de daadwerkelijke import geactiveerd.
Stap 3: Versiebeheer en audit trail
Elke succesvolle wijziging creëert een nieuwe versierij. Het onderliggende databaseschema volgt een eenvoudig principe — append-only:
INSERT INTO passport_versions (
passport_id,
version_number,
changed_fields,
changed_by,
changed_at,
previous_hash,
new_hash
)
VALUES (
$1, $2, $3::jsonb, $4, NOW(), $5, $6
);
Het hash-mechanisme zorgt ervoor dat manipulatie achteraf detecteerbaar is. Elke versie verwijst naar de hash van de vorige — vergelijkbaar met een blockchain, maar zonder de overhead van een publieke keten.
Stap 4: Invalideer de resolver-cache
Na een update moet de GS1 Digital Link Resolver zijn cache invalideren voor de betreffende GTIN/serienummer-vermelding. Anders zien gebruikers die de QR-code scannen nog steeds verouderde data. Typische cache-TTL's bedragen 5–15 minuten; voor tijdkritische updates (bijv. een productterugroeping) moet een onmiddellijke invalidatie via API worden geactiveerd.
Bijzondere aandachtspunten voor de textielindustrie
De Europese textielindustrie staat onder aanzienlijke druk. EURATEX meldt dat de sector voor het derde opeenvolgende jaar krimpt — fabrieken sluiten, supply chains verplaatsen zich. Juist in dergelijke periodes stapelen DPP-relevante wijzigingen zich op: een leverancier valt weg, een ander neemt het over, certificaten moeten opnieuw worden uitgegeven.
De ESPR-gedelegeerde verordening voor textiel (prioriteit vanaf 2026) vereist onder meer informatie over vezelsamenstelling, productieland en recyclebaarheid. Dit zijn allemaal velden die kunnen wijzigen wanneer een leverancier verandert. Bedrijven zouden daarom nu al processen moeten opzetten die automatisch een DPP-updateverzoek activeren zodra zo'n wijziging optreedt — in plaats van het als handmatig nawerk te behandelen.
Een pragmatische aanpak: webhook-integratie met je ERP-systeem. Zodra een nieuwe leverancier in het ERP wordt aangemaakt en aan een product wordt toegewezen, vuurt een webhook af en start er een DPP-update-workflow.
// ERP webhook handler (simplified)
app.post("/webhooks/supplier-change", async (req, res) => {
const { productId, newSupplierId, effectiveDate } = req.body;
await dppUpdateQueue.add({
passportId: await resolvePassportId(productId),
fields: {
supplyChain: {
primarySupplier: newSupplierId,
supplierChangeDate: effectiveDate,
},
},
requiresReview: true, // Manual approval before publishing
});
res.status(202).json({ queued: true });
});
Governance: Wie mag wat wijzigen?
Een DPP-update is geen triviale technische taak. De ESPR houdt de marktdeelnemer die het product op de markt brengt verantwoordelijk voor de juistheid van de data. Dat betekent dat niet elke medewerker willekeurige velden zou mogen bewerken.
Een rolgebaseerd model is aan te raden:
| Rol | Toegestane velden | Goedkeuring vereist |
|---|---|---|
| Leverancier | Materiaalsamenstelling, CO₂-data | Ja, door merkeigenaar |
| Reparatiewerkplaats | Reparatiehistorie, reserveonderdelen | Nee (automatisch) |
| Complianceteam | Certificaten, conformiteitsdocumentatie | Nee (automatisch) |
| Beheerder | Alle velden | Ja, vierogenprincipe |
Deze tabel dekt drie betekenisvolle dimensies (rol, velden, goedkeuring) — ze is bewust gestructureerd, niet opgeblazen.
Conclusie: Updates zijn de norm, niet de uitzondering
Het Digitaal Productpaspoort is geen eenmalig compliancedocument dat je afvinkt en vergeet. Het leeft. Zodra je dat begrijpt, bouw je vanaf het begin processen die updates ondersteunen — met duidelijk eigenaarschap, technisch versiebeheer en geautomatiseerde triggers vanuit het ERP.
De textielindustrie is een bijzonder sprekend voorbeeld: in een sector die structureel onder druk staat en waar supply chains vaak verschuiven, is een robuuste update-workflow geen nice-to-have — het is een operationele noodzaak. De regelgevende eisen van de ESPR en de bijbehorende gedelegeerde verordeningen zullen deze eisen in de komende jaren alleen maar verscherpen.
