elektropas.com

milyen formátumban kell bejelentenim a digitális termékútlevél adatait

Egy rögzített fájlformátum még nincs meghatározva, de az követelményei igen

Még nincs előírt fájlformátum (például JSON, XML vagy más) az elektronikai és ICT-berendezések digitális termékútleveléhez. Maga az ESPR nem ír elő specifikus formátumot, de az (EU) 2024/1781 rendelet 10. és 11. cikke meghatározza az útlevél technikai felépítésére vonatkozó követelményeket: az útlevelnek nyílt, interoperábilis szabványokon kell alapulnia, a rendszerek között cserélhetőnek kell lennie, és gépek által olvashatónak kell lennie. Hogy mely konkrét fájlstandard teljesíti ezeket a követelményeket, az termékcsalákonként egy delegált aktusban kerül kidolgozásra. Az elektronikai és ICT termékek esetén ez a felhatalmazott cselekmény még nem létezik.

Az elektronikaipar számára ez még iránymutatásként, nem pedig megállapított követelményként érvényes

Ez az oldal az ESPR szerinti elektronikai és ICT-berendezések digitális termékútleveléről szól. A 10. és 11. cikk az ESPR hatálya alá tartozó összes termékkategóriára vonatkozik, de a pontos technikai megvalósítás — beleértve a fájlformátumot — termékkategóriánként külön kerül szabályozásra. Ez azt jelenti, hogy amit jelenleg megállapítottak, az egy iránymutatás: az interoperabilitás, a nyílt szabványok és a gépek által olvashatóság követelményei. Ez nem jelenti azt, hogy már egy konkrét fájlformátum lett kijelölve, amelyben az elektronikai berendezések gyártójának vagy importőrének az adatokat bejelentenie kell. Aki olyan választ keres, mint a "JSON-ben adjon meg" vagy "használjon X XML-sémát", azt jelenleg sehol nem találja meg a szabályozásban ebben a termékcsoportban. Ez a téma également különbözik az olyan kérdéstől, hogy a termékútlevél egy adott elektronikai termékre vonatkozik-e — ez egy külön kérdés, más válasszal jár.

A delegált aktus elektronikában való közzététele határozza meg az időpontot

Nincs még rögzített időpontja annak, hogy mikor válnak ismertté az elektronika és ICT fájlformátumai. Az ESPR 2025–2030. évi munkaterve szerint a delegált aktusok termékkategóriánként kerülnek kidolgozásra, az első aktusok várhatóan 2027-től jelennek meg. Amint az elektronika és ICT számára egy delegált aktus közzé lesz téve, abban várhatóan szerepel majd a technikai formátum is, amelyben az adatokat be kell jelenteni. Addig csak az ESPR 10. és 11. cikkéből származó általános iránymutatás érvényes: nyílt szabványok, interoperabilitás és gépek által olvashatóság, anélkül, hogy egy konkrét fájlformátum lenne előírva. Ez az oldal frissítésre kerül, amint az ehhez a kategóriához tartozó delegált aktus konkrét választ adó.

Amit az importőr vagy gyártó már most előkészíthet

Még ha a fájlformátum sem rögzített, gyakorlatilag már sok mindent lehet tenni. Kezdetnek célszerű meghatározni, mely rendszerek és adatok képezik majd az útlevél alapját — a legtöbb vállalat ezeket az információkat már valahol tárja, például egy ERP- vagy készletrendszerben, és előzetesen célszerű megvizsgálni, hogyan lehet egy ilyen rendszert később a digitális termékútlevelhez csatlakoztatni. Ezenkívül célszerű átgondolni az azonosítást: minden terméket egy útlevelhez kell nyomon követni, és ez következetes megközelítést igényel a termékazonosító kód egyedi hozzárendeléséhez. Az a kérdés is, hogy a QR-kód később hogyan kerül a termékre, és hogyan viszonyul a meglévő vonalkódokhoz vagy GS1-rendszerekhez, már most is megvizsgálható, függetlenül attól, hogy később milyen fájlformátum lesz előírva. Amint az elektronika és ICT számára a delegált aktus megjelenik, feltehetően az összhangban lesz azzal az infrastruktúrával, amely már a 13. cikkben (a digitális termékútlevelek nyilvántartása) és a 14. cikkben (a webes portál) említésre kerül, ezért az erre a szerkezetre való felkészülés már most hasznos, függetlenül a pontos technikai formátumtól.

Az alapelv: az ESPR 10. és 11. cikke

