Διατηρώντας τα DPP επικαιροποιημένα: Τι προβλέπει πραγματικά η ESPR

Από την έγκριση της ESPR-Verordnung (EU) 2024/1781, το Digital Product Passport (DPP) αποτελεί δεσμευτικό δίκαιο της ΕΕ. Αυτό που πολλές επιχειρήσεις υποτιμούν είναι ότι το DPP δεν είναι ένα στατικό έγγραφο που δημιουργείται μία φορά κατά την κυκλοφορία του προϊόντος στην αγορά. Πρέπει να διατηρείται επικαιροποιημένο καθ’ όλη τη διάρκεια ζωής του προϊόντος — και οι σχετικές απαιτήσεις γίνονται ολοένα πιο συγκεκριμένες.

Αυτό το άρθρο εξηγεί ποια δεδομένα πρέπει να επικαιροποιούνται και πότε, πώς η αρχιτεκτονική Registry επηρεάζει το μοντέλο ενημερώσεων και ποια τεχνικά πρότυπα αποδεικνύονται αποτελεσματικά στην πράξη.

Τι προβλέπει ο κανονισμός για τον κύκλο ενημερώσεων

Στατικά και δυναμικά πεδία δεδομένων

Η ESPR δεν καθορίζει η ίδια ρητή συχνότητα ενημερώσεων, ορίζει όμως ότι το DPP πρέπει να περιέχει «επίκαιρες και ακριβείς πληροφορίες». Η εξειδίκευση γίνεται σε επίπεδο κλάδου — και εδώ το σχέδιο JRC για ημιτελή προϊόντα από σίδηρο και χάλυβα παρέχει μέχρι σήμερα την πιο σαφή εικόνα.

Το σχέδιο διακρίνει συστηματικά δύο επίπεδα κοκκώδους ανάλυσης δεδομένων:

Επίπεδο	Αναγνωριστικό	Ενδεικτικά δεδομένα	Αφορμή ενημέρωσης
Επίπεδο παρτίδας (Lot)	Αριθμός παρτίδας	Ποσοστό ανακυκλωμένου υλικού, σύσταση κράματος, PCF κατά ISO 14067	Αλλαγή στην παραγωγή, νέα παρτίδα
Επίπεδο προϊόντος (Item)	Σειριακός αριθμός	Διαστάσεις, πιστοποιήσεις, δηλώσεις συμμόρφωσης	Νέα πιστοποίηση, ανάκληση, επισκευή

Η διάκριση αυτή είναι καθοριστική για την αρχιτεκτονική της βάσης δεδομένων: Τα δεδομένα παρτίδας συνήθως καταγράφονται μία φορά ανά παραγωγική διαδικασία και στη συνέχεια παραμένουν σταθερά — εκτός αν ένας νέος υπολογισμός του αποτυπώματος CO₂ οδηγήσει σε διορθωμένη τιμή. Αντίθετα, τα δεδομένα σε επίπεδο προϊόντος μπορούν να αλλάξουν καθ’ όλη τη διάρκεια χρήσης, για παράδειγμα όταν μια συσκευή επισκευάζεται ή ανανεώνεται μια πιστοποίηση.

Ο Κανονισμός για τις μπαταρίες (ΕΕ) 2023/1542 αναγνωρίζει ήδη έμμεσα αυτή τη διάκριση: Τα δεδομένα χωρητικότητας, τα οποία μεταβάλλονται λόγω υποβάθμισης, πρέπει να διατηρούνται επικαιροποιημένα — απαίτηση που δύσκολα μπορεί να εκπληρωθεί χωρίς σαφή αρχιτεκτονική.

Το Registry ως κατάλογος και όχι ως αποθήκη δεδομένων

Μια συχνή παρανόηση αφορά τον ρόλο του κεντρικού DPP-Registry. Το σχέδιο εκτελεστικού κανονισμού για το DPP-Registry διευκρινίζει: Το Registry αποθηκεύει αποκλειστικά το μοναδικό αναγνωριστικό, το endpoint του resolver και τον κωδικό εμπορεύματος — όχι τα ίδια τα δεδομένα του διαβατηρίου.

