DPP: Jak utrzymywać dane aktualne zgodnie z wymogami ESPR

Jak prawidłowo aktualizować dane Digital Product Passport zgodnie z ESPR: poziom partii i produktu, obowiązki rejestrowe oraz wskazówki architektoniczne.

autor: QR3 Redaktion

DPP: Jak utrzymywać dane aktualne zgodnie z wymogami ESPR

Od czasu przyjęcia ESPR-rozporządzenia (UE) 2024/1781 Digital Product Passport (DPP) stanowi obowiązujące prawo UE. Wiele przedsiębiorstw nie docenia tego, że DPP nie jest statycznym dokumentem tworzonym raz, w momencie wprowadzenia produktu na rynek. Należy go aktualizować przez cały cykl życia produktu — a wymagania w tym zakresie stają się coraz bardziej precyzyjne.

Ten artykuł wyjaśnia, jakie dane i kiedy należy aktualizować, jak architektura rejestru wpływa na model aktualizacji oraz jakie wzorce techniczne sprawdzają się w praktyce.

Co rozporządzenie mówi o cyklu aktualizacji

Statyczne i dynamiczne pola danych

Samo ESPR nie określa wyraźnej częstotliwości aktualizacji, ale stanowi, że DPP musi zawierać „aktualne i dokładne informacje”. Uszczegółowienie następuje na poziomie sektorowym — a projekt JRC dotyczący półproduktów z żelaza i stali przedstawia jak dotąd najbardziej klarowny obraz.

Projekt systematycznie rozróżnia dwa poziomy szczegółowości danych:

Poziom Identyfikator Przykładowe dane Powód aktualizacji
Poziom partii (Lot) Numer partii Udział materiału z recyklingu, skład stopu, PCF zgodnie z ISO 14067 Zmiana w produkcji, nowa partia
Poziom produktu (Item) Numer seryjny Wymiary, certyfikaty, deklaracje zgodności Ponowna certyfikacja, wycofanie produktu, naprawa

To rozróżnienie ma kluczowe znaczenie dla architektury bazy danych: dane partii są zazwyczaj zapisywane raz dla każdego przebiegu produkcyjnego i pozostają stabilne — chyba że ponowne obliczenie śladu węglowego przyniesie skorygowaną wartość. Dane na poziomie produktu mogą natomiast zmieniać się przez cały okres użytkowania, na przykład gdy urządzenie zostanie naprawione lub certyfikacja odnowiona.

Rozporządzenie w sprawie baterii (UE) 2023/1542 już pośrednio uwzględnia to rozróżnienie: dane dotyczące pojemności, które zmieniają się w wyniku degradacji, muszą być aktualne — jest to wymaganie trudne do spełnienia bez klarownej architektury.

Rejestr jako katalog, a nie magazyn danych

Częste nieporozumienie dotyczy roli centralnego rejestru DPP. Projekt rozporządzenia wykonawczego dotyczącego rejestru DPP jasno stwierdza: rejestr przechowuje wyłącznie unikatowy identyfikator, punkt końcowy resolvera i kod towarowy — nie zaś właściwe dane paszportu.

Oznacza to dla zarządzania aktualizacjami, że treść paszportu i rejestr są odrębnymi systemami. Aktualizując dane produktu, zasadniczo nie trzeba modyfikować rejestru — chyba że zmieni się punkt końcowy resolvera, na przykład w wyniku zmiany systemu. Konsorcjum CIRPASS-2 wyraźnie wskazało ten wzorzec architektoniczny w swoim stanowisku dotyczącym projektu rejestru i zaleca włączenie normy EN 18219 do rozporządzenia wykonawczego jako wiążącego odniesienia — między innymi w celu zapewnienia interoperacyjności z GS1 Digital Link.

Scenariusze aktualizacji w praktyce

Scenariusz 1: Nowy ślad węglowy wskutek zmiany dostawcy

Ślad węglowy produktu (PCF) jest zgodnie z projektem JRC dotyczącym stali utrzymywany na poziomie partii i musi być obliczany z zastosowaniem metod zgodnych z ISO 14067. Jeśli producent stali zmieni nośnik energii lub dostawcę złomu, PCF nowej partii ulegnie zmianie — ale nie PCF partii już dostarczonych.

Technicznie oznacza to, że rekord DPP starej partii pozostaje niezmieniony. Dla nowej partii tworzony jest nowy rekord, który może korzystać z tego samego punktu końcowego resolvera, ale ma nowy numer partii jako identyfikator.

# 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}
  }'

Scenariusz 2: Wygasająca certyfikacja na poziomie produktu

