DPP-Menținerea actualizată a datelor: Ce prevede cu adevărat ESPR

De la adoptarea ESPR-Regulamentului (UE) 2024/1781, pașaportul digital al produsului (DPP) face parte din legislația obligatorie a UE. Ceea ce multe companii subestimează: DPP nu este un document static, generat o singură dată la lansarea pe piață. Acesta trebuie menținut actualizat pe întregul ciclu de viață al produsului — iar cerințele în acest sens devin tot mai precise.

Acest articol explică ce date trebuie actualizate și când, cum influențează arhitectura registrului modelul de actualizare și ce modele tehnice se dovedesc eficiente în practică.

Ce spune regulamentul despre ciclul de actualizare

Câmpuri de date statice vs. dinamice

ESPR în sine nu menționează o frecvență explicită de actualizare, dar stabilește că DPP trebuie să conțină „informații actuale și exacte”. Concretizarea are loc la nivel sectorial — iar proiectul JRC pentru produse semifabricate din fier și oțel oferă până acum cea mai clară imagine.

Proiectul face distincție sistematică între două niveluri de granularitate a datelor:

Nivel	Identificator	Date exemplificative	Eveniment de actualizare
Nivel de lot (Lot)	Număr de lot	Proporția de material reciclat, compoziția aliajului, PCF conform ISO 14067	La modificarea producției, la un lot nou
Nivel de produs (Item)	Număr de serie	Dimensiuni, certificări, declarații de conformitate	La recertificare, retragere, reparație

Această distincție este esențială pentru arhitectura bazei de date: datele despre lot sunt de regulă scrise o singură dată pentru fiecare ciclu de producție și rămân apoi stabile — cu excepția cazului în care recalcularea amprentei de CO₂ produce o valoare corectată. În schimb, datele la nivel de produs se pot modifica pe întreaga durată de utilizare, de exemplu atunci când un dispozitiv este reparat sau când o certificare este reînnoită.

Regulamentul privind bateriile (UE) 2023/1542 recunoaște deja implicit această distincție: datele privind capacitatea, care se modifică prin degradare, trebuie menținute actualizate — o cerință greu de îndeplinit fără o arhitectură clară.

Registrul ca director, nu ca depozit de date

O neînțelegere frecventă privește rolul DPP central. Proiectul regulamentului de punere în aplicare privind DPP precizează clar: registrul stochează exclusiv identificatorul unic, punctul final al resolverului și codul de marfă — nu datele propriu-zise ale pașaportului.

Aceasta înseamnă pentru gestionarea actualizărilor că datele pașaportului și registrul sunt sisteme separate. Cine actualizează datele produsului nu trebuie, de regulă, să modifice registrul — cu excepția cazului în care se schimbă punctul final al resolverului (de exemplu, la schimbarea sistemului). Consorțiul CIRPASS-2 a evidențiat explicit acest model arhitectural în poziția sa privind proiectul de registru și recomandă includerea standardului EN 18219 ca referință obligatorie în regulamentul de punere în aplicare — printre altele, pentru a asigura interoperabilitatea cu GS1 Digital Link.

Scenarii de actualizare în practică

Scenariul 1: O nouă amprentă de CO₂ ca urmare a schimbării furnizorului

Amprenta de CO₂ specifică produsului (PCF) este gestionată, conform proiectului JRC privind oțelul, la nivel de lot și trebuie calculată prin metode compatibile cu ISO 14067. Dacă un producător de oțel își schimbă sursa de energie sau furnizorul de deșeuri metalice, PCF-ul noului lot se modifică — nu însă și cel al loturilor deja livrate.

Tehnic, aceasta înseamnă că înregistrarea DPP vechiului lot rămâne neschimbată. Pentru noul lot se creează o înregistrare nouă, care poate utiliza același punct final al resolverului, dar are un număr de lot nou ca identificator.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scenariul 2: Expirarea certificării la nivel de produs

