Összekapcsolhatom a digitális termékúttevelet az ERP- vagy készletkezelő rendszeremmel?

Az összekapcsolás lehetséges, a forma nem rögzített a jogszabályban

Igen, a gyakorlatban egy digitális termékpaszport összekapcsolható egy ERP- vagy készletkezelő rendszerrel, de az ESPR nem írja elő, hogy ez az összekapcsolás hogyan nézzen ki. A rendelet a paszportra magára vonatkozó követelményeket tartalmaz: technikai szempontból úgy kell felépíteni, hogy az adatok gépek által olvashatók legyenek, és hogy a rendszerek azokat automatikusan ki tudják olvasni és feldolgozni, nyitott szabványok alapján, nem pedig zárt, márkaspecifikus formátumok alapján (az ESPR 11. cikk, (EU) 2024/1781 rendelet). Ez a követelmény a paszportra és az adathordozóra vonatkozik, nem a bandaimportőr, nagykereskedelem vagy járműflotta-kezelő belső rendszereire. Hogy egy adott ERP-csomaggal az összekapcsolás működik-e és hogyan, az a paszportot összeállító és hosztáló fél – ebben az esetben az olyan platform, mint a tyrepas.eu – technikai berendezésének kérdése, és nem olyan, amit a jogszabály részletesen szabályoz.

Kinek releváns ez, és kinek nem

Ez a kérdés különösen olyan szereplőket érint, akik nagy mennyiségű bandát dolgoznak fel, és ahol a termékadatok már egy rendszerben vannak: olyan importőrök, akik cikkszámokat, tételadatokat és műszaki specifikációkat kezelnek, olyan nagykereskedések, amelyek bandatípusonként készleteket vezetnek, és olyan járműflotta-kezelők, akik a bandákat járművekhez kapcsolják. Számukra az összekapcsolás elsősorban praktikus: az adatokat nem kell kétszer megadni, és a paszport-információ visszaáramlódhat a saját rendszerbe.

A végfelhasználók számára, akik csak egy bandát vásárolnak és beolvassák a QR-kódot, az ERP-rendszerrel történő összekapcsolásnak nincs szerepe – olvasnak a paszportból, nem pedig azt táplálják. A saját rendszer nélküli kisebb szereplőknél az összekapcsolás sem aktuális: a paszport ekkor éppúgy kézzel megadható és megtekinthető, anélkül, hogy ez bármit vonna le az érvényességéből. Az 11. cikkből eredő technikai követelmények egyébként magára a paszportra vonatkoznak, nem arra a kérdésre, hogy egy paszportszolgáltatás-nyújtó kínálhat-e egy adott ERP-márka konkrét összekapcsolódását.

Még nem rögzített dátum, de egyértelmű munkaterv

Az a pont, amikor a bandák digitális termékpaszportjára vonatkozó kötelezettség pontosan hatályba lép, még nem áll rendelkezésre. Az ESPR 2025–2030 közötti időszakra vonatkozó munkatervében a bandákra vonatkozó delegált jogi aktus 2027-ben várható; csak annak publikációjával válik ismertté egy konkrét hatálybalépési dátum. Addig a bandáknál nincsenek kötelező követelmények magára a paszportra, és így az adatok beadásának vagy cseréjének módjára sem.

Ez nem azt jelenti, hogy nincs mit tenni. Az ESPR 10. és 11. cikkéből származó általános követelmények már rögzítettnek tekinthetők azon keretként, amelyen belül a bandákra vonatkozó delegált jogi aktus továbbfejlődik: a gépek által olvashatóság, nyitott szabványok és interoperabilitás nem új találmány, amely csak 2027-ben jelenik meg, hanem az alapvető, amelyre a bandaspecifikus szabályok épülnek. Aki most már gondolkozik egy összekapcsolódáson, nem homokra építkezik, bár a véglegzetes dátum még hiányzik.

Hogyan valósul meg ez a gyakorlatban

Az első lépés annak megvizsgálása, hogy mely adatok vannak már az ERP- vagy készletkezelő rendszerben, amelyeknek később egy paszportban szerepelniük kell: cikkszám, tétel- vagy batchadatok, gyártási dátum, a bandatípusonkénti műszaki specifikációk. E adatok közül sok már létezik, csak még nem strukturáltan állnak rendelkezésre egy paszporthoz.

A második lépés annak kiderítése, hogy mely formátumot fogadja el a paszportot összeállító és hosztáló fél bemenetként. Mivel a tyrepas.eu a paszportot a gyártó vagy importőr adataiból építi fel, a gyakorlati kérdés nem annyira az, hogy az összekapcsolás megvalósulhat-e, hanem inkább az, hogy az adatbeszolgáltatás milyen formában a legkényelmesebb: egy rendszeres export az ERP-rendszerből, egy strukturált fájl, vagy egy másik beszerzési útvonal.

