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

Sąsaja yra techniškai įmanoma, tačiau nėra juridiškai privaloma ar draudžiama

ESPR nenustato, KAIP gamintojas arba importuotojas pateikia duomenis skaitmeniniam produkto pasui. Reglamentas nustato reikalavimus pačiam pasui — kokie duomenys turi jame būti, kaip jis turi būti pasiekiamas ir kokiais techniniais standartais turi veikti — tačiau nekonkretina, ar tie duomenys įvedami rankiniu būdu, gaunami iš skaičiamosios lentelės, ar automatiškai išimami iš ERP arba atsargų sistemos. Sąsaja tarp vidinio sistemos ir pasporto tarnybos todėl nėra klausimas, ką įstatyme leidžia, bet ką daro galima naudojama technika ir siūlomasioji tarnyba.

Kam tai aktualu ir kam ne

Šis klausimas ypač aktualesnis įmonėms, kurios jau naudoja ERP arba atsargų sistemą ir nenori du kartus prižiūrėti tų pačių produkto duomenų: vieną kartą savo sistemoje, vieną kartą pasui. Tai praktinis, o ne juridinis klausimas. ESPR nenustato, kad gamintojas turėtų turėti automatizuotą sąsają, ir jis taip pat nenustato, kad tai būtų draudžiama. Tai, ką reglamentas iš tikrųjų reglamentuoja, yra techninė forma, kurią galiausiai turi turėti pasporto duomenys — neatsižvelgiant į tai, kaip jie buvo pateikti. Šis klausimas todėl nesusijęs su pačios sąsajos pareigomis, bet su reikalavimais, kuriuos turi tenkinti pagrindiniai duomenys, o tai vėliau lemia, ar sąsaja yra naudinga ir praktiška.

Nėra dingstančios datos, tačiau jau fiksuoti techniniai rėmai

Delegiramasias aktas, kuris paverčia skaitmeninį produkto pasą privalomu baldams, dar nėra; ESPR veiksmų planas 2025–2030 nurodą 2028 m. kaip numatytą publikavimo laiką. Kol to akto nėra, taip pat neaiški, kokie konkrečiai produktų grupės duomenys bus privalomi ir kokiu formatu. Tačiau jau fiksuoti yra bendri techniniai reikalavimai pasui iš ESPR 10 ir 11 straipsnių: jie taikomi visiems produktams, kurie patenka į delegiruotą aktą, todėl netrukus ir baldams. Šie bendrieji rėmai jau dabar yra žinomi ir gali būti naudojami mąstant apie savos duomenų apdorojimo procesų organizavimą, nors tikslus pasalio turinio yra neaiškus.

Kaip tai praktikoje įgyvendinti

Kas dabar mąsto apie sąsają, turėtų pirmiausia pažvelgti, kokie produkto duomenys jau sustruktūrizuoti savoje ERP arba atsargų sistemoje: medžiagų sudėtis, dalių kilmė, matmenys, priežiūros instrukcijos ir panašiai. Tai yra pagrindas, iš kurio sudaromas pasas, nesvarbu, ar tai daroma rankiniu būdu, ar naudojant sąsają. Toliau yra naudinga sužinoti, kokiu formatu tie duomenys įrašomi, ir ar tas formatas tinka keistis su išorine sistema — pagalvokite apie sustruktūrizuotus laukus, o ne laisvo žodžio tekstą. Šioje platformoje pasas sudaromas iš duomenų, kuriuos pateikia gamintojas arba importuotojas; kaip tiksliai vyksta tas pateikimas ir ar tam galima naudoti automatizuotą sąsają, yra praktinis klausimas, kuris gali būti aptartas atskirai. Ilgiau žvelgiant į ateitį, produkto duomenis tikslinga sustruktūrizuoti taip, kad jie be didelių pakeitimų būtų tinkami skaitmeniniam pasui, nesvarbu, ar pateikimas vyksta rankiniu būdu, ar vėliau automatizuotai. Tai sutaupo dvobulyj darbą, kai pasui pareiga baldams įsigalioja.

Pagrindas: ESPR 10 ir 11 straipsniai

