Kas saan digitaalse tootepassi siduda oma ERP- või varude süsteemiga?

Sidumisi on võimalik andmeformaaditahe piiride jooksul

Sidumisi digitaalse tootepassi ja oma ERP- või varude süsteemi vahel on põhimõtteliselt võimalik, kuid selle viis sõltub tootepassi jaoks kehtestatud tehisest kujundusest. ESPR (määrus (EL) 2024/1781) ette näeb artiklis 10, millisele nõuetele peab digitaalne tootepast vastama, ja artiklis 11, kuidas see tehniline on ehitatud ja toimib. Sellest järeldub, et pass peab olema masinaga loetav ja vahetatav — mitte, et iga tootja võib vabalt ehitada oma sidumise suvalisele süsteemile, nagu talle meeldib. Sidumine toimub praktikas platvormi kaudu, mis passi koostab ja hostib, ning andmeformaadie kaudu, mis selleks kokku lepitakse.

Kellele see on asjakohane ja millele mitte

See küsimus on asjakohane alumiiniumi pooltoodete valmistajate ja importijate jaoks, kes peavad andmeid produktipassi jaoks esitama — profiilivalmistajad, valumid, pakendialumiiniu tootjad. Nende jaoks on oluline, kas nende olemasolevad tootmisandmed (materjalide koostis, partiinumbrid, päritolu, tehnilised spetsifikatsioonid) saavad automaatselt passisse kulgevad, selle asemel, et neid käsitsi ümber tippida. See ei käi küsimuse kohta, kas ettevõte on kohustatud ERP-sidumine ehitama — sellist kohustust pole. ESPR reguleerib, mida pass peab saama tegema (interoperaabel, masinaga loetav, juurdepääsetav andmekandjate kaudu nagu QR-kood), mitte seda, kuidas individuaalne ettevõte oma sisemist tarkvara korraldab. Ettevõte ilma ERP-süsteemita saab andmeid sama hästi esitada vormi või faili kaudu; ettevõte laialdase ERP-süsteemiga saab neid andmeid võimalikult tõhusalt esitada, kuid selleks pole kohustatud.

Kui see kehtib: kuupäev pole veel fikseeritud

Pole veel kindlat kuupäeva, millal need kohustused alumiiniumi pooltoodete jaoks jõustuvad. Delegeeritud akt, mis seda selle tootegrupi jaoks konkreetseks peab tegema, on Euroopa Komisjoni tööplaani järgi 2025–2030 aastatel oodatav 2027. Alles selle aktiga selguneb, millised andmeväljad on kohustuslikud, mis formaadis, ja milliseid tehniliste spetsifikatsioonidega vahetamiseks — seega ka alles siis saab täpselt selgeks, kuidas tehniline ERP-süsteemiga sidumine välja näha võib. Kuni selleni on kindel, et ESPR artikkel 10 ja artikkel 11 moodustavad üldise raamistiku: interoperaablus ja tehisline loetavus on lähtekohad, konkreetne tehisne täitmine tuleb hiljem. Niipea kui delegeeritud akt on avaldatud, täiendatakse siin oodatavat jõustumiskuupäeva.

Mida see tähendab lähenemisviisi jaoks

Kelle jaoks tahab siin juba arvestada, on loogiline järjekord: esmalt koostada, millised andmed alumiiniumi toote kohta asuvad praegu oma süsteemis — koostis, päritolu, partiandmed, tehnilised omadused. Seejärel on otstarbekus vaadata, kas need andmed on struktureeritud, ekspordiga kujul saadaval (eksport faili, sidumine liidese kaudu) selle asemel, et ainult paberil või hajutatud eri osakondade vahel. Seejärel on see küsimus, kuidas liituda formaati, mida platvorm nõuab, et see pass koostada: alupas.eu koostab passi teiste andmete alusel, mis tootja või importija esitab, ja kuidas see andmeesitus tehiselt toimib — käsitsi sisestamine, failide üleslaadimine või automaatne sidumine — on küsimus, mida platvormiga alustatakse, niipea kui delegeeritud aktist tehnilised spetsifikatsioonid teada on. Ettevõtte, mis juba hoiab tema tootandmeid selges ja struktureeritud viisil, pole hiljem vähem tööd, et need andmed esitada, sõltumata sellest, kas see siis ERP-sidumise kaudu käib või muul moel.