Deklaracje zgodności i certyfikaty mają daty ważności. Po wystawieniu nowego certyfikatu należy zaktualizować DPP na poziomie produktu. Ponieważ punkt końcowy resolvera pozostaje niezmieniony, aktualizacja rejestru nie jest potrzebna — zmienia się tylko rekord znajdujący się za tym punktem końcowym.

// 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,
  });
}

Scenariusz 3: Migracja resolvera przy zmianie systemu

Jeśli przedsiębiorstwo zmieni dostawcę usługi DPP, zmieni się punkt końcowy resolvera. W takim przypadku rejestr trzeba zaktualizować — dla każdego objętego zmianą identyfikatora. Jest to najbardziej pracochłonny typ aktualizacji, ponieważ wymaga zapisu w rejestrze.

Zalecenie: należy korzystać ze stabilnego, własnego resolvera (np. dpp.ihrunternehmen.de) jako warstwy pośredniej, która wewnętrznie przekierowuje do właściwego dostawcy. Dzięki temu punkt końcowy zapisany w rejestrze pozostaje trwale stabilny.

Wymagania techniczne wobec systemu aktualizacji

Wersjonowanie i ścieżka audytu

ESPR nie wymaga wyraźnie wersjonowania, ale połączenie odpowiedzialności za produkt i kontroli celnej sprawia, że ścieżka audytu jest w praktyce niezbędna. Jeśli w 2030 roku celnik sprawdza DPP stalowej belki wyprodukowanej w 2027 roku, musi być możliwe ustalenie, jakie dane obowiązywały w momencie przywozu.

Minimalny schemat dla wersjonowanej tabeli DPP:

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 wyraźnie rozdziela identyfikator i resolver: kod QR na produkcie koduje adres URL, taki jak https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, który za pośrednictwem resolvera GS1 lub własnego resolvera wskazuje aktualny rekord DPP. Aktualizacje rekordu nie wymagają ponownego etykietowania — fizyczny nośnik pozostaje niezmieniony.

Firma TEKLYNX zaktualizowała swoje oprogramowanie CODESOFT i obecnie obsługuje schematy kodowania GS1 „++”, umożliwiające bezpośredni zapis adresów URL do pamięci znaczników RAIN-RFID — jest to wymaganie wynikające z połączenia normy EN 18220 i standardu GS1 Digital Link.

Ład organizacyjny: kto może co aktualizować?

Oprócz kwestii technicznej pojawia się pytanie dotyczące ładu organizacyjnego: którzy uczestnicy łańcucha dostaw mogą zapisywać poszczególne pola DPP? Konsorcjum CIRPASS-2 wskazało w tym zakresie krytyczne kwestie suwerenności danych w transgranicznych łańcuchach dostaw.

Praktyczny model rozróżnia trzy role:

  • Producent (Creator): Zapisuje wszystkie pola podczas tworzenia; może aktualizować wszystkie pola.
  • Upoważniony uczestnik (Editor): Może aktualizować określone pola, np. historię napraw i nowe certyfikaty — z dokumentacją zawierającą jego własny identyfikator.
  • Czytelnik (Reader): Może odczytywać wszystkie pola publiczne, ale nie ma uprawnień do zapisu.

Ecommerce Europe zażądało w swoim stanowisku dotyczącym wdrożenia DPP, aby również dla produktów używanych możliwe były „częściowe DPPs” — czyli rekordy aktualizujące tylko część pierwotnych pól. Jest to już dziś technicznie wykonalne, ale nadal brakuje tej kategorii jako formalnego rozwiązania w rozporządzeniach wykonawczych.

Podsumowanie

Utrzymywanie danych DPP aktualnych nie jest jednorazowym zadaniem, lecz procesem operacyjnym. Najważniejsze wnioski z obecnego stanu regulacyjnego:

  1. Należy rozdzielić partię i produkt — strategia identyfikatorów określa, które dane i kiedy trzeba aktualizować.
  2. Rejestr nie jest magazynem danych — aktualizacje treści paszportu z reguły nie wymagają zapisu w rejestrze.
  3. Wersjonowanie jest faktycznie obowiązkowe — nawet jeśli rozporządzenie nie wymaga go wyraźnie.
  4. GS1 Digital Link oddziela fizyczny nośnik od rekordu — znacznie ogranicza to nakład pracy przy aktualizacjach danych.
  5. Role w ramach ładu organizacyjnego należy zdefiniować z wyprzedzeniem — kto może co zapisywać i jak jest to rejestrowane?

Normy stają się coraz bardziej precyzyjne, a pierwsze pilotaże już trwają — właściwe przygotowanie architektury pozwoli uniknąć kosztownych korekt, gdy wejdą w życie sektorowe rozporządzenia wykonawcze.

Źródła