elektropas.com

în ce format trebuie să furnizez datele pașaportului produsului

Un format de fişier fix nu este încă stabilit, dar cerințele pe care trebuie să le îndeplinească sunt bine definite

Nu există încă un format de fişier prescris (cum ar fi JSON, XML sau altceva) pentru pasaportul digital al produselor de electronică şi echipamente ICT. ESPR în sine nu prescrie un format specific, dar stabilește în articolele 10 şi 11 ale Regulamentului (UE) 2024/1781 cerințele pe care trebuie să le îndeplinească configurația tehnică a pasaportului: pasaportul trebuie să se bazeze pe standarde deschise şi interoperabile, trebuie să fie interschimbabil între sisteme şi trebuie să fie citibil de mașini. Ce standard de fişier concret îndeplinește aceste cerințe se va detalia per categorie de produs într-un act delegat. Pentru electronică şi ICT, acel act nu există încă.

Pentru electronică, aceasta rămâne încă ca cadru, nu ca o cerință stabilită

Această pagină tratează pasaportul digital al produselor de electronică şi ICT în temeiul ESPR. Articolele 10 şi 11 se aplică tuturor categoriilor de produse care se încadrează în ESPR, dar implementarea tehnică precisă — inclusiv formatul de fişier — se reglementează separat per subcategorie. Aceasta înseamnă că ceea ce este stabilit acum este un cadru: cerințe privind interoperabilitatea, standardele deschise şi citibilitatea de mașini. Nu înseamnă că a fost deja desemnat un format de fişier concret în care un producător sau importator de electronică trebuie să furnizeze datele. Oricine caută un răspuns de genul "furnizați în JSON" sau "utilizați schema XML X" nu va găsi asta nicăieri în reglementări pentru acest grup de produse în acest moment. De asemenea, acest subiect este diferit de întrebarea dacă pasaportul digital se aplică unui anumit produs electronic — aceasta este o întrebare separată cu un răspuns diferit.

Publicarea actului delegat pentru electronică va determina data

Nu există încă o dată fixă când formatul de fişier pentru electronică şi ICT va fi cunoscut. Conform planului de lucru ESPR 2025-2030, actele delegate se vor elabora per subcategorie, cu primele acte aşteptate să apară din 2027. Imediat după ce un act delegat va fi publicat pentru electronică şi ICT, va conține probabil şi formatul tehnic în care datele trebuie furnizate. Până atunci, se aplică doar cadrul general din articolele 10 şi 11: standarde deschise, interoperabilitate şi citibilitate de mașini, fără ca un singur format de fişier concret să fie prescris. Această pagină va fi actualizată imediat ce actul delegat pentru această categorie va oferi un răspuns concret.

Ce poate pregăti deja un importator sau producător

Chiar şi fără un format de fişier stabilit, există practic deja foarte mult de făcut. Pentru început, este util să se determine care sisteme şi date vor forma baza pasaportului — majoritatea companiilor au aceste informații stocate deja undeva, de exemplu într-un sistem ERP sau de gestionare a stocurilor, şi este util să se revizuiască în prealabil cum un asemenea sistem ar putea fi conectat la pasaportul digital al produselor mai târziu. În plus, este recomandabil să se gândească la identificare: fiecare produs trebuie să fie reductibil la un pasaport, ceea ce necesită o abordare consecventă pentru acordarea unui cod de identificare unic fiecărui produs. De asemenea, întrebarea cum va ajunge codul QR pe produs şi cum se raportează la codurile de bare existente sau la sistemele GS1 poate fi investigată acum, indiferent de ce format de fişier va fi prescris mai târziu. Imediat ce actul delegat pentru electronică şi ICT va apărea, acesta va trebui probabil să se alinieze la infrastructura deja menționată în articolul 13 (registrul pasapoartelor digitale ale produselor) şi articolul 14 (portalul web), deci o pregătire pe baza acestei structuri este deja utilă acum, indiferent de formatul tehnic exact.

Baza juridică: articolele 10 şi 11 ale ESPR

