matrapas.eu

Ali lahko digitalni proizvod povežem s svojim sistemom ERP ali blagajno?

Povezava je tehnično mogoča, vendar je oblika še nedoločena

Digitalni produktni potni list je zasnovan kot strukturirana, strojno berljiva zbirka podatkov, in kot tak se načeloma ujema s povezavo s sistemom ERP ali zalog. ESPR predpisuje, da se podatki za potni list zabeležijo na podlagi odprtih standardov in da morajo sistemi med seboj izmenjati podatke. To je prav načelo, na katerem bi temeljila povezava z obstoječim poslovnim sistemom: brez ročnega vnosa na posamezen vzmetnico, ampak preskrba iz podatkov, ki jih proizvajalec ali uvoznik že vodi. Kako ta povezava v praksi izgleda — kateri oblikovni format, katera polja, katera metoda preskrbe — še ni določeno, ker mora tehnična razdelava za vzmetnice šele nastati.

Za koga to velja in za koga ne

Ta razlaga se nanaša na strukturo podatkov za potni list, ne na specifično vmesnik za povezovanje ali priključek, ki bi bil že na voljo. ESPR opisuje zahteve za interoperabilnost in način, na katerega je potni list tehnično zasnovan (nosilec podatkov, enotne identifikacijske kode, shranjevanje podatkov), vendar ne ureja, kako se mora posamezni paket ERP ali sistem zalog nanj priključiti. Slednje je vprašanje izvajanja, ne predpisovanja: uredba določa, kaj mora biti interoperabilno, ne pa s katero programsko opremo podjetje deluje. Za trgovino s posteljnino, ki samo prodaja in ne sestavlja potnega lista, povezava s lastnim sistemom ERP navadno ni potrebna; to je predvsem naloga tiste stranke, ki podatke preskrbi, navadno proizvajalca ali uvoznika.

Tehnične specifikacije pridejo z delegirano uredbo

Ni še dogovorjenega datuma, kdaj se tehnična razdelava za vzmetnice pojavi. V načrtu Evropske komisije za 2025-2030 se pričakuje delegirana uredba za vzmetnice leta 2028, vendar je to le načrt, ne zagotovilo. Dokler ta uredba ni objavljena, ni določeno, kateri format podatkov, katera polja in katera metoda preskrbe bodo veljali za vzmetnice. Kar je res, je okvir iz samega ESPR: potni list mora biti zasnovan v skladu z odprtimi, interoperabilnimi standardi in vezan na enotno identifikacijo proizvoda. Ta okvir se ne spremeni več; izpolnitev za vzmetnice posebej pa še vedno.

Kaj to pomeni za pripravo

Tistim, ki že razmišljajo o povezavi, je zdaj že mogoče narediti nekaj stvari, ne da bi morali čakati na končno specifikacijo. Najprej je smiselno preveriti, kateri podatki o vzmetnici že stojijo nekje v lastnem sistemu — sestava materialov, izvor surovin, datum proizvodnje, številka serije ali naročila — in ali so ti podatki zabeleženi na ravni proizvoda ali samo na ravni naročila. Nato je pametno pogledati, ali ima sistem izvozno funkcijo, ki lahko proizvede strukturirane podatke (na primer izvoz v običajnem formatu), kajti to je priključna točka za kasnejšo povezavo, ne glede na točen format, ki ga bo predpisala delegirana uredba. Naslednje je praktično ugotoviti, ali se podatki vodijo na proizvod, serijo ali naročilo, ker bo potni list sčasoma na proizvod dobil enotno identifikacijo. Na koncu se splača biti v stiku s stranko, ki potni list sestavlja in gosti, tako da je ob objavi tehnične specifikacije hitro jasno, katera oblika preskrbe je potrebna in ali se obstoječa sistemska ureditev na to ujema ali zahteva prilagoditev. Neposredna, avtomatizirana povezava med sistemom ERP in potnim listom torej še ni nekaj, za kar obstaja danes že tehnični standard; kar pa je mogoče, je lastne podatke že sedaj tako urediti, da bo povezavo kasneje enostavno narediti.

