Ar galiu produkto pasą susieti su savo ERP arba atsargų sistema?
Sujungimas galimas, atsižvelgiant į duomenų formato ribas
Sujungimas tarp skaitmeninio produkto paso ir jūsų ERP arba atsargų sistemos iš principo yra galimas, tačiau jo būdas priklauso nuo techninio projektavimo, kuris bus nustatytas produkto pasui. ESPR (Reglamentas (ES) 2024/1781) 10 straipsnyje nurodo reikalavimus, kuriuos turi atitikti skaitmeninis produkto pasas, o 11 straipsnyje – kaip jis techniškai yra subudėtas ir veikia. Iš to išplaukia, kad pasas turi būti mašiniškai skaitomas ir keičiamas – ne tai, kad kiekvienas gamintojas gali laisvai kurti savo sujungimą su bet kuria sertifikuota sistema, kaip jam patinka. Sujungimas praktikoje vyksta per platformą, kuri surenka ir talpina pasą, bei per duomenų formatą, kuris tam yra suderintas.
Kam tai aktualu, ir kam ne
Šis klausimas iš esmės yra svarbus aliuminio pusgaminių gamintojams ir importuotojams, kurie turi pateikti duomenis produkto pasui – profilių gamintojams, lietu gamyklose, verpalo aliuminio gamintojams. Jų atžvilgiu svarbias sąlygas sudaro tai, ar jų esami gamybos duomenys (medžiagos sudėtis, partijos numeriai, kilmė, techninės specifikacijos) gali automatiškai perduoti pasui, o ne rankiniu būdu perrašyti. Tai nuo klausimo, ar įmonė privalo kurti ERP sujungimą – tokia pareiga neegzistuoja. ESPR reglamentuoja tai, ką pasas turi sugebėti (grąžintina, mašiniškai skaitoma, prieinama per duomenų nešiklį, tokį kaip QR kodas), bet ne tai, kaip atskira įmonė susitvarkius savo vidinę programinę įrangą. Įmonė be ERP sistemos gali duomenis pateikti tiesiai per formą ar failą; įmonė su plačia ERP sistema gali šiuos duomenis pateikti galbūt efektyviau, tačiau ji daryti privalo.
Kada tai išvysta: data nenustatyta
Nėra fiksuotos datos, kada šios pareigos aliuminio pusgaminių grupėje pradės galioti. Delegavimas sprendimas, kuris tai turėtų konkrečiai nustatyti šiai produktų grupei, pagal Europos Komisijos darbo planą 2025–2030 m. numatomas 2027 m. Tik su tuo sprendimu taps aišku, kurie duomenų laukai yra privalomi, kokiu formatu ir kokiomis techninėmis specifikacijomis keistis – taigi tik tada bus tiksliai aišku, kaip techniškai gali atrodyti ERP sistemos sujungimas. Kol tol nusistovėjęs faktas yra tai, kad ESPR 10 ir 11 straipsniai sudaro bendrąjį pamatą: grąžintinumas ir mašininė skaitomumas yra išeities principas, konkretūs techniniai detalizavimas seks vėliau. Iš karto po to, kai bus paskelbtas delegavimas sprendimas, čia bus papildyta numatyta pradžios data.
Ką tai reiškia jūsų požiūriui
Tam, kas dabar nori tai apsvarstyti iš anksto, logiška eiga būtų: pirmiausia numatyti, kurie duomenys apie aliuminio produktą dabar jau yra jūsų sistemoje – sudėtis, kilmė, partijos duomenys, techninės charakteristikos. Toliau naudinga patikrinti, ar šie duomenys yra prieinami strukturuotai, eksportuojamam būdu (eksportas į failą, sujungimas per sąsają) užuot tik ant popieriaus arba išsibarsčiusią per kelis padalinių. Po to tai yra klausimas, kuris susijęs su formatu, kurį reikalauja tos platformos, kurie surenka produkto pasą: alupas.eu surenka pasą remdamasi duomenimis, kuriuos pateikia gamintojas arba importuotojas, ir kaip ta pateiktis techniškai vyksta – rankinė įrašymas, failą augštalas, arba automizuotas sujungimas – tai klausimas, kuris su platforma suderinamas iš karto, kai žinomos techninės specifikacijos iš delegavimo sprendimo. Įmonė, kurie dabar jau geba laikyti savo produkto duomenis aiškiai ir struktūrizuotai, vėliau turi sumažinti darbą, siekiant pateikti šiuos duomenis, neatsižvelgiant į tai, ar tai vėliau vyks per ERP sujungimą ar kitaip.
Iš kur tai seka: ESPR 10 ir 11 straipsniai
Straipsnisarticolo 10 of the ESPR describes the requirements that a digital product passport must meet, including data accessibility and linkage with a data carrier. Straipsnisarticolo 11 specifically addresses the technical design and operation of the passport system: how data is recorded, stored and exchanged, with a view to interoperability between different systems and actors in the chain. Both articles leave the concrete technical standards and formats to later implementing rules; they do establish the principle that the passport must be machine-readable and system-independent in its functioning, which forms the basis for any future linkage with an external system such as an ERP package.
Kas norite iš anksto paruošti medžiagą, geriausia yra turėti savų produktų duomenis struktūrizuotus ir skaitmeninėje formoje tvarkingai suorganizuotus, kad tiekimas — kokia nors forma — vėliau būtų tiesiog prijungimas, o ne iš naujo nustatymas.
Kuo tai paremta
- Direktyva (ES) 2024/1781 (ESPR), 11 straipsnis (skaitmeninio produkto paso techninis dизайn ir veikimas)
- Reguliacija (ES) 2024/1781 (ESPR), 10 straipsnis (skaitmeninio produkto paso reikalavimai)
Pati reglamentacija yra EUR-Lex. Mes nurodome pagal kiekvieną teiginį; jums mūsų tikėti nereikia.
Ką tiksliai turite daryti
Ką iš jūsų tikimasi
Pasportas turi būti perkeliamas kaip duomenų rinkinys, o ne tik kaip ekranas
10 straipsnis ESPR (Reglamento (ES) 2024/1781) aprašo skaitmeninį produkto pasportą kaip duomenų rinkinį, kuris yra skaitomas ir persiuntimas per elektronines priemones. Tai yra kitoks reikalavimas nei „gražus puslapis, kuris atsidaro nuskaitius QR kodą". Įmonei, turėjusiai nuo 10 iki 100 darbuotojų, tai reiškia, kad duomenys, esantys pasporte, taip pat turi būti pasiekiami kaip struktūrizuoti duomenys — ne tik kaip tekstas žiniatinklio puslapyje. Ar ir kaip jie bus susieti su nuosava ERP ar atsargų sistema, sprendžia pati įmonė; normatyvai neveda integracijos, bet reikalauja duomenų rinkinio, kuris tam pritinka.
Tarpusavio sudernamumas tarp sistemų yra pagrindinė prielaida, o ne techninis tiekėjo pasirinkimas
11 straipsnis ESPR aprašo skaitmeninio produkto pasporto techninį projektą ir veikimą bei tarpusavio suderinamumą nurodo kaip vieną iš pagrindinių principų, kuriems turi atitikti pasporto sistema. Tai tiesiogiai liečia klausimą, ar galima susieti su nuosava sistema: pasportas, sudarytас pagal šį straipsnį, iš esmės skirtas duomenimis keistis tarp sistemų, o ne būti uždarų aplinkai. Praktikoje įmonė tai labiausiai pastebės klausiant, kokius duomenų formatus ir identifikavimo kodus naudoja platforma, ir ar jie sutampa su tuo, ką jau naudoja nuosavas ERP sistemos.
Unikalus identifikavimo kodas yra grandinė tarp pasporto ir savosios administracijos
Ryšys tarp produkto pasporto ir vidaus sistemos priklauso nuo patikimo identifikavimo kodo, tenkančio kiekvienam produktui ar partijai. Be vienareikšmio jungties rakto ERP integracija praktikoje yra sunki automatizuoti, net jei tai negriebtai nenurodyta 10 arba 11 straipsnio tekste. Kaip tas identifikavimo kodas sudaromas ir priskiriamas, aprašyta puslapyje apie kaip kiekvienam produktui suteikti unikalų identifikavimo kodą. Įmonei, parduodančiai aliuminio partijas, tai taip pat susiję su klausimu, ar registracija atliekama pagal partiją ar pagal vienetą, kuris plačiau išdėstys puslapyje apie partijos ar vieneto registraciją.
Pasportas išlieka, net jei vidaus sistema keičiasi
ERP sistema tam tikru momentu yra keičiama, perkeliama arba atnaujinama. Pats produkto pasportas automatiškai negriebs tų pakeitimų — jis yra šešiems metams šeimininkaujamas atskira nuo to, kas vyksta viduje su atsargų administracija. Šis skirtumas yra svarbus norint nustatyti jungtį: jungtis yra patogumas savai verslo veiklai, o ne pasporto prieinamumo pareigos pakeitimas. Daugiau apie tą saugojimo terminą nurodytas puslapyje apie kiek laiko pasportas turi likti prieinamas.
Kur praktikoje nueitilsta
Kai kurie dalykai dažnai grįžta prie įmonių, svarstančių jungtį tarp pasporto ir savosios sistemos:
- ERP sistemos yra laikomos šaltiniu, o pasportas turi likti šaltiniu. Kai duomenys kartą paskelbti, pasportas yra išorės pasauliui patikimas nuoroda. Pasikeitumai vidaus sistemoje nenuyra per jį, ir kas supainioja šią aplinkybę, rizikuoja pasportu ir savąja administracija išsiskirdinti.
- Atsargų pokyčiai painiojami su pasporto pakeitimais. Vidaus atsargų sistema keičiasi kasdien: skaičiai, vietos, partijos būsenų. Produkto pasportas registruoja produkto charakteristikas, ne šiandienį atsargų padėtį. Kas šias dvi duomenų rūšis suplakš jungtį, sukurs nereikalingą sudėtingumą — kartais ir neteisėtus pakeitimus pasporte, kuris jau paskelbtas. Kaip tas keitimas po paskelbimo veikia, aprašyta puslapyje apie duomenų keitimas po publikavimo.
- Jungtis sudaroma neatsižvelgiant į platformos identifikavimo kodo. Jei vidinis prekės numeris neatitinka kodo, kuris naudojamas pasporte, reikalinga rankinė vertimo procedūra, kuri praktiškai panaikina ryšį.
- Manoma, kad ERP sujungimas taip pat užtikrina fizinį QR kodą ant produkto. Tai yra du atskiri komponentai: duomenų sujungimas tvarko informacijos mainus, nešiklio priklijimas pačiam aliuminiui yra atskiras procesas. Žr. apie tai kaip QR kodas atsiduoda ant produkto.
- Manoma, kad savoji sistema netrukus pati "sugeneruos" pasportą. Kol aliuminiui skirta deleguota priemonė dar nebus paskelbta, nepasitvirtiną, kuris duomenų formatas tiksliai bus privalomas. Sujungimas gali būti parengtas, tačiau prielaida, kad savoji ERP sistema netrukus savarankiškai atitiks visus reikalavimus, yra paskubinta.
Ką jūs galite užfiksuoti
Įmonėms, svarstančioms ryšį tarp produkto pasporto ir savosios sistemos, praktiškai yra naudinga šiuos klausimus viduje sufiksavoti — net jei sujungimas dar nėra kuriamas:
- Kurie ERP arba atsargų sistemos laukai atitinka kuriuos produkto pasporto laukus, įskaitant kiekvienam produktui arba partijai naudojamą identifikavimo kodą.
- Kas įmonėje atsakingas už duomenų, kurie naudojami tiek viduje, tiek pasporte, aktualumą.
- Susitarimas dėl laiko, kada duomenys iš vidaus sistemos perkeliami į pasportą, ir laiko, kada tai aiškiai nevyksta automatiškai.
- Dokumentacija apie tai, kuris sistemos šaltinis taikytinas kuriam duomeniui — kad atliekant patikrą arba atsakant į pirkėjo klausimą, būtų aišku, iš kur yra skaičius arba charakteristika.
- Apžvalga, ar pasportas yra sudaryt pagal vienetą arba pagal partiją, nes tai lemia, kaip sujungimas su atsargų linijomis geriausiai gali būti sutvarkytas.
Šie punktai nekiša rezultato ir nėra garantija, kad sujungimas atitiks, ką netrukus kelis deleguota priemonė — tas tekstas dar nėra. Tačiau jie užtikrina, kad įmonė, kai tik techniniai reikalavimai taps konkretūs, nepradės nuo nulio ieškomos, kurie duomenys kur priklauso.
Tai nėra teisinė nuomonė. Šis puslapis suteikia bendrą informaciją apie reglamentavimą, kuriuo remiasi šia platforma. Mes nežinome jūsų situacijos. Jei abejojate dėl savo konkrečių aplinkybių, pasikonsultavimo su teisininku arba su kompetentinga priežiūros institucija.
Parašyta dirbtinio intelekto pagalba remiantis aukščiau nurodytais šaltiniais, žmogaus patikrinta 2026-08-22. Ar ką nors ne taip? Pranešokite mums — pataisymai yra pirmo laipsnio svarbumo.