Αυτό σημαίνει για τη διαχείριση ενημερώσεων ότι: Το περιεχόμενο του διαβατηρίου και το Registry είναι ξεχωριστά συστήματα. Όποιος επικαιροποιεί δεδομένα προϊόντος, κατά κανόνα δεν χρειάζεται να αγγίξει το Registry — εκτός αν αλλάξει το endpoint του resolver (για παράδειγμα, σε περίπτωση αλλαγής συστήματος). Η κοινοπραξία CIRPASS-2 επισήμανε ρητά αυτό το αρχιτεκτονικό πρότυπο στη θέση της για το σχέδιο Registry και συνιστά την ένταξη του προτύπου EN 18219 ως δεσμευτικής αναφοράς στον εκτελεστικό κανονισμό — μεταξύ άλλων, για να διασφαλιστεί η διαλειτουργικότητα με το GS1 Digital Link.

Σενάρια ενημερώσεων στην πράξη

Σενάριο 1: Νέο αποτύπωμα CO₂ λόγω αλλαγής προμηθευτή

Το ειδικό για το προϊόν αποτύπωμα άνθρακα (PCF) τηρείται, σύμφωνα με το σχέδιο JRC για τον χάλυβα, σε επίπεδο παρτίδας και πρέπει να υπολογίζεται με μεθόδους συμβατές με το ISO 14067. Αν ένας παραγωγός χάλυβα αλλάξει ενεργειακό φορέα ή προμηθευτή παλιοσιδήρου, αλλάζει το PCF της νέας παρτίδας — όχι όμως των παρτίδων που έχουν ήδη παραδοθεί.

Τεχνικά αυτό σημαίνει ότι: Η εγγραφή DPP της παλιάς παρτίδας παραμένει αμετάβλητη. Για τη νέα παρτίδα δημιουργείται νέα εγγραφή, η οποία μπορεί να χρησιμοποιεί το ίδιο endpoint του resolver, αλλά φέρει νέο αριθμό παρτίδας ως αναγνωριστικό.

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

Σενάριο 2: Λήξη πιστοποίησης σε επίπεδο προϊόντος

Οι δηλώσεις συμμόρφωσης και οι πιστοποιήσεις έχουν ημερομηνίες λήξης. Μόλις εκδοθεί νέα πιστοποίηση, πρέπει να επικαιροποιηθεί το DPP σε επίπεδο προϊόντος. Καθώς το endpoint του resolver παραμένει αμετάβλητο, δεν απαιτείται ενημέρωση του Registry — αλλάζει μόνο η εγγραφή πίσω από το endpoint.

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

Σενάριο 3: Μετεγκατάσταση του resolver σε περίπτωση αλλαγής συστήματος

Αν μια επιχείρηση αλλάξει πάροχο υπηρεσιών DPP, αλλάζει το endpoint του resolver. Σε αυτή την περίπτωση πρέπει να ενημερωθεί το Registry — για κάθε επηρεαζόμενο αναγνωριστικό. Αυτός είναι ο πιο απαιτητικός τύπος ενημέρωσης, επειδή απαιτεί εγγραφή στο Registry.

Σύσταση: Χρησιμοποιήστε έναν σταθερό, δικό σας resolver (π.χ. dpp.ihrunternehmen.de) ως ενδιάμεσο επίπεδο, ο οποίος προωθεί εσωτερικά τα αιτήματα στον εκάστοτε πάροχο. Έτσι, το endpoint που είναι καταχωρισμένο στο Registry παραμένει μόνιμα σταθερό.

Τεχνικές απαιτήσεις για το σύστημα ενημερώσεων

Εκδόσεις και ίχνος ελέγχου

Η ESPR δεν απαιτεί ρητή διαχείριση εκδόσεων, όμως ο συνδυασμός ευθύνης προϊόντος και τελωνειακού ελέγχου καθιστά πρακτικά απαραίτητο ένα ίχνος ελέγχου. Αν ένας τελωνειακός υπάλληλος ελέγξει το DPP ενός χαλύβδινου δοκαριού που παρήχθη το 2027, το 2030, πρέπει να μπορεί να διαπιστωθεί ποια δεδομένα ίσχυαν κατά την εισαγωγή.

Ελάχιστο σχήμα για έναν πίνακα 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 ως σταθερό σημείο αγκύρωσης αναγνωριστικού

