Kas saan toote digitaalse passi oma ERP- või varusüsteemiga ühendada?

Ühendamine on võimalik, vorm ei ole seadusega fikseeritud

Jah, digitaalset tootetehist saab praktikas ühendada ERP- või varude süsteemiga, kuid ESPR ei sätesta, kuidas see ühendamine välja näeb. Määrus kehtestab siiski nõudeid passi enda suhtes: see peab olema tehniliselt konstrueeritud nii, et andmed oleksid masinloetavad ja et süsteemid saaksid neid automaatselt lugeda ja töödelda, avatud standardite alusel, mitte suletud, kaubamärgiga seotud vormingute alusel (ESPR artikkel 11, määrus (EL) 2024/1781). See nõue on suunatud passi ja andmekandjale, mitte bandide importöörj, jaemüügi või autovarga halduri sisemistele süsteemidele. See, kas ja kuidas ühendamine konkreetse ERP-paketiga toimib, on seega tehniline küsimus passi koostamise ja hostimise poole jaoks — antud juhul platvormi tyrepas.eu jaoks — ja mitte miski, mida seadus üksikasjalikult sätestab.

Kellele see asjakohaselt on ja kellele mitte

See küsimus puudutab eelkõige pooli, kes töötlevad suuri ridade mahte ja kellel tooteteated juba süsteemi kuuluvad: importöörid, kes haldurit artiklinumbreid, partiide andmeid ja tehnilisi spetsifikatsioone, jaemüüjad, kes hoiustavad varude jälgimisel reatüübi järgi, ja autovarga haldurid, kes seovad rehve sõidukitega. Neile on ühendamine peamiselt praktiline: andmeid ei pea siis kaks korda sisestama ja passi teavet saab tagasi oma süsteemi.

Lõpptarbijad, kes ostlevad vaid ühe rehvi ja skannivad QR-koodi, ei puutu ühendamist ERP-süsteemiga — nad loevad passi, nad seda ei täida. Ja väiksemate osapoolte jaoks ilma oma süsteemita pole ühendamine ka kohane: passi saab siis sama hästi käsitsi esitada ja konsulteerida, ilma et see kaoks selle kehtivuse seisukohalt. Artikli 11 tehnilised nõudmised käsitlevad lisaks passi ennast, mitte küsimust, kas passi teenuste pakkuja peab pakkuma konkreetset ühendamist määratud ERP-kaubamärgiga.

Veel pole fikseeritud kuupäeva, kuid selge tööraja

Millal digitaalse tootetehise kohustus rehvide suhtes täpselt kehtima hakkab, pole veel kindel. ESPR-i tööplaanis perioodil 2025–2030 oodatakse rehvide delegeeritud akti 2027. aastal; alles selle avaldamisega saab teada konkreetsest rakendamiskuupäevast. Kuni selle ajani ei kehti rehvidele passi endale kohustusliku nõudeid ega seega ka andmete esitamise või vahetamise viisile.

See ei tähenda, et ei oleks midagi teha. ESPR artikli 10 ja artikli 11 üldnõudmised on juba kehtestatud, kuidas delegeeritud akt rehvide jaoks täiendavalt täidetakse: masinloetavus, avatud standardid ja interooperaalsus ei ole uus leiutis, mis 2027. aastal ilmub, vaid alus, millele rehvide spetsiifilised reeglid ehitatakse. Kes praegu ühendamisest mõtleb, ei ehita seega liivale, ehkki lõplik kuupäev puudub.

Kuidas seda praktikas käsitletakse

Esimene samm on kontrollida, millised andmed on juba ERP- või varude süsteemis, mis tulevikus passi tagasi tulla peab: artiklinumber, partii- või partiiandmed, tootmiskuupäev, tehnilised spetsifikatsioonid reatüübi kohta. Paljud neist andmetest on juba olemas, need on lihtsalt veel struktureeritud kujul passi jaoks valmistamatuid.

Teine samm on välja selgitada, millise vormingu passi koostamise ja hostimise pool sisendina aktsepteerib. Kuna tyrepas.eu ehitab passi fabrikandi või importöörilt saadud andmetest, pole praktiliseks küsimuseks nii palju see, kas ühendamine saab toimuda, vaid millise vormi andmete esitamine kõige mugavamini toimub: perioodiline eksport ERP-süsteemist, struktureeritud fail või muu esitamistee.