Declarațiile de conformitate și certificările au date de expirare. De îndată ce este emisă o certificare nouă, DPP trebuie actualizat la nivel de produs. Deoarece punctul final al resolverului rămâne neschimbat, nu este necesară o actualizare a registrului — se modifică doar înregistrarea din spatele punctului final.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scenariul 3: Migrarea resolverului la schimbarea sistemului

Dacă o companie își schimbă furnizorul de servicii DPP, punctul final al resolverului se modifică. În acest caz, registrul trebuie actualizat — pentru fiecare identificator afectat. Acesta este cel mai costisitor tip de actualizare, deoarece necesită o scriere în registru.

Recomandare: utilizați un resolver stabil, propriu (de exemplu dpp.ihrunternehmen.de) ca strat intermediar, care redirecționează intern către furnizorul respectiv. Astfel, punctul final înregistrat în registru rămâne stabil pe termen lung.

Cerințe tehnice pentru sistemul de actualizare

Versionare și pistă de audit

ESPR nu impune o versionare explicită, însă combinația dintre răspunderea pentru produse și controlul vamal face ca o pistă de audit să fie, practic, inevitabilă. Dacă în 2030 un funcționar vamal verifică DPP al unei grinzi de oțel produse în 2027, trebuie să poată fi urmărite datele valabile la momentul importului.

Schemă minimă pentru un tabel DPP cu versionare:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link ca ancoră stabilă a identificatorului

GS1 Digital Link separă clar identificatorul de resolver: codul QR de pe produs codifică un URL precum https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, care indică, prin resolverul GS1 sau printr-un resolver propriu, înregistrarea DPP actuală. Actualizările înregistrării nu necesită o nouă etichetare — suportul fizic rămâne neschimbat.

TEKLYNX și-a actualizat software-ul CODESOFT și acceptă acum scheme de codificare GS1 „++”, cu care URL-urile web pot fi scrise direct în memoria tagurilor RAIN-RFID — o cerință care rezultă din combinația dintre EN 18220 și standardul GS1 Digital Link.

Guvernanță: cine are dreptul să actualizeze ce?

Pe lângă aspectul tehnic, se pune și problema guvernanței: ce actori din lanțul de aprovizionare au dreptul să scrie ce câmpuri ale DPP? Consorțiul CIRPASS-2 a identificat aici puncte critice privind suveranitatea datelor în lanțurile de aprovizionare transfrontaliere.

Un model practic diferențiază trei roluri:

Producător (Creator): Scrie toate câmpurile la creare; poate actualiza toate câmpurile.
Actor autorizat (Editor): Poate actualiza câmpuri definite (de exemplu, istoricul reparațiilor, certificări noi) — documentat cu propriul identificator.
Cititor (Reader): Poate citi toate câmpurile publice, fără drepturi de scriere.

Ecommerce Europe a solicitat în documentul său de poziție privind implementarea DPP ca și pentru produsele second-hand să fie posibile „DPPs parțiale” — adică înregistrări care actualizează doar o parte dintre câmpurile inițiale. Acest lucru poate fi deja implementat tehnic, dar încă lipsește ca categorie formală în regulamentele de punere în aplicare.

Concluzie

Menținerea actualizată a datelor DPP nu este o activitate unică, ci un proces operațional. Principalele concluzii ale cadrului de reglementare actual:

Separați lotul de produs — strategia identificatorilor stabilește ce date trebuie actualizate și când.
Registrul nu este un depozit de date — actualizările conținutului pașaportului nu necesită, de regulă, o scriere în registru.
Versionarea este, practic, obligatorie — chiar dacă regulamentul nu o impune explicit.
GS1 Digital Link decuplează suportul fizic de înregistrare — ceea ce reduce semnificativ efortul de actualizare a datelor.
Rolurile de guvernanță trebuie definite în prealabil — cine are dreptul să scrie ce și cum este consemnat acest lucru?

Standardele devin mai precise, primele proiecte-pilot sunt în desfășurare — cei care își configurează corect arhitectura acum vor evita corecții costisitoare atunci când vor intra în vigoare regulamentele de punere în aplicare specifice sectoarelor.