A harmadik lépés annak átgondolása, hogy a másik irányba hogyan működjön: a útleveladatok visszacsatolása saját rendszerbe, például úgy, hogy egy flottakezelő az útleveladatokat egy járműregisztrációhoz kapcsolhassa anélkül, hogy maga kellene megkeresnie az útlevelet a QR-kódon keresztül. Ez is az ERP-rendszer és a platform közötti technikai koordináció kérdése, nem pedig jogszabályi kötelezettség.

Végül fontos figyelembe venni az időtartamot: egy útlevelet tíz évre szóló időszakra tárolunk. Aki csatolást létesít, jól teszi, ha ezen időszak alatt az olyan frissítésekre is gondol — például amikor a termékinformációk változnak —, hogy a csatolás ne csak az első adatszolgáltatásnál működjön, hanem a későbbi módosításoknál is.

A jogi alap: az ESPR 10. és 11. cikke

A digitális termékútlevélre vonatkozó követelmények az ESPR (az Európai Unió 2024/1781 rendelete) 10. cikkében találhatók, amely az útlevél általános követelményeit állapítja meg. Az ugyanez rendelete 11. cikke kifejezetten az útlevél technikai kialakítására és működésére vonatkozik, az interoperabilitás és a nyílt szabványok hangsúlyozásával, hogy az adatok olvashatóak és cserélhetőek legyenek. Mindkét cikk az útlevelet mint terméket veszi célba, nem az importőrök, nagykereskedők vagy flottakezelők belső információs rendszereit — az ezekkel való csatolás egy olyan technikai megoldás, amely ezen felül jön.

Aki már most szeretne előkészületeket tenni, a legjobb módszer a saját termékinformációk feltérképezésével kezdeni, és felvenni a kapcsolatot azzal a féllel, aki az abroncs digitális útlevelét összeállítja és tárolni fogja, hogy megvitassák, mely szállítási útvonal illeszkedik legjobban a meglévő ERP- vagy készletkezelő rendszerhez.

Erre alapul

A rendelet maga az EUR-Lex-en található. Állításonként hivatkozunk; nem kell bennünk bíznia.

Mit kell konkrétan tennie

Mit várnak el Öntől

A útlevélnek képes kell lennie az adatokat forráskészülékből fogadni

Egy termékalapú útlevelet nem szabad manuálisan beírni egy különálló formanyomtatványba — az adatok valahonnan származnak: egy ERP-rendszerből, egy készletkezelő csomagból, a gyártó Excel-exportjából vagy ezek kombinációjából. Az ESPR (2024/1781 EU rendelet) 10. cikkelye megállapítja, hogy mely adatoknak kell az útlevélben szerepelniük és hogyan kell azok hozzáférhetőnek lenni, de nem írja elő, hogy egy vállalkozás milyen rendszeren keresztül szolgáltatja ezeket az adatokat. Egy 10–100 fős gumiabroncs-importőr vagy nagykereskedő számára ez gyakorlatilag azt jelenti, hogy rögzített, megismételhető módon kell ahhoz jutnia, hogy a termékinformációkat a saját rendszeréből az útlevélbe juttassa — és nem egy olyan egyszeri manuális bevitel, amelyet a következő gumiabroncs-tételnél újra feltalálnak.

A csatolásnak egyedi termékazonosítási kódhoz kell illeszkednie

Az ESPR 11. cikkelye azt írja le, hogy a digitális termékalapú útlevélnek technikai szempontból hogyan kell működnie, beleértve a termék és útlevele közötti csatolást egy azonosítási kód segítségével. Egy ERP- vagy készletrendszer általában saját cikkszámokkal, SKU-kkal vagy belső kódokkal működik. Az útlevéllel való csatoláshoz az belső kódnak meg kell egyeznie azzal az azonosítási kóddal, amelyet az útlevél használ, vagy azt le kell fordítania. A vállalkozások, amelyek már gumiabroncs-méretenként vagy tételenként egyértelműen egyedi kódot vezetnek a készletrendszerükben, ebben előnyre tesznek szert; azok a vállalkozások, amelyek gyűjtőtételekkel vagy általános modellnevekkel dolgoznak, gyakran csak a csatoláskor fedezik fel, hogy belső adminisztrációjuk nem elég részletgazdag. Erről a bázisintézkedésről több információ található: hogyan adok minden terméknek egy egyedi azonosító kódot?

A forráskészülékben végzett módosítások az útlevélben is érvényesülniük kell

Egy készletkezelő rendszer soha nem statikus: az árak megváltoznak, a specifikációkat frissítik, egy szállító megváltoztat egy összetételt. A 10. cikk abból indul ki, hogy az útlevél az adott kategóriában előírt aktuális helyzetet tükrözi. Egy vállalkozás számára ez azt jelenti, hogy a saját rendszerrel való csatolásnak nem csak az első bevitelnél kell működnie, hanem a későbbi módosításoknál is — különben olyan útlevél jön létre, amely publikálásának pillanatában helyes volt, de most már nem.

