kokiame formate turėčiau pateikti produkto pasporto duomenis

Pastovus failo formatas dar nenustatytas, tačiau nustatyti reikalavimai, kuriems jis turi atitikti

Dar nėra nustatyto failo formato (pavyzdžiui, JSON, XML ar kito) skaitmeniniam elektronikos ir IKT įrangos produkto pasportui. Pati ESPR nenumato konkretaus formato, tačiau Reglamento (ES) 2024/1781 10 ir 11 straipsniuose nustatyti reikalavimai, kuriems turi atitikti pasporto techninis struktūra: pasportas turi būti pagrįstas atvirais, tarpusavyje suderinamo standartais, keičiamas tarp sistemų ir skaitomasis mašinos. Kuri konkreti failo standarta tai įgyvendina, bus išsamiai apgalvota kiekvienai produktų kategorijai atitinkamoje deleguotoje veikoje. Elektronikai ir IKT ši veika dar neegzistuoja.

Elektronikai tai vis dar taikoma kaip nuorama, o ne kaip nustatyta sąlyga

Šiame puslapyje aptariamas skaitmeninis produkto pasportas elektronikos ir IKT įrangai pagal ESPR. 10 ir 11 straipsniai galioja visoms produktų kategorijoms, kurios patenka į ESPR taikymo sritį, tačiau tikslus techninis įgyvendinimas — įskaitant failo formatą — nustatomas kiekvienai daliai atskirai. Tai reiškia, kad tai, kas dabar nustatyta, yra nuorama: reikalavimai tarpusavyjje suderinamumui, atviems standartams ir mašinos skaitymo galimybei. Tai nereiškia, kad jau nustatytas konkretus failo formatas, kuriame elektronikos gamintojas ar importuotojas turi pateikti duomenis. Kas ieško atsakymo, pavyzdžiui, "pateikite JSON" arba "naudokite XML schemą X", šiuo metu to negali rasti niekur šios produktų grupės teisės aktuose. Taip pat ši tema skiriasi nuo klausimu, ar produkto pasportas taikomas tam tikram elektronikos produktui — tai atskira klausimas su kitu atsakymu.

Deleguotos veikos dėl elektronikos paskelbimas nusako datą

Dar nėra nustatytos datos, kada elektronikos ir IKT failo formatas taps žinomas. Pagal ESPR darbo planą 2025–2030 m., deleguotos veikos bus išsamiai nagrinėjamos kiekvienai kategorijai, o pirmiausia tikėtasi nuo 2027 m. Kai tik elektronikai ir IKT bus paskelbta deleguota veika, joje, kaip tikėtasi, bus nurodyta ir techninis formatas, kuriame duomenys turi būti pateikti. Tol galioja tik bendroji nuorama iš 10 ir 11 straipsnių: atvirieji standartai, tarpusavyje suderinimas ir mašinos skaitymo galimybė, be to, kad būtų nustatytas vienas konkretus failo formatas. Šis puslapis bus atnaujintas, kai tik deleguota veika šiai kategorijai duos konkretų atsakymą.

Ką importuotojas ar gamintojas gali pasiruošti jau dabar

Net ir be nustatyto failo formato yra daug praktiškų dalykų, kuriuos galima atlikti. Pirmiausiai tikslinga nustatyti, kurie sistemai ir duomenys sudarys pasporto pagrindą — dauguma įmonių šią informaciją jau turi kažkur, pavyzdžiui, ERP arba atsargų sistemoje, ir naudinga iš anksto peržiūrėti, kaip tokia sistema vėliau gali būti susieta su produkto pasportu. Be to, tikslinga galvoti apie identifikavimą: kiekvienas produktas turi būti galimas sugrąžinti į pasportą, o tai reikalauja nuoseklaus požiūrio į unikalaus identifikacijos kodo suteikimą kiekvienam produktui. Taip pat klausimas, kaip QR kodas vėliau atsiranda produktui ir kaip jis susijęs su esamais brūkšniniais kodais ar GS1 sistemomis, gali būti tirtas jau dabar, neatsižvelgiant į tai, koks failo formatas vėliau bus nustatytas. Kai tik deleguota elektronikos ir IKT veika pasirodys, ji tikriausiai atitiks infrastruktūrą, jau minėtą 13 straipsnyje (skaitmeninio produkto pasporto registras) ir 14 straipsnyje (interneto portalas), todėl pasiruošimas tai struktūrai dabar jau yra naudingas, nepriklausomai nuo tikslaus techninio formato.

Pagrindas: ESPR 10 ir 11 straipsniai

