Voinko yhdistää tuotepassin omaan ERP- tai varastojärjestelmääni?

Kytkentä on mahdollista, muoto ei ole lain mukaan määritetty

Kyllä, digitaalista tuotepassia voidaan käytännössä kytkeä ERP- tai varastojärjestelmään, mutta ESPR ei määritä, miltä kytkentä näyttää. Asetuksessa asetetaan kuitenkin vaatimuksia itse pasportille: sen on oltava teknisesti rakennettu siten, että tiedot ovat koneen luettavissa ja että järjestelmät voivat lukea ja käsitellä ne automaattisesti avointen standardien perusteella suljettujen, merkkeihin sidottujen muotojen sijaan (ESPR:n 11. artikla, asetus (EU) 2024/1781). Tämä vaatimus on suunnattu passiin ja tietojen välittäjään, ei bandentuojan, tukkukauppiaan tai ajoneuvon hallintapalvelun tarjoajan sisäisiin järjestelmiin. Se, toimiiko tietyn ERP-paketin kytkentä ja miten se toimii, on siis teknisen organisoinnin kysymys osapuolelle, joka kokoaa ja isännöi passia — tässä tapauksessa platform kuten tyrepas.eu — eikä se ole asia, jota laki säätää yksityiskohtaisesti.

Ketä se koskee ja ketä ei

Tämä kysymys on ajankohtainen erityisesti suurten bande-erämäärien käsittelyyn osallistuville osapuolille, joilla tuotetiedot ovat jo jonkin järjestelmän sisällä: tuojille, jotka hallinnoivat artikkeleiden numeroita, eräätietoja ja teknisiä spesifikaatioita, tukkukauppiaille, jotka pitävät varastoa bandityypeittäin, ja ajoneuvon hallintopalvelun tarjoajille, jotka kytkevät bandet ajoneuvoihin. Heille kytkentä on ensisijaisesti käytännöllistä: tietoja ei tarvitse syöttää kahdesti, ja passitiedot voivat palata omaan järjestelmään.

Loppukäyttäjille, jotka vain ostavat bandet ja skannaa QR-koodin, ERP-järjestelmän kytkennällä ei ole merkitystä — he lukevat passia, he eivät syötä sitä. Pienemmille osapuolille, joilla ei ole omaa järjestelmää, kytkentä ei myöskään ole ratkaiseva tekijä: passia voidaan yhtä hyvin toimittaa ja tutustua siihen manuaalisesti ilman, että se vaikuttaa sen pätevyyteen. ESPR:n 11. artiklan tekniset vaatimukset koskevat lisäksi passia sinänsä, eivät kysymystä siitä, onko passin toimittajan annettava tiettyä ERP-merkkiä koskeva kytkentä.

Ei vielä kiinteää päivämäärää, mutta selkeä työsarja

Milloin digitaalisen tuotepassin velvoite bandeille tarkalleen astuu voimaan, ei ole vielä selvää. ESPR:n työsuunnitelmassa vuosille 2025–2030 odotetaan delegoitua säädöstä bandeille vuonna 2027; vasta sen julkaisemisen jälkeen on tiedossa konkreettinen voimaantulopäivä. Siihen asti bandeille ei ole velvoitettuja vaatimuksia passista itsestään, ja siten ei myöskään siihen, miten tiedot toimitetaan tai vaihdetaan.

Tämä ei tarkoita, että ei olisi mitään tekemistä. ESPR:n 10. ja 11. artiklan yleiset vaatimukset ovat jo vahvistettuja puitteina, joihin bandeja koskeva delegoitu säädös laajennetaan: koneen luettavuus, avoimet standardit ja yhteentoimivuus eivät ole uusi keksintö, joka ilmestyy vasta vuonna 2027, vaan perusta, jolle bandeille erityisiä sääntöjä rakennetaan. Joka nyt miettii kytkentää, ei siis rakenna hiekkalle, vaikka lopullinen päivämäärä puuttuukin.

Kuinka tämä toteutetaan käytännössä

Ensimmäinen vaihe on tarkistaa, mitkä tiedot ovat jo ERP- tai varastojärjestelmässä, jotka joutuvat myöhemmin pasportille: artikkelien numeroita, eräämittauksia tai eräätietoja, tuotantopäivää, teknisiä spesifikaatioita bandityypeittäin. Monet näistä tiedoista ovat jo olemassa, ne eivät ole vain vielä strukturoituneina valmiita pasportilla.

Toinen vaihe on selvittää, minkä muodon passin kokoava ja isännöivä osapuoli hyväksyy syötteeksi. Koska tyrepas.eu kokoaa passin valmistajan tai tuojan tiedoista, käytännöllinen kysymys ei ole niinkään se, voidaanko kytkentä tehdä, vaan missä muodossa tietojen toimitus sujuu hankalammin: säännöllinen vienti ERP-järjestelmästä, strukturoitu tiedosto vai muu jakelukanava.

