missä muodossa minun tulee toimittaa tuotepassitiedot

Kiinteä tiedostomuoto ei ole vielä varmistettu, mutta vaatimukset, joita sen on täytettävä, ovat selvät

ESPR:ssä ei vielä ole määrätty konkreettista tiedostomuotoa (kuten JSON, XML tai muuta) elektroniikka- ja ICT-laitteiden digitaaliselle tuotepassille. ESPR itse ei määrää tiettyä muotoa, mutta asetuksen (EU) 2024/1781 10 ja 11 artiklassa vahvistetaan vaatimukset, joita passin teknisen rakenteen on täytettävä: passin on oltava avoimille ja yhteentoimiville standardeille perustuva, siirrettävä järjestelmien välillä ja koneluettava. Mitä konkreettista tiedostostandaardi täyttää nämä vaatimukset, määritellään delegoidulla säädöksellä tuoteluokittain. Elektroniikassa ja ICT:ssä tätä säädöstä ei vielä ole.

Elektroniikassa tämä pätee vielä kehikkonaan, ei vahvistetuksi vaatimukseksi

Tämä sivu käsittelee digitaalista tuotepassia elektroniikka- ja ICT-laitteille ESPR:n nojalla. Artikkelit 10 ja 11 koskevat kaikkia ESPR:n piiriin kuuluvia tuotekategorioita, mutta tarkka tekninen täytäntöönpano — mukaan lukien tiedostomuoto — järjestetään tuotealaryhmittäin erikseen. Se tarkoittaa, että mitä nyt on vahvistettu, on kehikko: vaatimukset yhteentoimivuudesta, avoimista standardeista ja koneluettavuudesta. Se ei tarkoita, että konkreettista tiedostomuotoa olisi jo määrätty, jossa valmistajan tai elektroniikkatuotteiden maahantuojan on annettava tiedot. Kuka etsii vastausta kuten "toimita JSON-muodossa" tai "käytä XML-skeemaa X", ei löydä sitä tällä hetkellä missään säädöksistä tätä tuoteryhmää varten. Myöskään tämä aihe ei ole sama kuin kysymys siitä, ovatko tuotepassi koskee tiettyä elektroniikkatuotetta — se on erillinen kysymys, jolla on eri vastaus.

Delegoidun säädöksen julkaiseminen elektroniikalle määrittää päivämäärän

Ei ole vielä varmuudella määritettyä päivämäärää, jolloin elektroniikan ja ICT:n tiedostomuoto tulee tunnetuksi. ESPR:n työsuunnitelman 2025–2030 mukaisesti delegoidut säädökset laaditaan tuotealaryhmittäin, ja ensimmäisten säädösten odotetaan tulevan vuodesta 2027 alkaen. Kun elektroniikalle ja ICT:lle julkaistaan delegoitu säädös, siinä odotetaan olevan myös tekninen muoto, jossa tiedot on annettava. Siihen saakka sovelletaan vain 10 ja 11 artiklan yleistä kehikkoa: avoimia standardeja, yhteentoimivuutta ja koneluettavuutta ilman, että yhtä konkreettista tiedostomuotoa olisi määrätty. Tämä sivu päivitetään, kun delegoitu säädös tästä kategoriasta antaa konkreettisen vastauksen.

Mitä maahantuoja tai valmistaja voi jo nyt valmistella

Vaikka tiedostomuotoa ei ole vielä vahvistettu, on käytännössä jo paljon tehtävää. Ensinnäkin on järkevää määritellä, mitkä järjestelmät ja tiedot ovat myöhemmin passin perusta — useimmilla yrityksillä nämä tiedot ovat jo jonkin järjestelmän sisällä, kuten ERP- tai varastojärjestelmässä, ja on hyödyllistä tarkistaa etukäteen, kuinka tällainen järjestelmä voidaan myöhemmin liittää tuotepassiin. Lisäksi on järkevää harkita tunnisteita: jokainen tuote on jäljitettävä passiinsa, ja se edellyttää johdonmukaista lähestymistapaa kunkin tuotteen yksilöllisen tunnistekoodin antamiseen. Myös kysymys siitä, kuinka QR-koodi tulee myöhemmin tuotteeseen ja kuinka se suhtautuu olemassa oleviin viivakoodeihin tai GS1-järjestelmiin, on jo nyt tutkittava, riippumatta siitä, mitä tiedostomuotoa myöhemmin määrätään. Kun delegoitu säädös elektroniikalle ja ICT:lle ilmestyy, se todennäköisesti liittyy infrastruktuuriin, jota mainitaan jo 13 artiklassa (digitaalisten tuotepassien rekisteri) ja 14 artiklassa (verkkoportaali), joten valmistautuminen tähän rakenteeseen on jo nyt järkevää, riippumatta tarkan teknisen muodon sisällöstä.

Perusta: ESPR:n 10 ja 11 artikla

