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

Sujungimas yra techniškai galimas, bet forma dar neapibrėžta

Skaitmeninė produkto pase sudaryta kaip struktūrizuota, mašinoms skaitoma duomenų bazė, ir tai iš esmės atitinka sujungimą su ERP ar atsargų sistema. ESPR numato, kad duomenys, esantys po paso, turi būti fiksuojami remiantis atvirais standartais ir kad sistemos turi galėti keistis duomenimis. Tai yra būtent principas, kuriuo remtųsi sujungimas su esama verslo sistema: ne rankinis įvedimas kiekvienai matraciui, bet duomenų, kuriuos fabrikantai ar importuotojai jau veda, pateikimas. Kaip toks sujungimas praktikoje atrodys — kokie failų formatai, kurie laukai, koks pateikimo metodas — dar neapibrėžta, nes matracams skirta techninio naudojimo instrukcija dar turi būti paskelbta.

Kam tai taikoma ir kam ne

Šis paaiškinimas skirtas duomenų struktūrai, esančiai po paso, o ne konkrečiam sąsajui ar jungčiai, kuri jau yra prieinama. ESPR aprašo reikalavimus tarpoperabilumui ir tam, kaip techniškai sudaryta pase (duomenų nešėlis, unikalūs identifikavimo kodai, duomenų saugojimas), bet nereguliuoja to, kaip atskiras ERP paketas ar atsargų sistema turi prie jo prisijungti. Pastarasis dalykas — tai įgyvendinimo klausimas, ne teisės aktų klausimas: verordimas nustato, KAS turi būti tarpoperable, o ne tuo, kokia programine įranga dirba įmonė. Lovų parduotuvei, kuri tik parduoda ir nešamsto paso, sujungimas su savo ERP sistema dažniausiai nereikalingas; tai ypač aktualu tiesioginei duomenų pateikimo partijai, dažniausiai fabrikantui ar importuotojui.

Techninės specifikacijos bus paskelbtos su deleguotaisiais aktais

Dar nėra nustatytos datos, kada matracams skirta techninio naudojimo instrukcija bus paskelbta. Europos Komisijos darbo plane 2025–2030 metams numatomas deleguotasis aktas dėl matracų 2028 metais, bet tai yra planas, o ne garantija. Kol šis aktas nepaskelbtas, nėra nustatyti duomenų formatai, laukai ir pateikimo metodai matracams. Tai, kas iš tikrųjų nustatyta, yra pats ESPR karkasas: pase turi būti sudaryta pagal atvirus, tarpoperabius standartus ir susieta su unikaliu produkto identifikatoriumi. Šis karkasas nepasikeiss; jo užpildymas matracams konkretizuojant — gali pasikeisti.

Ką tai reiškia pasiruošimui

Kas dabar jau pagalvoja apie sujungimą, gali daryti kelias dalykus nepramatę galutinės specifikacijos. Visų pirma tikslinga ištirti, kurie duomenys apie matracu jau guli kur nors savoje sistemoje — medžiagų sudėtis, žaliavų kilmė, gamybos data, partijos ar užsakymo numeris — ir ar tie duomenys yra užfiksuoti produkto lygiu, ar tik užsakymo lygiu. Tada naudinga patikrinti, ar jūsų sistema turi eksportavimo funkciją, kuri gali gaminti struktūrizuotus duomenis (pavyzdžiui, eksportavimą į įprastą formatą), nes tai yra atsegimo taškas vėlesniam sujungimui, neatsižvelgiant į tai, kuris tikslus formatas deleguotasis aktas nustatys. Toliau praktiška nustatyti, ar duomenys saugomi pagal produktą, pagal partiją ar pagal užsakymą, nes pase iš galo gaus unikalų identifikatorių kiekviena produkto kopija. Galiausiai verta palaikyti ryšį su puse, kuri sudaryta ir šaito pasą, kad publikavus technines specifikacijas iš karto būtų aišku, koks pateikimo formatas reikalingas ir ar esama sistemos struktūra tam atitinka, ar reikia ją koreguoti. Tiesioginis, automatinis sujungimas tarp ERP sistemos ir paso dar nėra kažkas, kam šiandien jau egzistuoja techninis standartас; kas gali būti — tai savi duomenys iš anksto taip suorganizuoti, kad sujungimas būtų lengvas padaryti vėliau.

