DPP duomenų atnaujinimas: ką iš tiesų nustato ESPR

Nuo ESPR reglamento (ES) 2024/1781 priėmimo Digital Product Passport (DPP) yra privaloma ES teisės dalis. Daugelis įmonių neįvertina vieno dalyko: DPP nėra statiškas dokumentas, vieną kartą sukuriamas pateikiant produktą į rinką. Jis turi būti nuolat atnaujinamas per visą produkto gyvavimo ciklą, o reikalavimai vis labiau tikslinami.

Šiame straipsnyje paaiškinama, kokius duomenis ir kada reikia atnaujinti, kaip registro architektūra veikia atnaujinimo modelį ir kokie techniniai modeliai pasiteisina praktikoje.

Ką reglamentas sako apie atnaujinimo ciklą

Statiniai ir dinaminiai duomenų laukai

Pats ESPR nenustato konkretaus atnaujinimo dažnio, tačiau įtvirtina, kad DPP turi būti pateikta „aktuali ir tiksli informacija“. Konkretizavimas atliekamas sektoriaus lygmeniu, o kol kas aiškiausią vaizdą pateikia JRC projektas dėl geležies ir plieno pusgaminių.

Projekte sistemiškai skiriami du duomenų detalumo lygiai:

Lygis	Identifikatorius	Duomenų pavyzdžiai	Atnaujinimo priežastis
Partijos lygis (Lot)	Partijos numeris	Perdirbtos medžiagos dalis, lydinio sudėtis, PCF pagal ISO 14067	Pasikeitus gamybai, naujai partijai
Produkto lygis (Item)	Serijos numeris	Matmenys, sertifikatai, atitikties deklaracijos	Pakartotinis sertifikavimas, atšaukimas, remontas

Šis skirtumas yra labai svarbus duomenų bazės architektūrai: partijos duomenys paprastai įrašomi kartą per gamybos ciklą ir vėliau išlieka stabilūs, nebent perskaičiavus CO₂ pėdsaką gaunama patikslinta reikšmė. Produkto lygmens duomenys gali keistis per visą naudojimo laikotarpį, pavyzdžiui, kai įrenginys suremontuojamas arba atnaujinamas sertifikatas.

Baterijų reglamente (ES) 2023/1542 šis skirtumas jau numanomas: dėl degradacijos besikeičiantys talpos duomenys turi būti atnaujinami, o šio reikalavimo be aiškios architektūros beveik neįmanoma įvykdyti.

Registras kaip katalogas, o ne duomenų saugykla

Dažnas nesusipratimas susijęs su centrinio DPP registro vaidmeniu. Įgyvendinimo reglamento dėl DPP registro projekte aiškiai nurodyta: registre saugomas tik unikalus identifikatorius, sprendiklio galinis taškas ir prekių kodas, o ne patys paso duomenys.

Tai reiškia, kad atnaujinimų valdymo požiūriu paso turinys ir registras yra atskiros sistemos. Atnaujinant produkto duomenis paprastai nereikia keisti registro, nebent pasikeičia sprendiklio galinis taškas, pavyzdžiui, pereinant prie kitos sistemos. CIRPASS-2 konsorciumas savo pozicijoje dėl registro projekto aiškiai atkreipė dėmesį į šį architektūros modelį ir rekomenduoja į įgyvendinimo reglamentą įtraukti standartą EN 18219 kaip privalomą nuorodą, be kita ko, siekiant užtikrinti sąveikumą su GS1 Digital Link.

Atnaujinimo scenarijai praktikoje

1 scenarijus: naujas CO₂ pėdsakas pasikeitus tiekėjui

Produkto CO₂ pėdsakas (PCF) pagal JRC plieno projektą tvarkomas partijos lygmeniu ir turi būti apskaičiuojamas taikant su ISO 14067 suderinamus metodus. Plieno gamintojui pakeitus energijos išteklių ar metalo laužo tiekėją, pasikeičia naujos partijos PCF, bet ne jau išsiųstų partijų PCF.

Techniškai tai reiškia, kad senos partijos DPP įrašas lieka nepakeistas. Naujai partijai sukuriamas naujas įrašas, kuris gali naudoti tą patį sprendiklio galinį tašką, tačiau turi naują partijos numerį kaip identifikatorių.

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

2 scenarijus: baigiantis galioti produkto lygmens sertifikavimas

