am nevoie de software special pentru a crea un pașaport digital de produs

Nu, nu software specială necesară conform legislației

ESPR nu prescrie niciun pachet software, sistem sau marcă anumite. Ceea ce stabiliți ordonanța sunt cerințe privind rezultatul: pasaportul digital al produsului trebuie să conțină date care sunt accesibile într-o manieră stabilită prin intermediul unui purtător de date, trebuie să îndeplinească anumite condiții tehnice și organizatorice, și trebuie să fie consultabil de către cei care au dreptul la acest lucru. Modul în care un producător sau importator reglează acest lucru din punct de vedere tehnic — cu un sistem dezvoltat intern, un modul în pachetul ERP, sau un serviciu de la o terță parte — nu este stabilit în lege. Nu există deci software "pasaport digital" obligatoriu care să se găsească pe o listă și care trebuie achiziționat. Ceea ce trebuie să existe cu siguranță este un întreg funcțional care îndeplinește cerințele din ordonanță, iar aceasta este o altă chestiune decât software-ul folosit pentru aceasta.

Pentru saltele se aplică aceasta, pentru administrația din spate nu în mod automat

Această libertate de mijloace se aplică pasaportului digital al produsului pentru saltele pe care ESPR îl va necesita în curând: purtătorul de date, stocarea și punerea la dispoziție a datelor din pasaport. Nu se aplică pentru tot ceea ce un producător sau importator folosește deja sau trebuie să folosească din punct de vedere software. Un sistem de contabilitate, un pachet de gestionare a stocurilor sau un dosar de marcare CE sunt în afara acestei reglementări și au propriile reguli. De asemenea, nu se aplică pentru întrebarea dacă un anumit sistem este "suficient de bun" — aceasta nu este evaluată după marca sau furnizorul software-ului, ci după faptul că rezultatul îndeplinește cerințele din ordonanță. O foaie de calcul care întâmplător îndeplinește toate cerințele este din punct de vedere teoretic la fel de valabilă ca o soluție scumpă și specializată; invers, un sistem scump nu îndeplinește automat cerințele doar pentru că este scump.

Nici o dată fixă pentru moment, dar deja cerințe fixe pentru proiectare

Momentul în care pasaportul digital al produsului devine obligatoriu pentru saltele nu este încă stabilit; acesta rezultă dintr-un act delegat care trebuie încă publicat pentru acest grup de produse. Până atunci, nu există nicio obligație de a introduce deja un pasaport digital. Ceea ce este deja stabilit sunt cerințele tehnice generale din ESPR pe care trebuie să le îndeplinească în curând un pasaport digital, indiferent de software-ul cu care va fi construit. Aceste cerințe privesc printre altele interoperabilitatea, utilizarea de standarde deschise și modul în care datele trebuie să fie puse la dispoziție. Oricine alege deja sau dezvoltă software-ul poate lua, prin urmare, aceste cerințe ca punct de plecare, chiar dacă data de intrare în vigoare obligatorie pentru saltele în sine nu este încă cunoscută.

Unde să înceapă la alegerea unui sistem

Ordinea practică nu începe cu software-ul, ci cu datele: mai întâi trebuie să fie clar care informații despre produs trebuie să apară în pasaport, înainte de a se uita la modul în care aceste informații sunt stocate și puse la dispoziție din punct de vedere tehnic. După aceea vine întrebarea cum fiecare cod de identificare unic primește, pentru că acel cod este legătura dintre produsul fizic și datele digitale despre acesta. În continuare, este o alegere dacă acel proces este configurat intern sau este externalizat unei părți care asigură stocarea și accesul — aceasta este exact locul unde se potrivește o platformă ca această platformă, prin asamblarea pasaportului din datele furnizate și asigurarea găzduirii și a purtătorului de date QR. Pentru companiile care lucrează deja cu un sistem ERP sau de inventar, este apoi relevant dacă și cum acel sistem poate fi conectat la pasaportul produsului, astfel încât datele să nu trebuie introduse de două ori. Cei care preferă mai întâi o imagine mai largă înainte de a lua o decizie privind sistemul, pot începe și cu întrebarea cum se raportează registrul european al pasapoartelor produselor la pasaportul propriu, pentru că acel registru este o parte obligatorie alături de oricare software ar fi ales.

