DPP-Datu aktualizēšana: ko patiesībā nosaka ESPR

Kopš ESPR regulas (ES) 2024/1781 pieņemšanas Digital Product Passport (DPP) ir saistošas ES tiesības. Daudzi uzņēmumi nenovērtē to, ka DPP nav statisks dokuments, kas tiek izveidots vienreiz, produktam nonākot tirgū. Tas ir jāuztur aktuāls visā produkta dzīves ciklā — un prasības šajā jomā kļūst arvien precīzākas.

Šajā rakstā skaidrots, kādi dati un kad ir jāatjaunina, kā reģistra arhitektūra ietekmē atjaunināšanas modeli un kādi tehniskie risinājumi praksē sevi pierāda.

Ko regula nosaka par atjaunināšanas ciklu

Statiskie un dinamiskie datu lauki

Pati ESPR nenosaka skaidru atjaunināšanas biežumu, taču paredz, ka DPP jāietver “aktuāla un precīza informācija”. Konkretizācija notiek nozaru līmenī — un līdz šim skaidrāko ainu sniedz JRC projekts dzelzs un tērauda pusfabrikātiem.

Projektā sistemātiski nošķirti divi datu detalizācijas līmeņi:

Līmenis	Identifikators	Datu piemēri	Atjaunināšanas iemesls
Partijas līmenis (Lot)	Partijas numurs	Pārstrādātā materiāla īpatsvars, sakausējuma sastāvs, PCF saskaņā ar ISO 14067	Ražošanas izmaiņas, jauna partija
Produkta līmenis (Item)	Sērijas numurs	Izmēri, sertifikāti, atbilstības deklarācijas	Atkārtota sertifikācija, atsaukšana, remonts

Šis nošķīrums ir izšķirošs datubāzes arhitektūrai: partijas dati parasti tiek ierakstīti vienreiz katrā ražošanas ciklā un pēc tam paliek nemainīgi — izņemot gadījumu, kad CO₂ pēdas pārrēķins dod koriģētu vērtību. Savukārt produkta līmeņa dati var mainīties visā lietošanas laikā, piemēram, ja ierīce tiek salabota vai sertifikāts atjaunots.

Bateriju regula (ES) 2023/1542 šo nošķīrumu jau netieši atzīst: kapacitātes dati, kas degradācijas dēļ mainās, ir jāuztur aktuāli — prasība, kuru bez skaidras arhitektūras ir grūti izpildīt.

Reģistrs kā direktorijs, nevis datu glabātuve

Bieži sastopams pārpratums attiecas uz centrālā DPP reģistra lomu. Īstenošanas regulas projekta par DPP reģistru ir skaidri norādīts: reģistrā tiek glabāts tikai unikālais identifikators, atrisinātāja galapunkts un preču kods — nevis faktiskie pases dati.

Tas nozīmē, ka atjaunināšanas pārvaldībā pases saturs un reģistrs ir atsevišķas sistēmas. Atjauninot produkta datus, parasti reģistrs nav jāmaina — izņemot gadījumu, kad mainās atrisinātāja galapunkts (piemēram, mainot sistēmu). CIRPASS-2 konsorcijs savā atzinumā par reģistra projektu ir skaidri norādījis uz šo arhitektūras modeli un iesaka īstenošanas regulā kā saistošu atsauci iekļaut standartu EN 18219 — cita starpā, lai nodrošinātu sadarbspēju ar GS1 Digital Link.

Atjaunināšanas scenāriji praksē

1. scenārijs: jauna CO₂ pēda piegādātāja maiņas dēļ

Saskaņā ar JRC tērauda projektu konkrētajam produktam raksturīgā CO₂ pēda (PCF) tiek uzturēta partijas līmenī un jāaprēķina, izmantojot ar ISO 14067 saderīgas metodes. Ja tērauda ražotājs maina enerģijas avotu vai metāllūžņu piegādātāju, jaunajai partijai mainās PCF — bet jau piegādātajām partijām ne.

Tehniski tas nozīmē: vecās partijas DPP ieraksts paliek nemainīgs. Jaunajai partijai tiek izveidots jauns ieraksts, kurā var izmantot to pašu atrisinātāja galapunktu, taču kā identifikators tiek norādīts jauns partijas numurs.

# 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. scenārijs: sertifikācijas termiņa beigas produkta līmenī

Atbilstības deklarācijām un sertifikātiem ir derīguma termiņi. Tiklīdz tiek izsniegts jauns sertifikāts, DPP produkta līmenī ir jāatjaunina. Tā kā atrisinātāja galapunkts paliek nemainīgs, reģistrs nav jāatjaunina — mainās tikai aiz galapunkta esošais ieraksts.

