Ar galiu produkto pasą susieti su savo ERP arba atsargų sistema?

Sujungimas yra atskaitos taškas, techninis formatas dar nenustatytas

Sujungimas tarp skaitmeninio produkto paso ir savos ERP arba atsargų sistemos atitinka tai, kaip ESPR nustatė pasą: duomenys turi būti mašiniškai skaitomi ir tarpoperable, būtent todėl, kad jie nereikalautų vis iš naujo rankiniu būdu įvedami. ESPR 10 straipsnis (Reglamentas (ES) 2024/1781) nustato produkto paso reikalavimus, orientuotus į tarpoperabilumą, o 11 straipsnis susijęs su techniniu projektavimu ir veikimu, įskaitant duomenų mainų būdą. Tai reiškia, kad sujungimas iš esmės yra įmanomas. To, kas dar trūksta, yra konkretus tekstilės techninis įgyvendinimas: koks failų formatas, kurie laukai yra privalomi ir ar bus standartinė API, dar nenustatytas. Šie detalės kyla iš papildomų taisyklių, kurios bus nustatytos specialiai aprangai ir tekstilei.

Kam tai taikoma ir kam ne

Tarpoperabilumo reikalavimas iš 10 straipsnio ir techninės nuostatos iš 11 straipsnio taikomi skaitmeniniam produkto pasui kaip tokiam, neatsižvelgiant į tai, ar prekės ženklas, importuotojas ar privatus etiketė patys sudaro pasą, ar jį sudaro. Tai yra bendras ESPR reikalavimas, ne kas nors, kas atskirai išradinėjamas pagal produkto kategoriją. Iš to neišplaukia pareiga dabar jau konstruoti techninį susukinimą, arba garantija, kad tam tikras failų formatas ar protokolas vėliau pasirodytų naudingas. Be to, pasas nėra ERP sistemos kopija: jame yra duomenys, kurie yra svarbūs pasui (sudėtis, kilmė, priežiūros informacija ir panašiai), o ne visa atsargų arba užsakymų administracija. Praktikoje sujungimas reiškia, kad dalis jau esančių produkto duomenų perkeliama į pasą, o ne tai, kad abi sistemos visiškai susilietų.

Kada tai konkretiškai vyksta ir kas galioja tol

Nėra fiksuotos datos šiam įpareigojimui. Iš ESPR veiksmų plano 2025–2030 matyti, kad tekstilei tikėtinas deleguotasis aktas 2027 metais, o aprangoje su aštuoniasdešimt procentų ar daugiau tekstilės skaidulų pirmiausiai ateis eilė. Kai tik tas aktas bus paskelbtas, taip pat paaiškės, kokie techniniai reikalavimai keliami duomenų mainams, ir taigi ar ir kaip gali atrodyti sujungimas su ERP arba atsargų sistema. Kol to nebus, galioja tik bendrosios nuostatos iš 10 ir 11 straipsnių: rėmas egzistuoja, tekstilės techninis įgyvendinimas dar ne. Jei kas dabar norėtų pradėti kurti susukinimą, tai yra nustatyti ant rėmo, kurio detalės gali pasikeitinti.

Ką tai praktikoje reiškia, žingsnis po žingsnio

Pirmiausia pravartu pamatyti, kokie duomenys jau yra savoje sistemoje ir kurie iš jų tikriausiai atsidurs pasporte: skaidulų sudėtis, gamybos šalis, medžiagų kilmė, priežiūros instrukcijos. Toliau praktiška tuos duomenis fiksuoti kuo labiau struktūrizuotai, pastoviais laukais su nedviprasmiškomis reikšmėmis, o ne laisvu tekstu, kad jie būtų lengviau perkelti į bet kokį formatą. Po to tikslinga palaukti su tikra techninio susukinimo arba API konstravimo, nes tekstilės reikalavimai dar nenustatyti; energija, kuris dabar skiriama konkrečiam susukinimui, gali po deleguoto akto paskelbimo vis tiek prireikti peržiūrėti. Ką jau nuo pat pradžios galima, tai duomenų teikimas tokiu būdu, koks dabar yra prieinamas: rankinis, per failą, arba per paprastą eksportą iš esamos sistemos. Texpas sudeda pasą iš duomenų, kuriuos teikia gamintojas arba importuotojas, ir tą tiekimą dabar jau apdoroja be to, kad tam reikalinga tiesioginė sujungimas. Kai bus žinomas tekstilės techninis rėmas, galima bus patikrinti, ar tiesioginis susukinimas iš ERP arba atsargų sistemos suteikia didesnę naudą.