Az Európai Unió 2024/1781 rendeletének (ESPR) 10. cikke leírja azokat az általános követelményeket, amelyeknek a digitális termékpasszust teljesítenie kell, beleértve az adatok hozzáférhetőségét és megbízhatóságát. A 11. cikk kifejezetten a passzus műszaki tervezésére és működésére vonatkozik, és olyan követelményeket említ, mint a különböző piaci szereplők rendszerei közötti interoperabilitás, valamint a nyílt szabványok alkalmazása, anélkül, hogy egyetlen fájlformátumot kötelezően előírna. A további műszaki részletezés — amely feltehetően a konkrét adatformátumot is magában foglalja — delegált aktusok útján kerül kidolgozásra termékenként, az ESPR-munkaprogram 2025-2030 szerint. A verordening 13. és 14. cikke kiegészítésképpen ismerteti az olyan nyilvántartást és webes portált, amelyeken keresztül a passzus-adatok hozzáférhetővé válnak, ami releváns a beadott fájl végső megjelenítésének és kereshetőségének módjára nézve. Az elektronika és az ICT tekintetében az ezt konkrétizáló delegált aktus jelenleg még nem jelent meg.

Aki már most szeretne előkészületeket tenni, az a saját termékladatainak és azonosítási rendszereinek rendbe tételésével kezdheti a legjobban, hogy a konkrét fájlformátumra való átállás később csupán összekapcsolódásként valósuljon meg, ahelyett, hogy nulláról kezdene. Célszerű az idő alatt azt is megvizsgálni, mit tartalmaz a digitális termékpasszusok nyilvántartása és mi kerül abba,, mivel ez a nyilvántartás valószínűleg közvetlenül összefügg az utolsó adatbejelentési mechanizmussal.

Mit kell konkrétan tennie

Mit várnak el Önöktől

Az a kérdés, hogy mely fájlformátum kötelező — JSON, XML, PDF, egy specifikus API-struktúra — minden importőr és gyártó számára felmerül, mihelyt az IT-osztály kezd fejlesztésekbe. A jelenlegi ESPR-szöveg alapján adott válasz nüchtern: egy konkrét fájlformátum nincs az rendeletben. Az ESPR 10. és 11. cikke (2024/1781 EU-rendelet) rögzíti, hogy minek kell teljesítenie a digitális termékpasszust, de ezt funkcionális és műszaki követelmények szintjén teszi, nem pedig "használj JSON-LD"-t vagy "adj be XML-fájlt ezzel a sémával" szintjén. Ennek a kitöltése delegált és végrehajtási aktusok útján várható, termékenként.

Az interoperabilitás áll a középpontban, nem egy konkrét formátum

Az ESPR 10. cikke az interoperabilitást emeli ki alapvetõ követelményként: a passzust úgy kell felépíteni, hogy különböző felek — felügyeleti hatóságok, piaci szereplők, fogyasztók — rendszerei képesek legyenek az adatokat kiolvasni. Egy 10 és 100 fő közötti vállalat számára ez gyakorlatilag azt jelenti, hogy a tárolási és adatcserélési formátum választása csak akkor tehető meg biztos alapokon, amikor a saját termékkategóriára vonatkozó delegált aktus rendelkezésre áll. Addig is javasolt strukturált adatokkal (például egy adatbázis vagy ERP-rendszer mezőivel) dolgozni, ahelyett hogy az adatokat csak egy laza dokumentumban vagy PDF-ben tárolnák, így a későbbi adatkifejezés a végső formátumban kevesebb átdolgozást igényelne.

A terméktájékoztatónak a QR-adathordozón keresztül olvashatónak kell lennie

Az ESPR 11. cikke a terméktájékoztatási rendszer technikai működését írja le, ideértve az adathordozónak a terméken való összekapcsolódását. Ez azt jelenti, hogy a mögöttes adatokat bármilyen formátumban fel kell tudni szabadítani abban a pillanatban, amikor valaki beolvassa a kódot. Hogy ez a kapcsolat technikai szinten hogyan működik, és mely azonosítási szabványok játszanak ebben szerepet, a következő oldal ismerteti: hogyan kerül a QR-kód a terméktájékoztatóra az én elektronikus eszközömönAzok a vállalkozások, amelyek már GS1-vonalkódokkal dolgoznak, számára az a kérdés, hogy egy meglévő azonosítási struktúra újrafelhasználható-e — ez a téma az alábbi oldalon tárgyalódik: mi a GS1 Digital Link, és szükséges-e a terméktájékoztatóhoz.

Minden termék egyedi azonosíthatónak kell lennie, függetlenül a fájlformátumtól

A használandó technikai formátumtól függetlenül az alapvető követelmény az, hogy minden termék egyedi azonosítókódot kapjon. Ez egy külön követelmény, amely nem változik, ha a fájlformátum később rögzítésre kerül. Azok a vállalatok, amelyek már most elkezdik termékadat-struktúrájuk kialakítását, jól teszik, ha ezt az azonosítást állandó összetevőként beépítik. Az, hogy ez a gyakorlatban hogyan épül fel, a következő oldal tartalmazza: az egyes termékek egyedi azonosítókódjának biztosítása.

