DPP-Datan pitäminen ajan tasalla: mitä ESPR todella edellyttää

Sen jälkeen kun ESPR-asetus (EU) 2024/1781 hyväksyttiin, Digital Product Passport (DPP) on ollut sitovaa EU-lainsäädäntöä. Monet yritykset aliarvioivat seuraavan asian: DPP ei ole staattinen asiakirja, joka luodaan kerran markkinoille saattamisen yhteydessä. Se on pidettävä ajan tasalla koko tuotteen elinkaaren ajan — ja sitä koskevat vaatimukset täsmentyvät jatkuvasti.

Tässä artikkelissa selitetään, mitä tietoja on päivitettävä ja milloin, miten rekisteriarkkitehtuuri vaikuttaa päivitysmalliin ja mitkä tekniset käytännöt ovat osoittautuneet toimiviksi.

Mitä asetus sanoo päivityssyklistä

Staattiset ja dynaamiset tietokentät

ESPR ei itse määritä nimenomaista päivitystiheyttä, mutta siinä edellytetään, että DPP sisältää ”ajantasaiset ja täsmälliset tiedot”. Täsmennykset tehdään sektoritasolla — ja JRC:n luonnos rauta- ja teräspuolivalmisteille tarjoaa tähän mennessä selkeimmän kuvan.

Luonnoksessa erotetaan järjestelmällisesti kaksi tietojen tarkkuustasoa:

Taso	Tunniste	Esimerkkitiedot	Päivityksen aiheuttaja
Erätaso (Lot)	Eränumero	Kierrätysmateriaalin osuus, seoksen koostumus, ISO 14067:n mukainen PCF	Tuotantomuutos, uusi erä
Tuotetaso (Item)	Sarjanumero	Mitat, sertifioinnit, vaatimustenmukaisuusvakuutukset	Uudelleensertifiointi, takaisinvetotapaus, korjaus

Tämä erottelu on tietokanta-arkkitehtuurin kannalta ratkaiseva: Erätiedot kirjoitetaan tyypillisesti kerran tuotantoajon aikana, minkä jälkeen ne pysyvät muuttumattomina — ellei hiilijalanjäljen uudelleenlaskenta tuota korjattua arvoa. Tuotetason tiedot sen sijaan voivat muuttua koko käyttöiän aikana, esimerkiksi kun laite korjataan tai sertifiointi uusitaan.

Paristoasetus (EU) 2023/1542 tuntee tämän erottelun jo implisiittisesti: heikkenemisen seurauksena muuttuvat kapasiteettitiedot on pidettävä ajan tasalla — vaatimus, jota on vaikea täyttää ilman selkeää arkkitehtuuria.

Rekisteri hakemistona, ei tietovarastona

Keskitetyn DPP-rekisterin rooli ymmärretään usein väärin. DPP-rekisteriä koskevan täytäntöönpanoasetuksen luonnoksessa selvennetään: rekisteriin tallennetaan ainoastaan yksilöllinen tunniste, resolver-päätepiste ja tavarakoodi — ei varsinaisia passitietoja.

Tämä tarkoittaa päivitysten hallinnan kannalta seuraavaa: passin sisältö ja rekisteri ovat erillisiä järjestelmiä. Kun tuotetietoja päivitetään, rekisteriin ei yleensä tarvitse tehdä muutoksia — paitsi jos resolver-päätepiste muuttuu (esimerkiksi järjestelmävaihdoksen yhteydessä). CIRPASS-2-konsortio korosti tätä arkkitehtuurimallia nimenomaisesti rekisteriluonnosta koskevassa lausunnossaan ja suosittelee standardin EN 18219 sisällyttämistä sitovana viitteenä täytäntöönpanoasetukseen — muun muassa yhteentoimivuuden varmistamiseksi GS1 Digital Link:n kanssa.

Päivitysskenaariot käytännössä

Skenaario 1: Uusi hiilijalanjälki toimittajan vaihdon seurauksena

Tuotekohtainen hiilijalanjälki (PCF) ylläpidetään JRC:n teräsluonnoksen mukaan erätasolla, ja se on laskettava ISO 14067:n kanssa yhteensopivilla menetelmillä. Jos teräksentuottaja vaihtaa energialähdettä tai romutoimittajaa, uuden erän PCF muuttuu — jo toimitettujen erien PCF ei.

Teknisesti tämä tarkoittaa, että vanhan erän DPP-tietue pysyy muuttumattomana. Uudelle erälle luodaan uusi tietue, joka voi käyttää samaa resolver-päätepistettä mutta jonka tunnisteena on uusi eränumero.

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

Skenaario 2: Tuotetason sertifioinnin vanheneminen

Vaatimustenmukaisuusvakuutuksilla ja sertifioinneilla on voimassaoloajat. Kun uusi sertifiointi myönnetään, tuotetason DPP on päivitettävä. Koska resolver-päätepiste pysyy ennallaan, rekisteriä ei tarvitse päivittää — ainoastaan päätepisteen takana oleva tietue muuttuu.

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

