---
title: "DPP-Datan pitäminen ajan tasalla: mitä ESPR todella edellyttää — qr3.app Blog"
description: "Näin päivität Digital Product Passport -tiedot ESPR mukaisesti: erä- ja tuotetaso, rekisterivelvoitteet ja käytännön arkkitehtuurivinkit."
canonical: "https://qr3.app/fi/blog/howto-20260610/"
lang: "fi"
robots: "index,follow,max-image-preview:large,max-snippet:-1"
---
# DPP-Datan pitäminen ajan tasalla: mitä ESPR todella edellyttää — qr3.app Blog
> Näin päivität Digital Product Passport -tiedot ESPR mukaisesti: erä- ja tuotetaso, rekisterivelvoitteet ja käytännön arkkitehtuurivinkit.
Canonical:
[← Blogi](/fi/blog/) [Tutorials](/fi/blog/category/tutorials/)
10. kesäkuuta 2026 4 min lukuaika [Tutorials](/fi/blog/category/tutorials/) [digital-product-passport](/fi/blog/tag/digital-product-passport/)[espr](/fi/blog/tag/espr/)[dpp-update](/fi/blog/tag/dpp-update/)[gs1-digital-link](/fi/blog/tag/gs1-digital-link/)[datenarchitektur](/fi/blog/tag/datenarchitektur/)[compliance](/fi/blog/tag/compliance/)
# DPP-Datan pitäminen ajan tasalla: mitä ESPR todella edellyttää
Näin päivität Digital Product Passport -tiedot ESPR mukaisesti: erä- ja tuotetaso, rekisterivelvoitteet ja käytännön arkkitehtuurivinkit.
kirjoittanut **QR3 Redaktion**
Sen jälkeen kun [ESPR-asetus (EU) 2024/1781](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1781) 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](https://susproc.jrc.ec.europa.eu/product-bureau/product-groups/467/documents) 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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1542) 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](https://zenodo.org/records/11354831) 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 {
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](https://zenodo.org/records/11354831) 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:
1. **Erottakaa erä ja tuote** — tunnistestrategia määrittää, mitä tietoja on päivitettävä ja milloin.
2. **Rekisteri ei ole tietovarasto** — passin sisällön päivitykset eivät yleensä edellytä rekisteriin kirjoittamista.
3. **Versiointi on käytännössä pakollista** — vaikka asetus ei sitä nimenomaisesti edellytä.
4. **GS1 Digital Link erottaa fyysisen tietovälineen ja tietueen toisistaan** — tämä vähentää tietojen päivittämiseen liittyvää työtä huomattavasti.
5. **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.
## Lähteet
- [Regulation (EU) 2024/1781 of the European Parliament and of the Council of 13 June 2024 establishing a framework for the setting of ecodesign requirements for sustainable products](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1781)
- [Study on DPP content for iron and steel products under ESPR - Circular Economy: Environmental and Waste Management](https://susproc.jrc.ec.europa.eu/product-bureau/product-groups/467/documents)
- [Regulation (EU) 2023/1542 of the European Parliament and of the Council of 12 July 2023 concerning batteries and waste batteries](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32023R1542)
- [CIRPASS-2 Consortium – Stellungnahme zur DPP-Registry (Zenodo)](https://zenodo.org/records/11354831)
## Aiheeseen liittyvät artikkelit
- [ Tutorials DPP-tietojen pitäminen ajan tasalla: näin päivitysprosessi toimii Mitä ESPR-asetus todellisuudessa vaatii digitaalisten tuotepassien päivittämiseltä — ja kuinka ylläpitää oikein rekisterimerkintöjä, resolvereita ja tuotetietoja.](/fi/blog/howto-20260521/)
- [ DPP Practice Digitaalisen tuotepassin pitäminen ajan tasalla: näin päivitystyönkulku toimii Näin päivität olemassa olevan digitaalisen tuotepassin oikein — tietomuutoksista ja GS1 Digital Link -hallinnasta pakollisiin auditointijäljen vaatimuksiin.](/fi/blog/howto-20260516/)
- [ Regulation Digitaalinen akkupassi 2027: mitä EU-asetus todella edellyttää Digitaalinen akkupassi tulee voimaan helmikuussa 2027. Katsaus pakollisiin tietoihin, standardeihin, rekisterivaatimuksiin ja toteutuksen nykytilaan.](/fi/blog/regulation-20260626/)
- [ Regulation Digitaalinen akkupassi 2027: mitä EU-asetus todella edellyttää Helmikuusta 2027 alkaen digitaalinen akkupassi koskee teollisuus- ja vetoakkuja. Katsaus pakollisiin tietoihin, vaatimustenmukaisuuden puutteisiin ja markkinoiden kehitykseen.](/fi/blog/regulation-20260623/)
[← Kaikki artikkelit](/fi/blog/) [Aloita ilmaiseksi](https://app.qr3.app/sign-up)