Aceasta rezultă din articolele 9, 10 și 11 ale ESPR

Baza se găsește în articolul 9 al ESPR (Regulamentul (UE) 2024/1781), care introduce pașaportul digital al produsului ca instrument. Articolul 10 al ESPR detaliază cerințele de conținut pe care trebuie să le îndeplinească un pașaport, fără a prescrie o anumită tehnologie sau furnizor. Articolul 11 al ESPR se referă în mod specific la concepția tehnică și funcționarea pașaportului digital al produsului, menționând cerințe precum interoperabilitatea și utilizarea standardelor deschise — cerințe stabilite pentru rezultat, nu pentru instrumentul cu care se obține acel rezultat. Aceste trei articole arată că regulamentul este structurat funcțional: el reglementează ceea ce trebuie să poată face un pașaport și cum trebuie să fie accesibil, și lasă alegerea software-ului în seama celui care asamblează pașaportul.

Oricine dorește să se pregătească din timp, ar face bine să înceapă prin punerea în ordine a datelor proprii ale produsului și prin determinarea unui sistem de identificare per saltea, astfel încât să existe o bază solidă atunci când se va publica actul delegat pentru saltele — alegerea unui sistem software specific poate urma apoi, în conformitate cu cerințele tehnice aplicabile la acel moment.

Pe ce se bazează aceasta

Regulamentul în sine se află pe EUR-Lex. Facem referință per afirmație; nu trebuie să ne credeți.

Ce trebuie să faceți în mod concret

Ce se așteaptă de la dumneavoastră

Un pașaport care este citibil prin standarde deschise

Articolul 10 al ESPR (Regulamentul (UE) 2024/1781) prevede că pașaportul digital al produsului funcționează pe baza standardelor deschise și interoperabile. Aceasta înseamnă că datele nu trebuie să fie blocate într-un format de fișier închis și proprietar care poate fi deschis doar cu un singur program specific. Pentru un producător de saltele cu 10 până la 100 de angajați, aceasta înseamnă în principal că alegerea unui sistem sau platform trebuie verificată în raport cu această cerință: pot fi extrase datele, și pot fi citite de alte părți fără ca acestea să aibă exact același software ca dumneavoastră?

Accesibilitate prin intermediul unui purtător de date, nu printr-o aplicație

Articolul 11 reglementează modul în care funcționează din punct de vedere tehnic pașaportul: prin intermediul unui purtător de date (în practică, adesea un cod QR) care face referință la date. Consumatorul, autoritatea de supraveghere sau partenerul comercial trebuie să poată consulta acele date fără a fi nevoie de o aplicație separată furnizată de dumneavoastră. Din punct de vedere practic, aceasta înseamnă că un smartphone obișnuit cu cameră și navigator trebuie să fie suficient. Oricine ia în considerare construirea unei aplicații proprii pentru a afișa pașaportul, face acest lucru ca serviciu suplimentar — nu pentru că regulamentul impune o aplicație. Modul în care purtătorul de date ajunge pe produs este descris pe pagina cu privire la cum ajunge codul QR pentru certificatul de produs pe saltelele dvs..

Legătura cu un număr de identificare unic

Articolul 9 leagă pașaportul de o identificare unică a produsului sau modelului. Aceasta necesită o modalitate de a conecta fiecare pașaport la produsul fizic corect. Pentru întreprinderile care lucrează deja cu numere de lot, coduri EAN sau coduri de articol interne, aceasta este de obicei o chestiune de a continua consistent această numerotare existentă în sistemul pașaportului. Modul în care se stabilește această legătură în practică este explicat pe pagina cu privire la cum să acordați fiecărui produs un cod unic de identificare.

