DPP-andmete ajakohasena hoidmine: mida ESPR tegelikult nõuab

Alates ESPR-määruse (EL) 2024/1781 vastuvõtmisest on Digital Product Passport (DPP) ELi siduv õigus. Paljud ettevõtted alahindavad aga seda, et DPP ei ole staatiline dokument, mis luuakse üks kord turuletoomisel. Seda tuleb ajakohasena hoida kogu toote elutsükli vältel — ning nõuded muutuvad üha täpsemaks.

See artikkel selgitab, milliseid andmeid ja millal tuleb ajakohastada, kuidas registri arhitektuur mõjutab uuendamismudelit ning millised tehnilised mustrid on praktikas end tõestanud.

Mida määrus uuendamistsükli kohta ütleb

Staatilised vs. dünaamilised andmeväljad

ESPR ise ei määra sõnaselget uuendamissagedust, kuid sätestab, et DPP peab sisaldama „ajakohast ja täpset teavet“. Täpsustus toimub sektoritasandil — ning JRC terasest ja rauast pooltoodete eelnõu annab seni kõige selgema pildi.

Eelnõu eristab süstemaatiliselt kahte andmete detailsusastet:

Tase	Identifikaator	Näidisandmed	Uuendamise põhjus
Partiitase (Lot)	Partiinumber	Taaskasutatud materjali osakaal, sulami koostis, PCF standardi ISO 14067 järgi	Tootmise muudatuse, uue partii korral
Toote tase (Item)	Seerianumber	Mõõtmed, sertifikaadid, vastavusdeklaratsioonid	Uuesti sertifitseerimise, tagasikutsumise, parandamise korral

See eristus on andmebaasi arhitektuuri jaoks otsustava tähtsusega: partiiandmed kirjutatakse tavaliselt üks kord iga tootmispartii kohta ja on seejärel muutumatud — välja arvatud juhul, kui CO₂-jalajälje ümberarvutamisel saadakse korrigeeritud väärtus. Tootetaseme andmed võivad seevastu kogu kasutusaja jooksul muutuda, näiteks kui seadet parandatakse või sertifikaati uuendatakse.

Batterieverordnung (EL) 2023/1542 sisaldab seda eristust juba kaudselt: lagunemise tõttu muutuvad võimsusandmed tuleb ajakohasena hoida — nõue, mida on ilma selge arhitektuurita vaevalt võimalik täita.

Register kui kataloog, mitte andmehoidla

Levinud arusaamatus puudutab keskse DPP-registri rolli. DPP-registri rakendusmääruse eelnõu täpsustab: register salvestab üksnes kordumatu identifikaatori, lahendaja lõpp-punkti ja kaubakoodi — mitte passi tegelikke andmeid.

See tähendab uuenduste haldamise jaoks järgmist: passi sisu ja register on eraldi süsteemid. Tooteandmete ajakohastamisel ei ole üldjuhul vaja registrit muuta — välja arvatud juhul, kui lahendaja lõpp-punkt muutub (näiteks süsteemivahetuse korral). CIRPASS-2 konsortsium juhtis oma registri eelnõu käsitlevas seisukohas sellele arhitektuurimustrile sõnaselgelt tähelepanu ja soovitab lisada standardi EN 18219 rakendusmäärusesse siduva viitena — muu hulgas selleks, et tagada koostalitlusvõime GS1 Digital Link-ga.

Uuendamise stsenaariumid praktikas

Stsenaarium 1: tarnija vahetamise tõttu uus CO₂-jalajälg

Tootepõhist CO₂-jalajälge (PCF) hallatakse JRC terase-eelnõu kohaselt partiitasemel ning see tuleb arvutada standardiga ISO 14067 ühilduvate meetodite abil. Kui terasetootja vahetab energiakandjat või vanaraua tarnijat, muutub uue partii PCF — juba tarnitud partiide oma aga mitte.

Tehniliselt tähendab see, et vana partii DPP-kirje jääb muutmata. Uue partii jaoks luuakse uus kirje, mis võib kasutada sama lahendaja lõpp-punkti, kuid mille identifikaatoriks on uus partiinumber.

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

Stsenaarium 2: tootetaseme sertifikaadi aegumine