10 straipsnis Reglamento (ES) 2024/1781 (ESPR) aprašo bendruosius reikalavimus, kuriuos turi atitikti skaitmeninis produkto pasas, įskaitant duomenų prieinamumą ir patikimumą. 11 straipsnis konkrečiai skirtas paso techninio projektavimo ir veikimo klausimams ir nurodo tokius reikalavimus kaip skirtingų rinkos dalyvių sistemų tarpusavio suderinamumas ir atvirųjų standartų naudojimas, nenustatytas joks verbinai privalomas failų formatas. Tolimesnis techninis įgyvendimas — įskaitant, kaip tikėtasi, konkretų duomenų formatą — bus išsamiau išnagrinėtas per deleguotus aktus pagal kiekvieno produkto grupę, kaip paskelbta ESPR veiksmų plane 2025–2030. 13 straipsnis ir 14 straipsnis iš tos pačios reglamento aprašo papildomai pasų registro ir interneto portalo, per kurį pasų duomenys yra prieinami, kas yra svarbu atsižvelgiant į tai, kaip galutinai pateiktas failas bus rodomas ir ieškomas. Elektronikos ir IKT atveju deleguotasis aktas, kuris tai konkrečiai nustato, šiuo metu dar nepaskelbtas.

Tie, kas norėtų dabar jau pradėti ruošti iš anksto, geriausiai pradėtų nuo savo produktų duomenų ir identifikavimo sistemų sutvarkymo, kad perėjimas prie konkretaus failų formato vėliau būtų tiesiog prijungimas, o ne pradžia iš nulio. Taip pat, tuo tarpu būtina prisiminti kas yra skaitmeninių produkto pasų registras ir kas jame atsiduria, nes tas registras tikriausiai tiesiogiai susijęs su galutine pateikimo sistema.

Pagrindu

Direktyva pati yra EUR-Lex. Mes nurodome pagal teiginį; jums mūsų tikėti nereikia.

Ką jūs konkrečiai turite daryti

Ko iš jūsų tikimasi

Klausimas, kuris failų formatas yra privalomas — JSON, XML, PDF, specifinė API struktūra — pasitaiko kiekvienam importuotojui ir gamintojui iš karto, kai IT skyrius pradeda kurti. Atsakymas remiantis dabartine ESPR tekstu yra pragmatiškas: konkretus failų formatas nenurodomas reglamente. ESPR 10 ir 11 straipsniai (Reglamentas (ES) 2024/1781) nustato, kokiais reikalavimais turi atitikti skaitmeninis produkto pasas, tačiau tai daroma funkcinių ir techninių reikalavimų lygmeniu, o ne "naudokite JSON-LD" arba "pateikite XML failą pagal šią schemą" lygmeniu. Šios nuostatos turėtų būti konkretinamos per deleguotus ir įgyvendinamuosius aktus pagal produkto grupę.

Interoperabilumas yra svarbiausia, o ne vienas konkretus formatas

ESPR 10 straipsnis nurodo interoperabilumą kaip pagrindinį reikalavimą: pasas turi būti sustrukturizuotas taip, kad skirtingų šalių sistemos — reguliavimo institucijos, rinkos dalyviai, vartotojai — galėtų perskaityti duomenis. Praktiškai įmonei, kurioje dirba nuo 10 iki 100 darbuotojų, tai reiškia, kad sprendimas dėl saugojimo ir duomenų mainų formato gali būti priimtas su tikrumu tik tada, kai bus priimtas deleguotasis aktas dėl jos pačios produkto kategorijos. Tol kol to nebus, rekomenduojama dirbti su struktūrizuotais duomenimis (duomenų bazės arba ERP sistemos laukai) ir nesaugoti duomenų tik laisvame dokumente arba PDF faile, kad vėlesnis duomenų atvėrimas į galutinį formatą reikalautų mažiau papildomo darbo.

Pasportą turi būti galima nuskaityti naudojant QR duomenų nešiklį

11 straipsnis ESPR aprašo pasporto techninį veikimą, įskaitant ryšį su duomenų nešikliu ant produkto. Tai reiškia, kad pagrindiniai duomenys, neatsižvelgiant į formatą, turi būti prieinami tuo metu, kai kas nors nuskaito kodą. Kaip šis ryšys techniškai funkcionuoja ir kokie identifikavimo standartai vaidina svarbų vaidmenį, aprašyta puslapyje apie kaip QR kodas produkto pasportui atsiranda į mano elektroniką. Bendrovėms, kurios jau dirba su GS1 brūkšniniais kodais, klausimas, ar galima pakartotinai panaudoti esamą identifikavimo struktūrą, yra aktualus — šis klausimas grįžta puslapyje apie kas yra GS1 Digital Link ir ar jis reikalingas produkto pasportui.

Kiekvienas produktas turi būti unikaliai identifikuojamas, neatsižvelgiant į failo formatą