Date care rămân actuale și identificabile

Articolele 9 și 10 împreună implică faptul că pașaportul nu este o imagine statică care poate fi uitată după publicare, ci o colecție de date care rămâne legată de un produs specific pe durata în care pașaportul trebuie să fie disponibil. Aceasta cere unei întreprinderi o modalitate de a ști ce informații aparțin fiecărui produs, chiar dacă apar mai târziu întrebări cu privire la o saltea vândută cu câțiva ani în urmă.

Unde merge prost în practică

Un producător lasă un pașaport să fie creat într-un program care funcționează bine, dar furnizorul furnizează datele doar ca PDF sau captură de ecran. Aceasta este lizibilă pentru om, dar nu citibilă de mașină după cum înțelege articolul 10 — datele subiacente trebuie să fie structurat solicitabile, nu doar reprezentate vizual.

O companie dezvoltă o aplicație proprie pentru a afișa pasaportul, presupunând că acest lucru este obligatoriu. Aceasta necesită timp și bani pentru dezvoltare, în timp ce articolul 11 cere accesibilitate fără software special — o pagină web obișnuită care se deschide prin codul QR este suficientă pentru această intenție.

Un importator folosește pentru fiecare livrare un fișier Excel nou, ad-hoc, care este convertit manual într-un pasaport. Odată ce volumul crește, apar erori în cuplarea dintre produs și pasaport, și devine neclar ce pasaport aparține care lot.

Un producător alege un sistem fără a verifica dacă datele pot fi exportate vreodată din acesta. Atunci când se trece mai târziu la o altă platformă, sau dacă furnizorul de găzduire încetează, datele rămân blocate la un singur furnizor. Ceea ce implică acest lucru este descris pe pagina despre ce se întâmplă cu pasapoartele dumneavoastră de produs dacă furnizorul de găzduire se retrage.

O companie crede că sistemul de pasaport trebuie să funcționeze separat de operațiunile proprii și introduce datele de produs dublu: o dată în sistemul ERP, o dată în sistemul de pasaport. Aceasta dublează munca și crește riscul de discrepanțe între cele două surse.

Ceea ce puteți înregistra

Un prezentare generală a formatelor de fișier pe care le utilizează sistemul ales, și dacă acestea sunt deschise și exportabile — aceasta poate fi evaluată în funcție de cerința de interoperabilitate din articolul 10.
O descriere a modului în care purtătorul de date (codul QR) oferă acces la pasaport, fără a fi necesară o aplicație separată, așa cum se prevede în articolul 11.
Un tabel de cuplare între codurile interne de produs și numerele de identificare ale pasaportului, astfel încât în orice moment să se poată urmări ce pasaport aparține cărei produse fizice. Pentru cine dorește să combine sisteme în acest scop, poate consulta posibilitățile descrise pe pagina despre cuplarea pasaportului de produs la un sistem ERP sau de gestionare a inventarului.
Acorduri cu furnizorul de software sau cu platforma privind exportul de date, disponibilitatea pe termen lung și ce se întâmplă la încetarea serviciului.
Un proces intern pentru menținerea datelor de produs, astfel încât modificările în compoziția materialelor sau alte caracteristici să se reflecte consecvent în pasaport, în loc să fie ținute dublu și separat.

Pentru companiile care produc saltele personalizate, este de asemenea bine să stabilească cum sunt procesate variantele individuale în sistemul de pasaport — acest proces diferă adesea de producția standard și este explicat pe pagina despre cum funcționează paşaportul produsului în cazul saltelelor personalizate.

Aceasta nu este sfat juridic. Această pagină furnizează informații generale despre reglementarea pe care se bazează această platformă. Nu cunoaștem situația dvs. În caz de îndoială cu privire la propriul caz, consultați un jurist sau autoritatea competentă de supraveghere.

Redactat cu ajutorul AI pe baza surselor de mai sus, verificat de o persoană pe 2026-09-05. Ceva nu este corect? Anunțați-ne — corecțiile au prioritate.