DPP-Adatok naprakészen tartása: Mit ír elő valójában a ESPR

Így frissítheti helyesen a Digital Product Passport adatait a ESPR alapján: tétel- és termékszint, nyilvántartási kötelezettségek és gyakorlati architekturális útmutató.

szerző: QR3 Redaktion

DPP-Adatok naprakészen tartása: Mit ír elő valójában a ESPR

A ESPR-rendelet (EU) 2024/1781 elfogadása óta a Digital Product Passport (DPP) kötelező erejű uniós jog. Amit sok vállalat alábecsül: a DPP nem egy statikus dokumentum, amelyet egyszer, a piaci bevezetéskor hoznak létre. A teljes termékéletciklus során naprakészen kell tartani — és az erre vonatkozó követelmények egyre pontosabbak.

Ez a cikk bemutatja, hogy mely adatokat mikor kell frissíteni, hogyan befolyásolja a nyilvántartási architektúra a frissítési modellt, és mely műszaki minták bizonyulnak beváltnak a gyakorlatban.

Mit mond a rendelet a frissítési ciklusról

Statikus és dinamikus adatmezők

Maga a ESPR nem nevez meg kifejezett frissítési gyakoriságot, de előírja, hogy a DPP „aktuális és pontos információkat” tartalmazzon. A pontosítás ágazati szinten történik — és ebben a vas- és acélból készült félkész termékekre vonatkozó JRC-tervezet adja eddig a legtisztább képet.

A tervezet rendszeresen megkülönböztet két adatszemcsézettségi szintet:

Szint Azonosító Példaadatok Frissítés kiváltó oka
Tételszint (Lot) Tételszám Újrahasznosított anyag aránya, ötvözet összetétele, PCF az ISO 14067 szerint Gyártási változáskor, új tétel esetén
Termékszint (Item) Sorozatszám Méretek, tanúsítványok, megfelelőségi nyilatkozatok Újratanúsításkor, visszahíváskor, javításkor

Ez a megkülönböztetés döntő fontosságú az adatbázis-architektúra szempontjából: a tételszintű adatokat jellemzően gyártási futásonként egyszer írják be, és ezt követően stabilak maradnak — kivéve, ha a CO₂-lábnyom utólagos újraszámítása korrigált értéket eredményez. A termékszintű adatok ezzel szemben a teljes használati idő alatt változhatnak, például ha egy készüléket megjavítanak vagy megújítanak egy tanúsítványt.

A rendelet az elemekről és akkumulátorokról (EU) 2023/1542 már implicit módon ismeri ezt a megkülönböztetést: a degradáció miatt változó kapacitásadatokat naprakészen kell tartani — ez a követelmény egyértelmű architektúra nélkül aligha teljesíthető.

A nyilvántartás mint jegyzék, nem pedig adattár

Gyakori félreértés övezi a központi DPP-nyilvántartás szerepét. A DPP-nyilvántartás végrehajtási rendeletének tervezete egyértelművé teszi: a nyilvántartás kizárólag az egyedi azonosítót, a feloldó végpontot és az áru kódját tárolja — magukat a passadatokat nem.

Ez mit jelent a frissítéskezelés szempontjából: a pass tartalma és a nyilvántartás két külön rendszer. A termékadatok frissítésekor általában nincs szükség a nyilvántartás módosítására — kivéve, ha a feloldó végpont megváltozik (például rendszerátálláskor). A CIRPASS-2 konzorcium a nyilvántartási tervezetről szóló állásfoglalásában kifejezetten felhívta a figyelmet erre az architekturális mintára, és javasolja az EN 18219 szabvány kötelező hivatkozásként való felvételét a végrehajtási rendeletbe — többek között a GS1 Digital Link-val való interoperabilitás biztosítása érdekében.

Frissítési forgatókönyvek a gyakorlatban

1. forgatókönyv: Új CO₂-lábnyom beszállítóváltás miatt

A termékspecifikus CO₂-lábnyomot (PCF) a JRC acélipari tervezete szerint tételszinten tartják nyilván, és azt az ISO 14067 szabvánnyal kompatibilis módszerekkel kell kiszámítani. Ha egy acélgyártó energiahordozót vagy hulladékbeszállítót vált, az új tétel PCF-je megváltozik — a már kiszállított tételeké azonban nem.

Műszakilag ez azt jelenti: a régi tétel DPP-rekordja változatlan marad. Az új tételhez új rekordot kell létrehozni, amely használhatja ugyanazt a feloldó végpontot, de azonosítóként új tételszámot tartalmaz.