// 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. scenārijs: atrisinātāja migrācija, mainot sistēmu

Ja uzņēmums maina DPP pakalpojumu sniedzēju, mainās atrisinātāja galapunkts. Šādā gadījumā reģistrs ir jāatjaunina — turklāt katram ietekmētajam identifikatoram. Šis ir sarežģītākais atjaunināšanas veids, jo tam nepieciešama izmaiņu veikšana reģistrā.

Ieteikums: izmantojiet stabilu, paša uzturētu atrisinātāju (piemēram, dpp.ihrunternehmen.de) kā starpslāni, kas iekšēji pārsūta pieprasījumus attiecīgajam pakalpojumu sniedzējam. Tādējādi reģistrā ierakstītais galapunkts paliek nemainīgs.

Tehniskās prasības atjaunināšanas sistēmai

Versiju pārvaldība un audita pēdas

ESPR neprasa skaidru versiju pārvaldību, taču produktu atbildības un muitas kontroles kombinācija padara audita pēdu faktiski neizbēgamu. Ja muitas amatpersona 2030. gadā pārbauda 2027. gadā ražotas tērauda sijas DPP, ir jābūt iespējai izsekot, kādi dati bija spēkā importa brīdī.

Minimālā versiju pārvaldītas DPP-tabulas shēma:

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 kā stabils identifikatora enkurs

GS1 Digital Link skaidri nošķir identifikatoru un atrisinātāju: produktā esošais QR kods kodē tādu URL kā https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, kas caur GS1 atrisinātāju vai paša uzturētu atrisinātāju novirza uz aktuālo DPP ierakstu. Ieraksta atjaunināšanai nav nepieciešama jauna marķēšana — fiziskais nesējs paliek nemainīgs.

TEKLYNX ir atjauninājis savu CODESOFT programmatūru un tagad atbalsta GS1 “++” kodēšanas shēmas, ar kurām tīmekļa URL var tieši ierakstīt RAIN-RFID tagu atmiņā — prasība, kas izriet no EN 18220 un GS1 Digital Link standarta kombinācijas.

Pārvaldība: kas ko drīkst atjaunināt?

Papildus tehniskajam jautājumam jāatbild arī uz pārvaldības jautājumu: kuri piegādes ķēdes dalībnieki drīkst ierakstīt kādus DPP laukus? CIRPASS-2 konsorcijs šeit ir identificējis kritiskus datu suverenitātes aspektus pārrobežu piegādes ķēdēs.

Praktisks modelis nošķir trīs lomas:

Ražotājs (Creator): Ieraksta visus laukus izveides brīdī; drīkst atjaunināt visus laukus.
Pilnvarotais dalībnieks (Editor): Drīkst atjaunināt noteiktus laukus (piemēram, remonta vēsturi, jaunu sertifikāciju) — dokumentējot to ar savu identifikatoru.
Lasītājs (Reader): Var lasīt visus publiskos laukus, bet tam nav rakstīšanas tiesību.

Ecommerce Europe savā nostājas dokumentā par DPP ieviešanu ir pieprasījusi, lai arī lietotiem produktiem būtu iespējami “daļēji DPPs” — proti, ieraksti, kuros tiek atjaunināta tikai daļa sākotnējo lauku. Tehniski tas jau šodien ir īstenojams, taču īstenošanas regulās vēl nav iekļauts kā formāla kategorija.

Secinājumi

DPP-datu uzturēšana aktuālā stāvoklī nav vienreizējs uzdevums, bet gan darbības process. Svarīgākās atziņas no pašreizējā regulējuma:

Nošķiriet partiju un produktu — identifikatoru stratēģija nosaka, kādi dati un kad ir jāatjaunina.
Reģistrs nav datu glabātuve — pases satura atjaunināšanai parasti nav nepieciešama izmaiņu veikšana reģistrā.
Versiju pārvaldība faktiski ir obligāta — pat ja regula to skaidri nenosaka.
GS1 Digital Link nošķir fizisko nesēju no ieraksta — tas būtiski samazina atjaunināšanas izmaksas.
Pārvaldības lomas jādefinē iepriekš — kas drīkst ko ierakstīt un kā tas tiks reģistrēts?

Standarti kļūst precīzāki, pirmie izmēģinājuma projekti jau notiek — tie, kuri tagad pareizi izveidos arhitektūru, izvairīsies no dārgām korekcijām, kad stāsies spēkā nozaru īstenošanas regulas.