Kje je to navedeno: člen 10 in člen 11 ESPR

Članek 10 Uredbe (EU) 2024/1781 (ESPR) opisuje zahteve za digitalni produktni potni list, vključno s zahtevo, da se podatki zbirajo na podlagi odprtih standardov in da morajo biti sistemi za obdelavo podatkov medsebojno združljivi. Članek 11 obravnava tehnično zasnovo in delovanje potnega lista z določbami o podatkovnem nosilcu, enotnih identifikacijskih kodah za proizvod, tržnega subjekta in obrata ter način shranjevanja in dostopnosti podatkov. Skupaj ta членka tvorita okvir, v katerem je mogoča povezava z zunanjim sistemom, ne da bi določala specifičen tehnični standard za matrače — ta sledi šele iz še objaviti delegirane uredbe.

Kaj storiti sedaj

Zaenkrat je najpomembnejše, kar je mogoče storiti: urediti lastne podatke o proizvodu in jih zabeležiti na ravni proizvoda (namesto le na ravni naročila), preslikati možnost izvoza iz obstoječega sistema in spremljati objavo tehnične specifikacije za matrače. Takoj ko je ta specifikacija na voljo, bo ta stran dopolnjena s podatki o tem, kateri format in katera metoda predložitve veljata.

Podlaga za to

Uredba sama je objavljena na EUR-Lex. Pri vsakem trditvi se sklicujemo nanj; nam vam ne treba verjeti.

Kaj konkretno morate storiti

Kaj se pričakuje od vas

Povezava med produktnim potrdilom in ERP- ali inventarnim sistemom ni sama po sebi zakonska obveznost. ESPR ne predpisuje, katere izvorne sisteme mora proizvajalec uporabiti za dostavo podatkov potrdila. Kar je vsak primer zastavljeno, so zahteve za samo potrdilo: kako tehnično deluje in kaj mora biti sposobno. Te zahteve posredno določajo, ali — in kako — je povezava z notranjimi sistemi smiselna.

Potrdilo se mora tehnično ujemati s poenotenim delovanjem

Članek 11 ESPR (Uredba (EU) 2024/1781) opisuje tehnične zahteve za digitalno produktno potrdilo, kot je interoperabilnost s sistemi, ki jih uporablja Komisija in trg. Za podjetje z 10 do 100 zaposlenimi to pomeni, da podatki potrdila ne smejo preprosto ostati v lastnem, drugačnem formatu: na koncu morajo biti v obliki, ki jo lahko prebere sistem potrdila. Ali je to preko neposredne povezave z ERP-sistemom ali preko ročnega izvoza, je izbira — ne obveznost iz uredbe.

Vsebina potrdila mora biti trenutna in zajamčeno pravilna

Članek 10 ESPR (Uredba (EU) 2024/1781) predpisuje zahteve glede tega, kaj mora biti v potrdilu in kdo je zato odgovoren. Praktično to pomeni, da morajo biti podatki, ki izhajajo iz ERP- ali inventarnega sistema — sestava materiala, datum proizvodnje, številka serije — pravilni in trenutni v trenutku, ko se potrdilo ustvari ali posodobi. Za podjetje z več proizvodnimi linijami in rednimi spremembami sestave (drugačna vrsta pene, drugačen dobavitelj polnilnega materiala) je to razlog, da razmislite, ali se podatki ročno prepisujejo ali se samodejno prevzamejo iz sistema, v katerem se že vodijo.

Vsak proizvod mora biti sledljiv do pravilnih podatkov