Nepriklausomai nuo to, koks techninis formatas vėliau bus nustatytas, pagrindinė sąlyga yra ta, kad kiekvienas produktas turi gauti unikalų identifikavimo kodą. Tai atskiras reikalavimas, kuris nesikeičia, kai vėliau nustatomas failo formatas. Įmonės, kurios jau dabar pradeda struktūruoti savo produktų duomenis, turėtų atsiminti, kad šis identifikavimas turi būti nuolatinis jų darbo dalis. Kaip tai praktikoje kuriama, paaiškinta puslapyje apie kaip suteikti kiekvienam produktui unikalų identifikavimo kodą.

Pateikimas į registrą reikalauja savito formato

ESPR 13 straipsnis įveda skaitmeninių produkto pasų registrą, į kurį įtraukiami tam tikri duomenys apie pasą. Čia taip pat dar nenustatytas tikslus failo formatas, kuriuo turi būti atliekama pateikimas — tai bus toliau nudetalizuota. Tačiau aišku, kad šis registras yra atskiras pateikimo kanalas, atskiras nuo paso, pasiekiamo per QR kodą. Daugiau informacijos apie tai, kas turi būti jame, rasite puslapyje apie kas yra skaitmeninis produkto pasų registras ir kas jame turi būti.

Kur praktikoje klystauja

Per anksti fixuoti standžiame formate. Kai kurios įmonės jau dabar sukuria PDF-pasą, nes tai yra greitai ir gerai atpažįstama, o galutinis reikalavimas tikriausiai reikalaus struktūrizuotų, mašininei skaityti skirtų duomenų. PDF yra žmogui skaitytinas, tačiau jis nėra automatiškai tinkamas sąveikai, kurią numato ESPR 10 straipsnis.

Duomenys pasiskirstę kelių sistemų be sujungimo. Produkto informacija dažnai yra iš dalies ERP sistemoje, iš dalies rinkodaros dokumentuose, iš dalies pas išorinį tiekėją. Be plano, kaip tai sujungti, bus sudėtinga greitai perejungti, kai žinomas bus privalomas formatas. Įmonės, svarsčiusios, ar leisti savo sistemai dalyvauti, daugiau informacijos apie galimybes rasite puslapyje apie skaitmeninio produkto paso sujungimą su savo ERP arba atsargų sistema.

Painiava tarp paties paso ir registro. Pas, kurį galima pasiekti per QR kodą, ir duomenys, patalpinti į registrą, nėra automatiškai identiški forma ar formatu. Prielaida, kad vienas failas tinka abiem tikslams, yra rizika, kuri tampa matoma tik tada, kai vykdomieji aktai konkrečiai nustatomi.

Neatsižvelgimas į kelis produkto lygius. Produktams, parduodamiems sudėtuose pakuotuose, arba kai aparatas susideda iš kelių dalių, kurių kiekviena turi savo pasą, duomenų formatų tarpusavio sąveika tampa dar sudėtingesnė. Tai aktualu, pavyzdžiui, dėžėje su keliais aparatais viduje ir produktams, kuriems reikalingi keli produkto pasai.

Nepakankamas dėmesys ilgalaikiam skaitomumui. Dabar dažnas failo formatas gali nelikti toks ilgesnį laiką. Kadangi pas turi būti pasiekiamas tam tikrą laiką, formato pasirinkimas taip pat yra klausimas apie išliekamumą — žr. paaiškinimą apie kaip ilgai produkto pas turi būti prieinamas.

Ką galite užfiksuoti

Produktų duomenų, kurie jau dabar fiksuojami (ERP, PIM, skaičiuoklės, tiekėjų dokumentai), sąrašas ir jų formatas.
Pareigų šaltinių sąrašas pagal produkto kategoriją, kai tik ta kategorija skirta delegavusiojo akto publikuojama.
Susitarimai su tiekėjais ir subtiekėjais dėl formato, kuriuo jie pateikia savo produktų duomenis, kad sąveika būtų vėliau lengvesnė.
Vidinis atsakingas asmuo arba komanda, kuri seka techninio standarto kūrimą, kadangi ESPR 11 straipsnis apie tai gaus tolimesnius patikslinimus.
Dokumentacija apie pasirinktą identifikavimo metodą kiekvienam produktui, nepriklausomai nuo galutinio failo formato.
Hosting ir prieinamumo reikalavimų apžvalga, kuri kartu su formatu nustatyti, kaip techniškai bus nustatytas pas — žr. puslapį apie kokie hosting reikalavimai galioja.

Tai nėra juridinis patarimas. Šis puslapis pateikia bendrąją informaciją apie reguliavimą, kuris yra šios platformos objektas. Mes nežinome jūsų situacijos. Jei abejojate dėl savo konkretaus atvejo, pasitarkite su teisininku arba kompetentinga priežiūros institucija.

Parašyta naudojant AI pagal aukščiau nurodytus šaltinius, žmogaus patikrinta 2026-09-05. Ar kažkas negerai? Praneškite mums — pataisymai turi prioritetą.