DPP-Udržování dat aktuálních: Co ESPR skutečně stanoví

Od přijetí ESPR-nařízení (EU) 2024/1781 je Digital Product Passport (DPP) závazným právem EU. Mnoho podniků podceňuje, že DPP není statický dokument vytvořený jednorázově při uvedení na trh. Musí být aktualizován po celý životní cyklus produktu — a požadavky na něj jsou stále konkrétnější.

Tento článek vysvětluje, která data je třeba kdy aktualizovat, jak architektura registru ovlivňuje model aktualizací a které technické vzory se v praxi osvědčují.

Co nařízení říká o cyklu aktualizací

Statická vs. dynamická datová pole

Samotné ESPR nestanoví výslovnou frekvenci aktualizací, vyžaduje však, aby DPP obsahoval „aktuální a přesné informace“. Konkretizace probíhá na úrovni odvětví — a nejjasnější obraz dosud poskytuje návrh JRC pro polotovary ze železa a oceli.

Návrh systematicky rozlišuje dvě datové granularities:

Úroveň	Identifikátor	Příklad dat	Důvod aktualizace
Úroveň šarže (Lot)	Číslo šarže	Podíl recyklátu, složení slitiny, PCF podle ISO 14067	Při změně výroby, nová šarže
Úroveň produktu (Item)	Sériové číslo	Rozměry, certifikace, prohlášení o shodě	Při recertifikaci, stažení z trhu, opravě

Toto rozlišení je pro architekturu databáze zásadní: Data šarže se obvykle zapisují jednou na výrobní běh a poté zůstávají stabilní — ledaže by přepočet uhlíkové stopy vedl k opravené hodnotě. Data na úrovni produktu se naproti tomu mohou měnit po celou dobu používání, například když je zařízení opraveno nebo je obnovena certifikace.

Nařízení o bateriích (EU) 2023/1542 toto rozlišení již implicitně zná: Údaje o kapacitě, které se mění v důsledku degradace, musí být udržovány aktuální — požadavek, který lze bez jasné architektury jen obtížně splnit.

Registr jako adresář, nikoli úložiště dat

Časté nedorozumění se týká role centrálního DPP-registru. Návrh prováděcího nařízení k DPP-registru objasňuje: Registr ukládá výhradně jedinečný identifikátor, koncový bod resolveru a kód zboží — nikoli samotná data pasu.

Pro správu aktualizací to znamená: Obsah pasu a registr jsou oddělené systémy. Kdo aktualizuje produktová data, zpravidla nemusí zasahovat do registru — s výjimkou případu, kdy se změní koncový bod resolveru (například při změně systému). Konsorcium CIRPASS-2 na tento architektonický vzor výslovně upozornilo ve svém stanovisku k návrhu registru a doporučuje zahrnout normu EN 18219 jako závaznou referenci do prováděcího nařízení — mimo jiné za účelem zajištění interoperability s GS1 Digital Link.

Scénáře aktualizací v praxi

Scénář 1: Nová uhlíková stopa v důsledku změny dodavatele

Uhlíková stopa konkrétního produktu (PCF) se podle návrhu JRC pro ocel spravuje na úrovni šarže a musí se vypočítávat metodami kompatibilními s ISO 14067. Pokud výrobce oceli změní zdroj energie nebo dodavatele šrotu, změní se PCF nové šarže — nikoli však již expedovaných šarží.

Technicky to znamená: Záznam DPP-staré šarže zůstává beze změny. Pro novou šarži se vytvoří nový záznam, který může používat stejný koncový bod resolveru, ale nese nové číslo šarže jako identifikátor.

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

Scénář 2: Končící certifikace na úrovni produktu

Prohlášení o shodě a certifikace mají data platnosti. Jakmile je vydána nová certifikace, musí být DPP aktualizován na úrovni produktu. Protože koncový bod resolveru zůstává nezměněn, není nutná aktualizace registru — mění se pouze záznam za koncovým bodem.

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

Scénář 3: Migrace resolveru při změně systému

Pokud podnik změní poskytovatele služby DPP, změní se koncový bod resolveru. V takovém případě je nutné aktualizovat registr — a to pro každý dotčený identifikátor. Jde o nejnáročnější typ aktualizace, protože vyžaduje zápis do registru.

Doporučení: Používejte stabilní vlastní resolver (např. dpp.ihrunternehmen.de) jako mezivrstvu, která interně přesměrovává na příslušného poskytovatele. Koncový bod zapsaný v registru tak zůstane trvale stabilní.

Technické požadavky na aktualizační systém

Verzování a auditní stopa

ESPR nevyžaduje explicitní verzování, ale kombinace odpovědnosti za produkt a celní kontroly činí auditní stopu fakticky nevyhnutelnou. Pokud celník v roce 2030 kontroluje DPP ocelového nosníku vyrobeného v roce 2027, musí být dohledatelné, která data platila v okamžiku dovozu.

Minimální schéma pro verzovanou tabulku 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 jako stabilní kotva identifikátoru

GS1 Digital Link čistě odděluje identifikátor a resolver: QR kód na produktu kóduje URL, například https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, která prostřednictvím GS1 resolveru nebo vlastního resolveru odkazuje na aktuální záznam DPP. Aktualizace záznamu nevyžadují nové označení — fyzický nosič zůstává beze změny.

Společnost TEKLYNX aktualizovala software CODESOFT a nyní podporuje schémata kódování GS1 „++“, pomocí nichž lze webové adresy zapisovat přímo do paměti štítků RAIN-RFID — požadavek vyplývající z kombinace EN 18220 a standardu GS1 Digital Link.

Governance: Kdo smí co aktualizovat?

Vedle technické otázky vyvstává i otázka governance: Kteří aktéři v dodavatelském řetězci smějí zapisovat která pole DPP? Konsorcium CIRPASS-2 zde identifikovalo kritické otázky datové suverenity v přeshraničních dodavatelských řetězcích.

Praktický model rozlišuje tři role:

Výrobce (Creator): Při vytvoření zapisuje všechna pole; smí aktualizovat všechna pole.
Autorizovaný aktér (Editor): Smí aktualizovat definovaná pole (např. historii oprav, nové certifikace) — s dokumentací vlastním identifikátorem.
Čtenář (Reader): Může číst všechna veřejná pole, nemá oprávnění k zápisu.

Ecommerce Europe ve svém pozičním dokumentu k implementaci DPP požaduje, aby i u použitých produktů byly možné „částečné DPPs“ — tedy záznamy, které aktualizují pouze část původních polí. Technicky je to již dnes proveditelné, jako formální kategorie v prováděcích nařízeních to však stále chybí.

Závěr

Udržovat data DPP aktuální není jednorázový úkol, ale provozní proces. Nejdůležitější poznatky ze současného regulačního rámce:

Oddělujte šarži a produkt — strategie identifikátorů určuje, která data je třeba kdy aktualizovat.
Registr není úložiště dat — aktualizace obsahu pasu zpravidla nevyžadují zápis do registru.
Verzování je fakticky povinné — i když je nařízení výslovně nevyžaduje.
GS1 Digital Link odděluje fyzický nosič a záznam — to výrazně snižuje náklady na aktualizace dat.
Role governance musí být definovány předem — kdo smí co zapisovat a jak se to eviduje?

Normy se zpřesňují a první pilotní projekty běží — kdo nyní správně nastaví architekturu, vyhne se nákladným opravám, až vstoupí v platnost prováděcí nařízení pro jednotlivá odvětví.