DPP-Udržiavanie aktuálnosti údajov: Čo ESPR skutočne vyžaduje

Ako správne aktualizovať údaje Digital Product Passport podľa ESPR: úroveň šarže vs. produktu, povinnosti registra a praktické architektonické odporúčania.

autor QR3 Redaktion

DPP-Udržiavanie aktuálnosti údajov: Čo ESPR skutočne vyžaduje

Od prijatia ESPR-nariadenia (EÚ) 2024/1781 je Digital Product Passport (DPP) záväzným právom EÚ. Mnohé podniky podceňujú, že DPP nie je statický dokument, ktorý sa vytvorí raz pri uvedení na trh. Musí sa udržiavať aktuálny počas celého životného cyklu produktu — a požiadavky na to sú čoraz presnejšie.

Tento článok vysvetľuje, ktoré údaje sa musia aktualizovať a kedy, ako architektúra registra ovplyvňuje model aktualizácií a ktoré technické vzory sa v praxi osvedčujú.

Čo nariadenie hovorí o cykle aktualizácií

Statické vs. dynamické údajové polia

Samotné ESPR neuvádza explicitnú frekvenciu aktualizácií, stanovuje však, že DPP musí obsahovať „aktuálne a presné informácie“. Konkretizácia prebieha na úrovni sektorov — a doteraz najjasnejší obraz poskytuje návrh JRC pre polotovary zo železa a ocele.

Návrh systematicky rozlišuje medzi dvoma granularitami údajov:

Úroveň Identifikátor Príklady údajov Dôvod aktualizácie
Úroveň šarže (Lot) Číslo šarže Podiel recyklátu, zloženie zliatiny, PCF podľa ISO 14067 Pri zmene výroby, nová šarža
Úroveň produktu (Item) Sériové číslo Rozmery, certifikácie, vyhlásenia o zhode Pri opätovnej certifikácii, stiahnutí z trhu, oprave

Toto rozlíšenie je pre architektúru databázy rozhodujúce: Údaje o šarži sa zvyčajne zapisujú raz na výrobnú dávku a potom zostávajú stabilné — s výnimkou prípadu, keď prepočet uhlíkovej stopy prinesie opravenú hodnotu. Údaje na úrovni produktu sa, naopak, môžu meniť počas celej doby používania, napríklad keď sa zariadenie opraví alebo obnoví certifikácia.

Batériové nariadenie (EÚ) 2023/1542 toto rozlíšenie už implicitne pozná: Údaje o kapacite, ktoré sa menia v dôsledku degradácie, sa musia udržiavať aktuálne — ide o požiadavku, ktorú bez jasnej architektúry možno len ťažko splniť.

Register ako zoznam, nie ako úložisko údajov

Časté nedorozumenie sa týka úlohy centrálneho DPP-registra. Návrh vykonávacieho nariadenia o DPP-registri objasňuje: Register uchováva výlučne jednoznačný identifikátor, koncový bod resolvera a kód tovaru — nie samotné údaje pasu.

To znamená pre správu aktualizácií: Obsah pasu a register sú oddelené systémy. Kto aktualizuje údaje o produkte, spravidla nemusí zasahovať do registra — s výnimkou prípadu, keď sa zmení koncový bod resolvera (napríklad pri zmene systému). Konzorcium CIRPASS-2 na tento architektonický vzor výslovne upozornilo vo svojom stanovisku k návrhu registra a odporúča zaradiť normu EN 18219 ako záväznú referenciu do vykonávacieho nariadenia — okrem iného s cieľom zabezpečiť interoperabilitu s GS1 Digital Link.

Scenáre aktualizácií v praxi

Scenár 1: Nová uhlíková stopa v dôsledku zmeny dodávateľa

Uhlíková stopa špecifická pre produkt (PCF) sa podľa návrhu JRC pre oceľ spravuje na úrovni šarže a musí sa vypočítavať metódami kompatibilnými s normou ISO 14067. Ak výrobca ocele zmení zdroj energie alebo dodávateľa šrotu, zmení sa PCF novej šarže — nie však už dodaných šarží.

Technicky to znamená: Záznam DPP starej šarže zostáva nezmenený. Pre novú šaržu sa vytvorí nový záznam, ktorý môže používať rovnaký koncový bod resolvera, ale ako identifikátor nesie nové číslo šarže.

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

