Az Európai Bizottság 2026. július 20-án üzembe helyezte a digitális termékútlevelek nyilvántartását és a tesztkörnyezetet. Ezzel egy elvont ESPR-komponensből olyan rendszer lett, amelyet a vállalatok ténylegesen kipróbálhatnak. A gyártók számára most mindenekelőtt egy megkülönböztetés fontos: a nyilvántartás a központi index, maga a termékútlevél pedig továbbra is decentralizált.
Mi vált elérhetővé július 20-án?
A nyilvántartás egyedi termékazonosítókat, regisztrációs adatokat és kiválasztott metaadatokat tárol. A teljes termékinformáció továbbra is a felelős gazdasági szereplőnél vagy egy megbízott DPP-szolgáltatónál marad. A Bizottság ezért kifejezetten indexszolgáltatásként, nem pedig központi tartalomkezelő rendszerként írja le a nyilvántartást.
A regisztrációk biztonságos felhasználói felületen és API-n keresztül is elvégezhetők. A vállalatok emellett elektronikus regisztrációs igazolást is létrehozhatnak. Ez a B2B-folyamatok szempontjából fontos, mivel a beszállítók és az ügyfelek így igazolhatják, hogy egy útlevelet bejegyeztek az uniós rendszerbe, anélkül hogy a teljes adatkészletet meg kellene kettőzniük.
A bevezetés nemcsak a ESPR-termékcsoportokat érinti. A Bizottság az akkumulátorokat, az építési termékeket, a játékokat, a mosószereket és a végfelhasználói tenzideket is megnevezi, amennyiben az adott uniós jog digitális termékútlevelet ír elő. Az első kötelező határidő továbbra is 2027. február 18. bizonyos akkumulátorok esetében.
A nyilvántartás, a resolver és az adatforrás három különböző réteg
Egy megbízható DPP-rendszerben világosan el kell különíteni a feladatokat:
- Az uniós nyilvántartás megerősíti, hogy egy azonosítót és az előírt metaadatokat regisztrálták.
- Egy resolver a tartós termékazonosítót a megfelelő erőforráshoz irányítja.
- Maga az adatforrás biztosítja az aktuális tartalmakat emberek és gépek számára.
Ez az elkülönítés nem részletkérdés. Aki minden adatot kizárólag saját termékoldalán helyez el, még nem integrálta a nyilvántartást. Aki viszont csak egy azonosítót regisztrál, még nem biztosít használható termékútlevelet. A kettőt stabil azonosítókkal kell összekapcsolni.
A feloldáshoz nyílt, tartós hivatkozás használható. Egy digitális hivatkozás-feloldó lehetővé teheti, hogy ugyanahhoz az azonosítóhoz különböző megjelenítések legyenek elérhetők: egy közérthető weboldal, géppel olvasható JSON-LD vagy kiegészítő dokumentáció. A terméken vagy a csomagoláson található adathordozó eközben változatlan marad, még akkor is, ha a célrendszerek továbbfejlődnek.
Mit ellenőrizzenek a vállalatok a tesztkörnyezetben?
A tesztkörnyezet nem csupán egy manuális kattintási próbára szolgál. Úgy kell kezelni, mint az éles integráció előszobáját.
Szervezet és szerepkörök
Elsőként tisztázni kell, mely jogalany regisztrál, ki képviseli a rendszerben, és mely csapatok hozhatnak létre vagy módosíthatnak regisztrációkat. Ez a törzsadatkezelést, a megfelelőséget, az informatikát és adott esetben a külső szolgáltatókat is érinti. Egy személyes teszthozzáférés nem helyettesíti a későbbi működés szerepkörmodelljét.
Azonosítók és granularitás
A termékcsapatnak meg kell állapítania, hogy a későbbi útlevelet modell-, tétel- vagy egyedi darabszinten vezetik-e. A választ az adott ágazati jog határozza meg. A nyilvántartási teszt a megfelelő időpont arra, hogy a belső termékazonosítókat, a GTINs azonosítókat, a tételazonosítókat és a külső használatra szánt tartós azonosítót egymáshoz rendeljék.
API és megismételhetőség
Egy éles folyamatnak többre van szüksége, mint egy sikeres POST-kérésre. A regisztrációnak, a frissítésnek és a hibakezelésnek megismételhetőnek és naplózottnak kell lennie. Ide tartoznak az idempotens kérések, a technikai visszaigazolások, valamint az ERP-rekord, a DPP és a nyilvántartási bejegyzés közötti egyértelmű megfeleltetés. Egy API-alapú DPP-folyamat csökkenti a manuális eltéréseket, amikor nagyobb mennyiségben hoznak létre termékeket.
A metaadatok és a szakterületi adatok elkülönítése
A nyilvántartási adatokból nem szabad második termékadatállományt létrehozni. Határozzák meg, mely mezők szükségesek a nyilvántartásban, és melyek maradnak a decentralizált útlevélben. Minden információhoz tartoznia kell egy elsődleges forrásnak, egy felelős szervezeti egységnek és egy frissítési szabálynak.
Igazolás és monitorozás
A regisztrációs igazolásokat az időbélyeggel, a használt azonosítóval és a rendszer válaszával együtt kell tárolni. Emellett egyeztetésre is szükség van: létezik-e az útlevél, elérhető-e a resolver, és továbbra is összhangban van-e a nyilvántartási metaadat a termék státuszával?
Miért van szükség külön vámellenőrzési folyamatra?
A nyilvántartás támogatja a vámhatóságokat annak automatizált ellenőrzésében, hogy a szabad forgalomba bocsátás előtt rendelkezésre áll-e egy érvényes, regisztrált DPP és a szükséges vámtarifaszám. Az importőrök számára ebből új függőség adódik: a termékazonosítónak, a nyilvántartási bejegyzésnek és a vámáru-nyilatkozatnak összhangban kell lennie.
Ezért a hiba nem csak a termékoldalon válik láthatóvá. A határfolyamatot is érintheti. A vállalatoknak már a tesztelés során szimulálniuk kell a termék létrehozásától az importdokumentációig terjedő adatáramlást, és meg kell határozniuk, ki jogosult rövid időn belül kijavítani a hibás regisztrációt.
Ésszerű 30 napos tesztterv
- Válasszanak ki egy valós jogalanyt és egy kicsi, reprezentatív termékválasztékot.
- Dokumentálják minden terméknél a tervezett DPP-granularitást és az elsődleges azonosítókat.
- Futtassanak végig egy teljes folyamatot a felhasználói felületen és – ha releváns – az API-n keresztül.
- Archiválják együtt a regisztrációs igazolást, a resolver válaszát és a géppel olvasható termékadatokat.
- Teszteljék a hibás eseteket: kettős azonosító, elavult metaadatok, elérhetetlen adatszerver és visszavont termék.
- Az eredményekből vezessenek le működési modellt felelősségi körökkel, monitorozással és eszkalációs folyamattal.
A nyilvántartás operatív indulása még nem jelenti azt, hogy minden ágazatspecifikus adatigény már teljes körűen hatályos. A vitát azonban az előadásokról ellenőrizhető folyamatokra helyezi át. A vállalatok most felismerhetik, hogy azonosítóik, szerepköreik és API-jaik összhangban vannak-e, még mielőtt elérkeznek az első kötelező határidők.