Iš kur tai kilo: ESPR 10 ir 11 straipsniai

10 straipsnis iš ESPR (Reglamento (ES) 2024/1781) apibūdina skaitmeninio produkto paso reikalavimus, įskaitant reikalavimą, kad duomenys būtų fiksavami pagal atvirus standartus ir kad sistemos, apdorojančios duomenis, turėtų būti suderinamos. 11 straipsnis kalbėja apie techninio projekto ir paso veikimą, su nuostatomis dėl duomenų nešiklio, unikalių produkto, rinkos dalyvio ir patalpos identifikavimo kodų, ir kaip duomenys yra saugomi ir prieinami. Kartu šie straipsniai sudaro sistemą, kurioje galimas ryšys su išorine sistema, nors jie nenustato konkrečio techninio standarto matracijams — tas išplauks iš dar paskelbtino deleguoto akto.

Ką daryti dabar

Kol kas konkrečiausias žingsnis, kuris gali būti atliekamas: sutvarkytus pagrindinius produktų duomenis ir juos fiksuoti produkto lygiu (o ne tik užsakymo lygiu), nustatyti eksportavimo galimybę iš esamos sistemos ir stebėti matracių techninės specifikacijos paskelbiamą. Kai tik tos specifikacijos bus, šiame puslapyje bus papildyta, kuris formatas ir kuris pristatymo metodas galioja.

Šios informacijos pagrindas

Pats reglamentas yra EUR-Lex. Mes nurodome pagal teiginį; jums nereikia mums tikėti.

Ką jūs konkrečiai turite daryti

Ko tikimasi iš jūsų

Produkto pasporto susietas su ERP ar atsargų sistema nėra savaime nustatyta teisinė pareiga. ESPR nenumato, kurias šaltinio sistemas gamintoja turi naudoti pasporto duomenims pateikti. Tačiau yra aiški reikalavimų sritis — reikalavimai pačiam pasportui: kaip jis techniškai veikia ir ką jis turi sugebėti daryti. Šie reikalavimai netiesiogiai lemia, ar — ir kaip — ryšys su vidinėmis sistemomis yra naudingas.

Pasportas turi techniškai atitikti vienodą veikimą

11 straipsnis iš ESPR (Reglamentas (ES) 2024/1781) nusako techninius reikalavimus skaitmeniniam produkto pasportui, tokius kaip suderinamumas su sistemomis, kurias naudoja Komisija ir rinka. Kai kurių 10–100 darbuotojų turinčių įmonių atžvilgiu tai reiškia, kad pasporto duomenys negali likti savoje, skirtingoje formoje: jie galiausiai turi būti pateikti tokiu formatu, kurį gali perskaityti pasporto sistema. Tai gali būti atliekama tiesiogine ERP sistemos sąsaja arba per rankinį eksportavimą — tai yra pasirinkimas, o ne reglamento pareiga.

Pasporto turinys turi būti aktualus ir garantuotai teisingas

10 straipsnis iš ESPR (Reglamentas (ES) 2024/1781) nustato reikalavimus tam, kas turi būti pasporte, ir atsaką, kas už tai atsakingas. Praktiškai tai reiškia, kad duomenys, gaunami iš ERP ar atsargų sistemos — medžiagos sudėtis, gamybos data, partijos numeris — turi būti teisingi ir aktualūs tuo metu, kai pasportas kuriamas ar atnaujinamas. Kai kuriam įmonę su keliomis gamybos linijomis ir reguliairiai keičiamomis sąvėmis (kita putų rūšis, kitas žaliavų tiekėjas) tai yra priežastis peržiūrėti, ar duomenys yra rankiniu būdu perraš omi, ar automatiškai perkelti iš sistemos, kurioje jie jau yra tvarkomi.

Kiekvienas produktas turi būti sugrąžinamas į teisingus duomenis

Sąsaja su atsargų sistema turi prasmę tik jei kiekvienas fizinis produktas turi unikalų identifikacinį kodą, kuris pasportą susieja su tinkamais produkto duomenimis. Be šio ryšio tarp produkto ir kodo ERP sistema negali pateikti jokios prasminės informacijos pasportui, nepaisant to, kaip automatizuotas yra likusi procesų dalis. Įmonės, kurios dar to neįrengė, tai pirma pasitikrina čia kaip suteikti kiekvienam produktui unikalų identifikacinį kodą?

