tyrepas.eu
Prijava Registracija

Ali lahko produktni pasport povežem s svojim sistemom ERP ali upravljanja zalog?

Povezava je mogoča, oblika ni določena v zakonu

Ja, se lahko digitalni produktni potni list v praksi poveže z ERP- ali skladiščnim sistemom, vendar ESPR ne predpisuje, kako ta povezava izgleda. Uredba sicer postavlja zahteve za sam potni list: tehnično mora biti zgrajen tako, da so podatki strojno berljivi in da sistemi lahko samodejno berejo in obdelujejo podatke na podlagi odprtih standardov namesto zaprtih, znamkam pripadajočih formatov (člen 11 ESPR, Uredba (EU) 2024/1781). Ta zahteva je namenjena potnimu listu in nosilcu podatkov, ne notranjim sistemom uvoznika pnevmatik, trgovine na debelo ali upravljavca voznega parka. To, ali in kako dela specifična povezava s konkretnim ERP-paketom, je zato stvar tehnične ureditve pri stranki, ki potni list sestavi in gosti — v tem primeru platforma, kot je tyrepas.eu — in ne nekaj, kar zakon podrobno ureja.

Za koga je to relevantno in za koga ne

To vprašanje je predvsem aktualno pri subjektih, ki obdelajo velike količine pnevmatik in imajo podatke o proizvodih že nekje v sistemu: uvozniki, ki upravljajo številke člankov, podatke o serijah in tehnične specifikacije, trgovine na debelo, ki vodijo zaloge po vrsti pnevmatik, in upravljavci voznih parkov, ki pnevmatike povezujejo z vozili. Zanje je povezava predvsem praktična: podatki se ne morajo dvakrat vpisati, potni list pa se lahko vrne v lastni sistem.

Za končne uporabnike, ki samo kupijo pnevmatiko in skenirajo QR-kodo, povezava z ERP-sistemom nima vloge — le berejo potni list, ga ne vnašajo. Za manjše subjekte brez lastnega sistema tudi povezava ni vprašljiva: potni list se lahko enako dobro dostavi in pregleda ročno, ne da bi to kaj vplivalo na njegovo veljavnost. Tehnične zahteve iz člena 11 se poleg tega nanašajo na sam potni list, ne na vprašanje, ali mora dobavitelj storitev potnega lista nuditi specifično povezavo z določeno ERP-blagovno znamko.

Še ni trdnega datuma, je pa jasen delovni načrt

Kdaj se obveznost za digitalni produktni potni list za pnevmatike res začne, še ni znano. V delovnem načrtu ESPR za obdobje 2025-2030 je pričakovana delegirana uredba za pnevmatike leta 2027; šele z njeno objavo bo znan konkreten začetni datum. Do takrat za pnevmatike ne veljajo obvezne zahteve glede samega potnega lista, zato tudi ne glede načina, kako se podatki dostavljajo ali izmenjujejo.

To ne pomeni, da ni kaj storiti. Splošne zahteve iz člena 10 in člena 11 ESPR so že dane kot okvir, v katerem se delegirana uredba za pnevmatike nadaljnje dopolni: strojno berljivost, odprti standardi in interoperabilnost niso novo odkritje, ki bi se pojavilo šele leta 2027, ampak temelj, na katerem se gradijo pravila, značilna za pnevmatike. Kdor se že sedaj pogaja o povezavi, torej ne gradi na pesku, čeprav še manjka dokončni datum.

Kako se to v praksi izvaja

Prvi korak je preveriti, kateri podatki že so v ERP- ali skladiščnem sistemu, ki morajo kmalu priti v potni list: številka članka, podatki o seriji ali seriji, datum proizvodnje, tehnične specifikacije po vrsti pnevmatik. Marsikateri od teh podatkov že obstaja, le da še niso strukturirano pripravljeni za potni list.

Drugi korak je ugotoviti, kateri format sprejme stranka, ki potni list sestavi in gosti, kot vnos. Ker tyrepas.eu potni list sestavi iz podatkov proizvajalca ali uvoznika, ni praktično vprašanje toliko to, ali je povezava mogoča, ampak v kakšni obliki poteka dostava podatkov najprimerneje: periodični izvoz iz ERP-sistema, strukturirana datoteka ali druga pot dostave.