Kust see tuleneb: ESPR artikkel 10 ja 11

Artikkel 10 ESPR-st kirjeldab digitaalse tootepassi nõudeid, sealhulgas andmete ligipääsetavust ja andmekandja sidumist. Artikkel 11 käsitleb spetsiaalselt passiisüsteemi tehtilist kujundust ja toimimist: kuidas andmeid registreeritakse, talletatakse ja vahetatakse, arvestades erinevate süsteemide ja tarneahela osaliste interoperaablust. Mõlemad artiklid jätavad konkreetsed tehilised standardid ja vormingud hilisematele rakendusaktidele; nad seavad siiski põhimõtte, et pass peab olema masinavõimalik ja süsteemist sõltumatu, mis on aluseks igasugusele tulevikupõhisele sidumisele välisstandardiga nagu ERP-pakett.

Kellel on soov juba nüüd ette valmistuda, peaks parandama oma tooteandmeid struktureeritult ja digitaalselt, nii et andmete edastamine — olenemata vormist — oleks hiljem küsimus ühendamisest, mitte uuesti organiseerimisest.

Millele see põhineb

Määrus ise asub EUR-Lexis. Me viitame iga väitele; te ei pea meid uskuma.

Mida te konkreetselt peate tegema

Mida teilt oodatakse

Pasport peab olema andmekogumina ülekantav, mitte ainult kuva kujul

ESPR artikkel 10 (Määrus (EL) 2024/1781) kirjeldab digitaalset tootepasporti kui andmekogumit, mis on elektrooniliste vahendite abil loetav ja ülekantav. See on erinev nõue kui "kaunis leht, mis avaneb QR-koodi skannimise järel". 10–100 töötajaga ettevõtte jaoks tähendab see, et pasportis olevad andmed peavad olema saadaval ka struktureeritud andmetena — mitte ainult veebilehe tekstina. Kas ja kuidas see seotakse ettevõtte enda ERP- või varude süsteemiga, on ettevõtte enda valik; regulatsioon ei kohusta integreerimisele, kuid nõuab andmekogumit, mis selleks sobib.

Süsteemide vahelne koostalitlus on lähteprintsiip, mitte tarnija tehniline valik

ESPR artikkel 11 käsitleb digitaalse tootepasporti tehnilist kujundamist ja toimimist ning nimetab koostalitluse üheks põhiprintsiibiks, millele paspordi süsteem peab vastama. See on otseselt seotud küsimusega, kas integreerimine enda süsteemiga on võimalik: selle artikli kohaselt üles ehitatud pasport on põhimõtteliselt mõeldud andmete vahetamiseks süsteemide vahel, mitte suletud keskkonnaks. Praktikas märkab ettevõte seda peamiselt küsimusega, milliseid andmeformaate ja identifikaatsioonkoode platvorm kasutab, ja kas need sobituvad ettevõtte enda ERP-süsteemiga.

Unikaalne identifikaatsioonikood on sild pasporti ja enda haldusvahendi vahel

Tootepasporti ja sisemise süsteemi vaheline integreerimine sõltub täielikust identifikaatsioonkoodist toote või partii kohta. Ilma üheselt määratud koppeltusvõtmeta jääb ERP-integreerimine praktikas automatiseerimiseks raskeks, ehkki seda ei ole artikkel 10 või 11 teksti literaalselt kirjas. Selle identifikaatsioonikood kuidas koostatakse ja määratakse, on kirjeldatud lehel kuidas anda igale tootele unikaalne identifikaatsioonikood. Alumiiniumi partiidena müüva ettevõtte jaoks on see seotud ka küsimusega, kas registreerimine toimub partiide või üksikute toodete kaupa, mis on käsitletud lehel partiide või üksikute toodete registreerimine.

Pasport jääb olemasolevaks, isegi kui sisene süsteem muutub

ERP-süsteem asendatakse, migreeritakse või uuendatakse mingil hetkel. Tootepasport ise sellega automaatselt kaasa ei lähe — seda hostivad kümme aastat, sõltumata sellest, mis sisemiselt varude haldusega juhtub. See erinevus on oluline integreerimise korraldamisel: integreerimine on mugavus ettevõtte tegevuse jaoks, mitte asendaja kohustusele, et pasport jääb ligipääsetavaks. Rohkem selle säilitamistähtaja kohta on lehel kui kaua pasport peab saadaval olema.