# 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. forgatókönyv: Lejáró tanúsítás termékszinten

A megfelelőségi nyilatkozatoknak és tanúsítványoknak lejárati idejük van. Amint új tanúsítványt állítanak ki, a DPP-t termékszinten frissíteni kell. Mivel a feloldó végpont változatlan marad, nincs szükség a nyilvántartás frissítésére — csak a végpont mögötti rekord változik.

// 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. forgatókönyv: Feloldómigráció rendszerátálláskor

Ha egy vállalat DPP-szolgáltatót vált, a feloldó végpont megváltozik. Ebben az esetben a nyilvántartást frissíteni kell — mégpedig minden érintett azonosító esetében. Ez a legösszetettebb frissítéstípus, mivel nyilvántartási írást igényel.

Javaslat: használjon stabil, saját feloldót (pl. dpp.ihrunternehmen.de) köztes rétegként, amely belsőleg az adott szolgáltatóhoz továbbítja a kéréseket. Így a nyilvántartásban szereplő végpont tartósan stabil marad.

A frissítési rendszer műszaki követelményei

Verziókezelés és auditnyom

A ESPR nem ír elő kifejezett verziókezelést, de a termékfelelősség és a vámellenőrzés kombinációja a gyakorlatban elkerülhetetlenné teszi az auditnyomot. Ha 2030-ban egy vámtiszt megvizsgálja egy 2027-ben gyártott acélgerenda DPP-ját, visszakövethetőnek kell lennie, hogy a behozatal időpontjában mely adatok voltak érvényben.

Egy verziózott DPP-tábla minimális sémája:

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);

A GS1 Digital Link tisztán elválasztja egymástól az azonosítót és a feloldót: a terméken lévő QR-kód egy olyan URL-t kódol, mint a https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, amely a GS1-feloldón vagy egy saját feloldón keresztül az aktuális DPP-rekordra mutat. A rekord frissítéseihez nincs szükség új címkézésre — a fizikai adathordozó változatlan marad.

A TEKLYNX frissítette CODESOFT szoftverét, és most támogatja a GS1 „++” kódolási sémákat, amelyekkel a web-URL-ek közvetlenül RAIN-RFID-címkék memóriájába írhatók — ez az EN 18220 és a GS1 Digital Link-szabvány kombinációjából következő követelmény.

Irányítás: ki mit frissíthet?

A műszaki kérdés mellett felmerül az irányítás kérdése is: az ellátási lánc mely szereplői írhatják a DPP mely mezőit? A CIRPASS-2 konzorcium itt a határokon átnyúló ellátási láncok adat-szuverenitásával kapcsolatban kritikus pontokat azonosított.

Egy gyakorlati modell három szerepet különböztet meg:

  • Gyártó (Creator): Létrehozáskor minden mezőt kitölt; minden mezőt frissíthet.
  • Felhatalmazott szereplő (Editor): Meghatározott mezőket frissíthet (pl. javítási előzmények, új tanúsítványok) — saját azonosítóval dokumentálva.
  • Olvasó (Reader): Minden nyilvános mezőt olvashat, írási jogosultsága nincs.

Az Ecommerce Europe a DPP megvalósításáról szóló állásfoglalásában azt követelte, hogy használt termékek esetén is legyenek lehetségesek „részleges DPPs” — vagyis olyan rekordok, amelyek az eredeti mezőknek csak egy részét frissítik. Ez műszakilag már ma is megvalósítható, de a végrehajtási rendeletekben még hiányzik formális kategóriaként.

Összegzés

A DPP-adatok naprakészen tartása nem egyszeri feladat, hanem működési folyamat. A jelenlegi szabályozási helyzet legfontosabb tanulságai:

  1. Válassza szét a tételt és a terméket — az azonosítási stratégia határozza meg, hogy mely adatokat mikor kell frissíteni.
  2. A nyilvántartás nem adattár — a pass tartalmának frissítése általában nem igényel nyilvántartási írást.
  3. A verziókezelés a gyakorlatban kötelező — még akkor is, ha a rendelet nem írja elő kifejezetten.
  4. A GS1 Digital Link szétválasztja a fizikai adathordozót és a rekordot — ez jelentősen csökkenti az adatfrissítések ráfordítását.
  5. Az irányítási szerepeket előre meg kell határozni — ki mit írhat, és hogyan dokumentálják ezt?

A szabványok egyre pontosabbak, az első kísérleti projektek futnak — aki most megfelelően alakítja ki az architektúrát, elkerüli a költséges javításokat, amikor az ágazatspecifikus végrehajtási rendeletek hatályba lépnek.

Források