A DPP-adatok naprakészen tartása: hogyan működik a frissítési folyamat

A digitális termékútlevél (DPP) nem egy statikus dokumentum. Ha egyszer létrehozzuk, majd megfeledkezünk róla, megfelelőségi hiányosságokat kockáztatunk — méghozzá nagyon hosszú időtávon: az ESPR-rendelet (EU) 2024/1781 előírja, hogy a nyilvántartási bejegyzéseknek elérhetőnek és naprakésznek kell maradniuk legalább 10 évig azután, hogy egy terméket utoljára forgalomba hoztak. Ez a cikk elmagyarázza, milyen adatrétegek léteznek, mikor kell az egyes rétegeket frissíteni, és hogyan valósítható meg a folyamat tisztán technikai szempontból.

A DPP három rétege — és ki tartja karban őket

Egy teljes DPP legalább három logikailag elkülönülő rétegből áll, amelyek mindegyikének saját frissítési ütemezése van.

1. Nyilvántartási bejegyzés (azonosító + feloldó)

A központi DPP-nyilvántartás — amelynek végrehajtási rendeletét az Európai Bizottság 2026. április 29-én tervezetként tette közzé — kizárólag a következőket tárolja:

a termék egyedi azonosítóját (UID) — a gyakorlatban egy GS1 GTIN vagy egy ISO/IEC 15459-kompatibilis kódot,
a feloldó végpontot, vagyis azt az URL-t, amelyen a tényleges útlevéltartalom lekérhető,
a kapcsolódó árukódot.

Ez a réteg ritkán változik. Frissítésre elsősorban akkor van szükség, ha a feloldó végpont megváltozik — például mert egy vállalat lecseréli a DPP-szolgáltatóját vagy domaint vált. Mivel a fizikai terméken lévő QR-kód erre a bejegyzésre mutat, a feloldó folytonosságát megszakítás nélkül biztosítani kell.

2. Feloldó-konfiguráció (linkútválasztás)

A feloldó egy beérkező beolvasást a megfelelő cél-URL-re fordít le — a kontextustól, nyelvtől vagy felhasználói szereptől függően. A GS1 Digital Link szabványt használó szervezetek strukturált linktípusok (pl. gs1:sustainabilityInfo, gs1:epcis) révén különböző adatkészletekre irányíthatnak.

Ezen a rétegen akkor van szükség frissítésre, ha:

felhatalmazáson alapuló jogi aktusok új kötelező mezőket vezetnek be (pl. a 2026/2027-től várható textil- és akkumulátorrendeletek),
a cél-URL-ek megváltoznak,
új nyelvi változatok vagy piaci régiók kerülnek hozzáadásra.

3. Termékadatok (a tényleges útlevéltartalom)

Itt található a valódi lényeg: az anyagösszetétel, a javíthatósági index, a szénlábnyom, a veszélyes anyagokra vonatkozó nyilatkozatok, a garanciális információk. Ennek a rétegnek a legmagasabb a frissítési gyakorisága, mert a termék életciklusában bekövetkező valós eseményektől függ.

Mikor kell frissíteni a DPP-adatokat?

Az ESPR-rendelet nem ír elő rögzített frissítési időközöket. Ehelyett az adatnaprakészség elve érvényesül: az információknak tükrözniük kell a termék tényleges állapotát. Ebből több, a gyakorlatban releváns kiváltó tényező adódik:

Szabályozási változások

Amint egy felhatalmazáson alapuló jogi aktus új adatszolgáltatási kötelezettségeket vezet be, a meglévő útleveleket ennek megfelelően frissíteni kell. Ez nem egy elméleti, jövőbeli aggály: az első termékspecifikus rendeletek a textíliákra és akkumulátorokra az ESPR ütemterve szerint 2026-ra és 2027-re ütemezve lépnek hatályba.

Az akkumulátorgyártók számára ez azt jelenti: 2026 augusztusától az EU-ban értékesített összes akkumulátoron látható QR-kódoknak és címkézésnek kell szerepelnie, amely lefedi a kapacitást, a kémiát és a veszélyes anyagokat — a 2027-ben kötelezővé váló teljes akkumulátorútlevél előfutáraként. Az uniós akkumulátorrendelet ezért a DPP frissítési folyamatának egyik első valós, nagy léptékű próbája.

Termékváltozások

Ha egy termék anyagösszetétele megváltozik — még akkor is, ha a GTIN ugyanaz marad —, a DPP-t frissíteni kell. Ugyanez vonatkozik a következőkre:

új javítási útmutatók vagy pótalkatrész-források,
felülvizsgált garanciális feltételek,
frissített biztonsági adatlapok.

Visszahívások vagy biztonsági figyelmeztetések

A biztonság szempontjából releváns információkat haladéktalanul rögzíteni kell. A DPP nem helyettesíti a RAPEX gyorsriasztási rendszert, de kiegészítő csatorna, amelyet mind a fogyasztók, mind a szabályozó hatóságok használhatnak.

Technikai frissítési folyamat: lépésről lépésre

1. lépés: az azonosítók és a verziókezelés tisztázása

Az útlevéltartalom minden módosítását verziózni kell. A következők kombinációja ajánlott:

Termék-UID (megváltoztathatatlan, pl. GTIN + sorozatszám),
Útlevélverzió (szemantikus verziószám vagy időbélyeg),
A módosítás oka (szabályozási, termékkel kapcsolatos, korrekciós).

{
  "uid": "urn:epc:id:sgtin:4012345.067890.1234567",
  "passVersion": "2.1.0",
  "lastModified": "2026-05-19T10:00:00Z",
  "changeReason": "battery-regulation-aug2026"
}

2. lépés: csak az érintett adatréteg frissítése

Gyakori hiba az egész útlevél-rekord újraírása, amikor szabályozási frissítés következik be. Ez növeli a hibák kockázatát, és megnehezíti a módosítások nyomon követését. Jobb megközelítés: használjunk moduláris adatszerkezetet, amelyben az egyes adatmezők egymástól függetlenül frissíthetők.

Ha API-n keresztül dolgozunk, használjuk a HTTP PATCH műveletet a PUT helyett:

PATCH /api/v1/dpp/{uid}/sections/battery
Content-Type: application/json

{
  "capacityWh": 42.5,
  "chemistry": "LFP",
  "hazardousSubstances": ["Li", "P"],
  "carbonFootprintKgCO2e": 18.3
}

3. lépés: a feloldó elérhetőségének biztosítása

Egy olyan frissítés, amely átmenetileg offline állapotba helyezi a feloldót, megfelelőségi szempontból kritikus. Az ESPR 10 éves elérhetőségi követelménye nem hagy teret a leállásra tartalék megoldás nélkül. Az ajánlott gyakorlatok közé tartozik:

Kék-zöld telepítés (blue-green deployment) a feloldó frissítéseihez,
a feloldó végpont figyelése riasztással a ≥ 400 HTTP-hibakódok esetén,
annak rendszeres ellenőrzése, hogy a nyilvántartásban regisztrált végpont valóban elérhető-e.

4. lépés: tömeges frissítések nagy termékportfóliókhoz

Aki több száz vagy több ezer terméket kezel, az nem kerülheti el a strukturált tömeges import folyamatot. A kulcselv: a módosításokat differenciális frissítésekként (delta importok) kell feldolgozni, nem pedig teljes importként, hogy minimalizáljuk a hibaforrásokat és megőrizzük az ellenőrzési nyomvonalakat.

Egy delta frissítés tipikus CSV-formátuma így nézhet ki:

uid,field,newValue,effectiveDate,changeReason
urn:epc:...:001,capacityWh,42.5,2026-08-18,battery-reg-2026
urn:epc:...:002,chemistry,NMC,2026-08-18,battery-reg-2026

Különös szempontok a textíliák és a Fair Trade vita kapcsán

A textilgyártók számára az ESPR ütemterve különös kihívásokat hoz. A Fair Trade Movement a textíliákra vonatkozó felhatalmazáson alapuló jogi aktusról szóló ajánlásaiban azt kérte, hogy a DPP-adatarchitektúra a harmadik országokbeli kkv-k és kistermelők számára is kezelhető legyen. Ennek közvetlen következményei vannak a frissítési folyamatra: amikor az ellátási lánc adatai olyan szereplőktől származnak, akiknek nincs közvetlen API-hozzáférésük, elengedhetetlenek a megbízható kézi vagy félautomata adatbeviteli útvonalak.

Ez jól mutatja, hogy a frissítési folyamat nemcsak technikai, hanem szervezeti kérdés is: ki jogosult mely adatok módosítására? Ki validálja a módosításokat? Hogyan integrálják a beszállítókat a folyamatba?

A GS1 Digital Link mint a frissítés lehetővé tevője

A 2026-os GS1 Általános Közgyűlés, amely Varsóban a 2D vonalkódokra való globális átállásra összpontosított, alátámasztja ezt a megállapítást: a GS1 Digital Link az előnyben részesített mechanizmus a termékidentitások aktuális tartalomhoz való összekapcsolására. A frissítési folyamat szempontjából a kulcsfontosságú előny: a terméken lévő QR-kód változatlan marad — csak a feloldó mögötti tartalom változik. Pontosan ez teszi egyáltalán lehetővé a már piacon értékesített termékek visszamenőleges frissítését.

A kiskereskedelmi 2D vonalkódokra vonatkozó Sunrise 2027 határidő közeledtével egyre közelebb kerül az a pont, amikor a márkák már nem halaszthatják tovább a GS1 Digital Link QR-kódokat — mind a kiskereskedelmi megfelelőség, mind a DPP-követelmények szempontjából.

Összegzés: a frissíthetőség nem funkció — hanem követelmény

Az ESPR-rendelet a DPP-t élő dokumentumként kezeli. Aki ma tervez egy megvalósítást, annak már a kezdetektől be kell építenie a frissítési folyamatokat: verziózott adatszerkezeteket, moduláris API-kat, stabil feloldókat és egyértelmű irányítási szabályokat az adatmódosításokhoz. Az első kötelező határidők — az akkumulátorok 2026 augusztusától, a textíliák várhatóan 2027-ben — elég közel vannak ahhoz, hogy a technikai felkészülést most kell elkezdeni.