Kas saan tootepassi oma ERP- või varustussüsteemiga seostada?

Ühendamine on tehniliselt võimalik, kuid mitte seaduslikult kohustuslik ega välistatud

ESPR-i ega ette, kuidas tootja või importija digitaalse tootepassi andmeid esitab. Määrus seab nõudmised passile endale — millised andmed peab see sisaldama, kuidas see peab olema juurdepääsetav ja milliseid tehnilisi standarte kasutama — kuid jätab avatud, kas andmed sisestatakse käsitsi, pärinevad arvutustabelisse või hangitakse automaatselt ERP- või varusüsteemist. Seega ei ole sisemise süsteemi ja passiteenuse vaheline ühendamine küsimus selles, mis on seadusega lubatud, vaid selles, mis on kasutatava tehnika ja pakutava teenuse jaoks võimalik.

Kellele see asjaomane on ja millele mitte

See küsimus on eriti terav ettevõtetel, kes kasutavad juba ERP- või varusüsteemi ning ei soovi sama tooteteabe kaks korda pidada: kord enda süsteemis, kord passi jaoks. Tegemist on praktilist, mitte õiguslikku küsimust. ESPR ei nõua, et tootjal oleks automaatne ühendamine, ja ei keela seda samuti. Mis määrusega reguleeritakse, on passi andmete lõppkuju, olenemata sellest, kuidas need on esitatud — ja see määrab omakorda, kas ühendamine on mõistlik ja praktiline.

Konkreetset kuupäeva pole, kuid tehnilised raamid on juba paika pandud

Delegeeritud õigusakt, mis teeb digitaalse tootepassi kohustuslikkuse mööblile konkreetseks, puudub veel; ESPR-i tööplaan 2025–2030 nimetab 2028. aastat oodatavaks avaldamise perioodiks. Kuni see õigusakt on olemas, pole kindel ka see, millised tooterühmale omased andmed täpselt kohustuslikud ja mis formaadis. Mis juba kindel on, on ESPR-i artikli 10 ja artikli 11 üldised tehnilised nõudmised passile: need kehtivad kõigi toodete kohta, mis kuuluvad delegeeritud õigusakte alla, seega ka tulevikus mööblile. Need üldised raamid on juba teada ja neid saab kasutada, et mõelda enda andmetöötluse korraldusele, isegi kui täpne sisumine mööblipassi sisu pole veel kindel.

Kuidas seda praktikas käsitleda

Kes nüüd juba ühendamist kaalub, on mõistlik kõigepealt vaadata, millised tooteteated on enda ERP- või varusüsteemis juba struktureeritud: materjali koostis, osade päritolu, mõõtmed, hoolduse juhised ja muud. See on alus, millest passi koostatakse, tehes seda käsitsi või ühendamise kaudu. Järgmisena on mõistlik selgitada välja, millises formaadis need andmed salvestatakse ja kas see formaat sobib välisel süsteemiga vahetamiseks — arvesse võttes struktureeritud välju vabateksti asemel. Sellel platvormil koostatakse pass andmetest, mida tootja või importija esitab; kuidas täpselt see esitus toimub ja kas selleks on saadaval automaatne ühendamine, on praktiline küsimus, mida saab eraldi arutada. Pikema aja jooksul on mõistlik tooteteated nii struktureerida, et need sobivad digitaalse passi jaoks ilma suuremate muudatusteta, olenemata sellest, kas esitus toimub käsitsi või hiljem automaatselt. See säästab topeltööd sel hetkel, kui mööblile kohustus jõustub.

Alus: ESPR-i artikli 10 ja artikli 11