Tretji korak je razmislek o drugi smeri: povratna povezava podatkov potnega lista v lastni sistem, na primer, da lahko upravljavec voznega parka informacije iz potnega lista poveže z registracijo vozila, ne da bi sam poizkušal najti potni list prek QR-kode. Tudi to je vprašanje tehnične usklajenosti med sistemom ERP in platformo, ne pravne obveznosti.

Nazadnje je pomembno upoštevati trajanje: potni list se gosti za obdobje desetih let. Kdor vzpostavi povezavo, bi moral dobro premisliti tudi na posodobitve v tem obdobju — na primer, ko se podatki o proizvodih spremenijo — da povezava ne deluje samo pri prvem predložitvi, temveč tudi pri kasnejših spremembah.

Pravna podlaga: člen 10 in 11 ESPR

Zahteve za digitalni produktni potni list so navedene v členu 10 Uredbe ESPR (Uredba (EU) 2024/1781), ki določa splošne zahteve za potni list. Člen 11 iste uredbe se posebej ukvarja s tehnično zasnovo in delovanjem potnega lista s poudarkom na interoperabilnosti in odprtih standardih, da so podatki strojno berljivi in izmenljivi. Oba člena se nanašata na potni list kot proizvod, ne na notranje informacijske sisteme uvoznikov, trgovinskih podjetij ali upravljavcev voznih parkov — povezava z njimi je tehnična izvedba, ki pride v dodatku.

Tisti, ki že zdaj želi biti pripravljen, se lahko najbolje prične s preugledom lastnih podatkov o proizvodih in vzpostavitvijo stika s stranjo, ki bo sestavila in gostila potni list za pnevmatike, da se dogovori, katera pot oddaje podatkov je najbolj primerna za obstoječi sistem ERP ali zalogo.

Osnova za to

Sama uredba je dostopna na EUR-Lex. Sklicujemo se na vsako trditev; vam ni treba verjeti nam.

Kaj konkretno morate storiti

Kaj se pričakuje od vas

Potni list mora biti sposoben prejemati podatke iz izvornega sistema

Produktni potni list se ne tipka ročno v ločeni obrazec — podatki prihajajo od nekod: iz sistema ERP, paketa za upravljanje zalog, izvoza Excel od proizvajalca ali kombinacije tega. Člen 10 ESPR (Uredba (EU) 2024/1781) postavlja zahteve glede tega, kateri podatki morajo biti v potnem listu in kako so dostopni, vendar ne predpisuje, prek katerega sistema podjetje te podatke preskrbi. Za uvoznika pnevmatik ali trgovca na debelo z 10 do 100 zaposlenimi to v praksi pomeni, da mora obstajati stabilen, ponovljiv način za prenos podatkov o proizvodih iz lastnega sistema v potni list — ne enkratni ročni vnos, ki ga je pri naslednji seriji pnevmatik treba znova izmisliti.

Povezava mora biti usklajena s to edino identifikacijsko kodo na proizvod

Člen 11 ESPR opisuje, kako mora digitalni produktni potni list tehnično delovati, vključno s povezavo med proizvodom in njegovim potnim listom prek identifikacijske kode. Sistem ERP ali upravljanja zalog običajno deluje z lastnimi številkami artiklov, SKU ali internimi kodami. Za povezavo s potnim listom mora ta interna koda sovpadati z identifikacijsko kodo, ki jo uporablja potni list, ali pa biti vanjo prevedena. Podjetja, ki že vodijo jasno, edino kodo na velikost pnevmatike ali serijo v svojem sistemu upravljanja zalog, imajo tu prednost; podjetja, ki delujejo s skupnimi postavkami ali splošnimi imeni modelov, pogosto ugotovijo šele pri povezavi, da njihova interna administracija ni dovolj natančna. Več o tem osnovnem koraku je zapisano v kako dodelim vsakemu proizvodu edinstveno identifikacijsko kodo?

Spremembe v izvornem sistemu se morajo odražati v potnem listu

Sistem upravljanja zalog nikoli ni statičen: cene se spreminjajo, specifikacije se posodabljajo, dobavitelj spremeni sestavo. Člen 10 izhaja iz potnega lista, ki odraža trenutno stanje, kolikor to zahteva kategorija podatkov. Za podjetje to pomeni, da povezava z lastnim sistemom ne sme delovati le pri prvem vnosu, ampak tudi pri kasnejših spremembah — sicer nastane potni list, ki je bil v času objave pravilen, zdaj pa ni več.