Kolmas vaihe on pohtia muuta suuntaa: pasaporttitietojen palauttamista omaan järjestelmään, esimerkiksi siten, että ajoneuvokantaa hallinnoiva osapuoli voi yhdistää pasaporttitiedot ajoneuvon rekisteröintiin ilman, että hänen tarvitsee itse etsiä pasaporttia QR-koodin avulla. Tämäkään ei ole oikeudellisen velvoitteen kysymys, vaan teknisen yhteensovituksen kysymys ERP-järjestelmän ja alustan välillä.

Lopuksi on tärkeää ottaa huomioon käyttöaika: pasaporttia ylläpidetään kymmenen vuoden ajan. Joka perustaa yhdistämisen, tekee hyvin harkitessaan päivityksiä myös tänä ajanjaksona — esimerkiksi tuotetietojen muuttuessa — jotta yhdistäminen toimii paitsi ensimmäisen toimittamisen yhteydessä myös myöhempien muutosten yhteydessä.

Oikeudellinen perusta: ESPR:n 10. ja 11. artikla

Digitaalisen tuotepassaportin vaatimukset ovat ESPR:n 10. artiklassa (Asetus (EU) 2024/1781), joka säätää pasaportin yleiset vaatimukset. Saman asetuksen 11. artikla käsittelee erityisesti pasaportin teknistä muotoilua ja toimintaa, painottaen yhteentoimivuutta ja avoimia standardeja niin, että tiedot ovat koneen luettavissa ja vaihdettavissa. Molemmat artiklalit koskevat pasaporttia tuotteena, ei tuojien, tukkukauppiaiden tai ajoneuvokantaa hallinnoivien osapuolten sisäisiä tietojärjestelmiä — yhdistäminen niihin on tekninen toteutus, joka tulee sen lisäksi.

Joka haluaa varautua nyt, tekee parhaiten aloittamalla omien tuotetietojen kartoittamisella ja ottamalla yhteyttä osapuoleen, joka tulee kokoamaan ja ylläpitämään renkaiden digitaalista tuotepassaporttia, keskustellakseen siitä, mikä toimitusmenetelmä sopii parhaiten olemassa olevaan ERP- tai varastojärjestelmään.

Mihin tämä perustuu

Asetus itsessään on saatavilla EUR-Lexissä. Viitamme jokaiseen väitteeseen; ette joudu luottamaan meihin.

Mitä sinun on konkreettisesti tehtävä

Mitä sinulta odotetaan

Passin on pystyttävä vastaanottamaan tietoja lähnejärjestelmästä

Tuotepassia ei kirjoiteta manuaalisesti erilliseen lomakkeeseen — tiedot tulevat jostakin: ERP-järjestelmästä, varastonhallintapakettista, valmistajan Excel-viennistä tai näiden yhdistelmästä. ESPR:n (asetus (EU) 2024/1781) 10 artikla asettaa vaatimukset siitä, mitkä tiedot passin on sisällettävä ja miten ne ovat saatavilla, mutta se ei määrää, millä järjestelmällä yritys toimittaa nämä tiedot. Renkaiden tuojaalle tai tukkukauppiaalle, jolla on 10–100 työntekijää, tämä tarkoittaa käytännössä sitä, että on oltava kiinteä, toistettava tapa saada tuotetiedot omasta järjestelmästä pasiin — ei kertaluontoinen manuaalinen syöttö, joka keksitään uudelleen jokaisen rengasterän kohdalla.

Kytkennän on oltava yhteensopimatonta tuotteen kohtaisen tunnistenumeron kanssa

ESPR:n 11 artikla kuvaa, kuinka digitaalisen tuotepassin on toimittava tekniikaltaan, mukaan lukien tuotteen ja sen passin välisen kytkennän tunnistenumeron kautta. ERP- tai varastoijärjestelmä käyttää yleensä omia artikkelinumeroita, SKU-koodeja tai sisäisiä koodeja. Passin kytkentää varten se sisäinen koodi on oltava yhdenmukainen sen tunnistenumeron kanssa, jota passi käyttää, tai se on käännettävä kyseiseen tunnistenumeroon. Yritykset, jotka käyttävät jo selkeää, ainutlaatuista koodia kunkin renkaankoon tai erän kohdalla varastojärjestelmässään, ovat tässä askeessa edellä; yritykset, jotka käyttävät keräyssarjoja tai yleisiä mallinimiä, huomaavat usein vasta kytkennässä, että heidän sisäinen hallinto ei ole tarpeeksi yksityiskohtaista. Lisää tästä perustoiminnosta on kuinka annan jokaiselle tuotteelle ainutlaatuisen tunnistekoodin?

Lähnejärjestelmän muutokset on heijastuttava passiin

Varastojärjestelmä ei ole koskaan staattinen: hinnat muuttuvat, tekniset tiedot päivitetään, toimittaja muuttaa koostumusta. 10 artikla edellyttää passia, joka kuvastaa kulloinkin voimassa olevaa tilaa siinä määrin kuin tietojen luokka sen vaatii. Yritykselle tämä tarkoittaa sitä, että oman järjestelmän kytkennän on toimittava paitsi ensimmäisen syöttökerran yhteydessä myös myöhemmissä muutoksissa — muuten syntyy passi, joka oli oikea julkaisuhetkellä, mutta ei enää nyt.

