Pot cuplați pasaportul digital al produsului la sistemul meu ERP sau de inventar?

Cuplarea devine concretă doar atunci când există standardul tehnic

O cuplare directă între pașaportul digital al produsului și un sistem ERP sau de gestionare a stocurilor nu este posibilă în acest moment, deoarece specificațiile tehnice pentru aceasta nu au fost încă stabilite. ESPR (Regulamentul (UE) 2024/1781) stabilește totuși fundamentele în articolul 10 și articolul 11: pașaportul trebuie să fie interoperabil, bazat pe standarde deschise și citibil de mașini. Aceasta înseamnă că schimbul automat cu sisteme de afaceri va fi în cele din urmă punctul de plecare, nu o excepție. Însă modul în care acest schimb arată în practică — ce format de fișier, ce interfață, ce drepturi de acces — urmează abia din actele delegate per grup de produse. Pentru fier și oțel, acest act nu există încă.

Pentru ce aceasta se aplică și pentru ce nu

Aceasta privește întrebarea dacă sistemele vor putea prelua automat date din pașaport sau vor putea rescrie în el. Aceasta afectează structura tehnică a pașaportului însuși, așa cum este descrisă în regulament: cum este construit, cine are acces la el și sub ce formă sunt disponibile datele. Nu privește întrebarea dacă un pachet ERP specific este potrivit, nici nu privește o API concretă sau un format de date — aceste alegeri nu au fost încă făcute. De asemenea, nu privește obligația în sine de a avea un pașaport; acesta este un subiect separat care va fi completat per grup de produse. Ceea ce este descris aici este exclusiv principiul că pașaportul trebuie să fie citibil de mașini și interoperabil — modul în care acest principiu devine concret pentru fier și oțel rămâne deschis.

Încă nicio dată fixă, încă niciun standard tehnic fix

Nu există încă o dată la care un standard de cuplare tehnică pentru fier și oțel intră în vigoare, deoarece acel standard face parte din actul delegat care urmează să apară. Conform planului de lucru al ESPR pentru perioada 2025-2030, se preconizează ca primul act delegat să apară în 2026, cu obligații care au o perioadă de tranziție de optsprezece luni după aceea. Până în momentul în care actul acesta apare, este stabilit faptul că pașaportul trebuie să fie interoperabil și citibil de mașini (articolele 10 și 11), dar nu și modul în care aceasta va fi implementată din punct de vedere tehnic. Până în acel moment, pașaportul funcționează în practică ca un document care trebuie consultat de o persoană prin intermediul QR-data carrier-ului, nu ca un flux de date automat către un sistem extern.

Ce înseamnă aceasta pentru abordare

Pentru cine gândește deja acum la cuplarea cu propriul sistem, ordinea este următoarea. În primul rând: nu trebuie să se construiască nimic încă, deoarece nu există niciun standard de urmat. În al doilea rând: aducerea propriilor date de produs în ordine este utilă chiar acum, indiferent de forma tehnică finală — un set clar și consistent de date per produs (origine, compoziție, certificate) este baza pe care va sprijini orice viitor mecanism de cuplare. În al treilea rând: de îndată ce actul delegat pentru fier și oțel apare, va deveni clar ce format și ce metodă de acces se aplică, și abia atunci se poate proiecta o cuplare concretă. În al patrulea rând: până atunci, pașaportul rămâne consultabil prin codul QR atașat produsului, ceea ce pentru majoritatea tranzacțiilor zilnice în comerțul cu oțel și procesarea metalelor este deja suficient — cuplarea cu un sistem ERP este atunci o îmbunătățire a eficienței pentru mai târziu, nu o condiție pentru a putea lucra acum cu pașaportul.

De unde urmează aceasta: articolele 10 și 11 ale ESPR