Povezava z inventarnim sistemom ima smisel le, če ima vsak fizični proizvod edinstveno identifikacijsko kodo, ki potrdilo poveže s pravilnimi podatki proizvoda. Brez te povezave med proizvodom in kodo ne more ERP-sistem zagotoviti smiselnega vnosa v potrdilo, ne glede na to, kako avtomatiziran je preostanek procesa. Podjetja, ki tega še niso uredila, to preberite nazaj pri kako dodelim vsakemu proizvodu edinstveno identifikacijsko kodo?

Kje gre narobe v praksi

Inventarni sistem in podatki potrdila se razilijo. Proizvajalec matrac spremeni polnilo proizvodne linije, to prilagodi v ERP-sistemu, vendar pozabi, da ista sprememba tudi v že objavljena potrdila. Rezultat: potrdilo in dejanski proizvod se več ne ujemata.

Povezava je premalo zapletena za lastno obseg. Podjetje s peščico proizvodnih linij vzpostavi v celoti avtomatizirano povezavo v realnem času med ERP in sistemom potrdila, medtem ko bi periodični izvoz s ročnim preverjanjem vsekakor zadostoval za število sprememb, ki se dejansko pojavljajo.

Edinstvena identifikacijska številka ni dosledno izvedena. Inventarni sistem uporablja notranje kode artiklov, potrdilo zahteva drugačno strukturo identifikacije, in nihče ni opredelil, kako se ti dve nanašata drug na drugega. Med pregledom ali ob vračilu ni več preprosto ugotoviti, katero potrdilo pripada kateremu fizičnemu proizvodu.

Odgovornost za posodobitve podatkov ni dodeljena. Oddelek IT meni, da oddelek za kakovost vzdržuje podatke potrdila, oddelek za kakovost meni, da to samodejno izhaja iz ERP-sistema. Nihče tega dejansko ne nadzira, zato podatki zastarijo brez da bi se to opazilo.

Predpostavka, da je povezava obvezna, medtem ko je možna tudi ročna dostava. Nekatera podjetja investirajo v drage integracije na podlagi predpostavke, da je to zakonska obveznost, medtem ko uredba sama ne predpisuje, kako se podatki dostavljajo — le da mora potrdilo izpolnjevati določene tehnične in vsebinske zahteve.

Kaj lahko zabeležite

  • Pregled podatkov, ki prihajajo iz sistema ERP ali zalog, in tistih, ki se dostavljajo posebej (na primer od dobavitelja polnilnega materiala).
  • Uspostavljena povezava med notranjimi kodami artiklov in edinstveno identifikacijsko kodo, ki se uporablja v pasportu — glej tudi kako dodelim vsakemu proizvodu edinstveno identifikacijsko kodo?
  • Dogovor o tem, kdo je odgovoren za uvajanje sprememb v sestavo proizvoda v obstoječe pasporte.
  • Izbira in utemeljitev za način dostave: samodejno povezovanje, periodični izvoz ali ročni vnos — vključno z razmislekom, ali je za to potrebna ločena programska oprema, kot je bilo obravnavano pri ali potrebujem posebno programsko opremo za ustvarjanje digitalnega proizvodnega potnega lista
  • Postopek za preverjanje skladnosti med podatki zalog in objavljenimi pasporti s stalnimi preverjujočimi trenutki.
  • Dokumentacija o tem, katera polja iz sistema ERP so obvezna za pasport in katera izbirna, tako da lahko novi zaposleni to prevzamejo brez posveta.
  • Opomba o situaciji pri izdelkih po meri, pri katerih sistemi zalog pogosto delujejo drugače kot pri standardnih modelih — glej kako deluje produktni pasport za matrače po meri?

To ni pravni nasvet. Ta stran daje splošne informacije o regulaciji, s katero se ukvarja ta platforma. Ne poznamo vaše situacije. Če ste v dvomih glede vašega primeira, se posпосvetуйте s pravnikom ali pristojnim nadzornim organom.

Napisano s pomočjo AI na podlagi zgoraj navedenih virov, preverjeno s strani ljudi dne 2026-08-22. Ali je kaj narobe? Dajte nam vedeti — popravki so prioriteta.