mire kell ügyelni a termékútlevél-szolgáltató kiválasztásakor

Mit kell konkrétan tennie

Mit várnak önnel

A termékazonosítóhoz szoftveres szállítót választani nem arról szól, hogy a legolcsóbb QR-kód-generátort keressük. Az ESPR követelményeket támasztott az azonosítóval szemben, és ezek a követelmények közvetlenül meghatározzák, hogy egy rendszernek minek kell megfelelnie. Aki ezt előzetesen áttekinti, elkerüli, hogy később új rendszerre legyen szükség.

Az azonosítót egy fizikai adathordozóhoz kell csatolni

Az ESPR 9. cikke (az Európai Unió 2024/1781. rendelete) az digitális termékazonosítót olyan adatkészletként írja le, amely egy hordozó — a gyakorlatban általában egy QR-kód — útján csatolódik a termékhez. A 10-100 alkalmazottal rendelkező vállalat számára ez azt jelenti, hogy a szoftveroldás nem csak adatokat tárol, hanem működő kapcsolatot is biztosítania kell egy fizikai hordozóval a terméken vagy a címkén. Egy olyan rendszer, amely csak egy pdf-et állít elő, nem felel meg ennek a gondolatnak. Aki még ebben kételkedik, vagy azt szeretné tudni, hogy a címkét már most módosítani kell-e, többet olvas róla most már módosítania kell-e a ruhacímkéit és csomagolását a termékútlevél számára.

A műszaki működésnek rögzített követelményeknek kell megfelelnie

Az ESPR 11. cikke (az Európai Unió 2024/1781. rendelete) az azonosító műszaki tervezéséről és működéséről szól: többek között arról, hogy az adatoknak hozzáférhetőnek kell maradniuk, a hordozónak és a tárolórendszernek megbízhatóan kell működnie, és az adatoknak a helyes termékhez csatolva kell maradniuk, még akkor is, ha az gazdát cserél. Egy vállalat számára ez azt jelenti, hogy a szállítónak tudnia kell igazolni, meddig maradnak az adatok, ki férhet hozzájuk, és mi történik, ha maga a vállalat szállítót cserél vagy leáll.

A tartalmnak összhangban kell lennie azzal, amit a termékreguláció később elő fog írni

Az ESPR 10. cikke (az Európai Unió 2024/1781. rendelete) azokat a követelményeket írja le, amelyeknek az azonosító tartalmának meg kell felelnie, például mely adatkategóriák tartoznak bele. Ezt a tartalmat termékenként delegált jogi aktusok útján teszik részletesebbre — ruhanemű és textil esetén még nem publikálták. A szoftveroldásnak tehát elég rugalmasnak kell lennie ahhoz, hogy később adatmezőket módosíthasson anélkül, hogy az egész rendszert újra kellene beállítani. Az olyan vállalatok, amelyek már most gyűjtenek adatokat, jól teszik, ha azt egy olyan szerkezetbe helyezik, amely a szabályozáshoz tudhat alkalmazkodni; lásd még mit tudok már tenni, amíg a szabályok még nem véglegesek.

Ahol hibák történnek a gyakorlatban

A gyakorlatban számos helyzet rendszeresen visszatér a szoftveroldás választásakor.

Egy vállalat olyan rendszert választ, amely QR-kódokat generál, de nem garantál hosszú távú tárolást. Egy év után a szállító leállítja a szolgáltatást vagy felvásárolják, és az eladott ruhákra nyomtatott QR-kódok nem mutatnak semmire.

Egy másik vállalat ruhaneműt importál több szállítón keresztül különböző országokból, és azt tapasztalja, hogy a kiválasztott szoftver nem biztosít lehetőséget az adatok több nyelven való megjelenítésére, miközben a végső vásárló más országban él, mint ahol a termék gyártása történt. Aki ebben felismeri magát, több információt talál a fordítással kapcsolatos felelősségről a magának kell gondoskodnia a termékútlevél-adatok fordításáról.

Harmadik helyzet: egy márka az új kollekcióhoz összeállítja a terméktajékoztatót, de megfeledkezik arról, hogy még nagy készlet van a raktárban, amely ugyanezek alá a szabályok alá eshet, miután a dátum véglegessé válik. A szoftver ezt követően nem képes visszamenőlegesen adatokat társítani a meglévő cikkszámokhoz. Erről bővebben olvashat a mit tegyek a ruházat és textil olyan készletével, amely már ott van, amikor a szabályok életbelépnek.

Negyedik visszatérő probléma: a kiválasztott rendszer új értékesítésre van felkészítve, de nem veszi figyelembe a másodjáték értékesítést vagy a visszáramlásokat, így homályos marad, hogy a terméktajékoztató mennyiben követi az újbóli értékesítést és hogyan. Erről lásd Az útmutató a használt ruhaneműre és a visszárakódott termékekre is vonatkozik.

Ötödik helyzet: a felügyelet során egy hatóság azt kéri, hogy mutassa meg az adatok forrásait a terméktajékoztatóban, és kiderül, hogy a szoftver nem őrzi meg a verzióelőzményeket vagy a forrásdokumentációt — csak az eredményt. Mit lehet konkrétan a hatóságtól kérni, az alábbi helyen olvasható: mit kér egy felügyelő egy ruházati és textilipari ellenőrzéskor.

Mit rögzíthet

A szoftverszállító kiválasztásakor gyakorlati megoldás, ha néhány pontot írásban megerősíttetünk, így nem marad kérdés abban, hogy mi volt ígérve és mi nem.

• Tárolási időtartam és folytonosság — az írásbeli megállapodás arról, hogy az adatok meddig maradnak hozzáférhetők, és mi történik a szállító leállítása vagy felvásárlása esetén.
• Az adatok tulajdonjoga és hordozhatósága — rögzítse, hogy az adatok igény esetén exportálhatók, és milyen feltételek mellett.
• Kapcsolat a fizikai hordozóval — leírás arról, hogy a QR-kód vagy egyéb hordozó technikai szempontból hogyan kapcsolódik a termékhez, és ki felelős annak feltüntetéséért a címkén vagy a csomagoláson.
• Az adatmezők bővíthetősége — megállapodás arról, hogy a rendszer képes-e adatkategóriákat hozzáadni, amint a ruha- és textiltermékekre vonatkozó delegált jogi aktus megjelenik.
• Az adatok forrása és verziókezelése — rögzítse, hogy a forrásdokumentumok és módosítások nyomon követhetők maradnak, nem csak a végeredmény.
• Nyelvek és célközönség — megállapodások arról, hogy az adatok milyen nyelveken jelennek meg, és ki felelős a fordítások helyességéért.

Aki ezt az folyamatot lépésről lépésre végig akarja menni, beleértve azt is, hogy a szoftver kiválasztása mikor fér bele a tervezésbe, egy áttekintést talál a Hogyan kezeljem az öltözethez és textilhez szóló terméktajékoztatót lépésről lépésrehelyen. Az ezekkel a választásokkal járó költségek becsléséhez Mennyibe kerül egy ruha- és textiltermék terméktajékoztatója.