Articolul 10 al Regulamentului (UE) 2024/1781 (ESPR) descrie cerințele generale pe care trebuie să le îndeplinească un pașaport digital al produsului, inclusiv accesibilitatea și fiabilitatea datelor. Articolul 11 tratează în mod specific proiectarea tehnică și funcționarea pașaportului și menționa cerințe precum interoperabilitatea între sistemele diferiților actori de pe piață și utilizarea standardelor deschise, fără a prescrie un singur format de fișier în mod obligatoriu. Detaliile tehnice suplimentare — inclusiv, presupunem, formatul concrete de date — vor fi elaborate prin acte delegate per grup de produse, după cum anunțat în planul de lucru ESPR 2025-2030. Articolul 13 și articolul 14 din același regulament descriu suplimentar registrul și portalul web prin care datele pașaportului sunt accesibile, ceea ce este relevant pentru modalitatea în care un fișier transmis va fi în final afișat și căutat. Pentru electronice și ICT, actul delegat care face acest lucru concret nu a fost încă publicat la acest moment.

Cine dorește să se pregătească deja acum, ar fi bine să înceapă cu punerea în ordine a propriilor date de produs și sisteme de identificare, astfel încât trecerea la un format de fișier concrete să fie mai degrabă o chestiune de conectare decât de a porni de la zero. De asemenea, este recomandabil să priviți în această perioadă la ce conține registrul pașapoartelor digitale ale produselor și ce intră în el, deoarece acel registru este probabil direct legat de mecanismul final de transmitere.

Ce trebuie să faceți concret

Ce se așteaptă de la dumneavoastră

Întrebarea ce format de fișier este obligatoriu — JSON, XML, PDF, o structură API specifică — apare la fiecare importator și producător de îndată ce departamentul IT începe construcția. Răspunsul pe baza textului actual ESPR este sobru: un format de fișier concrete nu se află în regulament. Articolul 10 și articolul 11 al ESPR (Regulamentul (UE) 2024/1781) stabilesc ce trebuie să îndeplinească pașaportul digital al produsului, dar aceasta se întâmplă la nivelul cerințelor funcționale și tehnice, nu la nivelul "utilizați JSON-LD" sau "transmiteți un fișier XML conform acestui schema". Detaliile vor fi așteptate prin acte delegate și de executare, per grup de produse.

Interoperabilitatea este în centru, nu un singur format specific

Articolul 10 al ESPR menționa interoperabilitatea ca cerință de bază: pașaportul trebuie să fie structurat în așa fel încât sistemele diferitelor părți — autoritățile de supraveghere, actorii de pe piață, consumatorii — să poată citi datele. Pentru o companie cu 10 până la 100 de angajați, aceasta înseamnă practic că alegerea unui format de stocare și schimb poate fi făcută cu certitudine doar odată ce actul delegat pentru propria categorie de produse este disponibil. Până atunci, este recomandabil să lucrați cu date structurate (gândiți-vă la câmpuri într-o bază de date sau sistem ERP) în loc să păstrați datele doar într-un document liber sau PDF, astfel încât o dezvăluire ulterioară în formatul final cere mai puțin refacere.

Pașaportul trebuie să fie citibil prin intermediul purtătorului de date cu cod QR

Articolul 11 al ESPR descrie funcționarea tehnică a pașaportului, inclusiv legătura cu purtătorul de date pe produs. Aceasta înseamnă că datele de bază, în orice format, trebuie să poată fi dezvăluite în momentul în care cineva scanează codul. Cum funcționează acea legătură din punct de vedere tehnic și ce standarde de identificare joacă un rol în aceasta, este descris pe pagina despre cum ajunge codul QR pentru pașaportul digital al produsului pe electronica mea. Pentru companiile care deja lucrează cu coduri de bare GS1, întrebarea dacă o structură de identificare existentă poate fi reutilizată este relevantă — acel subiect revine pe pagina despre ce este GS1 Digital Link și dacă este necesar pentru pașaportul produsului.

Fiecare produs trebuie să fie identificabil în mod unic, independent de formatul fișierului

Indiferent de ce format tehnic va fi prescris mai târziu, cerința fundamentală este că fiecare produs trebuie să primească un cod de identificare unic. Aceasta este o cerință separată care nu se schimbă atunci când formatul fișierului va fi stabilit mai târziu. Întreprinderile care încep deja acum să-și structureze datele despre produse sunt bine-venite să includă această identificare ca parte permanentă. Modul în care se construiește acest lucru în practică este explicat pe pagina despre cum să atribuiți fiecărui produs un cod de identificare unic.