Atitikties deklaracijos ir sertifikatai turi galiojimo datas. Išdavus naują sertifikatą, turi būti atnaujintas DPP produkto lygmeniu. Kadangi sprendiklio galinis taškas nesikeičia, registro atnaujinti nereikia, keičiasi tik už galinio taško esantis įrašas.

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

3 scenarijus: sprendiklio perkėlimas pakeitus sistemą

Įmonei pakeitus DPP paslaugų teikėją, pasikeičia sprendiklio galinis taškas. Tokiu atveju registrą reikia atnaujinti kiekvienam susijusiam identifikatoriui. Tai sudėtingiausias atnaujinimo tipas, nes reikia įrašyti duomenis į registrą.

Rekomendacija: naudokite stabilų nuosavą sprendiklį, pavyzdžiui, dpp.ihrunternehmen.de, kaip tarpinį sluoksnį, kuris viduje nukreipia į atitinkamą paslaugų teikėją. Taip registre įrašytas galinis taškas išlieka stabilus.

Techniniai atnaujinimo sistemos reikalavimai

Versijų valdymas ir audito seka

ESPR nereikalauja aiškaus versijų valdymo, tačiau dėl atsakomybės už gaminius ir muitinės kontrolės audito seka faktiškai yra neišvengiama. Jei 2030 m. muitinės pareigūnas tikrina 2027 m. pagamintos plieninės sijos DPP, turi būti įmanoma nustatyti, kokie duomenys galiojo importo metu.

Minimalus versijuotos DPP lentelės modelis:

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 kaip stabilus identifikatoriaus pagrindas

GS1 Digital Link aiškiai atskiria identifikatorių nuo sprendiklio: gaminyje esantis QR kodas užkoduoja URL, pavyzdžiui, https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, kuris per GS1 sprendiklį arba nuosavą sprendiklį nukreipia į aktualų DPP įrašą. Atnaujinant įrašą nereikia iš naujo ženklinti gaminio, nes fizinė laikmena lieka nepakitusi.

TEKLYNX atnaujino savo CODESOFT programinę įrangą ir dabar palaiko GS1 „++“ kodavimo schemas, leidžiančias interneto URL tiesiogiai įrašyti į RAIN RFID žymos atmintį. Tai reikalavimas, kylantis iš EN 18220 ir GS1 Digital Link standarto derinio.

Valdymas: kas ką gali atnaujinti?

Be techninio klausimo, kyla ir valdymo klausimas: kurie tiekimo grandinės dalyviai gali įrašyti konkrečius DPP laukus? CIRPASS-2 konsorciumas nustatė svarbius duomenų suvereniteto iššūkius tarpvalstybinėse tiekimo grandinėse.

Praktiniame modelyje skiriami trys vaidmenys:

Gamintojas (Creator): kurdamas įrašo visus laukus; gali atnaujinti visus laukus.
Įgaliotasis veikėjas (Editor): gali atnaujinti nustatytus laukus, pavyzdžiui, remonto istoriją ir naujus sertifikatus, o veiksmas dokumentuojamas jo identifikatoriumi.
Skaitytojas (Reader): gali skaityti visus viešus laukus, tačiau neturi rašymo teisių.

Ecommerce Europe savo pozicijoje dėl DPP įgyvendinimo pareikalavo, kad naudotiems gaminiams būtų galimi ir „daliniai DPPs“, t. y. įrašai, atnaujinantys tik dalį pradinių laukų. Techniškai tai jau įmanoma, tačiau įgyvendinimo reglamentuose ši kategorija dar nėra formaliai įtvirtinta.

Išvada

DPP duomenų atnaujinimas nėra vienkartinis darbas, o veiklos procesas. Svarbiausios išvados iš dabartinės reguliavimo padėties:

Atskirkite partiją ir produktą – identifikatorių strategija lemia, kokius duomenis ir kada reikia atnaujinti.
Registras nėra duomenų saugykla – paso turinio atnaujinimams paprastai nereikia įrašo registre.
Versijų valdymas faktiškai privalomas – net jei reglamente tai aiškiai nenurodyta.
GS1 Digital Link atskiria fizinę laikmeną nuo įrašo – tai gerokai sumažina duomenų atnaujinimo sąnaudas.
Valdymo vaidmenys turi būti apibrėžti iš anksto – kas gali ką įrašyti ir kaip tai registruojama?

Standartai tampa tikslesni, vykdomi pirmieji bandomieji projektai. Dabar tinkamai sukūrus architektūrą, bus išvengta brangiai kainuojančių taisymų, kai įsigalios sektorių įgyvendinimo reglamentai.