automatikusan frissíttethetjem-e a termékalkalmazott adatait
Az automatikus frissítés lehetséges, de nem magától történik
Igen, a terméktanúsítványban szereplő adatok automatikusan frissíthetők, de ez nem történik meg magától — ez valami, amit meg kell szervezni. Az ESPR előírja, hogy a tanúsítvány aktuális adatokat tartalmaz, és hogy technikai szempontból lehetséges az információ frissítése, azonban a rendelet nem írja elő az automatikus kapcsolódást. Az, hogy a frissítés automatikusan történik-e, attól függ, hogy a tanúsítvány hogyan van technikai szempontból felépítve: ha önálló, akkor valaki manuálisan frissíti; ha egy forrásrendszerhez kapcsolódik, akkor az ott történő változás közvetlenül átvezethetô a tanúsítványba.
Mely adatok esetén működik az automatizálás, és mely nem
Az itt releváns megkülönböztetés a termékelőállítás során rögzített adatok és a termék élettartama alatt változó adatok között van. Egy technikai jellemzô, például az anyagösszetétel vagy egy vizsgálati eredmény a termék készítésének pillanatában kerül megállapításra, és ezt követôen nem változik — az automatikus frissítés ott kevésbé fontos, mivel nincs mit módosítani. Más adatok azonban dinamikusak: a javítási státusz, a tulajdonosváltás, a garancia lejáratának frissítése, vagy az egyes piaci régiók szerinti eltérô adatok. Az ilyen adatok esetén egy forrásrendszerhez való kapcsolódás értékes, mivel a tanúsítvány így követi azt, ami a gyakorlatban változik, anélkül, hogy valakinek ezt minden alkalommal külön be kellene vinnie. Az ESPR (2024/1781. EU rendelet) 10. cikke előírásként rögzíti, hogy a tanúsítványban szereplô adatok helyesek, teljesek és aktuálisak legyenek — ez az a kötelezettség, amelyre az automatizálás gyakorlati választ adhat, de maga a rendelet nem írja elô az ennek eléréséhez szükséges technikát.
Ami szintén nem tartozik ide: az automatizálás puszta módosítással való helyettesítése. Az, hogy ki jogosult az egyes adatok módosítására, és hogyan marad ez bizonyítható, más kérdés, mint magának a frissítési technikának az ügye. Egy kapcsolódás felgyorsítja a folyamatot, de nem veszi el a felelôsséget annak meghatározásáról, hogy mely adatok helyesek.
Az, hogy ez mikor válik relevanssá, még nem rögzített termékkategóriánként
Nincs rögzített dátum az automatikus frissítés kötelezôségének bevezetésére, egyszerûen azért, mert ilyen kötelezettség nem létezik — ami azonban rögzített, az az az elôírás, hogy a tanúsítvány aktuális legyen, amint egy termékkategória alá tartozni kezd. Az, hogy mikor lép érvénybe termékkategóriánként, a delegált rendelet szabályozza, és így termékenként eltérô. Amíg egy termékkategória nem tartozik egy kötelezettség alá, nincs szükség tanúsítványra, így az actualizeálás kérdése sem merül fel. Amint egy termékkategória alá tartozik a kötelezettség, a helyesség és actualitás elôírása attól a pillanattól kezdve érvényes — annak a formája, ahogy ezt technikailag megoldják (manuálisan vagy automatikusan), a gyártó vagy importôr feladata, az ESPR (2024/1781. EU rendelet) 11. cikkében foglalt technikai kereteken belül.
Hogyan történik ez a gyakorlatban
Az elsô lépés annak megállapítása, hogy mely adatok változnak valóban a tanúsítványban a termék élettartama alatt, és mely adatok rögzítettek. A rögzített adatok esetén az automatizálás általában nem szükséges — ezeket egyszer megadják és így maradnak. A dinamikus adatok esetén a következô lépés annak megvizsgálása, hogy van-e már olyan rendszer, amelyben ezeket az információkat kezelik, például ERP-rendszer, készletkezelô rendszer vagy szervizadminisztráció. Ha van, akkor a terméktanúsítványt egy ERP- vagy készletkezelô rendszerhez csatlakoztatni az a módja annak, hogy biztosítsák, hogy a forrásban történô változás automatikusan átvezetôdjön a tanúsítványba, anélkül, hogy dupla munkát kellene végezni.
Ezt követően arról van szó, hogy a szervezeten belül ki jogosult a módosítás végrehajtására és hogyan marad nyomon követhető az adott módosítás — nem azért, mert a szabályozás ezt külön folyamatként írná elő, hanem azért, mert egy olyan digitális termékpasszust, amelyiknek tíz éven vagy még hosszabb ideig elérhetőnek kell lennie, ezen idő alatt többször is lehet tulajdonosváltás vagy státuszváltozás. Ez érinti azt a kérdést is, hogy egy passzust meddig kell elérhetőnek maradnia, és mi történik vele, ha az ezzel kapcsolatos adatok megváltoznak — lásd meddig kell egy termékazonosító-útlevélnek elérhetőnek maradniaAkik több termékcsoporthoz passzust állítanak össze, érdemes így beállítani a kapcsolatot, hogy a forrásnystem egy módosítása ne érhesse véletlen az értelmetlen passzust, különösen akkor, ha egy termék több passzus alá tartozik egyszerre .
A jogi alapok: az ESPR 9., 10. és 11. cikke
Az, hogy a passzusnak aktuális adatokat kell tartalmaznia, az ESPR 10. cikkéből (Regulations (EU) 2024/1781) következik, amely az információk helyességét, teljes voltát és aktualitását követeli meg a passzusban. Az ESPR 9. cikke (Regulations (EU) 2024/1781) azt írja le, hogy a digitális termékpasszus tartalmilag mit jelent és milyen információkat tartalmaz, az ESPR 11. cikke (Regulations (EU) 2024/1781) pedig a passzus technikai kialakítását és működését szabályozza, beleértve az adatok frissítésének lehetőségét. Ezen cikkek egyike sem ír elő meghatározott technológiát vagy automatizálási formát — a kötelezettség az eredmény (aktuális, helyes adatok), nem az a módszer, amellyel ezt az eredményt elérjük.
Aki szeretné megnézni, hogy a saját rendszerrel való kapcsolódás gyakorlatilag hogyan néz ki, vagy hogy egy termékenkénti egyedi azonosítás milyen szerepet játszik, azt megtalálja a tudásbázisban; az ESPR szövegének pontos verziójához az EUR-Lex közleménye az ESPR-ről a forrás, amelyhez fordulni kell.
Mely szabályozáson alapul
- 2024/1781 (EU) rendelet (ESPR), 11. cikk (a digitális termékazonosító technikai kialakítása és működése)
- 2024/1781 EU rendelet (ESPR), 10. cikk (az digitális termékpasszusz követelményei)
- Az Európai Unió 2024/1781. rendelete (ESPR), 9. cikk (digitális termékút)
A rendelet maga az EUR-Lex-en található. Nyilatkozatunk szerint hivatkozunk; nem kell bennünket hinnie.
Mit kell konkrétan tennie
Mit várnak el Öntől
A passzusban szereplő adatoknak meg kell egyezniük a termék aktuális helyzetével
Az ESPR 9. cikke követelményeket támasztja a digitális termékpasszus tartalmára vonatkozóan, és ez a tartalom a termék jellemzőit kell, hogy tükrözze, ahogy az a piacon van. Egy 10 és 100 fő közötti vállalat számára ez azt jelenti, hogy egy vonal vezethet abból a helyről, ahol a termékinformáció keletkezik vagy módosul (beszerzés, mérnöki, minőségellenőrzés) oda, ahol a passzus található. Kézi folyamat esetén ez egy olyan felelősség, amely egy személyhez tartozik; csatolt rendszer esetén ez a frissítés automatikusan követi a forrásnystem módosítást.
A passzust technikai szempontból úgy kell felépíteni, hogy az adatok frissíthetők legyenek
Az ESPR 11. cikke a digitális termékpasszus technikai kialakítására és működésére vonatkozik, és ebből az következik, hogy a passzus nem statikus dokumentum, amely egyszer megjelenik és utána ugyanígy marad. A QR-kód vagy más adathordozó egy olyan helyre mutat, ahonnan adatok letölthetők, és ennek a helynek az is módosíthatónak kell lennie. Egy vállalat számára ez azt jelenti, hogy a platform vagy szállító választása egyúttal az is, hogy a jövőben a frissítések mennyire lesznek egyszerűek — egy olyan passzus, amely gyakorlatilag egy rögzített PDF-szerű fájl, kevésbé felel meg ezeknek a technikai elvárásoknak, mint egy olyan passzus, amely egy élő adatforráshoz kapcsolódik.
A forrásnystemekhez való kapcsolódás egy saját technikai választás, önmagában nem kötelezettség
Az ESPR 10. cikke a digitális termékpasszusnak meg kell feleljen követelményeket írja le, de nem ír elő meghatározott technológiát az adatok szinkronizálásához. Az automatikus frissítés tehát nem egy külön jogi követelmény, hanem egy módja annak, hogy az helyes és aktuális adatok meglétének meglévő követelményét teljesítse. Az ERP- vagy PIM-rendszerrel rendelkező vállalatok számára a kérdés hogy a termékpasszus a saját rendszerre kapcsolható-e ezért elsősorban egy operatív kérdés: hány termék, milyen gyakran változnak a specifikációk, és mennyi kézi munka fogadható el, mielőtt hibák merülnének fel.
Ahol a gyakorlatban félresiklanak a dolgok
Egy gyakori helyzet: egy alkatrész szállítóváltása az ERP-rendszerben feldolgozásra kerül, de senki nem vette fel a termékazonosítólapot azon "rendszerek" listájára, amelyeket emiatt szintén módosítani kell. A termékazonosítólap ekkor egy régi összeállítást mutat, miközben a termék már hónapok óta másképpen szállított.
Egy második helyzet akkor keletkezik, ha olyan vállalatok dolgoznak több termékcsoporttal, és így több olyan útlevél, amelyeknek egymáshoz kell kapcsolódniuk. Ha egy alapul szolgáló adat (például egy anyagösszetétel) több útlevélben fordul elő, akkor az egyik helyen történő frissítés nem kerül automatikusan átvezetésre a többi helyre, kivéve, ha ezt kifejezetten így állították be.
Egy harmadik helyzet: egy vállalat azt gondolja, hogy az útlevél "kész" a szállítás után, és olyan módon kezeli, mint egy olyan tanúsítványt, amely már nem változik. Pedig éppen az olyan összetett termékek esetében, amelyekben egy útlevél termékenként egy alkatrész módosítása áthathat az összeállított termék útlevelén anélkül, hogy az magától feltűnne.
Negyedik helyzet adódik a portálon keresztüli kézi adatbevitelnél: valaki az indítás során egyszer bevezeti az adatokat, de nem kerül megállapodásra az ellenőrzésre vagy frissítésre vonatkozó ismétlődő folyamatról. Egy év múlva senki sem biztos abban, hogy az adatok még érvényben vannak-e, és senki sem érzi magára nézve felelősnek azt.
Ötödik helyzet akkor alakul ki, ha a vállalat megvásárlása vagy egy termékvonal leállítása következik be: az a kérdés mi történik az útlevéllel, ha a vállalat leáll csak akkor merül fel, amikor már sürgős a helyzet, miközben a frissítésekről és az átadásról szóló megállapodásokat tulajdonképpen előzetesen rögzíteni kellene.
Amit rögzíthet
- A forrásrendszerek (ERP, PIM, minőségi adatbázis) áttekintése, amely bemutatja, hogy mely rendszer mely adatmezőt táplál a passzportba, így egyértelmű, hogy mely módosítás hova kell hogy kerüljön.
- Egy belső folyamat vagy ellenőrzőlista, amely jelzi, hogy mikor vezet a termékváltozás automatikus passzport-frissítéshez, és mikor szükséges kézi ellenőrzés.
- Egy kijelölt felelős személy vagy szerep a passzport-adatok naprakészen tartásáért, még akkor is, ha ez technikailag nagyrészt automatizáltan történik.
- A saját rendszer és a passzport-platform közötti csatlakozás dokumentációja, beleértve, hogy mely mezők szinkronizálódnak automatikusan, és melyek nem — releváns a saját ERP- vagy készletrendszerhez való csatlakozás mérlegelésekor a saját ERP- vagy készletrendszerhez való csatlakozás.
- A termékazonosító kódok felépítésének áttekintése, így egy frissítés mindig a helyes passzporthoz kerül — lásd még a magyarázatot a termékenkénti egyedi azonosító kód megadásáról.
- Egy napló vagy módosítási verzióelőzmény a passzport-adatok módosításaihoz, így később visszavezethető, hogy mikor és miért történt egy módosítás.
- Megállapodások beszállítókkal vagy lánctársadalmakkal a passzportot érintő módosítások közléséről, így egy frissítés nem függ a véletlentől vagy az önálló e-mailektől.
Ez nem jogi tanácsadás. Ez az oldal általános információt nyújt az e platform szerinti szabályozásról. Nem ismerjük a helyzetet. Kétség esetén saját helyzetét illetően tanácsadjon egy jogászt vagy a illetékes hatóságot.
Mesterséges intelligenciával írva a fenti forrásokra támaszkodva, egy ember által ellenőrizve a 2026-09-05-én. Valami nem stimmel? Szóljon — a javításoknak első helyen áll.