A nyilvántartásba való bejelentkezéshez saját forma szükséges

Az ESPR 13. cikke a digitális termékalkalmazások nyilvántartását vezeti be, amely a passzport egyes adatait tartalmazza. Itt sem van még rögzítve, hogy pontosan milyen fájlformátumban kell történnie a bejelentkezés — ezt később részletezik. Világos azonban, hogy ez a nyilvántartás a QR-kód által hozzáférhető passzportok mellett egy külön benyújtási folyamat. Az ebben szereplő információkkal kapcsolatos további részletekért tekintse meg az alábbi oldalt: mi a digitális termékalkalmazások nyilvántartása és mi tartozik bele.

Hol megy félre a gyakorlatban

Túl korai rögzítés merev formátumban. Egyes vállalatok már most PDF-passzportot építtetnek, mert az gyors és felismerhető, míg a végső követelmény valószínűleg strukturált, gépi olvasásra alkalmas adatokat igényel. A PDF emberek számára olvasható, de nem feltétlenül alkalmas az ESPR 10. cikkében célzott interoperabilitásra.

Adatok több rendszerben szétszóródva, összekapcsolás nélkül. A termékadatok gyakran részben az ERP-rendszerben, részben marketingdokumentumokban, részben külső szállítónál találhatók. Ezeknek egy terv nélküli összekapcsolása nélkül nehéz lesz később gyorsan átváltani, amint a kötelező formátum ismertté válik. Azok a vállalatok, amelyek saját rendszerük közreműködésében gondolkodnak, további információkat a következő oldal tartalmaz: a termékalkalmazás saját ERP- vagy készletkezelő rendszerhez való csatolásáról.

Zavar a passzport és a nyilvántartás között. A QR-kód segítségével megtekinthető passzport és a nyilvántartásban szereplő adatok formájában vagy formátumában nem feltétlenül azonosak. Annak feltételezése, hogy egy fájl mindkét célra megfelelő, olyan kockázat, amely csak akkor válik láthatóvá, amikor a végrehajtási intézkedések konkrétesek lesznek.

Az összetett termékcsomagolási szintek figyelmen kívül hagyása. Az összetett csomagolásban értékesített termékek vagy olyan berendezések esetében, amelyek több, saját passzporttal rendelkező alkatrészből állnak, az adatformátumok közötti összehangolás sokkal összetettebb kérdés. Ez például a következőknél játszik szerepet: egy doboz több készülékkel benne valamint olyan termékeknél, amelyek több termékalkalmazásra van szükség.

Elégtelen figyelem a hosszú távú olvashatóságra. Egy ma általánosan használt fájlformátum nem marad az idővel. Mivel a passzportnak egy adott ideig elérhetőnek kell maradnia, a formátum választása a tartósság kérdése is — lásd a tájékoztatást arról: meddig kell egy termékalkalmazásnak rendelkezésre állnia.

Amit rögzíthet

  • Azon termékadat-források (ERP, PIM, táblázatok, szállítói dokumentumok) és azok formátumainak áttekintése, amelyekben jelenleg rögzítésre kerülnek.
  • A termékkategóriánként kötelezően megadandó adatforrások listája, amint az adott kategóriához delegált határozat közzétételre kerül.
  • Szállítókkal és alvállalkozókkal kötött megállapodások arról, hogy milyen formátumban szállítják be termékadat-adataikat, hogy az összekapcsolás később könnyebb legyen.
  • Egy belső felelős vagy csapat, amely az ESPR 11. cikke szerinti technikai szabványok fejlődésének nyomon követésére van megbízva, mivel ez még további specifikációkat fog kapni.
  • Dokumentáció az egyes termékekhez választott azonosítási módszerről, a végső fájlformátumon kívül.
  • Az üzemeltetési és rendelkezésre állási követelmények áttekintése, amelyek a formátummal együtt határozzák meg, hogy a passzport technikai szempontból hogyan épül fel — tekintse meg a következő oldalt: mely hosting-követelmények érvényesek.

Ez nem jogi tanács. Ez az oldal általános információt nyújt az érvényes szabályozásról. Mi nem ismerjük az Ön helyzetét. Ha bizonytalansága van saját ügyében, konzultáljon ügyvéddel vagy a hatáskörrel rendelkező felügyelettel.

Mesterséges intelligenciával íródott a fenti források alapján, 2026-09-05-én emberileg ellenőrizve. Valami nem stimmel? Jelezze — a javítások elsőbbséget kapnak.