Kas saab toodete passiporti ühendada minu ERP- või varude süsteemiga?

Ühendamine on lähtepunkt, tehniline vorm veel

Ühendamine digitaalse tootepassi ja omaenda ERP- või varude süsteemi vahel vastab viisile, kuidas ESPR on passi korraldanud: andmed peavad olema masinloetavad ja vastastikku ühilduvad, just selleks, et neid ei peaks iga kord uuesti käsitsi sisestama. ESPR-i artikkel 10 (Määrus (EL) 2024/1781) seab tootepassi nõudmised, mis on seotud vastastikuse ühilduvusega, ja artikkel 11 käsitleb selle tehnilist kujundamist ja toimimist, sealhulgas andmete vahetamise viisi. See tähendab, et ühendamine on põhimõtteliselt võimalik. See, mida veel puudub, on konkreetne tehniline teostus tekstiilile: milline failiformaat, millised väljad on kohustuslikud ja kas tuleb standard API, pole veel fikseeritud. Need üksikasjad tulevad täiendavast õigusaktist, mis saadetakse tekstiili ja riietuse jaoks spetsiaalselt."

Kellele see kehtib ja millele mitte

Artiklist 10 tulenev vastastikuse ühilduvuse nõue ja artiklist 11 tulevad tehnilised määrused kehtivad digitaalsele tootepasile omaette, olenemata sellest, kas kaubamärk, importija või privaatne silt koostab passi ise või teeb selle koostada. See on seega üldine nõue ESPRis, mitte midagi, mis leiutatakse eraldi iga tootekategooria jaoks. Sellest ei tulene, et nüüd tuleb juba ehitada tehniline ühendamine, ega garantiid, et mingi failiformaat või protokoll hiljem kasutatav osutub. Pass pole ka ERP-süsteemi koopia: see sisaldab tootepasile asjakohaseid andmeid (koostis, päritolu, hooldusteave ja muud), mitte täielikku varude- või tellimusehaldust. Ühendamine tähendab praktikas, et osa juba olemasolevast tooteteabest saadetakse passi, mitte et mõlemad süsteemid täielikult ühte sulavad.

Millal see konkreetne muutub ja mis selles aja jooksul kehtib

Selle kohustuse jaoks pole kindlat kuupäeva. ESPR-i tööplaanist 2025–2030 tuleneb, et tekstiili jaoks oodatakse delegeeritud akti 2027. aastal ja et riidel, mis sisaldab kaheksakümmend protsenti või rohkem teksti kiudaineid, on siis esimesena aeg käes. Niipea kui see õigusakt avaldatakse, selgub ka, millised tehnilised nõuded andmete vahetamisele esitatakse, ja seega kas ja kuidas ühendamine ERP- või varude süsteemiga välja näha võib. Kuni selleni kehtivad ainult artikli 10 ja 11 üldraamistikud: raamistik on paigal, tekstiili tehniline teostus veel mitte. Kes nüüd juba ühendamist ehitama tahaks, ehitab raamistikule, mille üksikasjad võivad veel muutuda.

Mida see praktikas tähendab, samm-sammu võrra

Kõigepealt on mõttekas vaadata, millised andmed on juba omaenda süsteemis ja millised neist tõenäoliselt passi satuvad: kiuaine koostis, tootmise riik, materjali päritolu, hooldusjuhised. Seejärel on praktiline neid andmeid võimalikult struktureeritult fikseerida, kindlates väljades üheselt mõistetavate väärtustega vabateksti asemel, et neid oleks hiljem lihtsam edastada ükskõik millisesse vormingusse. Seejärel on mõistlik oodake tehtu ühendamise või API tegeliku ehitamisega, sest tekstiili nõuded pole veel fikseeritud; energiat, mis praegu konkreetse ühendamise jaoks kulutatakse, võib delegeeritud akti avaldamise järel siiski muutmine nõuda. Aga see, mis juba töötab, on andmete esitamine nii, nagu see praegu saadaval on: käsitsi, faili kaudu või lihtsa ekspordina olemasolevast süsteemist. Texpas koostab passi andmetest, mida tootja või importija esitab, ja töötleb seda esitamist juba ilma reaalajas ühendamiseta. Niipea kui tekstiili tehniline raamistik on teada, saab kaaluda, kas otsesem ühendamine ERP- või varude süsteemist lisaväärtust annab.