Ant ko tai paremta: ESPR 10 ir 11 straipsniai

Interoperabilumo reikalavimas ir mašininio skaitomosti reikalavimas skaitmeniniam produkto pasui kyla iš ESPR (Reglamento (ES) 2024/1781) 10 straipsnio, kuriame nustatyti bendrieji paso reikalavimai. Tos pačios reglamento 11 straipsnis aprašo paso techninį projektavimą ir veikimą, įskaitant tai, kaip duomenys skaitmenine forma fiksuojami ir keičiamasi. Abu straipsniai sudaro sistemą, pagal kurią vėlesnė produktui specifinė tekstilės teisės akta turėtų užpildyti techninius detales; šis užpildymas tekstilei ir drabužiams dar neatliktas.

Kas dabar jau struktūruotai fiksuoja duomenis apie sudėtį, kilmę ir priežiūrą savo sistemoje, vėliau nereiks to pradėti iš naujo, nepaisant to, kokią techninę formą įgis ryšys. Norint sužinoti faktinę delegavimo akto padėtį ir tikslų laiko grafiką, reikėtų stebėti oficialų Europos Komisijos šaltinį.

Šiuo grindžiama

Pats reglamentas yra EUR-Lex. Nurodome pagal kiekvieną teiginį; jūs mums tikėti neturite.

Ką konkrečiai turite daryti

Ko iš jūsų tikimasi

Pasportas turi galėti gauti duomenis iš šaltinio sistemų

10 straipsnis ESPR (Reglamentas (ES) 2024/1781) nustato reikalavimus, kokie duomenys turi būti skaitmeniniame produkto pasprorte ir kaip jie prieinami. Šie duomenys atsiranda ne iš nieko: jie jau yra esamose sistemose, pvz., ERP paketiniame sprendime, PLM sistemoje arba atsargų valdymo pakete — medžiagų sudėtyje, tiekėjų duomenimis, partijos numeriais, priežiūros instrukcijomis. Praktiškai 10–100 darbuotojų turinti bendrovė turi turėti ryšį tarp sistemos, kurioje šie duomenys jau yra, ir sistemos, kuri surenka ir skelbia pasportą. Tai gali būti automatizuota sąsaja, bet taip pat ir periodinė eksportacija, kuri rankiniu būdu įkeliama. Abu variantai iš esmės įmanomi; kuris praktiškai tinkamas, priklauso nuo to, kiek produktų ir variantų yra ir kaip dažnai duomenys keičiasi.

Techninė veikla turi atitikti nustatytus standartus

11 straipsnis ESPR (Reglamentas (ES) 2024/1781) aprašo pasporto techninį projektavimą ir veikimą, įskaitant duomenų mainus. Tai tiesiogiai susiję su klausimu, kaip techninė sąsaja nustatoma: ne kiekvienas eksportavimo formatas iš bet kurios ERP sistemos be apdorojimo atitinka tai, ko tikisi pasporto sistema. Vidutinio dydžio bendrovei tai reiškia, kad reikalingas vertimas tarp savos duomenų struktūros ir formato, kuris naudojamas pasportui. Tai techninis klausimas, o ne juridinis — bet jis susiję ir su klausimu kas yra GS1 Digital Link ir ar tai būtina produkto pasui, nes dalis numatomo standartizavimo vyksta per tokias sistemas.

Kiekvienas produktas turi būti sugrąžintas į tinkamus pasporto duomenis

Sąsaja su ERP ar atsargų sistema veikia tik tada, jei yra aiški fiziniu produktą derinti su teisingu pasportu. Tam reikalus nuoseklus raktas tarp sistemų: tas pats straipsnio numeris, tas pats partijos kodas arba tas pats varianto identifikatorius ERP sistemoje kaip ir pasporte. Be šios sąsajos iškyla rizika, kad susieta sistema gali siųsti duomenis, bet į neteisingą pasportą, arba kad pakeitimas vienoje sistemoje neatsispindi kitoje. Tai glaudžiai susijęs su tuo, kaip kiekvienas produktas gauna unikalų identifikacijos kodą; be aiškios identifikacijos logikos sąsaja tarp sistemų turi mažą vertę.