Kolmas samm on mõelda teisele suunale: paspordi andmete tagasisidestamine oma süsteemi, näiteks selleks, et autopargihaldur saaks siduda paspordi teavet sõiduki registreeringuga, ilma et ta ise peakski pasporti QR-koodi kaudu otsima. Ka see on tehnilise koordineerimise küsimus ERP-süsteemi ja platvormi vahel, mitte seadusliku kohustuse küsimus.

Lõpuks tuleb arvestada kestvusega: pasporti hostitakse kümne aasta jooksul. Kes sidet loob, on hea teha ka hiljem värskendusi selle perioodi jooksul — näiteks kui tooteandmed muutuvad — nii et side ei tööta mitte ainult esimese andmete edastamise ajal, vaid ka hilisemate muudatuste korral.

Seaduslik alus: ESPR artikli 10 ja 11

Digitaalse tootepaspordi nõuded endid sisalduvad ESPR artiklis 10 (Määrus (EU) 2024/1781), mis kehtestab paspordi üldised nõuded. Sama määruse artikkel 11 käsitleb spetsiaalselt paspordi tehnilist kujundust ja tööd, rõhuga andmete koosoperatiivsusele ja avatud standarditele, nii et andmed oleksid masinloetavad ja vahetatavad. Mõlemad artiklid käsitlevad pasporti tootena, mitte importijate, hulgikauplejate ega autoparkihaldurite siseseid infosüsteeme — nendega sidumine on tehniline täitmine, mis lisandub.

Kes soovib juba ette ettevalmistatust võtta, saab alustada oma tooteandmete kaardistamisest ja võtta ühendust osapoolega, kes koostavad ja hoiavad bandi pasporti, et arutada, milline edastamise marsruut sobib kõige paremini olemasolevasse ERP- või varusüsteemi.

Millel see põhineb

Määrus ise asub EUR-Lexis. Me viidame iga väitena; te ei pea meid uskuma.

Mida te peate konkreetselt tegema

Mida teilt oodatakse

Passipass peab andmeid saama võtta lähtesüsteemist

Tootepassipass ei sisestata käsitsi eraldi vormi — andmed pärinevad kuskilt: ERP-süsteemist, varude haldamise paketist, tootja Excel-ekspordist või nende kombinatsioonist. ESPR-i artikkel 10 (Määrus (EL) 2024/1781) sätestab nõudmised, millised andmed peavad passipassis olema ja kuidas need on ligipääsetavad, kuid ei ettevaata, millise süsteemi kaudu ettevõte need andmed edastab. Bändide importijale või suurkaubandusele 10–100 töötajaga tähendab see praktikas seda, et peab olema kindel, korratav viis, kuidas tootetunnused oma süsteemist passipassi saada — mitte ühekordne käsitsi sisestamine, mis järgmise bändikoguse puhul uuesti välja mõeldakse.

Ühendus peab vastama tootele omase identifitseerimiskoodiga

ESPR-i artikkel 11 kirjeldab, kuidas tootepassipass tehniliselt peab toimima, sealhulgas toote ja tema passipassi ühendamine identifitseerimiskoodi kaudu. ERP- või varude süsteem töötab tavaliselt omade artiklinumbritega, SKU-dega või sisemiste koodidega. Ühendamiseks passipassiga peab see sisemised kood kokku langema või tõlgitava olema passipassi kasutatavasse identifitseerimiskoodisse. Ettevõtted, kes hoiavad iga bändi suuruse või partii jaoks selge, unikaalse koodi oma varude süsteemis, on siin ees; ettevõtted, kes kasutavad kogumipositsioonide või üldiste mudelite nimetuste alusel, avastab sageli alles ühendamisel, et nende sisemine administreerimine ei ole piisavalt detailne. Rohkem sellest algastmest on toodud lehel kuidas annate igale tootele unikaalse identifikaatsioonikooodi?

Muudatused lähtesüsteemis peavad avalduma passipassis

Varude süsteem ei ole kunagi staatiline: hinnad muutuvad, spetsifikatsioonid uuendatakse, tarnija muudab koosseisu. Artikkel 10 lähtub passipassist, mis peegeldab praegust seisu sellisel määral, nagu andmegrupp seda nõuab. Ettevõtte jaoks tähendab see, et ühendus oma süsteemiga ei toimi mitte ainult esimese sisestamise korral, vaid ka hilisemate muudatuste korral — muidu tekib passipass, mis oli avaldamise hetkel õige, kuid nüüd enam mitte.

Ühendus peab olema jäljendatav allikani

