DPP-Ohranjanje aktualnosti podatkov: kaj ESPR v resnici zahteva

Od sprejetja ESPR-Uredbe (EU) 2024/1781 je Digital Product Passport (DPP) zavezujoče pravo EU. Mnoge družbe podcenjujejo, da DPP ni statični dokument, ustvarjen enkrat ob uvedbi izdelka na trg. Aktualen mora ostati ves življenjski cikel izdelka — zahteve v zvezi s tem pa postajajo vse natančnejše.

Ta članek pojasnjuje, katere podatke je treba posodobiti in kdaj, kako arhitektura registra vpliva na model posodabljanja ter kateri tehnični vzorci so se v praksi izkazali za učinkovite.

Kaj uredba določa o ciklu posodabljanja

Statična in dinamična podatkovna polja

ESPR sama ne določa izrecne pogostosti posodabljanja, vendar določa, da mora DPP vsebovati »aktualne in točne informacije«. Podrobnosti se določajo na sektorski ravni — in tukaj osnutek JRC za polizdelke iz železa in jekla za zdaj ponuja najbolj jasno sliko.

Osnutek sistematično razlikuje med dvema ravnema podrobnosti podatkov:

Raven	Identifikator	Primeri podatkov	Povod za posodobitev
Raven serije (Lot)	Številka serije	Delež recikliranega materiala, sestava zlitine, PCF po ISO 14067	Ob spremembi proizvodnje, nova serija
Raven izdelka (Item)	Serijska številka	Mere, certifikati, izjave o skladnosti	Ob ponovni certifikaciji, odpoklicu, popravilu

Ta razlika je ključna za arhitekturo podatkovne zbirke: podatki o seriji se običajno zapišejo enkrat na proizvodni cikel in so nato stabilni — razen če ponovni izračun ogljičnega odtisa prinese popravljeno vrednost. Podatki na ravni izdelka pa se lahko spreminjajo ves čas uporabe, na primer ob popravilu naprave ali obnovitvi certifikata.

Uredba o baterijah (EU) 2023/1542 to razlikovanje že implicitno pozna: podatke o zmogljivosti, ki se spreminjajo zaradi degradacije, je treba ohranjati aktualne — zahtevo, ki jo je brez jasne arhitekture težko izpolniti.

Register kot imenik, ne kot podatkovna shramba

Pogost nesporazum se nanaša na vlogo osrednjega DPP-registra. Osnutek izvedbene uredbe o registru DPP jasno določa: register hrani izključno enolični identifikator, končno točko razreševalnika in oznako blaga — ne pa dejanskih podatkov potnega lista.

To pomeni za upravljanje posodobitev: vsebina potnega lista in register sta ločena sistema. Kdor posodablja podatke o izdelku, praviloma ne potrebuje posegati v register — razen če se spremeni končna točka razreševalnika (na primer ob zamenjavi sistema). Konzorcij CIRPASS-2 je v svojem mnenju o osnutku registra izrecno opozoril na ta arhitekturni vzorec in priporočil vključitev standarda EN 18219 kot zavezujoče reference v izvedbeno uredbo — med drugim za zagotavljanje interoperabilnosti z GS1 Digital Link.

Scenariji posodabljanja v praksi

Scenarij 1: Nov ogljični odtis zaradi zamenjave dobavitelja

Ogljični odtis, specifičen za izdelek (PCF), se po osnutku JRC za jeklo vzdržuje na ravni serije in ga je treba izračunati z metodami, združljivimi z ISO 14067. Če proizvajalec jekla zamenja vir energije ali dobavitelja odpadnega materiala, se PCF nove serije spremeni — ne pa tudi PCF že dobavljenih serij.

Tehnično to pomeni: zapis DPP stare serije ostane nespremenjen. Za novo serijo se ustvari nov zapis, ki lahko uporablja isto končno točko razreševalnika, vendar ima kot identifikator novo številko serije.

# 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}
  }'

Scenarij 2: Iztekajoča se certifikacija na ravni izdelka