10 straipsnis iš ESPR (Reglamento (ES) 2024/1781) aprašo reikalavimus, kuriuos turi atitikti skaitmeninis produkto pasas, įskaitant duomenų susiejimą su unikaliu produkto identifikavimo numeriu ir tų duomenų prieinamumą produkto naudojimo metu. 11 straipsnis iš tos pačios reglamento kalbama apie techninio projektavimo ir paso veikimą, ir nurodo reikalavimus, susijusius su atvirais standartais, tarpoperabilumu ir duomenų mašininio skaitomumo galimybe. Kartu šie straipsniai nusako ne tai, kaip turi būti teikiami duomenys, o tai, kokiai techninei formai tie duomenys galiausiai turi atitikti — ir tai yra būtent to susiejo su klausimu, ar ir kaip suderinimas su ERP arba atsargų sistema yra praktiškas.

Ką dabar galite padaryti

Nubrėžkite, kokie produkto duomenys jau yra jūsų ERP arba atsargų sistemoje ir kokiu formatu, ir aptarkite su paso tiekėju — šiuo atveju su šia platforma — kokie duomenų teikimo variantai yra praktiškai įmanomi. Kai tik bus paskelbutas deleginis aktas dėl baldų, čia bus nurodytas tikslus terminas ir tikslūs duomenų reikalavimai; kol to neatsitiks, pirmiausia tikslinga paruošti savo duomenis sutvarkytus ir perkeliamus.

Kuo tai pagrįsta

Pats reglamentas yra EUR-Lex. Mes nurodome pagal tvirtinimą; jūs neturite mums tikėti.

Ką konkrečiai jūs turite daryti

Ko iš jūsų tikimasi

Susieti jūsų ERP arba atsargų sistemą su skaitmeninių produktų pasportų sistema yra techniškai dažnai įmanoma ir gali sutaupyti daug rankinio darbo. ESPR nenustato, kaip jūs gausite savo duomenis arba kaip juos viduje valdysite; formas nustato reikalavimus pačiam pasportui, tam, kas jame turi būti, ir kaip jis turi būti prieinamas. Tai reiškia, kad susiėjimas su savo sistema nėra tikslas savaime, bet priemonė šiems reikalavimams įvykdyti.

Pasportas turi atitikti techninius reikalavimus, nepaisant duomenų šaltinio

ESPR 10 straipsnis (Reglamentas (ES) 2024/1781) aprašo, kokius duomenis turi turėti skaitmeninis produktų pasportas ir kokioms sąlygoms jis turi atitikti, tokioms kaip tikslumas ir pilnumas. Įmonei su 10–100 darbuotojų tai reiškia, kad duomenų kilmė — nesvarbu, ar jie įvedami rankiniu būdu, ar automatiškai iš ERP sistemos — nesumažina to, ko tikimasi iš turinio. Taigi susiėjimas nekeičia pareigos; jis keičia tik tai, kaip tu ją praktiškai įvykdai.

Pasportas turi atitikti techninę struktūrą, kurią reikalauja 11 straipsnis

ESPR 11 straipsnis (Reglamentas (ES) 2024/1781) nagrinėja skaitmeninio produktų pasporto techninę struktūrą ir veikimą, įskaitant duomenų saugojimo, mainų ir prieigos per duomenų nešiklį būdus. Susiėjimui su savo sistema tai reiškia, kad to susiėjimo išvestis — duomenys, kurie galiausiai patenka į pasportą — turi tilpti į pasportui taikomą techninį rėmą, tokį kaip naudojamas duomenų modelis ir prieigos būdas per QR kodą ant baldų. ERP paketo eksportavimo failas taigi retai yra tiesiogiai pasportas; jis paprastai yra šaltinis, kuris pirmiausia turi būti išverstas į tinkamą formatą.

Kiekvienas susiėjimas tiekia duomenis, kurie turi būti susieti su unikaliuoju identifikacijos kodu

ERP arba atsargų sistema paprastai veikia su vidiniais prekių numeriais arba SKU. Jie automatiškai nesusieja su identifikacijos kodu, kurio reikalauja produktų pasportas. Susiėjimą nustatant todėl svarbu nustatyti, kaip kiekvienas produktas gauna unikalų identifikacijos kodą ir kaip tas kodas susijęs su esama prekių kodu jūsų sistemoje. Be to vertimo žingsnio atsiranda rizika, kad vidiniai numeriai netyčia pateks į pasportą, arba kad vienas produktų pasportas negali būti tinkamai susietas su teisingas atsargų eilute.