Skenaario 3: Resolverin siirto järjestelmävaihdoksen yhteydessä

Jos yritys vaihtaa DPP-palveluntarjoajaa, resolver-päätepiste muuttuu. Tällöin rekisteri on päivitettävä jokaisen vaikutuksen alaisen tunnisteen osalta. Tämä on työläin päivitystyyppi, koska se edellyttää rekisteriin kirjoittamista.

Suositus: Käyttäkää vakaata, omaa resolveria (esim. dpp.ihrunternehmen.de) välikerroksena, joka välittää pyynnöt sisäisesti kulloisellekin palveluntarjoajalle. Näin rekisteriin merkitty päätepiste pysyy pysyvästi vakaana.

Päivitysjärjestelmää koskevat tekniset vaatimukset

Versiointi ja audit trail

ESPR ei edellytä nimenomaista versiointia, mutta tuotevastuun ja tullivalvonnan yhdistelmä tekee audit trailista käytännössä välttämättömän. Jos tullivirkailija tarkastaa vuonna 2030 vuonna 2027 valmistetun teräspalkin DPP:n, on voitava jäljittää, mitkä tiedot olivat voimassa tuontihetkellä.

Versioidun DPP-taulun vähimmäisrakenne:

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 vakaana tunnisteankkurina

GS1 Digital Link erottaa tunnisteen ja resolverin toisistaan selkeästi: tuotteessa oleva QR-koodi koodaa URL-osoitteen, kuten https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, joka GS1-resolverin tai oman resolverin kautta osoittaa ajantasaiseen DPP-tietueeseen. Tietueen päivittäminen ei edellytä uutta etiketöintiä — fyysinen tietoväline pysyy muuttumattomana.

TEKLYNX on päivittänyt CODESOFT-ohjelmistonsa, joka tukee nyt GS1:n ”++”-koodausmalleja. Niiden avulla verkko-URL-osoitteet voidaan kirjoittaa suoraan RAIN-RFID-tagin muistiin — vaatimus, joka seuraa standardin EN 18220 ja GS1 Digital Link-standardin yhdistelmästä.

Hallintamalli: kuka saa päivittää mitä?

Teknisen kysymyksen lisäksi on ratkaistava hallintomalli: mitkä toimitusketjun toimijat saavat kirjoittaa mitäkin DPP-kenttiä? CIRPASS-2-konsortio on tunnistanut tässä kriittisiä kysymyksiä, jotka liittyvät tietosuvereniteettiin rajat ylittävissä toimitusketjuissa.

Käytännön mallissa erotetaan kolme roolia:

Valmistaja (Creator): Kirjoittaa kaikki kentät luomisen yhteydessä ja saa päivittää kaikkia kenttiä.
Valtuutettu toimija (Editor): Saa päivittää määritettyjä kenttiä (esim. korjaushistoriaa ja uusia sertifiointeja) — omalla tunnisteellaan dokumentoituna.
Lukija (Reader): Voi lukea kaikki julkiset kentät, mutta ei voi kirjoittaa.

Ecommerce Europe vaati DPP-täytäntöönpanoa koskevassa kannanotossaan, että myös käytettyjen tuotteiden osalta olisi mahdollista tehdä ”osittaisia DPPs” — eli tietueita, joissa päivitetään vain osa alkuperäisistä kentistä. Tämä on teknisesti jo toteutettavissa, mutta sitä ei vielä ole määritelty muodolliseksi kategoriaksi täytäntöönpanoasetuksissa.

Yhteenveto

DPP-tietojen pitäminen ajan tasalla ei ole kertaluonteinen tehtävä vaan jatkuva operatiivinen prosessi. Nykyisestä sääntelytilanteesta voidaan nostaa esiin seuraavat tärkeimmät havainnot:

Erottakaa erä ja tuote — tunnistestrategia määrittää, mitä tietoja on päivitettävä ja milloin.
Rekisteri ei ole tietovarasto — passin sisällön päivitykset eivät yleensä edellytä rekisteriin kirjoittamista.
Versiointi on käytännössä pakollista — vaikka asetus ei sitä nimenomaisesti edellytä.
GS1 Digital Link erottaa fyysisen tietovälineen ja tietueen toisistaan — tämä vähentää tietojen päivittämiseen liittyvää työtä huomattavasti.
Hallintomallin roolit on määritettävä etukäteen — kuka saa kirjoittaa mitä ja miten tämä dokumentoidaan?

Standardit täsmentyvät ja ensimmäiset pilotit ovat käynnissä — kun arkkitehtuuri rakennetaan nyt oikein, vältetään kalliit korjaukset, kun sektorikohtaiset täytäntöönpanoasetukset tulevat voimaan.