Kytkentä on jäljitettävä lähteeseen

Passi, joka näyttää tietoja ilman, että on enää mahdollista jäljittää, mistä järjestelmästä, mihin viennista tai mihin versioon nämä tiedot tulevat, on vaikeaa puolustaa tarkastuksessa. Tämä ei noudata mitään erityistä artiklaa, vaan seuraa 10 ja 11 artiklan käytännön puolesta: tietojen on oltava oikeita JA tarkastettavissa. Yrityksille, joilla on kytkentä niiden ERP-järjestelmään, tämä tarkoittaa, että jonkinlainen kirjaaminen tai versionhallinta on toivottavaa — milloin mitkä tiedot on siirretty ja kuka ne on siirtänyt.

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

Tukkukauppias kytkee ERP-järjestelmän varastomoduulin pasiin kerran käynnistäessä, mutta unohtaa, että myöhemmin lisättyjä uusia renkaankokoja ei oteta automaattisesti mukaan — passi jää alkuperäiselle päivämäärälle olevan valikoiman tasolle.

Tuoja käyttää ERP-järjestelmässä koko tuotelinjalle yhteistä koodia ("175/65R14 kesärenkaat, eri merkit"), kun taas passi on toimittava kunkin ainutlaatuisen tunnistenumeron mukaan. Kytkentä tuottaa sitten yhden passin tuotteille, joilla olisi kukin omansa — katso myös kuinka renkaan koko suhteuttaa ainutlaatuiseen tunnistekoodiin?

Autonvuokraajaksi kutsuttu henkilö saa valmistajan viennin muodossa, joka ei vastaa omaa varastojärjestelmää, ja tiedot kirjoitetaan manuaalisesti väliintiedostoon. Seuraavalla toimituksella kyseistä väliintiedostoa ei päivitetä, joten passi näyttää vanempaa versiota tekniset tiedoista kuin mitä varastossa todellisuudessa on.

Yritys kytkee ERP-järjestelmän suoraan pasiin ilman välivaihetta, ja viantilanteessa olevassa vientikentässä (esimerkiksi sekoitettu sarake renkaankoot) tapahtuu virheen, joka tulee näkymättömästi useisiin paseihin, koska kukaan ei tarkasta kytkettyjä tietoja niiden siirron jälkeen.

Tuoja olettaa, että yhteen kertaan kopiointi riittää kaikille mallin tulevaisille varianteille, vaikka todellisuudessa jokaista kokoa tai suoritusmuotoa varten tarvitaan erilliset tiedot — kysymys siitä, voiko tietoja käyttää uudelleen saman mallin eri rengaskooille, tulee liian myöhään esille, katso Voiko käyttää samoja tietoja useiden saman mallin rengaskokojen osalta?

Mitä voit dokumentoida

Yhteenveto siitä, mikä järjestelmä (ERP, varaston hallinta, toimittajaportti) on lähteenä kullekin pasportin tietokentälle, jotta kysymyksen tai tarkastuksen yhteydessä on välittömästi selvää, mistä numero tai erittely on peräisin.
Kiinteä menettely tietojen siirtämiseksi uusille tuotteille, mukaan lukien hetki, jolloin yksilöllinen tunnuskoodi määritetään ja kytketään.
Sopimus siitä, kuka vastaa pasportin päivittämisestä, kun bronsysteemin tiedot muuttuvat — ja missä työnkulussa se tapahtuu.
Tarkistusaskel jokaisen kopioinnin tai viennin jälkeen, jossa tarkistetaan satunnaisotannalla, vastaavat pasportin tiedot bronsysteemiä.
Lokitiedosto tai versiohistoria siitä, mitä on siirretty ja milloin, jotta muutos on jälkikäteen jäljitettävissä.
Dokumentointi itse teknisestä kytkennästä (mitkä vientimuodot, mitkä kentät kartoitetaan, mikä ohjelmisto tai välikerros käytetään), käytettävissä sisäisten auditointien liitteenä.

Yrityksille, joiden on vielä määritettävä, kuuluvatko niiden renkaat ylipäänsä tämän velvoitteen piiriin, se on looginen aikaisempi vaihe — katso koskeeko digitaalinen tuotepassi minun renkaita? Joka haluaa tietää enemmän pasportin roolista kokonaisena ketjuna ja siitä, kuinka oman järjestelmän kytkentä siihen liittyy, löytää yleisen selityksen mitä on rengastuotteiden digitaalinen tuotepassi?

Tämä ei ole oikeudellinen neuvonta. Tämä sivu antaa yleistä tietoa säädöksistä, joita tämä alusta käsittelee. Emme tunne tilannettasi. Jos epäilet omaa tilannettasi, ota yhteyttä lakimieheen tai toimivaltaiseen valvontaviranomaiseen.

Kirjoitettu tekoälyllä edellä olevien lähteiden perusteella, ihmisen tarkistama 22.8.2026. Onko jokin vialla? Kerro meille — korjaukset saaivat prioriteetin.