Comisia Europeană a pus în funcțiune, la 20 iulie 2026, registrul UE pentru pașapoarte digitale de produs și mediul de testare aferent. Astfel, o componentă ESPR abstractă a devenit un sistem pe care companiile îl pot testa efectiv. Pentru producători, este importantă acum mai ales o distincție: registrul este indexul central, iar pașaportul de produs rămâne descentralizat.
Ce a devenit operațional la 20 iulie
Registrul preia identificatori unici ai produselor, date de înregistrare și anumite metadate. Informațiile complete despre produs rămân în continuare la operatorul economic responsabil sau la un furnizor de servicii DPP desemnat. De aceea, Comisia descrie în mod explicit registrul ca pe un serviciu de indexare, nu ca pe un sistem central de gestionare a conținutului.
Înregistrările sunt prevăzute printr-o interfață de utilizator securizată și printr-un API. Companiile pot genera, de asemenea, o dovadă electronică a înregistrării. Acest lucru este relevant pentru procesele B2B, deoarece furnizorii și clienții pot demonstra astfel că un pașaport a fost înregistrat în sistemul UE, fără să duplice întregul set de date.
Lansarea nu vizează doar grupele de produse ESPR. Comisia menționează și baterii, produse pentru construcții, jucării, detergenți și tenside destinate utilizatorilor finali, în măsura în care dreptul Uniunii aplicabil impune un pașaport digital de produs. Primul termen obligatoriu rămâne 18 februarie 2027 pentru anumite baterii.
Registrul, resolverul și sursa de date sunt trei straturi diferite
Un sistem DPP solid ar trebui să separe clar responsabilitățile:
- Registrul UE confirmă că un identificator și metadatele obligatorii sunt înregistrate.
- Un resolver direcționează identificatorul persistent al produsului către resursa corespunzătoare.
- Sursa propriu-zisă a datelor furnizează conținut actualizat pentru oameni și sisteme.
Această separare nu este un detaliu. Cine păstrează toate datele exclusiv pe propria pagină de produs nu are încă o integrare cu registrul. Invers, cine înregistrează doar un identificator nu pune încă la dispoziție un pașaport de produs utilizabil. Cele două trebuie conectate prin identificatori stabili.
Pentru rezoluție este potrivit un link deschis și persistent. Un resolver pentru legături digitale poate face accesibile diferite reprezentări pornind de la același identificator: o pagină web ușor de înțeles, JSON-LD care poate fi citit automat sau documentație suplimentară. Suportul de date de pe produs sau ambalaj rămâne stabil, chiar dacă sistemele țintă evoluează.
Ce ar trebui să verifice companiile în mediul de testare
Mediul de testare nu este destinat doar unui test manual prin clicuri. El ar trebui tratat ca o etapă preliminară a integrării în producție.
Organizație și roluri
Mai întâi trebuie clarificat ce entitate juridică face înregistrarea, cine o reprezintă în sistem și ce echipe au voie să creeze sau să modifice înregistrări. Acest lucru privește datele de bază, conformitatea, departamentul IT și, dacă este cazul, furnizorii externi de servicii. Un acces personal de testare nu înlocuiește un model de roluri pentru operarea ulterioară.
Identificatori și granularitate
Echipa de produs ar trebui să stabilească dacă pașaportul ulterior va fi gestionat la nivel de model, lot sau unitate individuală. Răspunsul depinde de legislația sectorială aplicabilă. Testarea registrului este momentul potrivit pentru a corela ID-urile interne ale produselor, GTINs, identificatorii loturilor și identificatorul persistent utilizat extern.
API și repetabilitate
Un proces de producție are nevoie de mai mult decât un POST reușit. Înregistrarea, actualizarea și tratarea erorilor trebuie să poată fi repetate și să fie jurnalizate. Acestea includ solicitări idempotente, confirmări tehnice și o asociere clară între înregistrarea din ERP, DPP și intrarea din registru. Un proces de DPP bazat pe API reduce abaterile manuale atunci când produsele sunt create în cantități mari.
Separarea metadatelor de datele de specialitate
Datele din registru nu ar trebui să devină o a doua bază de date a produselor. Definiți ce câmpuri sunt necesare în registru și care rămân în pașaportul descentralizat. Pentru fiecare informație este nevoie de o sursă principală, de o entitate responsabilă și de o regulă de actualizare.
Dovadă și monitorizare
Dovezile înregistrărilor ar trebui stocate împreună cu marca temporală, identificatorul utilizat și răspunsul sistemului. Este necesară și o reconciliere: pașaportul există, resolverul este accesibil și mai corespund metadatele din registru cu starea produsului?
De ce vama are nevoie de un lanț propriu de verificare
Registrul sprijină autoritățile vamale să verifice automat, înainte de punerea în liberă circulație, dacă există un DPP înregistrat valabil și codul tarifar necesar. Pentru importatori rezultă o nouă dependență: identificatorul produsului, înregistrarea din registru și declarația vamală trebuie să fie coerente.
Prin urmare, o eroare nu devine vizibilă abia pe o pagină de produs. Ea poate afecta procesul de frontieră. Companiile ar trebui să simuleze încă din etapa de testare fluxurile de date, de la crearea produsului până la documentația de import, și să stabilească cine poate corecta rapid o înregistrare eronată.
Un plan de testare util pentru 30 de zile
- Selectați o entitate juridică reală și un portofoliu restrâns și reprezentativ de produse.
- Documentați pentru fiecare produs granularitatea DPP planificată și identificatorii principali.
- Efectuați un parcurs complet prin interfața de utilizator și, dacă este relevant, prin API.
- Arhivați împreună dovada înregistrării, răspunsul resolverului și datele despre produs care pot fi citite automat.
- Testați cazuri de eroare: identificator duplicat, metadate învechite, gazdă de date inaccesibilă și produs retras.
- Pe baza rezultatelor, definiți un model operațional cu responsabilități, monitorizare și cale de escaladare.
Punerea în funcțiune a registrului nu înseamnă încă faptul că toate cerințele sectoriale privind datele se aplică deja integral. Ea mută însă discuția de la prezentări la fluxuri verificabile. Companiile pot identifica acum dacă identificatorii, rolurile și API-urile lor sunt compatibile, înainte de intrarea în vigoare a primelor termene obligatorii.