Passipass, mis näitab andmeid ilma et oleks võimalik jälgida, millisest süsteemist, millisest ekspordist või millisest versioonist need andmed pärinevad, on kontrolli korral raske põhjendada. See ei tulene konkreetsest artiklista, vaid artikli 10 ja 11 praktilisest aspektist: andmed peavad olema õiged JA kontrollitavad. Ettevõtetel, kellel on ühendus nende ERP-ga, tähendab see, et mingisugune logimine või versioonihaldus on soovitav — millal on millised andmed üle kantud ja kes seda tegi.

Kus praktikas valesti läheb

Suurkaubandus ühendab ERP-süsteemi varude mooduli passipassiga ühe korra käivitamisel, kuid unustab, et hiljem lisatud uued bändi suurused ei lisandu automaatselt — passipass jääb alguskuupäeva sortimendi peale.

Importija kasutab ERP-süsteemis terve tootelingi jaoks kogukood ("175/65R14 suverehv, erinevad kaubamärgid"), samas kui passipass peab töötama iga unikaalse identifitseerimiskoodi jaoks. Ühendus annab siis ühe passipassi tootele, mis tegelikult vajavad kõik oma passipassi — vt ka kuidas on bandi mõõt seotud unikaalse identifikaatsioonikoodiga?

Vagunitehaldur saab tootjalt ekspordi formaadis, mis ei ühti oma varude süsteemiga, ja andmed sisestatakse käsitsi vahefaili — järgmisel tarnemisel seda vahefaili ei uuendata, seega näitab passipass spetsifikatsioonide vanemat versiooni kui see, mis tegelikult laos on.

Ettevõte ühendab ERP-süsteemi otse passipassiga ilma vaheastmeta, ja ekspordiväljal olev viga (näiteks bändi suuruste segatud veerg) jõuab nägemata mitmes passipassis, kuna keegi ei kontrolli ühendatud andmeid pärast ülekandmist.

Importöör arvab, et ühe korra ühendamine piisab kõigi mudeli tulevaste versioonide jaoks, samas kui tegelikult on iga suuruse või variandi jaoks vaja eraldi andmeid — küsimus selle kohta, kas andmeid võib erinevate samade mudeli rehvide suuruste jaoks taaskasutada, tekib liiga hilja, vaata kas ma saaksin kasutada samu andmeid mitme samade mudeli rehvide suuruse jaoks?

Mida saate dokumenteerida

Ülevaade sellest, milline süsteem (ERP, varude haldus, tarnepakkuja portaal) on millise andmevälja allikas passoordis, nii et küsimuse või kontrolli korral on kohe selge, kust arv või spetsifikatsioon pärineb.
Kindel protseduur andmete ülekandmiseks uute toodete puhul, sealhulgas hetk, millal korraldatakse kordumatu identifitseerimiskood ja kytakse see ühendama.
Kokkulepe selle kohta, kes vastutab passoori värskendamise eest, kui andmed lähtekaustikus muutuvad — ja millise tööviisi raames seda tehakse.
Kontrollisamm pärast iga ühendamist või eksporditegevust, milles stikaaseliselt kontrollitakse, kas passoordis olevad andmed vastavad lähtekaustale.
Logiraamat või versiooniajalugu selle kohta, mis ülekandmise käigus toimus ja millal, nii et hilisem muudatus on jälgitav.
Dokumentatsioon ühendamise enda kohta (milliseid ekspordivorminguid kasutatakse, milliseid välju kaardistetakse, millist tarkvara või vahekihti kasutatakse), mida saab kasutada sisemiste auditite lisana.

Ettevõtete puhul, kes peavad veel otsustama, kas nende banded üldse selle kohustuse alla kuuluvad, on see loogiline varasem samm — vaata kas digitaalne tootepass kehtib minu pneuudele? Kes soovib rohkem teada passoori rollist ahelajas tervikuna ja kuhu oma süsteemiga ühendamine sobib, leiab üldise seletuse aadressilt mis on toas digitaalne tootepasport?

See ei ole juriidiline nõuanne. See leht annab üldist teavet regulatsioonist, millele see platvorm kuulub. Me ei tunne teie olukorda. Kui teil on kahtlusi oma juhtumi kohta, küsige nõu juristilt või pädevalt järelevalveorganitelt.

Kirjutatud AI-ga ülaltoodud allikatele tuginedes, inimese poolt kontrollitud 2026-08-22. Kas midagi pole õige? Teatage sellest — parandused saavad eesisikuse.