mis formaadis pean tootepaspordi andmeid esitama

Püsiv failivormingu standard pole veel kindel, kuid nõuded, mis sellele kehtivad, on teada

Digitaalsele elektroonika ja IKT-seadmete tootepassiile ette nähtud failivormingut (nagu JSON, XML või muud) veel ei ole. ESPR ise ei sätesta konkreetset vormingut, kuid määrab artiklis 10 ja artiklis 11 Euroopa Liidu määrusest (EL) 2024/1781 nõuded, mille alusel passi tehniline struktuur peab olema paigutatud: pass peab põhinema avatud, koostalitlusvõimeliste standardite peal, olema süsteemide vahel vahetatav ja masinloetav. Millise konkreetse failistandardiga sellele reaalsuses vastust antakse, töötame välja tootekaupa. Elektroonika ja IKT puhul pole see määrus veel kehtiv.

Elektroonika puhul kehtib see hetkeseisul kui raamistik, mitte kindlustatud nõudena

See leht käsitleb digitaalse tootepassi valdkonda elektroonika- ja IKT-seadmete jaoks ESPR alusel. Artiklid 10 ja 11 kehtivad kõigile ESPR-i reguleeritavatele tootegrupeile, kuid täpne tehniline sisu — kaasa arvatud failivormingu — määratakse kindlaks tootegrupi kaupa. See tähendab, et see, mis hetkeseisul kindlaks on määratud, on raamistik: nõuded koostoimivusele, avatud standarditele ja masinloetavusele. Aga see ei tähenda, et on juba kätte antud konkreetne failivormingu, mille alusel elektroonikatootete tootja või importija andmeid esitama peavad. Kes otsib vastust nagu "esita JSON-formaadis" või "kasuta XML-skeemi X", ei leia seda hetkeseisul õigusaktidest selle tootegruppi puudutavalt. Ka see teema erineb küsimusest, kas tootepasse kohaldatakse konkreetsele elektroonikatoramule — see on eraldi küsimus erineva vastusega.

Elektroonika kohase delegeeritud õigusakti avaldamine määrab kuupäeva kindlaks

Elektroonika ja IKT failivormingu tegemise kuupäev pole veel kindel. ESPR-i tegevuskava 2025–2030 järgi töötame välja delegeeritud õigusaktid tootegrupi kaupa, esimesed õigusaktid on oodatavad alates 2027. Kohe kui elektroonika ja IKT jaoks delegeeritud õigusakt avaldatakse, peavad selles ilmselt olema ka tehnilised nõuded, mille alusel andmeid esitama peavad. Kuni selle ajani kehtib üksnes üldine raamistik artiklist 10 ja 11: avatud standardid, koostoimivus ja masinloetavus, kehtiv konkreetne failivormingu ei ole sätestatud. Lehte uuendatakse niipea, kui antud kategooria delegeeritud õigusakt konkreetse vastuse annab.

Mida tootja ja importija juba hetkeseisul võivad ette valmistada

Isegi siis, kui failivormingut pole kinnitatud, on praktikas juba palju tegemist. Alguses on mõistlik selgeks teha, millised süsteemid ja andmed peavad tulevikus passi aluseks olema — enamikul ettevõttetel on need andmed juba kusagil olemas, näiteks ERP- või laovahenduses, ja on kasulik eelnevalt vaadata, kuidas selline süsteem hiljem tootepasiga ühendatakse. Lisaks on kasulik mõelda identifitseerimisele: igat toodet peab saama ühe passi juurde jälgida, ja see nõuab järjekindlat lähenemist iga toote jaoks unikaalse identifikaatorikoodi omistamisele. Samuti on kasulik juba praegu uurida, kuidas QR-kood hiljem tootele paigutatakse ja kuidas see seostub olemasolevate vöötkoodide või GS1-süsteemidega, olenemata sellest, milline failivormingu valitakse. Niipea kui elektroonika ja IKT-kategooria delegeeritud õigusakt ilmub, toetub see tõenäoliselt infrastruktuurile, mida mainitakse artiklis 13 (digitaalse tootepassi register) ja artiklis 14 (veebietalon), seega ettevalmistus sellele struktuurile on nüüd juba kasulik, olenemata täpsest tehnilisest vorming.

Õiguslik alus: ESPR-i artikkel 10 ja artikkel 11