Depunerea la register necesită o formă proprie

Articolul 13 din ESPR introduce registrul pașapoartelor digitale ale produselor, care conține anumite date despre pașaport. Nici aici nu a fost încă stabilit în ce exact format de fișier trebuie să aibă loc depunerea — aceasta va fi clarificată în continuare. Cu toate acestea, este clar că acest registru este un flux de depunere separat, pe lângă pașaportul accesibil prin codul QR. Mai multe informații despre ce trebuie să conțină registrul se găsesc pe pagina despre ce este registrul pașapoartelor digitale ale produselor și ce trebuie să conțină.

Unde lucrurile se petrec greșit în practică

Fixare prea devreme într-un format rigid. Unele întreprinderi construiesc deja un pașaport PDF pentru că este rapid și ușor de recunoscut, în timp ce cerința finală va cere probabil date structurate, citibile de mașini. Un PDF este ușor de citit pentru oameni, dar nu este automat potrivit pentru interoperabilitatea pe care o urmărește articolul 10 din ESPR.

Date dispersate în mai multe sisteme fără legătură. Informațiile despre produse se găsesc adesea parțial în sistemul ERP, parțial în documente de marketing, parțial la un furnizor extern. Fără un plan pentru a aduna acestea, va fi dificil să schimbați rapid mai târziu, odată ce formatul obligatoriu va fi cunoscut. Întreprinderile care intenționează să-și conecteze propriul sistem vor găsi mai multe informații despre posibilități pe pagina despre conectarea pașaportului produsului la propriul sistem ERP sau de inventar.

Confuzie între pașaport și register. Pașaportul care poate fi consultat prin codul QR și datele care vin în register nu sunt automat identice în formă sau format. Presupunerea că un singur fișier va fi suficient pentru ambele scopuri este un risc care devine vizibil abia atunci când actele de execuție devin concrete.

Fără luare în considerare a mai multor niveluri de produs. Pentru produsele vândute în ambalaje compuse, sau atunci când un aparat constă din mai multe componente cu propriul pașaport, întrebarea cum să se conecteze formatele datelor este și mai complexă. Acest lucru se aplică, de exemplu, la o cutie cu mai multe aparate în ea și la produse care au nevoie de mai multe pașapoarte digitale ale produselor.

Atenție insuficientă pentru lizibilitate pe termen lung. Un format de fișier care este comun acum nu trebuie să rămână astfel pe o perioadă mai lungă. Deoarece pașaportul trebuie să rămână accesibil pentru o anumită perioadă, alegerea formatului este, de asemenea, o chestiune cu privire la durabilitate — a se vedea explicația despre cât timp trebuie să rămână disponibil un pasaport de produs.

Ceea ce puteți documenta

  • O prezentare generală a locului în care sunt înregistrate acum datele despre produse (ERP, PIM, foi de calcul, documente de furnizori) și în ce format.
  • O listă cu sursele de date obligatorii per categorie de produs, odată ce actul delegat pentru acea categorie a fost publicat.
  • Acorduri cu furnizorii și subfurnizori cu privire la formatul în care furnizează datele lor despre produse, pentru ca conectarea să fie mai ușoară mai târziu.
  • Un responsabil intern sau o echipă care urmărește dezvoltarea standardelor tehnice, deoarece articolul 11 din ESPR va primi și alte specificații cu privire la aceasta.
  • Documentație cu privire la metoda de identificare aleasă per produs, chiar și separat de formatul final de fișier.
  • O prezentare generală a cerințelor privind găzduirea și disponibilitatea, care determină împreună cu formatul modul în care pașaportul este stabilit din punct de vedere tehnic — a se vedea pagina despre ce cerințe de hosting se aplică.

Aceasta nu este sfat juridic. Această pagină oferă informații generale despre reglementările cu care se ocupă această platformă. Nu cunoaștem situația dvs. În caz de îndoieli cu privire la cazul dumneavoastră, consultați un jurist sau autoritatea de supraveghere competentă.

Scris cu ajutorul AI pe baza surselor de mai sus, verificat de un om pe 2026-09-05. Nu e ceva în neregulă? Spuneți-ne — corecțiile au prioritate.