Kur praktikoje klystamuose

Automatinis sinchronizavimas be kontrolės etapo. Susiėjimas, kuris tiesiogiai ir be tarpinio žingsnio perduoda duomenis iš ERP sistemos į pasportą, atrodo efektyvus, bet tai reiškia ir tai, kad klaida šaltinio sistemoje — neteisingai įvestas medžiagos procentas, pasibaigęs sertifikatas — automatiškai atsispindi paskelbtame pasporte.

Painiava tarp vidinio SKU ir viešo identifikacijos kodo. Įmonės kartais naudoja tą patį vidinį prekių numerį kaip išorinį identifikacijos kodą, neišsiaiškindamos, ar tas numeris jau naudojamas kur nors kitur arba atitinka reikalavimus. Tai ypač aktualu įmonėms, kurios dirba su GS1 Digital Link ir turi suderinti su tuo susiėjimą.

Nėra susiėjimo tarp atsargų pokyčio ir pasporto būsenos. Jei produktas daugiau nėra gaminamas arba jį pakeičia nauja atmaina, tai dažnai baigiasi ERP sistemoje, bet nepriveda prie pasporto atnaujinimo. Klausimas, ar ir kaip duomenys po publikavimo gali būti pakeisti tada užduodamas per vėlai, paprastai tada, kai klientas arba priežiūros institucija nustatyti neatitikimą.

Nepakankamas dėmesys sudėtingiems produktams. ERP sistema paprastai atskirai registruoja dalis ir variantus, o klausimas, ar baldai kaip visuma ar kiekviena dalis atskirai reikalauja pasporto, turi būti atsakytas atskirai. Susiėjimas, pagrįstas atsargų sistemos struktūra, tada susiduria su rizika, kad naudotų neteisingą vienetą kaip pradžią.

Ryšys nutrūksta keičiant sistemą arba tiekėją. Kai įmonė keičia ERP paketą, keičia hosting partnerį arba nustoja bendradarbiauti su tam tikru IT tiekėju, ne visada atsižvelgiama į tai, kad ryšys su pasportu turi būti iš naujo nustatytas. Tai taip pat liečia klausimą, kas nutinka pasportui kai įmonė pati nustoja veikti arba keičia organizacinę formą.

Ką galite dokumentuoti

Sąrašas, kurie ERP arba atsargų sistemos laukai automatiškai perkeliami į pasportą ir kurie laukai visada neautomatiškai peržiūrimi prieš publikavimą.
Dokumentuota vertimo lentelė tarp vidinių produkto numerių ir išorėje naudojamų identifikavimo kodų, įskaitant susitarimą dėl to, kas šią lentelę atnaujina.
Procedūra situacijai, kai šaltinio sistemos pasikeitimas — naujas medžiaga, naujas tiekėjas, pakeista sudėtis — reikalauja pasporto patikrinimo arba atnaujinimo.
Susitarimai su IT tiekėju arba hosting partneriu dėl to, kas nutinka keičiant sistemą, įskaitant tai, kas yra atsakingas už ryšio perkėlimą.
Vidinis kontrolės punktas (pavyzdžiui, kas ketvirtį), kai atsitiktinės imties tvarka patikrinama, ar publikuoto pasporto duomenys vis dar atitinka esamą ERP sistemos būseną.
Dokumentacija apie kalbą arba kalbas, kuriomis duomenys iš ERP sistemos pateikiami, atsižvelgiant į klausimą kokia kalba pasportą reikia pateikti.

Suteikiame šablonų šiems susitarimams, kad jų dokumentavimas nebūtų kartojamas nuo nulio kiekvienam produktui.

Tai nėra teisinė nuomonė. Šis puslapis pateikia bendrą informaciją apie taisykles, kuriomis susijęs šis platform. Mes nežinome jūsų situacijos. Jei abejojate dėl jūsų konkrečios situacijos, kreipkitės į teisininką arba kompetentingą priežiūros organą.

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