Povezava mora biti sledljiva do vira

Potni list, ki prikazuje podatke brez možnosti ugotoviti, iz katerega sistema, katerega izvoza ali katere različice ti podatki prihajajo, je pri pregledu težko utemeljiti. To ne izhaja iz posebnega člena, ampak iz praktične strani členov 10 in 11 skupaj: podatki morajo biti pravilni IN preverljivi. Za podjetja s povezavo do svojega sistema ERP to pomeni, da je priporočljiva oblike nadzora dnevnika ali upravljanja različic — kdaj je bila katera set podatkov premeščena in od koga.

Kje se stvari v praksi zavlečejo

Trgovec na debelo poveže modul zalog sistema ERP ob zagonu samo enkrat s potnim listom, vendar pozabi, da nove velikosti pnevmatik, ki se pozneje dodajo, niso samodejno vključene — potni list ostane pri asortimanu iz datuma zagona.

Uvoznik v sistemu ERP uporablja skupno kodo za celo linijo izdelkov ("175/65R14 poletna pnevmatika, različne znamke"), medtem ko mora potni list delovati na edino identifikacijsko kodo. Povezava nato ustvari en potni list za izdelke, ki pravzaprav potrebujejo vsak svoj potni list — glej tudi kako se velikost pnevmatike nanaša na edinstveno identifikacijsko kodo?

Upravljavec voznega parka dobi izvoz proizvajalca v obliki, ki se ne ujema z lastnim sistemom upravljanja zalog, in podatki se ročno prepišejo v vmesno datoteko. Pri naslednji dostavi ta vmesna datoteka ni posodobljena, zato potni list prikazuje starejšo različico specifikacij kot tista, ki je pravzaprav v skladišču.

Podjetje poveže sistem ERP neposredno s potnim listom brez vmesnega koraka, in napaka v polju izvoza (na primer zamenjani stolpec z velikostmi pnevmatik) neopazno pride v več potnih listov, ker nihče ne preveri povezanih podatkov po premešanju.

Uvoznik misli, da je enkratna povezava dovoljna za vse prihodnje različice modela, medtem ko so za vsako velikost ali izvedbo dejansko potrebni ločeni podatki — vprašanje, ali je mogoče podatke ponovno uporabiti za različne velikosti pnevmatik istega modela, pa pride prekasno v poštev, glej ali lahko uporabim iste podatke za več velikosti pnevmatik istega modela?

Kaj lahko dokumentirate

  • Pregled sistema (ERP, upravljanje zalog, portal dobavitelja), ki je vir za katerega polja podatkov v pasportu, tako da je pri vprašanju ali pregledu takoj jasno, od kje izvirajo številka ali specifikacija.
  • Stalen postopek za prenos podatkov pri novih proizvodih, vključno s trenutkom, ko se dodeli in poveže edinstvena koda za identifikacijo.
  • Dogovor o tem, kdo je odgovoren za posodabljanje pasporta, kadar se podatki v izvornem sistemu spremenijo — in v katerem delovnem procesu se to dogodi.
  • Korak nadzora po vsaki povezavi ali izvozu, pri katerem se vzorčno preverja, ali se podatki v pasportu ujemajo z izvornim sistemom.
  • Dnevnik ali zgodovina različic, kaj je bilo preneseno in kdaj, tako da je sprememba pozneje sledljiva.
  • Dokumentacija tehnične povezave same (kateri obliki izvoza, katera polja se preslikavajo, katera programska oprema ali vmesna plast se uporablja), uporabna kot priloga pri notranjih revizijah.

Za podjetja, ki morajo še določiti, ali so njihove pnevmatike sploh pod to obveznostjo, je to logičen prej opravljen korak — glej velja digitalniProductPasport za moje pnevmatike? Kdor želi izvedeti več o vlogi pasporta v celotnem verigi in kje se povezava z lastnim sistemom umesti, najde splošno razlago v kaj je digitalni produktni pasport za pnevmatike?

To ni pravno nasvet. Ta stran zagotavlja splošne informacije o predpisih, na katere se nanaša ta platforma. Ne poznamo vašega položaja. Če dvomite o vašem primeru, posvetujte se s pravnikom ali pristojnim nadzornim organom.

Napisano z AI na podlagi virov zgoraj, pregledano s strani ljudi dne 2026-08-22. Je kaj narobe? Nam sporočite — popravki imajo prednost.