Kus praktikas valesti läheb

Ettevõtteid, kes kaaluvad integreerumist pasporti ja enda süsteemi vahel, saab ette regulaarselt mõned olukord:

ERP-süsteem näeb enda alusena, samas kui pasport peaks olema alus. Kui andmed on kord avaldatud, on pasport välismaailmale nõutav tõde. Sisemise süsteemi muutused ei lähe sinna automaatselt sisse, ja kes seda ajab segamini, riskib, et pasport ja enda haldus eralduvad.
Varude muutused aetakse segamini pasporti muutustega. Sisene varusüsteem muutub iga päev: kogused, asukohad, partii olekud. Tootepasport registreerib tootekujundused, mitte praegust varude positsiooni. Kes neid kaht andmetüüpi segatakse ühes integreerimisel, loob mittevajalikku keerukust — ja mõnikord ebaõigeeid muutusi juba avaldatud pasportis. Kuidas muutmine pärast avaldamist täpselt töötab, on kirjeldatud lehel andmete muutmine pärast avaldamist.
Integreerimine ehitatakse platvormi identifikaatsioonkoodi arvesse võtmata. Kui sisemine artiklinumber ei ole kooskõlas passiga kasutatava koodiga, tekib käsitsi tõlkeprotsess, mis praktiliselt tühistab sidestamise.
Eeldatakse, et ERP-sidestamine tagab ka füüsilise QR-koodi tootele. Need on kaks eraldatud komponenti: andmesidestumine reguleerib teabevahetust, kandja paigaldamine alumiiniumile endiselt on eraldiseisev protsess. Vaadake selle kohta kuidas QR-kood tootele jõuab.
Eeldatakse, et omaenda süsteem loob hiljem passi "automaatselt". Kuni alumiiniumi delegeeritud õigusakt ei ole avalikustatud, pole määratletud, milline andmevormingute formaat täpselt kohustuslik on. Sidestamist saab ette valmistada, kuid eeldus, et omaenda ERP-süsteem hiljem iseseisvalt kõigile nõuetele vastab, on ennatlik.

Mida saate fikseerida

Ettevõtetele, kes kaaluvad sidestamist tootepassi ja omaenda süsteemi vahel, on praktiline siseselt fikseerida alltoodud punktid — isegi kui sidestamist veel ei ehitata:

Millised ERP- või varude süsteemi väljad vastavad tootepassi väljadele, kaasa arvatud iga toote või partii jaoks kasutatud identifitseerimiskood.
Kes ettevõttes vastutab andmete ajakohastamise eest, mida kasutatakse nii siseselt kui ka passil.
Kokkulepe selle kohta, millal andmeid sisemisest süsteemist passi üle võetakse ja millal see kindlasti automaatselt ei toimu.
Dokumentatsioon selle kohta, milline süsteem on allikaks milliste andmete jaoks — et kontrolli ajal või ostja küsimuse korral oleks selge, kust arv või tunnus pärineb.
Ülevaade selle kohta, kas pass on ühe toote kohta või partii kohta seadistatud, kuna see määrab, kuidas varude ridadega sidestamine kõige paremini saab olema organiseeritud.

Need punktid ei määra tulemust kindlaks ega garanteeri, et sidestamine vastab sellele, mida delegeeritud õigusakt hiljem nõuab — seda teksti pole veel. Nad tagavad aga selle, et ettevõtte, kui tehnilistest nõuetest konkreetne saab, ei alusta nullist andmete väljaselgitamisega, kuhu need kuuluvad.

See pole õigusabi. See leht annab üldist teavet reguleerimise kohta, millele see platvorm on suunatud. Me ei tunne teie olukorda. Kahtluse korral oma olukorra suhtes konsulteerige juristiga või pädevate järelevalveasutustega.

Kirjutatud tehisintellekti abil ülaltoodud allikate alusel, inimese poolt kontrollitud 2026-08-22. Kas midagi pole õige? Andke teada — parandused saavad eesõiguse.