Kur praktikoje nepavyksta

Pirmoji dažnai pasitaikanti situacija: bendrovė turi ERP sistemą, kurioje straipsniai registruojami pagal stilių, bet ne pagal spalvą ar dydį. Tačiau pasportas turi atitikti variantų lygmeniu, ir tada sąsaja siunčia duomenis, kurie yra teisingi vienam dydžiui, bet neteisingi kitam.

Antroji situacija: duomenys perkeliami vieną kartą kolekcijai paleidžiant, tačiau vėlesnis pakeitimas ERP sistemoje — pavyzdžiui, kitas tiekėjas daliai partijos — nėra automatiškai naudojamas paskelbto pasporto atžvilgiu. Pasportas taip atsiskiriausias nuo realybės, nesprendžiant to, kol kažkas klaida neatranda ir klausia, ar paskelbtas produkto pasportas gali būti koreguojamas.

Trečioji situacija: sąsaja techninė nustatoma iš išorinės IT šalies, bet niekas bendrovėje vėliau nekontroliuoja, ar duomenys, kurie pasiekia pasportą, tikrai atitinka tai, kas yra žymoje ar pakuotėje. Techninė sąsaja, kuri veikia, nėra automatiškai sąsaja, kuri yra teisinga.

Ketvirtoji situacija: atsargų sistema naudojama automatiniam pasportų panaikinimui, kai produktas išparduodamas, neatsižvelgiant į tai, kaip ilgai pasportas turi būti prieinamas. Tai gali sukelti neatitikimą tarp to, kas operaciškai patogu atsargų administracijoje, ir to, ką tikimasi turėti atžvilgiu kiek laiko produkto pasas turi būti prieinas.

Penktoji situacija: sujungus, įsigijus ar nutraukus verslo dalį, ryšys atjungiamas neapgalvojus, kas po to tvarkyti duomenis, o tai vėl grįžta prie klausimo kas atsitinka produkto pasui, jei įmonė sustoja.

Ką galite užfiksuoti

Sistemų, kurios teikia tam tikrus pasporto duomenis, apžvalga: ERP medžiagai ir kilmei, atsargų sistema prieinamumui, PLM dizaino ir sudėties duomenims.
Užfiksuota susitarimo dėl sinchronizavimo dažnio: realaus laiko ryšys, kasdieninis eksportas arba rankinį atnaujinimas pagal kolekciją.
Dokumentas, kuriame aprašomas identifikavimo raktas, naudojamas produktui ERP sistemoje suderinti su teisingu pasportu – įskaitant tai, kaip tai veikia variacijoms pagal dydį ar spalvą.
Atsakinga funkcija arba asmuo, kuris patikrina, ar duomenys, gautami per ryšį, tikrai atitinka faktą prieš publikuojant arba atnaujinant pasportą.
Procedūra, nurodanti, kas atsitinka šaltinio sistemoje įvykus pakeitimui: kas tai signalizuoja ir kaip pakeitimas įvedamas į publikuotą pasportą.
Susitarimai su IT teikėju arba vidine IT skyriumi dėl ryšio techninio formato, įskaitant tai, kas atsitinka keičiant sistemą arba perkeliant duomenis.
Sistemų, kurios duomenis teikia automatiškai per ryšį, ir tų, kurias dar reikia papildyti rankiniu būdu, sąrašas, kad nebūtų spragos tarp to, ką sistema mano siunčianti, ir to, kas iš tikrųjų yra pasporte.

Tai nėra teisinė konsultacija. Šis puslapis suteikia bendrą informaciją apie taisykles, kuriomis remiasi šis platform. Mes nežinome jūsų situacijos. Jei abejojate dėl jūsų konkrečios situacijos, pasitarkite su jurista arba atitinkama priežiūros institucija.

Parašyta naudojant dirbtinį intelektą remiantis aukščiau nurodytais šaltiniais, žmogaus patikrinta 2026-08-22. Ar kažkas ne taip? Pranešite mums — pataisymai gaunami prioritetą.