DPP-Håll data aktuella: Vad ESPR faktiskt föreskriver

Sedan ESPR-förordningen (EU) 2024/1781 antogs är Digital Product Passport (DPP) bindande EU-rätt. Vad många företag underskattar: DPP är inget statiskt dokument som skapas en gång vid produktlanseringen. Det måste hållas aktuellt under hela produktens livscykel — och kraven på detta blir allt mer precisa.

Den här artikeln förklarar vilka data som måste uppdateras när, hur registerarkitekturen påverkar uppdateringsmodellen och vilka tekniska mönster som fungerar i praktiken.

Vad förordningen säger om uppdateringscykeln

Statiska och dynamiska datafält

Själva ESPR anger ingen uttrycklig uppdateringsfrekvens, men fastställer att DPP måste innehålla ”aktuell och korrekt information”. Konkretiseringen sker på sektorsnivå — och här ger JRC:s utkast för halvfabrikat av järn och stål den hittills tydligaste bilden.

Utkastet skiljer systematiskt mellan två datagranulariteter:

Nivå	Identifierare	Exempeldata	Anledning till uppdatering
Partinivå (Lot)	Partinummer	Återvunnet material, legeringssammansättning, PCF enligt ISO 14067	Vid produktionsändring, nytt parti
Produktnivå (Item)	Serienummer	Mått, certifieringar, försäkran om överensstämmelse	Vid omcertifiering, återkallelse, reparation

Denna åtskillnad är avgörande för databasarkitekturen: Partidata skrivs vanligtvis en gång per produktionskörning och är därefter stabila — såvida inte en efterberäkning av koldioxidavtrycket ger ett korrigerat värde. Data på produktnivå kan däremot ändras under hela användningstiden, till exempel när en enhet repareras eller en certifiering förnyas.

Batteriförordningen (EU) 2023/1542 känner redan implicit till denna åtskillnad: Kapacitetsdata som förändras genom degradering måste hållas aktuella — ett krav som knappast kan uppfyllas utan en tydlig arkitektur.

Registret som katalog, inte datalager

Ett vanligt missförstånd gäller rollen för det centrala DPP-registret. Utkastet till genomförandeförordning om DPP-registret klargör: Registret lagrar endast den unika identifieraren, resolver-slutpunkten och varukoden — inte själva passuppgifterna.

Detta innebär för uppdateringshanteringen: Passinnehåll och register är separata system. Den som uppdaterar produktdata behöver i regel inte ändra registret — såvida inte resolver-slutpunkten ändras (till exempel vid ett systembyte). CIRPASS-2-konsortiet har uttryckligen pekat på detta arkitekturmönster i sitt yttrande om registerutkastet och rekommenderar att standarden EN 18219 tas med som bindande referens i genomförandeförordningen — bland annat för att säkerställa interoperabilitet med GS1 Digital Link.

Uppdateringsscenarier i praktiken

Scenario 1: Nytt koldioxidavtryck efter leverantörsbyte

Det produktspecifika koldioxidavtrycket (PCF) hanteras enligt JRC:s stålutkast på partinivå och måste beräknas med ISO 14067-kompatibla metoder. Om en stålproducent byter energibärare eller skrotleverantör ändras PCF-värdet för det nya partiet — men inte för de redan levererade partierna.

Tekniskt innebär det att DPP-posten för det gamla partiet förblir oförändrad. För det nya partiet skapas en ny post, som kan använda samma resolver-slutpunkt men har ett nytt partinummer som identifierare.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scenario 2: Utgående certifiering på produktnivå

Försäkran om överensstämmelse och certifieringar har giltighetstider. Så snart en ny certifiering utfärdas måste DPP uppdateras på produktnivå. Eftersom resolver-slutpunkten förblir oförändrad behövs ingen registeruppdatering — endast posten bakom slutpunkten ändras.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scenario 3: Resolvermigrering vid systembyte

Om ett företag byter sin DPP-leverantör ändras resolver-slutpunkten. I detta fall måste registret uppdateras — för varje berörd identifierare. Det är den mest omfattande uppdateringstypen, eftersom den kräver en registerpost.

Rekommendation: Använd en stabil, egen resolver (t.ex. dpp.ihrunternehmen.de) som mellanlager och vidarebefordra internt till respektive leverantör. På så sätt förblir slutpunkten som registrerats i registret permanent stabil.

Tekniska krav på uppdateringssystemet

Versionshantering och revisionsspår

ESPR kräver ingen uttrycklig versionshantering, men kombinationen av produktansvar och tullkontroll gör ett revisionsspår i praktiken ofrånkomligt. Om en tulltjänsteman år 2030 kontrollerar DPP för en stålbalk som producerades 2027 måste det gå att fastställa vilka data som gällde vid importtillfället.

Minimalt schema för en versionshanterad DPP-tabell:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link som stabil identifierarankare

GS1 Digital Link skiljer tydligt mellan identifierare och resolver: QR-koden på produkten kodar en URL som https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, som via GS1-resolver eller en egen resolver pekar på den aktuella DPP-posten. Uppdateringar av posten kräver ingen ny etikettering — den fysiska databäraren förblir oförändrad.

TEKLYNX har uppdaterat sin CODESOFT-programvara och stöder nu GS1:s ”++”-kodningsscheman, med vilka webbadresser kan skrivas direkt till RAIN RFID-tagます minne — ett krav som följer av kombinationen av EN 18220 och GS1 Digital Link-standarden.

Styrning: Vem får uppdatera vad?

Utöver den tekniska frågan uppstår styrningsfrågan: Vilka aktörer i leveranskedjan får skriva vilka fält i DPP? CIRPASS-2-konsortiet har identifierat kritiska frågor om datasuveränitet i gränsöverskridande leveranskedjor.

En praktisk modell skiljer mellan tre roller:

Tillverkare (Creator): Skriver alla fält vid skapandet och får uppdatera alla fält.
Auktoriserad aktör (Editor): Får uppdatera definierade fält (t.ex. reparationshistorik och nya certifieringar) — dokumenterat med en egen identifierare.
Läsare (Reader): Kan läsa alla offentliga fält, men har inga skrivrättigheter.

Ecommerce Europe har i sitt positionspapper om DPP-implementeringen krävt att även ”partiella DPPs” ska vara möjliga för begagnade produkter — det vill säga poster som endast uppdaterar en del av de ursprungliga fälten. Detta kan redan genomföras tekniskt, men saknas fortfarande som formell kategori i genomförandeförordningarna.

Slutsats

Att hålla DPP-data aktuella är inte en engångsinsats, utan en löpande process. De viktigaste slutsatserna utifrån det aktuella regelverket:

Skilj mellan parti och produkt — identifierarstrategin avgör vilka data som måste uppdateras och när.
Registret är inget datalager — uppdateringar av passinnehållet kräver i regel ingen registerpost.
Versionshantering är i praktiken obligatorisk — även om förordningen inte uttryckligen kräver det.
GS1 Digital Link kopplar bort fysisk databärare från datapost — det minskar arbetet vid datauppdateringar avsevärt.
Styrningsroller måste definieras i förväg — vem får skriva vad, och hur loggas det?

Standarderna blir mer precisa och de första pilotprojekten pågår — den som sätter arkitekturen rätt nu undviker kostsamma korrigeringar när de sektorsspecifika genomförandeförordningarna träder i kraft.