Kur praktikoje susiduriama su problemomis

Atsargų sistema ir pasporto duomenys išsisklaido. Matrasų gamintojas keičia modelinio prasilenkimo užpildą, tai paaiškina ERP sistemoje, bet pamiršta, kad tas pats pakeitimas turi įsigalioti jau paskelbtame pasporte. Rezultatas: pasportas ir tikrasis produktas daugiau nesutampa.

Sąsaja yra per sudėtinga įrengtina pagal savą mastą. Įmonė, turinčia garsą produktų linijų, sukonstruoja visiškai automatizuotą realaus laiko sąsają tarp ERP ir pasporto sistemos, nors periodinis eksportavimas su rankiniu patikrintu būtų daugiau nei pakankamas tą keitimo kiekiui, kuris iš tikrųjų pasitaiko.

Unikalus identifikacinis numeris nėra nuosekliai diegtas. Atsargų sistema naudoja vidinius straipsnių kodus, pasportas reikalauja skirtingos identifikavimo struktūros, ir niekas nenustatė, kaip šie du yra tarpusavyje susiję. Atlikus patikrą ar grąžinant produktą nėra paprasta nustatyti, kuris pasportas atitinka kurį fizinį produktą.

Duomenų atnaujinimų atsakomybė nėra priskirta. IT skyrius mano, kad kokybės skyrius prižiūri pasporto duomenis, kokybės skyrius mano, kad tai automatiškai atliekama ERP sistemoje. Niekas to faktiškai nekontroliuoja, todėl duomenys pasena nepastebėti.

Prielaida, kad sąsaja yra privaloma, nors rankinis pateikimas taip pat gali būti. Kai kurie pasiūlymai daro daug investicijų į brangias integracijas iš prielaidos, kad tai yra teisinė pareiga, nors pats reglamentas nenumato, kaip duomenys turi būti pateikti — tik kad pasportas turi atitikti tam tikrus techninius ir turinio reikalavimus.

Ką galite dokumentuoti

Apžvalga, kurie duomenys gaunami iš ERP arba atsargų sistemos ir kurie pateikiami atskirai (pavyzdžiui, užpildo medžiagos tiekėjo).
Užfiksuota sąsaja tarp vidinių prekės kodų ir unikalaus identifikatoriaus, naudojamo pasporte — žr. taip pat kaip suteikti kiekvienam produktui unikalų identifikacinį kodą?
Susitarimas, kas atsakingas už produkto sudėties pokyčius įvesti į esančius pasporus.
Pasirinkimas ir pagrindimas, kaip pateikti duomenis: automatinė sąsaja, periodinė eksportavimas arba rankinis įvedimas — įskaitant apsvarstymus, ar šiam procesui reikalinga atskira programinė įranga, kaip aptarta ar man reikalinga speciali programinė įranga, kad sukurti skaitmeninį produkto pasą
Procedūra patikrinti nuoseklumą tarp atsargų duomenų ir paskelbtų pasporu, turinti fiksuotus tikrinimo laikus.
Dokumentacija, kurie ERP sistemos laukai yra privalomi pasporiui ir kurie pasirenkamieji, kad nauji darbuotojai tai galėtų persiimti be konsultacijos.
Pastaba apie situaciją su individualizuotais produktais, kai atsargų sistemos dažnai veikia kitaip nei standartinių modelių atveju — žr. kaip veikia produkto pasportai matrašams pagal užsakymą?

Tai nėra teisinė patarimo. Šiame puslapyje pateikiama bendra informacija apie reglamentavimą, kuriuo grindžiama ši platforma. Mes nežinome jūsų situacijos. Jei abejojate dėl jūsų konkretaus atvejo, pasikonsultuokite su juristo arba atsakinga priežiūros institucija.

Parašyta naudojant AI remiantis aukščiau nurodytais šaltiniais, žmogaus patikrinta 2026-08-22. Ar kažkas negerai? Praneškite — pataisymai gauna prioritetą.