Millel see põhineb: ESPR-i artikkel 10 ja 11

Interoperatiivsuse nõue ja digitaalse tootepassi masinloetavuse nõue tulenevad ESPR-i (Euroopa Parlamendi ja Nõukogu määrus (EL) 2024/1781) artiklist 10, mis sätestab passi üldised nõuded. Sama määruse artikkel 11 kirjeldab passi tehnilist kujundust ja toimimist, sealhulgas viisi, kuidas andmeid digitaalselt registreeritakse ja vahetatakse. Mõlemad artiklid loovad raamistiku, millesse hilisem tekstiilile kehtestatud toote-spetsiifiline regulatsioon peab täitma tehnilist üksikasju; teksti ja tekstiili kohta sellist täitmist veel ei ole.

Kes registreerib nüüd juba struktureeritult andmeid koostise, päritolu ja hoolduse kohta oma süsteemis, ei pea seda hiljem uuesti alustama, ükskõik millist tehnilist kuju ühendus saab. Määruse delegeeritud akti praeguse seisundi ja täpse ajakava kohta on Euroopa Komisjoni ametlik allikas jälgimiseks asjakohane.

Millel see põhineb

Määrus ise on EUR-Lexis. Me viitame igale väitele; te ei pea meil uskuma.

Mida te konkreetselt peate tegema

Mida teilt oodatakse

Pasport peab saama andmeid lähte-süsteemidest

Artikkel 10 ESPR-ist (Määrus (EL) 2024/1781) sätestab nõuded selle kohta, millised andmed peavad olema digitaalses toodepasporsis ja kuidas need on kättesaadavad. Need andmed ei tulnud niisama sealt: need asuvad juba olemasolevates süsteemides nagu ERP-pakett, PLM-süsteem või varustusjuhtimispakett — materjali koosseis, tarnija andmed, partii numbrid, hooldus juhised. 10–100 töötajaga ettevõtte jaoks tähendab see praktiliselt, et peavad olema ühenduses süsteem, kus need andmed juba asuvad, ja süsteem, mis pasporti koostab ja avaldab. See võib olla automatiseeritud ühendus, kuid ka perioodiline eksport, mis laetakse käsitsi üles. Mõlemad on põhimõtteliselt võimalikud; milline viis on praktiliselt sobiv, sõltub sellest, kui palju tooteid ja variante on ja kui sageli andmed muutuvad.

Tehniline toimimine peab olema kooskõlas kehtestatud standarditega

Artikkel 11 ESPR-ist (Määrus (EL) 2024/1781) kirjeldab paspordi tehnilist kujundust ja tööd, sealhulgas andmete vahetamise viisi. See puudutab otseselt küsimust, kuidas tehniline ühendus luuakse: mitte iga ekspordivormingust suvaliste ERP-süsteemi pealt ei ühildu ilma töötluseta sellega, mida paspordisüsteem ootab. Keskmise suurusega ettevõtte jaoks tähendab see, et peavad olema tõlgete vajadus omade andmestruktuuri ja paspordi jaoks kasutatava vormingu vahel. See on tehniline küsimus, mitte juriidiline — kuid see puudutab siiski küsimust mis on GS1 Digital Link ja kas see on tootepaspordi jaoks vajalik, kuna osa oodatavast standardiseerimisest käib selliste süsteemide kaudu.

Iga toode peab olema jäljendatav õigete paspordiga andmetele

ERP- või varustu süsteemiga ühendus toimib ainult siis, kui füüsiline toode sobib õige pasportiga kokku. See nõuab süsteemide vahel järjekindlat võtit: sama artiklinumber, sama partiikood või sama variandi-tunnus ERP-süsteemis kui paspordi puhul. Ilma sellise ühenduseta tekib oht, et ühendatud süsteem küll andmeid saadab, kuid vale paspordi juurde, või et muudatus ühes süsteemis ei jõustu teise süsteemini. See on tihedalt seotud viisiga, kuidas iga toode saab kordumatu identifitseerimiskoodi; ilma selge identifitseerimislogikata ei ole süsteemide vahelise ühendusega palju väärtust.