Scenár 2: Končiaca certifikácia na úrovni produktu

Vyhlásenia o zhode a certifikácie majú dátumy platnosti. Hneď po vydaní novej certifikácie sa musí DPP aktualizovať na úrovni produktu. Keďže koncový bod resolvera zostáva nezmenený, aktualizácia registra nie je potrebná — mení sa iba záznam za koncovým bodom.

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

Scenár 3: Migrácia resolvera pri zmene systému

Ak podnik zmení poskytovateľa služby DPP, zmení sa koncový bod resolvera. V takom prípade sa register musí aktualizovať — a to pre každý dotknutý identifikátor. Ide o najnáročnejší typ aktualizácie, pretože vyžaduje zápis do registra.

Odporúčanie: Používajte stabilný vlastný resolver (napr. dpp.ihrunternehmen.de) ako medzivrstvu, ktorá interne presmeruje na príslušného poskytovateľa. Koncový bod zapísaný v registri tak zostane trvalo stabilný.

Technické požiadavky na systém aktualizácií

Verziovanie a auditná stopa

ESPR nevyžaduje explicitné verziovanie, ale kombinácia zodpovednosti za produkt a colnej kontroly robí auditnú stopu fakticky nevyhnutnou. Ak colník v roku 2030 kontroluje DPP oceľového nosníka vyrobeného v roku 2027, musí byť možné spätne určiť, ktoré údaje platili v čase dovozu.

Minimálna schéma pre verzovanú tabuľku 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 jasne oddeľuje identifikátor a resolver: QR kód na produkte kóduje URL, napríklad https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, ktorá prostredníctvom GS1 resolvera alebo vlastného resolvera smeruje na aktuálny záznam DPP. Aktualizácie záznamu nevyžadujú nové označenie — fyzické médium zostáva nezmenené.

Spoločnosť TEKLYNX aktualizovala svoj softvér CODESOFT a teraz podporuje kódovacie schémy GS1 „++“, pomocou ktorých možno webové URL zapisovať priamo do pamäte tagov RAIN-RFID — ide o požiadavku vyplývajúcu z kombinácie noriem EN 18220 a GS1 Digital Link.

Správa: Kto smie čo aktualizovať?

Okrem technickej otázky vzniká aj otázka správy: Ktorí aktéri v dodávateľskom reťazci smú zapisovať ktoré polia DPP? Konzorcium CIRPASS-2 tu identifikovalo kritické otázky dátovej suverenity v cezhraničných dodávateľských reťazcoch.

Praktický model rozlišuje tri úlohy:

  • Výrobca (Creator): Pri vytvorení zapisuje všetky polia; môže aktualizovať všetky polia.
  • Autorizovaný aktér (Editor): Môže aktualizovať určené polia (napr. históriu opráv, nové certifikácie) — zaznamenané vlastným identifikátorom.
  • Čitateľ (Reader): Môže čítať všetky verejné polia, nemá práva na zápis.

Ecommerce Europe vo svojom pozičnom dokumente k implementácii DPP požaduje, aby boli aj pri použitých produktoch možné „čiastočné DPPs“ — teda záznamy, ktoré aktualizujú iba časť pôvodných polí. Technicky je to už dnes realizovateľné, vo vykonávacích nariadeniach však táto kategória zatiaľ chýba ako formálna kategória.

Záver

Udržiavanie aktuálnosti údajov DPP nie je jednorazová úloha, ale prevádzkový proces. Najdôležitejšie poznatky z aktuálneho regulačného rámca:

  1. Oddeľujte šaržu a produkt — stratégia identifikátorov určuje, ktoré údaje a kedy sa musia aktualizovať.
  2. Register nie je úložisko údajov — aktualizácie obsahu pasu spravidla nevyžadujú zápis do registra.
  3. Verziovanie je fakticky povinné — aj keď ho nariadenie výslovne nevyžaduje.
  4. GS1 Digital Link oddeľuje fyzické médium od záznamu — výrazne to znižuje náročnosť aktualizácií údajov.
  5. Úlohy v rámci správy musia byť definované vopred — kto smie čo zapisovať a ako sa to zaznamenáva?

Normy sa spresňujú a prvé pilotné projekty prebiehajú — kto teraz správne nastaví architektúru, vyhne sa nákladným opravám po nadobudnutí účinnosti sektorových vykonávacích nariadení.

Zdroje