Artikkel 10 ESPR-ist (määrus (EL) 2024/1781) käsitletakse nõudeid, millele digitaalne tootepasport peab vastama, sealhulgas andmete sidumine kordumatu tootekehaga ja nende andmete kättesaadavus toote elutsükli jooksul. Artikkel 11 samast määrusest käsitleb paspordi tehnilist kujundust ja toimimist ning sisaldab nõudeid avatud standardite, interoperaalsuse ja andmete masinloetavuse kohta. Koos määravad need artiklid mitte seda, kuidas andmeid esitada, vaid seda, millisele tehnilisele vormile need andmed lõppkokkuvõttes peavad vastama — ja see on täpselt lähtepunkt küsimusele, kas ja kuidas ERP- või varuvarusüsteemiga side on praktiline.

Mida saate praegu teha

Kaardistage, millised tooteteated on juba teie ERP- või varuvarusüsteemis ja millises vormingus, ning arutage paspordi pakkuja — antud juhul seda platvormi — hinnangul, millised esitamise võimalused on praktilised. Kui mööblite delegeeritud akt on avaldatud, ilmub siia konkreetne kuupäev ja täpsed andmenõuded; kuni selle ajani on otstarbekas muuta oma andmed juba struktureerituks ja ülekantavaks.

Mille alusel see on

Määrus ise asub EUR-Lexis. Me viitame igale väitele; teil ei pea meid uskuma.

Mida te konkreetselt peate tegema

Mida teilt oodatakse

ERP- või varude süsteemi ühendamine digitaalse tootepassi vahendiga on tehniliselt sageli võimalik ja võib säästida palju käsitöid. ESPR ei määra ette, kuidas te oma andmetele ligi jõuate ega kuidas te neid siseselt hallate; määrus seab nõudmisi passile endale, sellele, mis selles peab sisalduma, ja kuidas see peab olema ligipääsetav. See tähendab, et ühendus enda süsteemiga ei ole iseseisev eesmärk, vaid vahend nende nõudmiste täitmiseks.

Pass peab vastama tehtilistele nõudmistele, olenemata andmete allikast

ESPR artikkel 10 (määrus (EL) 2024/1781) kirjeldab, milliseid andmeid peab sisaldama digitaalne tootepasport ja milliste tingimustega peab see vastama, nagu õigsus ja terviklikkus. 10–100 töötajaga ettevõtte jaoks tähendab see, et andmete päritolu — olgu need siis käsitsi sisestatud või automaatselt ERP-süsteemist pärit — ei vähenda seda, mida andmete sisust oodatakse. Seega ühendus ei muuda midagi kohustuses; see muudab ainult seda, kuidas te seda kohustust praktiliselt täidate.

Pass peab vastama tehislikule kujundusele, mida artikkel 11 nõuab

ESPR artikkel 11 (määrus (EL) 2024/1781) käsitleb digitaalse tootepassi tehtilist kujundust ja toimimist, sealhulgas viisi, kuidas andmeid salvestatakse, vahetatakse ja avatakse andmekandjaga. Ühendamisel enda süsteemiga tähendab see, et selle ühenduse väljund — andmed, mis lõpuks passi jõuavad — peab mahutuma passi jaoks kehtivasse tetilistesse raamidesse, nagu kasutatav andmemudel ja juurdepääsu viis QR-koodi kaudu mööblis. Seega ERP-pakendist eksportfail on harva otsene pass; see on tavaliselt allikas, mis tuleb esmalt tõlkida õigesse vormingusse.

Iga ühendus tarnib andmeid, mis peavad olema seotud ainuidentifikaatoriga

ERP- või varude süsteem töötab tavaliselt sisemiste artiklinumbritega või SKU-dega. Need ei lange automaatselt kokku identifikaatoriga, mida tootepasport nõuab. Ühenduse seadistamisel on oluline määrata, kuidas iga toode saab ainuidentifikaatori ja kuidas see kood on seotud olemasoleva artiklikodeeringuga teie enda süsteemis. Ilma selle tõlketa on oht, et sisesed numbrid satuvad kogemata passi, või et ühte tootepassi ei ole õigesti võimalik jälgida õigele varude reale.

Kus läheb praktikas valesti