Määrus (EL) 2024/1781 (ESPR) artikkel 10 kirjeldab digitaalse tootepassi üldnõudeid, sealhulgas andmete kättesaadavust ja usaldusväärsust. Artikkel 11 käsitleb spetsiaalselt passi tehnilist kujundust ja toimimist ning nimetab nõudeid nagu erinevate turuosaliste süsteemide vaheliseline interoperaalsus ja avatud standardite kasutamine, ilma et oleks määratud ühtset kohustuslikku failivormingut. Edasine tehniline täiendamine — sealhulgas tõenäoliselt konkreetne andmevormingu — töötatatakse läbi delegeeritud aktide kaudu tootegrupiti, nagu on teatatud ESPR-i tegevuskava 2025–2030 kohaselt. Määrus (EU) 2024/1781 artikkel 13 ja artikkel 14 kirjeldavad täiendavalt registrit ja veebikeskkonda, kus passiandmed on kättesaadavad, mis on oluline selle kohta, kuidas esitatud fail lõpuks kuvatakse ja kuidas seda otsitakse. Elektroonika ja IKT puhul pole delegeeritud akt, mis seda konkreetselt teoks teeb, käesoleval ajal veel avaldatud.

Kes soovib juba nüüd ettevalmistusi teha, võib alustada oma tooteandmete ja identifitseerimissüsteemide korrastamisega, nii et ülemineku konkreetsele failivormingule saab hiljem lihtsalt ühendada, selle asemel et nullist alustada. Samuti on otstarbekas vahepeal vaadata, mis sisaldab digitaalse tootepassi register ja mis sinna jääbsest see register on tõenäoliselt otseselt seotud hilisema esitamismehhanism.

Millel see põhineb

Määrus ise asub EUR-Lexis. Viitame väitele; te ei pea meile usaldama.

Mida te konkreetselt peate tegema

Millised on teie kohustused

Küsimus, milline failivormingu on kohustuslik — JSON, XML, PDF, konkreetne API-struktuur — tuleb iga importöörile ja tootjale, niipea kui IT-osakond hakkab ehitama. Vastus praeguse ESPR-teksti alusel on pragmaatiline: konkreetne failivormingu ei sisaldu määruses. Määrus (EU) 2024/1781 artikkel 10 ja artikkel 11 on küll määranud, millele peavad vastama digitaalse tootepass, kuid see juhtub funktsionaalsete ja tehniliste nõudmiste tasandil, mitte tasandil "kasutage JSON-LD-d" või "esitage XML-fail selle skeemi kohaselt". Selle täiendamine eeldatakse delegeeritud ja tegevusaktide kaudu, tootegrupiti.

Interoperaalsus on kesksel kohal, mitte üks kindel vormingu

Määruse (EU) 2024/1781 artikkel 10 nimetab interoperaalsust põhilise nõudena: pass peab olema üles ehitatud nii, et erinevate osapoolte — järelevalveasutuste, turuosaliste, tarbijate — süsteemid saaksid andmeid lugeda. Üheteistkümnest sajani töötajatega ettevõtte jaoks tähendab see praktiliselt, et otsus salvestus- ja andmevahetuse vormingu kohta saab olla tehtud kindlalt alles siis, kui delegeeritud akt oma tootegrupi jaoks on olemas. Kuni selleni on soovitatav töötada struktureeritud andmetega (mõelge andmebaasi või ERP-süsteemi väljadele) selle asemel, et andmeid hoida ainult lahus dokumentis või PDF-is, nii et hilisem avamine lõplikul kujul nõuab vähem ümbertöötamist.

Pass peab olema loetav QR-andmekandjast

Määruse (EU) 2024/1781 artikkel 11 kirjeldab passi tehnilist toimimist, sealhulgas seost andmekandjaga tootel. See tähendab, et alusandmed, olenemata vormingust, tuleb avada sel hetkel, kui keegi koodi skannib. Kuidas see ühendus tehniliselt toimib ja millised identifitseerimise standardid selle käigus rolli mängivad, on kirjeldatud lehel,. kuidas saab digitaalse tootepassi QR-kood minu elektroonikavarustusele Ettevõtete jaoks, kes juba GS1-vöötkoodidega töötavad, on asjakohane küsimus, kas olemasolevat identifitseerimisstruktuuri saab uuesti kasutada — see teema tuleb uuesti lehel, mis on GS1 Digital Link ja kas seda on tootepassi jaoks vaja.

Iga toode peab olema ainulaadselt identifitseeritav, olenemata failivormingust