Asetuksen (EU) 2024/1781 (ESPR) artikla 10 kuvaa digitaalisen tuotepassin yleiset vaatimukset, kuten tietojen saavutettavuuden ja luotettavuuden. Artikla 11 käsittelee erityisesti passiin liittyvää teknistä suunnittelua ja toimintaa sekä mainitsee vaatimuksiksi eri markkinatoimijoiden järjestelmien välisen yhteentoimivuuden ja avointen standardien käytön, ilman että yksi tiedostomuoto määrättäisiin pakolliseksi. Lisäksi tekninen täytäntöönpano — johon kuuluu oletetusti myös konkreettinen datamuoto — toteutetaan delegoitujen säädösten kautta tuoteryhmittäin, kuten ESPR-työsuunnitelmassa 2025–2030 ilmoitetaan. Saman asetuksen artikla 13 ja artikla 14 kuvaavat täydentävästi rekisteriä ja verkkoportaalia, joiden kautta passin tiedot saatavuutetaan, mikä on olennaista sille, kuinka toimitettu tiedosto lopulta näytetään ja haetaan. Elektroniikasta ja tieto- ja viestintätekniikasta ei ole vielä julkaistu delegoitua säädöstä, joka tekee tämän konkreettiseksi.

Joka haluaa ryhtyä jo nyt valmisteluihin, voi parhaiten aloittaa omien tuotetietojen ja tunnistusjärjestelmien kuntoon saattamisesta, jotta siirtyminen konkreettiseen tiedostomuotoon on myöhemmin vain kytkemistä vastaavien järjestelmien alle, ei aloittamista alusta. On myös järkevää tarkastella samalla mitä digitaalisten tuotepassien rekisteri sisältää ja mitä siihen tallennetaan, koska rekisteri on todennäköisesti suoraan yhteydessä lopulliseen toimitusmenetelmään.

Mihin tämä perustuu

Asetus itsessään on EUR-Lexissä. Me viittaamme kullekin väitteelle; te ette joudu meitä uskomaan.

Mitä sinun on konkreettisesti tehtävä

Mitä sinulta odotetaan

Kysymys siitä, mikä tiedostomuoto on pakollinen — JSON, XML, PDF, tietty API-rakenne — tulee jokaisen tuontiin ryhtyvän yrityksen ja valmistajan eteen silloin, kun IT-osasto alkaa rakentamista. Vastaus nykyisen ESPR-tekstin perusteella on selkeä: konkreettista tiedostomuotoa ei mainita asetuksessa. Asetuksen (EU) 2024/1781 (ESPR) artikla 10 ja artikla 11 asettavat vaatimuksia sille, mihin digitaalisen tuotepassin on vastattava, mutta se tapahtuu toiminnallisten ja teknisten vaatimusten tasolla, ei tasolla "käytä JSON-LD:tä" tai "toimita XML-tiedosto tämän kaavan mukaisesti". Sen täytäntöönpano odotetaan delegoitujen ja täytäntöönpanousten kautta, tuoteryhmittäin.

Yhteentoimivuus on keskeistä, ei yksi tietty muoto

Asetuksen (EU) 2024/1781 artikla 10 mainitsee yhteentoimivuuden ydinvaatimukseksi: passin on oltava rakennettu siten, että eri osapuolten — valvontaviranomaisten, markkinatoimijoiden, kuluttajien — järjestelmät pystyvät lukemaan tiedot. 10–100 työntekijän yritykselle tämä tarkoittaa käytännössä sitä, että valinnat tallennuksen ja tietojenvaihdon muodosta voidaan tehdä varmasti vasta, kun oman tuoteryhmän delegoitu säädös on valmis. Siihen saakka on suositeltavaa työskennellä jäsennellyillä tiedoilla (kuten tietokannan tai ERP-järjestelmän kenttien kanssa) sen sijaan, että tiedot säilytettäisiin vain hajanaisessa asiakirjassa tai PDF-muodossa, jotta myöhempi saatavuuttaminen lopullisessa muodossa vaatii vähemmän uudelleentyötä.

Passiin on pääsy QR-datavirrittimellä

Asetuksen (EU) 2024/1781 artikla 11 kuvaa passiin liittyvää teknistä toimintaa, kuten yhteyden tietovirittimeen tuotteessa. Se tarkoittaa, että taustalla olevat tiedot, missä tahansa muodossa, on pystyttävä saatavuuttamaan sillä hetkellä, kun joku skannaa koodia. Kuinka tämä tekninen yhteys toimii ja mitä tunnistamisstandardeja siihen liittyy, kuvataan sivulla, joka käsittelee kuinka QR-koodi tuotepassia varten päätyy elektroniikkaaniYrityksissäEdellä, jotka jo käyttävät GS1-viivakoodeja, on merkitystä sillä, voiko olemassa olevaa tunnistusjärjestelmää käyttää uudelleen — aihe palaa sivulle, joka käsittelee mikä GS1 Digital Link on ja onko se välttämätön tuotepassille.

Jokainen tuote on oltava yksilöllisesti tunnistettavissa riippumatta tiedostomuodosta