A csatolásnak nyomonkövethetőnek kell lennie a forrásig

Egy útlevél, amely adatokat megjelenít anélkül, hogy még nyomonköveethető lenne, hogy azok mely rendszerből, mely exportból vagy mely verzióból származnak, nehezen indokolható meg egy ellenőrzéskor. Ez nem egy adott cikkből, hanem a 10. és 11. cikk gyakorlati kombinációjából következik: az adatoknak helyesnek és ellenőrizhetőnek kell lenniük. Az a vállalkozás számára, amely csatolva van az ERP-jéhez, ez azt jelenti, hogy valamilyen naplózás vagy verziókontroll kívánatos — mikor, mely adathalmaz került át, és ki által.

Hol sül el a gyakorlatban

Egy nagykereskedő az ERP-rendszer készletmodulját egyszer csatolja az útlevélhez az indítás során, de megfeledkezik arról, hogy a később hozzáadott új gumiabroncs-méretek nem kerülnek automatikusan be — az útlevél az indítási dátumon rögzül marad.

Egy importőr az ERP-rendszerben egy teljes termékcsalád gyűjtési kódját használja ("175/65R14 nyári gumi, különféle márka"), míg az útlevélnek egyedi azonosítási kódonként kell működnie. A csatolás akkor egyetlen útlevelet eredményez olyan termékekhez, amelyeknek valójában mindegyiknek saját útlevele lenne szükséges — lásd még hogyan viszonyul a gumiabroncs mérete az egyedi azonosító kódhoz?

Egy wagenparkkezelő exportot kap a gyártótól olyan formátumban, amely nem illeszkedik a saját készletkezelő rendszeréhez, és az adatok manuálisan kerülnek begépelésre egy köztes fájlba. A következő szállítás során ezt a köztes fájlt nem frissítik, így az útlevél az előírások régebbi verzióját mutatja, mint amely a raktárban ténylegesen megtalálható.

Egy vállalkozás az ERP-rendszert közvetlenül csatolja az útlevélhez közbülső lépés nélkül, és az exportálási mező hibája (például a gumiabroncs-méreteket tartalmazó oszlop összekeverése) az átültetés után ellenőrzés nélkül kerül több útlevélbe, mivel senki nem ellenőrzi a csatolt adatokat az átültetés után.

Egy importőr azt gondolja, hogy az egyszer történő csatolás elegendő a modell összes jövőbeli változatához, pedig valójában minden mérethez vagy kivitelhez külön adatok szükségesek — hogy az adatok újrafelhasználhatók-e ugyanez modell különböző abroncsméreteihez, ez a kérdés későn merül fel, lásd használhatok ugyanazokat az adatokat több abroncsmérethez ugyanabból a modellből?

Mit rögzíthet

Egy áttekintés arról, hogy melyik rendszer (ERP, készletkezelés, szállítói portál) az adatforrás az útlevelben szereplő egyes adatmezőkre, így egy kérdés vagy ellenőrzés során azonnal világos, hogy egy szám vagy specifikáció honnan származik.
Az új termékekhez szükséges adatok átadásának rögzített eljárása, ideértve azt az időpontot, amikor az egyedi azonosító kódot kiosztják és csatolják.
Megállapodás arról, hogy ki felelős az útlevél frissítéséért, amikor az adatok a forráskódban megváltoznak — és milyen eljárás keretében történik ez.
Ellenőrzési lépés minden csatolás vagy export után, amelyben mintavételezéssel ellenőrzik, hogy az útlevélben szereplő adatok megegyeznek-e a forráskódban szereplő adatokkal.
Az átadott adatok naplója vagy verzióelőzménye, hogy egy szóban forgó módosítás később visszavezethető legyen.
A technikai csatolás dokumentációja (mely exportformátumok, mely mezők vannak leképezve, milyen szoftvert vagy közbülső réteget használnak), amely felhasználható belső auditok mellékletéül.

Azoknak a vállalatoknak, amelyeknek még el kell dönteniük, hogy az abroncsaik egyáltalán e kötelezettség alá esnek-e, ez egy logikus előző lépés — lásd vonatkozik a digitális termékútlevél az én gumiabroncsaira? Akik többet szeretnének tudni az útlevél szerepéről az egész ellátási láncban, és arról, hogyan illeszkedik a saját rendszerrel való csatolás, egy általános magyarázatot találnak mi az a digitális termékadat-útlevél az abroncsokhoz?

Ez nem jogi tanácsadás. Ez az oldal általános tájékoztatást nyújt a szabályozásról, amelyre ez a platform vonatkozik. Nem ismerjük az Ön helyzetét. Kétsége merül fel saját esete vonatkozásában, kérjen meg egy jogászt vagy a letelepedett felügyeleti hatóságot.

AI-val írva a fenti források alapján, 2026-08-22-én egy ember által ellenőrizve. Valami nem jó? Szóljon — a javításokat előnyben részesítjük.