Olenemata sellest, milline tehniline vorming hiljem ette nähtakse, on aluseks seatud nõue, et iga toode saab ainulaadse identifitseerimiskoodi. See on eraldiseisev nõue, mis ei muutu, kui failivormingu hiljem kehtestada. Ettevõtetel, kes hakatavad juba nüüd oma tooteandmeid struktureerima, on otstarbekas see identifikatsioon püsiva osana kaasa võtta. Kuidas seda praktikas ehitatakse, on selgitatud lehel kuidas anda igale tootele ainulaadne identifikaatioonikood.

Registrisse esitamine nõuab erinevat vormi

ESPR artikkel 13 tutvustab digitaalse tootepassi registrit, kuhu sisestatakse teatavad passiga seotud andmed. Kaski siin ei ole täpsustatud, millises failivormingus see esitamine peab toimuma — seda täiendatakse hiljem. Selge on aga see, et see register on eraldiseisev esitamiste voog võrreldes passiga, mis on QR-koodi kaudu kättesaadav. Rohkem teabe kohta, mis sinna peab minema, leiab lehelt mis on digitaalsete tootepasside register ja mida peab sinna sisalduma.

Kus läheb praktikas valesti

Liiga vara määratlemimine staarses vormingus. Mõned ettevõtted lubavad nüüd juba PDF-passi luua, sest see on kiire ja äratuntav, kuigi lõplik nõue tõenäoliselt eeldab struktureeritud, masina-loetavaid andmeid. PDF on inimeste jaoks loetav, kuid ei ole automaatselt sobiv selleks interoperabilisuseks, mida ESPR artikkel 10 eesmärgistab.

Andmed hajutatud mitmes süsteemis ilma sidumeta. Tooteinfo asub sageli osaliselt ERP-süsteemis, osaliselt turunduskoondeis, osaliselt välise tarnija juures. Ilma plaanita seda kokku tuua, muutub hiljem keeruline kiiresti üle minna, kui kohustuslik vorming teada saab. Ettevõtted, kes kaalulevad oma süsteemi liitmist, leiavad rohkem teavet võimaluste kohta lehelt tootepassi sidumine oma ERP- või varusüsteemiga.

Segadus passi enda ja registri vahel. QR-koodi kaudu konsulteeritav pass ja registrisse kuuluvad andmed ei ole vormilt või formaadilt automaatselt samad. Eeldada, et üks fail kummalegi eesmärgile sobib, on risk, mis muutub nähtavaks alles siis, kui täiteavitamised konkreetseks muutuvad.

Arvestamine mitme tootetasemega. Toodete puhul, mida müüakse kompleksetes pakendites või kus seade koosneb mitmest osast, millel on oma pass, on küsimus andmeformaatide vastastamisest veelgi keerulisem. See kehtib näiteks kast, millesse on pandud mitu aparaati ja toodete puhul, mis on mitu tootedokumenti on vaja.

Ebapiisav tähelepanu pikaajaliste loetavusele. Failivormingu, mis nüüd levinud on, ei pea see olema pikema aja jooksul. Kuna pass peab mingi aja jooksul kättesaadav jääma, on vormingu valik ka küsimus säilivuse kohta — vt selgitust kui kaua peab tootepasport saadaval olema.

Mida saate dokumenteerida

Ülevaade sellest, kus tooteandmeid praegu salvestatakse (ERP, PIM, arvutustabelid, tarnija dokumendid) ja millisel kujul.
Nimekirja kohustuslikest andmeallikatest tootekaupa, kohe pärast seda, kui selle kategooria delegeeritud tegevus on avaldatud.
Kokkulepet tarnijate ja tükkitarnijatega vormingu kohta, milles nad oma tooteandmeid esitavad, nii et hiljem on ühildumine lihtsam.
Sisene vastutav isik või meeskond, kes jälgib tehnilistest standarditest arengu, kuna ESPR artikkel 11 saab nende kohta täpsemaid spetsifikatsioone.
Dokumentatsiooni valitud identifitseerimismeetodi kohta toote kaupa, ka olenemata lõplikust failivormingust.
Ülevaade majutusteenuse osutamise ja kättesaadavuse nõuetest, mis koos vorminguga määravad, kuidas pass tehnilist seisukohta võetuna asetatakse — vt lehte millised hosting-nõuded kehtivad.

See ei ole juriidiline nõu. See leht annab üldist teavet määruse kohta, millega see platvorm tegeleb. Me ei tea teie olukorda. Oma juhtumi puhul kahtluse korral konsulteerige juristiga või pädevas järelevalveorgani.

Kirjutatud AI-ga ülaltoodud allikate põhjal, inimese poolt kontrollimuud 2026-09-05.a.d. Kas midagi pole õige? Andke teada — parandused saavad eesõiguse.