Automaatne sünkroonimine ilma kontrollimiseta. Ühendus, mis edastab otse ja ilma vaheetapita andmeid ERP-süsteemist passi, tundub tõhus, kuid tähendab ka seda, et allikassüsteemis tekkinud viga — valesti sisestatud materjaliprotsent, aegunud sertifikaat — toimib automaatselt avaldatud passiga.

Segadus sisemise SKU ja avaliku identifikaatori vahel. Ettevõtted kasutavad mõnikord sama sisulist artiklinumbrit kui välise identifikaatorina, kontrollimata, kas see number on juba kuskil muul pool kasutuses või vastab nõuetele. See esineb eriti ettevõtetel, kes töötavad GS1 Digital Linkiga ja peavad ühendust sellega kooskõlla seadma.

Ühendus varude muutumise ja passi staatuse vahel puudub. Kui toode võetakse tootmisest välja või asendatakse uue variaadiga, registreeritakse see ERP-süsteemis küll sageli, kuid see ei viia automaatselt passi uuendamiseni. Küsimus, kas ja kuidas andmeid pärast avaldamist muuta saab esitatakse siis hiljem, tavaliselt siis, kui klient või järelevalveasutus märgib vastuolu.

Ebapiisav tähelepanu kombineeritud toodetele. ERP-süsteem registreerib osi ja variante sageli üksteisest eraldi, samas kui küsimus, kas mööbel tervikuna või iga osa eraldi vajab passi, tuleb eraldi lahendada. Ühendus, mis lähtub varude süsteemi struktuurist, riskib võtta vale üksuse lähtepunktiks.

Integratsioon peatub süsteemi vahetusel või hankija vahetusel. Kui ettevõte vahetab ERP-paketti, muudab majutusteenuse pakkujat või lõpetab koostöö teatud IT-hankijaga, ei arvestata alati, et integratsioon tootepassi süsteemiga tuleb uuesti konfigureerida. See puudutab ka küsimust, mis juhtub tootepasiga kui ettevõte ise lakkab tegevusest või muudab oma organisatsioonilise vormi.

Mida saate dokumenteerida

Ülevaade, millised väljad ERP- või varuosasüsteemist võetakse tootepassi automaatselt üle ja millised väljad kontrollivad alati käsitsi enne avaldamist.
Kindlaksmääratud tõlketabel siseste artiklinumbrite ja väliselt kasutatavate identifitseerimiskoodide vahel, sealhulgas kokkulepe selle kohta, kes hoiab seda tabelit ajakohasena.
Protseduur situatsiooniks, mil muutus alliksüsteemis — uus materjal, uus hankija, muudetud koostis — nõuab tootepassi kontrollimist või kohandamist.
Kokkuleppeid IT-hankijaga või majutusteenuse pakkujaga selle kohta, mis juhtub süsteemi vahetusel, sealhulgas see, kes vastutab integratsiooni ülekandmise eest.
Sisemine kontrollimishetk (näiteks kvartali kaupa), mil valimipõhiselt kontrollitakse, kas avaldatud tootepassi andmed vastavad endiselt ERP-süsteemi praegusele seisundile.
Dokumentatsioon keele või keelte kohta, milles andmeid ERP-süsteemist antakse, seoses küsimusega millisel keelel tootepassi tuleb pakkuda.

Pakume selliste kokkulepete jaoks mallid, et registreerimist ei peaks iga toote puhul uuesti nullist alustama.

See ei ole juriidiline nõuanne. See lehekülg annab üldist teavet reguleerimise kohta, millele see platvorm viitab. Me ei tunne teie olukorda. Kui teil on kahtlusi oma juhul, konsulteerige juristiga või pädevas järelevalveasutusega.

Kirjutatud tehisintellektiga ülaltoodud allikatest lähtudes, inimese kontrolli all 2026-08-22. Kas midagi pole korras? Andke teada — parandused saavad eesõiguse.