missä muodossa minun tulee toimittaa tiedot tuotepassia varten
Tiedostomuoto ei ole vielä määritetty
ESPR ei määritä tiedostomuotoa — ei ".csv"-muotoa, ei ".xml"-muotoa, ei ".json"-muotoa. ESPR:n 11 artikla (asetus (EU) 2024/1781) velvoittaa kuitenkin siihen, että digitaalisen tuotepassin on noudatettava avoimia, yhteentoimivia teknisiä standardeja, jotta eri osapuolten järjestelmät voivat lukea ja käsitellä tietoja. Mikä standardi siitä tulee, määritellään valtuutetuissa säädöksissä, jotka laaditaan tuoteryhmittäin. Raudalle ja teräkselle kyseistä säädöstä ei ole vielä olemassa. Jos joku nyt kysyy "missä muodossa minun tulee toimittaa", saa hän oikeutetusti epämääräisen vastauksen — sellaista vastausta ei tällä hetkellä yksinkertaisesti ole olemassa.
Kenen osalta tämä koskee ja ketä se ei koske
Tämä epäselvyys koskee kaikkia, jotka valmistavat, tuovat maahan tai käyvät kauppaa teräksellä tai raudasta valmistettujen puolivalmisteilla ja valmistavat tuotepassia: teräskauppaa, metallinkäsittelyjä, rakennusyrityksiä. Se ei koske vain terästä — jokaisen ESPR:n soveltamisalaan kuuluvan tuoteryhmän osalta laaditaan omat valtuutetut säädökset omilla teknisillä spesifikaatioilla. Akkujen, tekstiilien tai huonekalujen muoto voi siis poiketa siitä, mitä teräkselle tulee voimaan. On myös tärkeää erottaa säilytysmuoto ja siirtomuoto: 11 artikla koskee sitä, kuinka järjestelmien on voitava lukea tietoja keskenään, ei sitä, kuinka valmistaja järjestää omaa hallintoa. Yritys, joka tällä hetkellä säilyttää tietoja Excel-tiedostossa tai ERP-järjestelmässään, ei tarvitse muuttaa sitä — käännös lopulliseksi muodoksi tapahtuu passin kokoamisen yhteydessä, ei omissa lähdetiedoissa.
Milloin tämä on määritetty
Teräksen tiedostomuodon tuntemisen päivämäärää ei voi nimetä, koska sitä päivämäärää ei ole olemassa käytettävissä olevissa lähteissä. Mikä on varmaa, on reitti: Euroopan komissio työstää teknisiä vaatimuksia valtuutetulla säädöksellä tuoteryhmittäin, kuten ESPR:n 4 ja 11 artikla määrää. Niin kauan kuin rautaa ja terästä koskevaa valtuutettua säädöstä ei ole julkaistu, ei myöskään ole muotoa, johon noudattaa. Siihen asti mitään ei muutu siinä tavassa, jolla yritykset nyt pitävät kirjaa tuotetiedoistaan — ei ole väliaikaista muotoa, jota olisi jo sovellettava. Heti kun teräksen valtuutettu sääntö on julkaistu, tietty tekninen spesifikaatio ilmestyy tänne.
Mitä tehdä niin kauan kuin muoto ei ole määritetty
Jokaisen, joka haluaa nyt varautua etukäteen, käytännöllisin askel on omien lähdetietojen järjestäminen riippumatta lopullisesta tiedostomuodosta. Se alkaa sillä, että selvitetään, mitkä tiedot ovat saatavilla kutakin tuotetta kohden — koostumus, alkuperä, todistukset — ja miten nämä tiedot tallennetaan sisäisesti. Tämän jälkeen on järkevää katsoa, kuinka nämä tiedot voidaan myöhemmin linkittää järjestelmään, joka kootaan passia; linkittäminen omaan ERP- tai varastojärjestelmään on kysymys, johon voidaan vastata riippumatta tiedostomuodosta jo nyt. Myös kysymys siitä, kuinka jokainen tuote tai erä tunnistetaan, ei riipu muodosta ja voidaan selvittää jo nyt — katso miten jokainen tuote saa ainutlaatuisen tunnuskoodin". Heti kun teräksen valtuutettu säädös on voimassa, siitä todennäköisesti seuraa myös se, miten kytkentä standardiin, kuten GS1 Digital Link, tarkalleen ottaen täytetään; jokainen, joka haluaa rakentaa tietoa siitä nyt, voi aloittaa mitä GS1 Digital Link tarkoittaa tuotepassille". Tiedostomuoto itsessään on siis viimeinen vaihe sarjassa — valmistelu siihen alkaa tiedoista itsestään, ei teknisestä spesifikaatiosta, joka on vielä tulematta.
Oikeusperusta: ESPR:n 10 ja 11 artikla
Artikla 10 ESPR:stä (asetus (EU) 2024/1781) kuvaa digitaalisen tuotepassin yleiset vaatimukset, mukaan lukien tietojen saavutettavuus ja luotettavuus. Artikla 11 kehittää tätä edelleen passiin liittyvän teknisen suunnittelun ja toiminnan osalta: se määrää, että taustalla oleva teknologia on noudatettava avoimia standardeja, oltava yhteentoimiva markkinaosapuolten välillä ja oltava koneen luettavassa muodossa. Kumpikaan artikkeleista ei mainitse tiettyä tiedostomuotoa, tiettyä koodausta tai tiettyä teknistä normia — kyseinen sisältö on nimenomaisesti delegoitu myöhempiin toimenpiteisiin tuoteryhmittäin. Tämä on myös syy siihen, miksi tämä vastaus ei nyt voi mennä pidemmälle kuin periaatteen nimeämisessä: laki vahvistaa yhteentoimivuusvaatimuksen, mutta ei teknistä normia, jolla kyseinen vaatimus täytetään.
Mitä nyt on tehtävä
Tällä hetkellä ei ole mitään valittavaa tai asennettavaa tiedostomuodon osalta — valinta on delegoidulla toimenpiteellä, joka vielä on tuleva. Järkevämpää on kuitenkin saattaa omat tuotetiedot kuntoon ja selvittää yllä mainitut tunnistamis- ja kytkentäkysymykset, jotta siirtyminen lopulliseen muotoon myöhemmin on kyse liittämisestä sen sijaan, että aloitettaisiin alusta.
Mistä tämä perustuu
- Asetus (EU) 2024/1781 (ESPR), artikla 11 (digitaalisen tuotepassin tekninen suunnittelu ja toiminta)
- Asetus (EU) 2024/1781 (ESPR), 10. artikla (vaatimukset digitaalisesta tuotepassista)
Asetus itsessään on EUR-Lexissä. Viitaamme kullakin väitteellä; ette tarvitse uskomaan meitä.
Mitä sinun on konkreettisesti tehtävä
Mitä sinulta odotetaan
Käytä avoimia, standardoituja tietomuotoja
Artikla 10 ESPR:stä (asetus (EU) 2024/1781) edellyttää, että digitaalisen tuotepassin tiedot noudattavat avoimia, yhteentoimivia standardeja. Tämä tarkoittaa, että tiedostomuoto, joka on luettavissa vain yhdellä tietyllä ohjelmistopaketilla, ei vastaa asetuksen tarkoitusta. Teräskaupalle tai metallinjalostajalle, jolla on 10–100 työntekijää, tämä käytännössä tarkoittaa, että tiedot viedään omasta ERP- tai varaston hallintajärjestelmästä muotoon, jonka muut osapuolet — asiakkaat, valvontaviranomaiset, kierrätysbedriftit — voivat lukea ilman lisälisenssejä tai erityisohjelmistoja. Vienti suljettuun, yritysomistukseen kuuluvaan tiedostomuotoon ei siihen kuulu, vaikka kyseistä vientiformaattia olisi käytetty sisäisesti vuosia.
Toimita koneen luettavassa muodossa
Artikla 11 ESPR:stä (asetus (EU) 2024/1781) kuvaa, että passin on oltava koneen luettavassa muodossa ja että sitä voidaan lukea automaattisesti kantajasta (yleensä QR-koodi). Tämä käytännössä sulkee pois digitoidun PDF-tiedoston paperisesta sertifikaatista ainoana tietolähteenä: se on ihmisen luettavissa, mutta ei luotettavasti automaattisesti käsiteltävissä. Yritykselle, joka on tottunut lähettämään materiaalisertifikaatteja PDF-muodossa, tämä tarkoittaa, että muuntaminen jäsenneltyyn tietoon on tarpeen — ajattele kiinteitä merkityksiä sisältäviä kenttiä (teräslaji, erä, koostumus) vapaan tekstin sijaan asiakirjan asettelussa.
Rakenne, joka vastaa loput järjestelmää
Molemmat artikkelit osoittavat tietorakenteeseen, joka ei ole itsenäinen, vaan vastaa tuotepassin laajempaa infrastruktuuria: yksilöivä tunnistenumero, kytkentä rekisteriin ja sitä, miten passi pysyy haettavissa vuosia tuotteen myynnin jälkeen. Keskisuurelle metalliyritykselle tämä tarkoittaa, että tiedostomuodon valinta ei voi olla riippumaton siitä, kuinka jokainen tuote saa yksilöllisen tunnistekoodin: katso Miten annan jokaiselle tuotteelle ainutlaatuisen tunnuskoodin?. Tietojen muoto ja tuotteen tunnistaminen liittyvät toisiinsa; erillinen Excel-tiedosto ilman johdonmukaista kytkentää tuotekoodiin ei vastaa artiklassa 10 kuvattua yhteentoimivuuden ideaa.
Missä asiat menettävät hallintaansa käytännössä
Eräs tilanne, joka usein esiintyy: teräskauppa on toimittanut materiaalicertifikaatteja (esimerkiksi 3.1-sertifikaatteja) PDF-muodossa asiakkaille vuosia ja olettaa, että tämä riittää myös tuotepassiin. PDF sisältää oikeat tiedot, mutta ei muodossa, joka on automaattisesti luettavissa — joten se ei vastaa artiklassa 11 kuvattua.
Toinen tilanne: yritys käyttää sisäistä Excel-tiedostoa omilla sarakeotsikoinsa ja omilla terästyyppien lyhennyksillään. Se toimii hyvin yrityksen sisällä, mutta heti kun asiakas, valvontaviranomainen tai rekisteri joutuu tulkitsemaan tietoja, puuttuu yhteinen merkitys, jonka standardoitu muoto tarjoaisi.
Kolmas tilanne syntyy yrityksissä, joissa siirtyminen strukturoituun muotoon tapahtuu vasta silloin, kun tuote lähtenee ulos. Jos siirtyminen tapahtuu manuaalisesti, myyntitilaus kerrallaan, virhe- ja epäjohdonmukaisuuksien riski pasportissa on suuri — erityisesti kun valikoimassa on paljon vaihtelua seossuhteen, paksuuden tai lämpökäsittelyn suhteen.
Neljäs tilanne: tiedostomuoto valitaan kyllä oikein, mutta kytkentä omaan varaston hallintojärjestelmään puuttuu, minkä vuoksi tiedot syötetään kahdesti ja kun ERP-järjestelmä päivitetään, ne joutuvat epäsynkkiin pasportissa olevien tietojen kanssa. Katso tästä myös Voinko yhdistää tuotepassin ERP- tai varastointijärjestelmääni?.
Viides, vähemmän näkyvä tilanne: yritys ajattelee, että tiedostomuoto on kertaluonteinen valinta ensimmäisessä toimityksessa, kun taas pasportissa on oltava käytettävissä useiden vuosien ajan. Muoto, joka on nyt yleinen, ei välttämättä ole sitä vuosien kuluttua — riski, joka liittyy siihen, kuinka kauan pasportti todella on oltava olemassa, katso Kuinka kauan tuotepassin on oltava saatavilla?.
Mitä voitte kirjata ylös
- Yhteenveto nykyisistä vientitiedostomuodoista omasta ERP- tai varaston hallintojärjestelmästä, merkinnällä siitä, mitkä niistä ovat koneen luettavissa ja mitkä eivät (esimerkiksi PDF verrattuna CSV:iin tai XML:ään).
- Kiinteä kenttäluettelo tuoteryhmää kohden (terästyyppi, erä, mitat, koostumus), jotta sisäiset tiedot jäsennellään aina samalla tavalla riippumatta siitä, kuka tiedot syöttää.
- Sopimus toimittajien tai valmistajien kanssa siitä muodosta, jossa he toimittavat tietonsa, jotta tietoja ei tarvitse kirjoittaa manuaalisesti uudelleen sertifikaateista tai PDF-tiedostoista.
- Viite kytkennylle yksittäisen tunnistuskoodin kanssa jokaisesta tuotteesta, jotta tiedostomuoto ja tunnistus muodostavat yhdessä kokonaisuuden — katso Miten annan jokaiselle tuotteelle ainutlaatuisen tunnuskoodin?.
- Merkintä luettavuudesta ilman internetyhteyttä, siltä osin kuin se on merkityksellistä omissa työn prosesseissa tehtaalla tai kuljetussa, katso pitääkö tuotepassin toimia myös ilman internetyhteyttä.
- Kansio valittujen tietomuotojen osalta tuotesarjaa kohden, mukaan lukien muutoksen päivämäärä, jotta myöhemmässä standardien muutoksessa voidaan tarkistaa, mitkä vanhemmat pasportit ovat edelleen vanhentuneessa muodossa.
Käytettävän tiedostomuodon tarkat tekniset määritykset laaditaan tarkemmin delegoiduissa toimissa tuoteryhmää kohden; tällä hetkellä ESPR:n (Asetus (EU) 2024/1781) 10 ja 11 artikla kuvaavat puitteet, joissa nämä valinnat tehdään. Heti kun raudan ja teräksen delegoitu toimi on julkaistu, täydennämme tähän, mikä muoto konkreettisesti määrätään.
Tämä ei ole juridista neuvontaa. Tämä sivu sisältää yleisiä tietoja sääntelystä, jota tämä alusta koskee. Emme tunne vosituaatiota. Jos epäröitte omaa tilannettanne, kuulkaa juristi tai toimivaltainen valvontaviranomainen.
Kirjoitettu tekoälyllä edellä mainittujen lähteiden perusteella, jonka ihminen tarkisti 2026-09-05. Onko jotain vialla? Kerro meille — korjaukset saavat etusijaa.