Riippumatta siitä, mikä tekninen muoto myöhemmin määrätään, taustalla oleva vaatimus on, että jokainen tuote saa yksilöllisen tunnisteen. Tämä on erillinen vaatimus, joka ei muutu, jos tiedostomuoto määritellään myöhemmin. Yritykset, jotka alkavat jo nyt jäsentää tuotetietojaan, tekevät viisaasti sisällyttämällä tunnistamisen pysyväksi osaksi. Miten sitä käytännössä rakennetaan, on selostettu sivulla miten annat jokaiselle tuotteelle ainutlaatuisen tunnisteen.

Rekisteriin toimittaminen edellyttää omaa muotoa

ESPR:n 13 artiklassa esitellään digitaalisten tuotepassien rekisteri, jossa tiettyjä passia koskevia tietoja tallennetaan. Myöskään tässä ei ole vielä määritelty, missä tarkalleen tiedostomuodossa toimittaminen on tehtävä — se täsmennetään myöhemmin. On kuitenkin selvää, että tämä rekisteri on erillinen toimintavirta verrattuna QR-koodin kautta saatavilla olevaan passikirjaan. Lisätietoja siitä, mitä sinne on sisällytettävä, on sivulla mikä on digitaalisen tuotepassin rekisteri ja mitä siihen on merkittävä.

Missä asia menee pieleen käytännössä

Liian aikainen kiinnittäminen jäykkään muotoon. Jotkut yritykset rakentavat jo nyt PDF-passia, koska se on nopeaa ja tunnistettavaa, kun taas lopullinen vaatimus luultavasti edellyttää jäsenneltyjä, koneluettavia tietoja. PDF on ihmisille luettava, mutta ei automaattisesti sopiva ESPR:n 10 artiklassa tarkoitettuun yhteentoimivuuteen.

Tiedot hajallaan useissa järjestelmissä ilman kytkentää. Tuotetiedot sijaitsevat usein osittain ERP-järjestelmässä, osittain markkinointiasiakirjoissa, osittain ulkoisella toimittajalla. Ilman suunnitelmaa tietojen kokoamiseksi on tulevaisuudessa vaikea vaihtaa nopeasti, kun pakollinen muoto tunnetaan. Yritykset, jotka harkitsevat omansa järjestelmän ottamista mukaan, löytävät lisätietoja mahdollisuuksista sivulla tuotepassin kytkeminen omaan ERP- tai varastojärjestelmään.

Sekaannus itse passin ja rekisterin välillä. QR-koodin kautta konsultoitava passi ja rekisteriin sisällytettävät tiedot eivät välttämättä ole identtisiä muodoltaan tai muodostaan. Se, että yksi tiedosto riittää molempiin tarkoituksiin, on riski, joka tulee näkyväksi vasta, kun täytäntöönpanoasetus tulee konkreettiseksi.

Useiden tuotetasojen huomiotta jättäminen. Tuotteissa, jotka myydään yhdistetyssä pakkauksessa, tai joissa laite koostuu useista osista, joilla on omat passikirjat, on kysymys siitä, miten tiedostomuodot liittyvät toisiinsa, vieläkin monimutkaisempi. Tämä koskee esimerkiksi laatikkoa, jossa useita laitteita ja tuotteissa, jotka useita digitaalisia tuotepasseja tarvitaan.

Riittämätön huomio pitkäaikaisen luettavuuden suhteen. Tiedostomuoto, joka on nyt yleinen, ei välttämättä pysykään sellaisena pidemmällä aikavälillä. Koska passille on oltava saatavilla tietty aika, on muodon valinta myös kysymys kestävyydestä — katso tarkempi selvitys aiheesta kuinka kauan tuotepassin on oltava saatavilla.

Mitä voit dokumentoida

Yhteenveto siitä, missä tuotetietoja tällä hetkellä tallennetaan (ERP, PIM, laskentataulukot, toimittajien asiakirjat) ja missä muodossa.
Luettelo pakollisista tietolähteistä tuoteluokittain, kun kyseisen luokan täytäntöönpanoasetus on julkaistu.
Sopimukset toimittajien ja alihankkijoiden kanssa siitä, missä muodossa he toimittavat tuotetietojaan, jotta yhdistäminen on myöhemmin helpompaa.
Sisäinen vastuuhenkilö tai tiimi, joka seuraa teknisten standardien kehitystä, koska ESPR:n 11 artiklassa annetaan siitä vielä tarkempia määrityksiä.
Dokumentaatio kunkin tuotteen valitusta tunnistusmenetelmästä, myös erillään lopullisesta tiedostomuodosta.
Yhteenveto hosting- ja saatavuusvaatimuksista, jotka yhdessä muodon kanssa määrittävät, miten passi asetetaan teknisesti — katso sivu mitä hosting-vaatimuksia on voimassa.

Tämä ei ole juridista neuvontaa. Tämä sivu antaa yleistä tietoa sääntelystä, jota tämä alusta koskee. Emme tunne tilannettanne. Jos epäilet omaa tilannettanne, neuvottelkaa asianajajan tai toimivaltaisen valvontaviranomaisen kanssa.

Kirjoitettu tekoälylla yllä olevien lähteiden perusteella, ihmisen tarkistama 2026-09-05. Onko jokin väärässä? Kerro meille — korjaukset saa etusijaa.