Το GS1 Digital Link διαχωρίζει καθαρά το αναγνωριστικό από τον resolver: Ο κωδικός QR στο προϊόν κωδικοποιεί μια URL όπως https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, η οποία μέσω του resolver της GS1 ή ενός δικού σας resolver οδηγεί στην τρέχουσα εγγραφή DPP. Οι ενημερώσεις της εγγραφής δεν απαιτούν νέα ετικέτα — το φυσικό μέσο παραμένει αμετάβλητο.

Η TEKLYNX επικαιροποίησε το λογισμικό CODESOFT και πλέον υποστηρίζει σχήματα κωδικοποίησης GS1-«++», με τα οποία οι URL ιστού μπορούν να εγγράφονται απευθείας στη μνήμη ετικετών RAIN-RFID — απαίτηση που προκύπτει από τον συνδυασμό των EN 18220 και του προτύπου GS1 Digital Link.

Διακυβέρνηση: Ποιος επιτρέπεται να επικαιροποιεί τι;

Πέρα από το τεχνικό ζήτημα, τίθεται και το ζήτημα της διακυβέρνησης: Ποιοι παράγοντες της αλυσίδας εφοδιασμού επιτρέπεται να γράφουν ποια πεδία του DPP; Η κοινοπραξία CIRPASS-2 εντόπισε εδώ κρίσιμα ζητήματα σχετικά με την κυριαρχία επί των δεδομένων σε διασυνοριακές αλυσίδες εφοδιασμού.

Ένα πρακτικό μοντέλο διακρίνει τρεις ρόλους:

Κατασκευαστής (Creator): Γράφει όλα τα πεδία κατά τη δημιουργία· επιτρέπεται να επικαιροποιεί όλα τα πεδία.
Εξουσιοδοτημένος παράγοντας (Editor): Επιτρέπεται να επικαιροποιεί καθορισμένα πεδία (π.χ. ιστορικό επισκευών, νέες πιστοποιήσεις) — με τεκμηρίωση μέσω δικού του αναγνωριστικού.
Αναγνώστης (Reader): Μπορεί να διαβάζει όλα τα δημόσια πεδία, χωρίς δικαιώματα εγγραφής.

Η Ecommerce Europe ζήτησε στο έγγραφο θέσεων για την υλοποίηση του DPP να είναι δυνατές και για μεταχειρισμένα προϊόντα «μερικές DPPs» — δηλαδή εγγραφές που επικαιροποιούν μόνο ένα μέρος των αρχικών πεδίων. Αυτό είναι τεχνικά εφικτό ήδη σήμερα, όμως εξακολουθεί να απουσιάζει ως επίσημη κατηγορία από τους εκτελεστικούς κανονισμούς.

Συμπέρασμα

Η διατήρηση των δεδομένων DPP επικαιροποιημένων δεν είναι μια εφάπαξ ενέργεια, αλλά μια επιχειρησιακή διαδικασία. Τα σημαντικότερα συμπεράσματα από το τρέχον ρυθμιστικό πλαίσιο:

Διαχωρίστε την παρτίδα από το προϊόν — η στρατηγική αναγνωριστικών καθορίζει ποια δεδομένα πρέπει να επικαιροποιούνται και πότε.
Το Registry δεν είναι αποθήκη δεδομένων — οι ενημερώσεις στο περιεχόμενο του διαβατηρίου κατά κανόνα δεν απαιτούν εγγραφή στο Registry.
Η διαχείριση εκδόσεων είναι πρακτικά υποχρεωτική — ακόμη και αν ο κανονισμός δεν την απαιτεί ρητά.
Το GS1 Digital Link αποσυνδέει το φυσικό μέσο από την εγγραφή — μειώνοντας σημαντικά την προσπάθεια για τις ενημερώσεις δεδομένων.
Οι ρόλοι διακυβέρνησης πρέπει να καθορίζονται εκ των προτέρων — ποιος επιτρέπεται να γράφει τι και πώς καταγράφεται αυτό;

Τα πρότυπα γίνονται πιο συγκεκριμένα και τα πρώτα πιλοτικά έργα βρίσκονται σε εξέλιξη — όποιος θέσει τώρα σωστά την αρχιτεκτονική, θα αποφύγει δαπανηρές διορθώσεις όταν τεθούν σε ισχύ οι εκτελεστικοί κανονισμοί ανά κλάδο.