Articolul 10 al Regulamentului (UE) 2024/1781 (ESPR) descrie cerințele pe care trebuie să le îndeplinească pasaportul digital al produsului, inclusiv interoperabilitatea și utilizarea standardelor deschise. Articolul 11 tratează proiectarea tehnică și funcționarea pasaportului, cum ar fi registrele, accesul la date și modul în care funcționează pasaportul. Ambele articole conțin principiul că pasaportul trebuie să fie potrivit pentru prelucrarea automată, dar aplicarea acestuia — specificația tehnică efectivă pe grup de produse — este lăsată actelor delegate care urmează să apară. Pentru formularea precisă, textul oficial al regulamentului este orientativ.

Dacă dorești acum să sorezi în avans, cel mai bine este să menții propriile date de produs deja structurate și complete, pentru ca în momentul în care apare standardul tehnic să poată fi conectate fără prea mult efort la ceea ce va fi stabilit atunci. Această pagină va fi actualizată de îndată ce actul delegat pentru fier și oțel va fi publicat și vor fi cunoscute detaliile tehnice.

Baza acestui material

Regulamentul însuși se găsește pe EUR-Lex. Facem referiri pentru fiecare afirmație; nu trebuie să ne crezi pe cuvânt.

Ceea ce trebuie să faceți în mod concret

Ceea ce se așteaptă de la dumneavoastră

Datele trebuie să fie lizibile de mașină și transferabile

Articolul 10 al ESPR (Regulamentul (UE) 2024/1781) prevede că datele din pașaportul digital al produsului trebuie să fie disponibile într-un format structurat, lizibil de mașină. Acesta este chiar punctul de plecare pentru conectarea cu propriul sistem: datele care sunt lizibile de mașină sunt, în principiu, potrivite și pentru a trece automat în sau din sistemul ERP sau de gestionare a inventarului. Pentru o întreprindere cu 10 până la 100 de angajați, acest lucru înseamnă mai ales că întrebarea "poate fi conectat" nu este în primul rând o întrebare juridică, ci o întrebare tehnică: ce format folosește pașaportul și poate software-ul propriu să citească sau să scrie în acel format. Vezi și pagina despre în ce format trebuie să furnizez datele pentru pasaportul de produs.

Pașaportul trebuie să fie conform unei structuri tehnice uniforme

Articolul 11 al ESPR tratează proiectarea tehnică și funcționarea pașaportului și face trimitere la specificațiile tehnice pe care Comisia le va detalia în continuare. Pentru practica conectării, aceasta înseamnă că nu se poate furniza sau prelua pur și simplu "un fișier propriu": se află o structură standardizată dedesubt, probabil bazată pe sisteme de identificare existente. Cine lucrează deja cu un sistem pentru codarea articolelor ar trebui să verifice cum se conectează aceasta la modul în care vor fi atribuite mai târziu codurile de identificare unice — vezi cum atribui fiecărui produs un cod de identificare unic". Un sistem ERP care funcționează deja cu coduri de produs univoce și stabile are perspective mai bune pentru conectare decât un sistem în care codurile diferă pentru fiecare comandă sau client.

Conectarea se realizează printr-o purtător de date, nu printr-o conexiune directă la bază de date

Articolul 11 descrie, de asemenea, că pașaportul este accesibil printr-un purtător de date pe produs. Acesta este un punct important pentru așteptările pe care le poate avea o întreprindere cu privire la "conectare": nu este vorba despre o conexiune directă la baza de date între două întreprinderi, ci despre un lanț în care purtătorul de date (de obicei un cod QR) trimite la un pașaport stocat. Conectarea cu un sistem ERP sau de gestionare a inventarului se află deci la două capete: la furnizarea datelor produsului din propriul sistem către partea care asamblează pașaportul și la citirea datelor pașaportului (de exemplu, la achiziționarea oțelului) în propriul sistem. Mai multe informații despre acel purtător sunt pe pagina cum ajunge codul QR pentru pașaportul produsului pe oțelul meu.

Datele trebuie să rămână actuale atât timp cât pașaportul există