Vastavusdeklaratsioonidel ja sertifikaatidel on aegumiskuupäevad. Niipea kui väljastatakse uus sertifikaat, tuleb DPP tootetasemel ajakohastada. Kuna lahendaja lõpp-punkt jääb muutumatuks, ei ole registri uuendamine vajalik — muutub ainult lõpp-punkti taga olev kirje.

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

Stsenaarium 3: lahendaja migreerimine süsteemivahetuse korral

Kui ettevõte vahetab oma DPP-teenusepakkujat, muutub lahendaja lõpp-punkt. Sel juhul tuleb registrit uuendada — iga mõjutatud identifikaatori puhul. See on kõige töömahukam uuendustüüp, sest nõuab registrisse kirjutamist.

Soovitus: kasutage stabiilset enda lahendajat (nt dpp.ihrunternehmen.de) vahekihina, mis suunab päringud sisemiselt vastava teenusepakkuja juurde. Nii jääb registrisse kantud lõpp-punkt püsivalt stabiilseks.

Uuendamissüsteemi tehnilised nõuded

Versioonihaldus ja auditijälg

ESPR ei nõua sõnaselgelt versioonihaldust, kuid tootevastutuse ja tollikontrolli kombinatsioon muudab auditijälje tegelikult vältimatuks. Kui tolliametnik kontrollib 2030. aastal 2027. aastal toodetud terastala DPP, peab olema võimalik tuvastada, millised andmed kehtisid importimise ajal.

Versioonitud DPP-tabeli minimaalne skeem:

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 kui stabiilne identifikaatori ankur

GS1 Digital Link eraldab identifikaatori ja lahendaja selgelt: tootel olev QR-kood kodeerib URL-i, näiteks https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, mis suunab GS1-lahendaja või oma lahendaja kaudu praeguse DPP-kirjeni. Kirje uuendamine ei nõua uut sildistamist — füüsiline andmekandja jääb muutumatuks.

TEKLYNX on oma CODESOFTi tarkvara uuendanud ja toetab nüüd GS1 „++“-kodeerimisskeeme, millega saab veebi-URL-id otse RAIN-RFID-märgise mällu kirjutada — nõue, mis tuleneb standardi EN 18220 ja GS1 Digital Link-standardi kombinatsioonist.

Juhtimine: kes võib mida ajakohastada?

Lisaks tehnilisele küsimusele tuleb lahendada ka juhtimisküsimus: millised tarneahela osalised võivad milliseid DPP välju kirjutada? CIRPASS-2 konsortsium on siin tuvastanud piiriüleste tarneahelate andmesuveräänsusega seotud kriitilised probleemid.

Praktiline mudel eristab kolme rolli:

Tootja (Creator): kirjutab loomisel kõik väljad; võib kõiki välju ajakohastada.
Volitatud osaline (Editor): võib ajakohastada määratletud välju (nt paranduste ajalugu, uued sertifikaadid) — dokumenteerituna oma identifikaatoriga.
Lugeja (Reader): võib lugeda kõiki avalikke välju, kirjutamisõigusi ei ole.

Ecommerce Europe nõudis oma DPP rakendamist käsitlevas seisukohas, et ka kasutatud toodete puhul oleksid võimalikud „osalised DPPs“ — st kirjed, mille puhul uuendatakse vaid osa algsetest väljadest. Tehniliselt on see juba praegu teostatav, kuid rakendusmäärustes puudub see veel formaalse kategooriana.

Kokkuvõte

DPP-andmete ajakohasena hoidmine ei ole ühekordne ülesanne, vaid käitlusprotsess. Kehtivast regulatiivsest olukorrast tulenevad peamised järeldused:

Eristage partiid ja toodet — identifikaatoristrateegia määrab, milliseid andmeid ja millal tuleb ajakohastada.
Register ei ole andmehoidla — passi sisu uuendamine ei nõua üldjuhul registrisse kirjutamist.
Versioonihaldus on tegelikult kohustuslik — isegi kui määrus seda sõnaselgelt ei nõua.
GS1 Digital Link lahutab füüsilise andmekandja ja kirje — see vähendab andmete uuendamisega seotud tööd märgatavalt.
Juhtimisrollid tuleb eelnevalt määratleda — kes tohib mida kirjutada ja kuidas seda protokollitakse?

Standardid muutuvad täpsemaks, esimesed pilootprojektid käivad — kes seab arhitektuuri nüüd õigesti üles, väldib kulukaid parandusi, kui sektoripõhised rakendusmäärused jõustuvad.