Izjave o skladnosti in certifikati imajo datume poteka. Takoj ko je izdan nov certifikat, je treba DPP posodobiti na ravni izdelka. Ker končna točka razreševalnika ostane nespremenjena, posodobitev registra ni potrebna — spremeni se le zapis za končno točko.

// 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,
  });
}

Scenarij 3: Migracija razreševalnika ob zamenjavi sistema

Če podjetje zamenja ponudnika storitve DPP, se končna točka razreševalnika spremeni. V tem primeru je treba posodobiti register — za vsak prizadeti identifikator. To je najzahtevnejša vrsta posodobitve, saj zahteva zapis v register.

Priporočilo: uporabite stabilen lasten razreševalnik (npr. dpp.ihrunternehmen.de) kot vmesni sloj, ki interno preusmerja na ustreznega ponudnika. Tako končna točka, vpisana v register, ostane trajno stabilna.

Tehnične zahteve za sistem posodabljanja

Različice in revizijska sled

ESPR ne zahteva izrecnega različičenja, vendar je zaradi kombinacije odgovornosti za izdelek in carinskega nadzora revizijska sled dejansko neizogibna. Če carinik leta 2030 preverja DPP jeklenega nosilca, proizvedenega leta 2027, mora biti mogoče ugotoviti, kateri podatki so veljali ob uvozu.

Minimalna shema za različiceno tabelo DPP:

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 kot stabilno sidro identifikatorja

GS1 Digital Link jasno ločuje identifikator in razreševalnik: koda QR na izdelku kodira URL, kot je https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, ki prek razreševalnika GS1 ali lastnega razreševalnika kaže na aktualni zapis DPP. Posodobitve zapisa ne zahtevajo novega označevanja — fizični nosilec ostane nespremenjen.

TEKLYNX je posodobil svojo programsko opremo CODESOFT in zdaj podpira kodirne sheme GS1 »++«, s katerimi je mogoče spletne URL-je neposredno zapisati v pomnilnik oznak RAIN-RFID — zahteva, ki izhaja iz kombinacije standarda EN 18220 in standarda GS1 Digital Link.

Upravljanje: kdo lahko kaj posodablja?

Poleg tehničnega vprašanja se postavlja tudi vprašanje upravljanja: kateri akterji v dobavni verigi smejo zapisovati katera polja DPP? Konzorcij CIRPASS-2 je tu opredelil ključne vidike suverenosti podatkov v čezmejnih dobavnih verigah.

Praktični model razlikuje tri vloge:

Proizvajalec (Creator): Ob ustvarjanju zapiše vsa polja; posodablja lahko vsa polja.
Pooblaščeni akter (Editor): Posodablja lahko določena polja (npr. zgodovino popravil, nove certifikate) — zabeleženo z lastnim identifikatorjem.
Bralec (Reader): Bere lahko vsa javna polja, nima pravic pisanja.

Ecommerce Europe je v svojem stališču o izvajanju DPP zahteval, da so tudi pri rabljenih izdelkih mogoči »delni DPPs« — torej zapisi, ki posodobijo le del prvotnih polj. Tehnično je to danes že izvedljivo, vendar v izvedbenih uredbah še ni opredeljeno kot formalna kategorija.

Sklep

Ohranjanje aktualnosti podatkov DPP ni enkraten opravek, temveč operativni proces. Najpomembnejše ugotovitve glede trenutnega regulativnega stanja:

Ločite serijo in izdelek — strategija identifikatorjev določa, katere podatke in kdaj je treba posodobiti.
Register ni podatkovna shramba — posodobitve vsebine potnega lista praviloma ne zahtevajo zapisa v register.
Različicenje je dejansko obvezno — tudi če ga uredba izrecno ne zahteva.
GS1 Digital Link ločuje fizični nosilec in zapis — to bistveno zmanjša napor pri posodabljanju podatkov.
Vloge upravljanja je treba opredeliti vnaprej — kdo sme kaj zapisovati in kako se to beleži?

Standardi postajajo natančnejši, prvi pilotni projekti že potekajo — kdor zdaj pravilno vzpostavi arhitekturo, se bo izognil dragim popravkom, ko bodo sektorske izvedbene uredbe začele veljati.