Din articolul 10 rezultă și că datele din pașaport trebuie să fie corecte și actuale atât timp cât pașaportul există. Pentru o conectare cu un sistem de gestionare a inventarului, aceasta înseamnă că furnizarea unică de obicei nu este suficientă: dacă proprietățile unei partide de oțel se schimbă sau dacă se descoperă o eroare, trebuie să existe o modalitate de a comunica acest lucru locului în care pașaportul este găzduit. Întreprinderile care conectează sistemul ERP trebuie să se gândească și la cât timp trebuie menținută acea actualitate — vezi cât timp trebuie să rămână disponibil un pașaport de produs.

Unde nu funcționează în practică

Codurile interne ale articolelor sunt confundate cu identificarea oficială a produsului. Un sistem ERP cunoaște un produs sub un SKU intern, în timp ce pașaportul necesită un cod de identificare diferit și unic. Fără o tabel de traducere între cele două, apare confuzie la conectare, mai ales dacă un cod intern acoperă mai multe loturi.

Mutările de inventar nu sunt implementate în datele pașaportului. Un sistem de gestionare a inventarului înregistrează, de exemplu, că o partidă de oțel a fost retopită, divizată sau combinată, dar acea schimbare nu ajunge automat la pașaport. Aceasta joacă un rol important în răspunsul la întrebarea dacă oțelul este înregistrat per lot sau per bucată — vezi înregistrez oțelul per lot sau per bucată — deoarece unitatea de înregistrare din sistemul ERP trebuie să se alinieze cu unitatea pe care se bazează pașaportul.

Fișierele exportate din sistemul ERP nu sunt conforme cu formatul cerut. Multe pachete ERP exportă în mod implicit în Excel, CSV sau o structură XML proprie. Fără o coordonare prealabilă, un asemenea fișier se dovedește a nu fi compatibil cu formatul necesar pentru pasaport, cu întârziere și muncă suplimentară ca rezultat.

Se presupune că legătura funcționează și fără conexiune la internet. Unele sisteme de inventar pe teren funcționează parțial offline, de exemplu pe un terminal de depozit. Aceasta ridică întrebarea dacă pasaportul în sine trebuie să fie consultabil și fără conexiune; aceasta este o întrebare separată care se află în afara legăturii cu sistemul ERP. Vezi trebuie ca pasaportul de produs să funcționeze și fără conexiune la internet.

Drepturile de acces între sisteme nu sunt reglementate. O legătură înseamnă că datele curg între două sau mai multe sisteme, adesea prin intermediul unui terț care găzduiește pasaportul. Dacă nu este clar cine are dreptul să vadă, să modifice sau să transmită anumite date, apare ambiguitate cu privire la responsabilitate în caz de eroare — o întrebare care se referă la modul în care datele sunt securizate în tranzit, vezi cum mă asigur că datele din pasaportul de produs sunt securizate.

Ce puteți documenta

Un inventar al câmpurilor din sistemul ERP sau de inventar care corespund câmpurilor din pasaportul de produs, inclusiv un tabel de traducere între codurile de articole interne și codul unic de identificare al produsului.
O descriere a formatului de export pe care sistemul propriu îl utilizează, și o comparație cu formatul necesar pentru pasaport.
Acorduri cu terța parte care compune sau găzduiește pasaportul cu privire la frecvența și modul schimbului de date: o singură dată la creație, sau continuu la modificări.
O procedură pentru transmiterea modificărilor în inventar, grupare de loturi sau proprietăți de produs la datele pasaportului, inclusiv cine este responsabil pentru aceasta.
Un inventar al persoanelor din cadrul companiei care au acces la legătura dintre sistemul propriu și pasaport, și ce drepturi sunt asociate.
Un acord stabilit cu privire la ceea ce se întâmplă cu legătura și fluxul de date dacă pasaportul pentru un produs este modificat, retras sau înlocuit.

Aceasta nu este o consultanță juridică. Această pagină oferă informații generale despre reglementarea pe care se bazează această platformă. Nu cunoaștem situația dvs. În caz de îndoieli privind situația dvs. specifică, consultați un jurist sau autoritatea competentă de supraveghere.

Scris cu AI pe baza surselor de mai sus, verificat de o persoană pe 2026-08-22. Ceva nu este în regulă? Spune-ne — corecțiile au prioritate.