Kus asjad praktikas valesti lähevad

Esimene sageli esinevav olukord: ettevõttel on ERP-süsteem, kus artiklid on kinnitatud stiili järgi, kuid mitte värvuse või suuruse järgi. Pasport peab aga varianttasandil klapima, ja siis selgub, et ühendus saadab andmeid, mis ühele suurusele sobivad ja teisele mitte.

Teine olukord: andmeid kantakse üks kord kolleemi stardi ajal, kuid hilisem muudatus ERP-süsteemis — näiteks erinevate tarnijate tarvitamine osale partiist — ei kanti automaatselt avaldatud pasporti. Pasport kaob seega tegelikkusest ilma, et keegi seda märkaks, kuni keegi veale tabab ja mõtiskleb, kas avaldatud toodepasporti saab veel parandada.

Kolmas olukord: ühendus on tehniliselt seadistanud väline IT-pool, kuid keegi ettevõttes ei kontrolli hiljem, kas andmed, mis pasporti jõuavad, langevad kokku sellega, mis sildil või pakendil on. Ühendus, mis tehniline töötab, ei ole automaatselt ühendus, mis õige on.

Neljas olukord: varustu süsteem kasutatakse pasportide automaatseks aegumiseks niipea, kui toode on välja müüdud, arvestamata küsimusega, kui kaua pasport saadaval olla peab. See võib põhjustada mittevastavust selle vahel, mis on operatsioonilt mugav varustu haldusele ja mida oodatakse juhul, kui kui kaua peab tootepasport saadaval olema.

Viies olukord: füsiooni, ülevõtmise või äriüksuse lõpetamise korral katkestaksatakse ühendus ilma mõtlemata, kes andmeid seejärel haldab, mis omakorda seondub küsimusega mis juhtub tootepassiportaaliga, kui ettevõte lõpetab töö.

Mida saate salvestada

Ülevaade, millised süsteemid milliseid paspoordandmeid edastaksavad: ERP materjali ja päritolu jaoks, varude süsteem kättesaadavuse jaoks, PLM kujundus- ja koosseisandmete jaoks.
Dokumenteeritud kokkulepe sünkroonimise sageduse kohta: reaalajas ühendus, päevane eksport või käsitsi värskendus kollektsiooni kohta.
Dokument, milles kirjeldatakse identifikaatorivõtit, mida kasutatakse toote sobitamiseks ERP-süsteemis õige paspoordiga – sealhulgas kuidas see toimib suuruse või värvi variantide puhul.
Vastutav funktsioon või isik, kes kontrollib, kas ühenduse kaudu saabutavad andmed on tõepoolest õiged, enne kui paspoort avaldatakse või ajakohastatakse.
Protseduur selle jaoks, mis juhtub bronikonasüsteemi muutumise korral: kes seda signaliseerib ja kuidas muudatus jõudab avaldatud paspoordini.
Kokkuleppet IT-pakkujaga või sisemise IT-osakonnaga ühenduse tehnilist formaati käsitlevalt, sealhulgas selle kohta, mis juhtub süsteemi vahetuse või ülemineku korral.
Ülevaade, millised andmed antakse tegelikult ühenduse kaudu automaatselt edasi ja millised tuleb käsitsi täiendada, et ei tekiks lünk selle vahel, mida süsteem arvab saadavat, ja sellega, mis paspoordis tegelikult on.

See ei ole õiguslik nõu. See leht annab üldist teavet reguleerimise kohta, mille üle see platvorm käib. Me ei tea teie olukorda. Kui te kahtlete oma juhul, konsulteerige juristiga või pädevate järelevalveasutustega.

Kirjutatud AI-ga ülaltoodud allikate põhjal, kontrollitud inimese poolt 2026-08-22. Kas midagi ei ole õige? Andke teada — parandused saavad prioriteedi.