Vai es varu saistīt produkta pasi ar manu ERP vai krājumu sistēmu?

Savienojums ir sākumpunkts, tehniskā forma vēl nav definēta

Savienojums starp digitālo produkta pasi un paša ERP vai krājuma sistēmu atbilst tam, kā ESPR ir uzbūvējusi pasi: dati jābūt mašīnlasāmiem un savietojamiem, tieši tāpēc, lai tie nebūtu atkārtoti jāievada manuāli. ESPR (Regula (ES) 2024/1781) 10. pants nosaka produkta pasem prasības, kas orientētas uz savietojamību, un 11. pants attiecas uz tehnisko dizainu un darbību, ieskaitant datu apmaiņas veidu. Tas nozīmē, ka savienojums pamatā ir iespējams. Tas, kas vēl trūkst, ir konkrēta tehniskā realizācija tekstilam: kāds faila formāts, kuri lauki ir obligāti un vai tiks izstrādāts standarta API, vēl nav noteikts. Šie detaļi izriet no papildu regulējuma, kas tiek izstrādāts specifiski apģērbam un tekstilam.

Kuriem tas ir paredzēts un kuriem nē

Savietojamības prasība no 10. panta un tehniskās normes no 11. panta attiecas uz digitālo produkta pasi kā tādu, neatkarīgi no tā, vai marka, importiera vai privātā marka īpašnieks pasi pats sagatavo vai laiž sagatavot. Tas ir vispārējā prasība ESPR ietvaros, nevis kaut kas, kas tiek izdomāts atsevišķi katrai produktu kategorijai. Tas nesaka, ka jau tagad ir jāuzbūvē tehniskais savienojums vai jāgarantē, ka noteikts faila formāts vai protokols vēlāk izrādīsies derīgs. Turklāt pase nav ERP sistēmas kopija: tā satur datus, kas ir aktuāli pasei (sastāvs, izcelsme, apkopes informācija un tamlīdzīgi), nevis pilnīgu krājuma vai pasūtījuma administrāciju. Savienojums praksē nozīmē, ka daļa no jau esošiem produkta datiem tiek nosūtīta uz pasi, nevis tas, ka abi sistēmi pilnībā saplūst.

Kad tas kļūst konkrēts un kas līdz tam ir spēkā

Fiksēts šīs pienākuma termiņš vēl nav noteikts. No ESPR darbības plāna 2025.-2030. gadam izriet, ka tekstilam paredzētais delegētais akts tiek gaidīts 2027. gadā, un apģērbam ar astoņdesmit procentiem vai vairāk tekstilšķiedras jābūt pirmajiem kandidātiem. Tiklīdz šis akts tiks publicēts, arī kļūs skaidrs, kādas tehniskās prasības tiek noteiktas datu apmaiņai, un līdz ar to tas, vai un kā savienojums ar ERP vai krājuma sistēmu var izskatīties. Līdz tam spēkā ir tikai vispārējās normes no 10. un 11. panta: rāmis ir izveidots, tekstila tehniskā realizācija vēl nav. Ikviens, kurš tagad vēlētos veidot savienojumu, to veidotu uz rāmja, kura detaļas joprojām var mainīties.

Ko tas nozīmē praksē, soli pa solim

Pirmkārt, ir jēdzīgi apsvērt, kādi dati jau atrodas paša sistēmā un kuri no tiem iespējams nonāks pasē: šķiedru sastāvs, ražošanas valsts, materiāla izcelsme, apkopes instrukcijas. Tālāk ir praktiski šos datus fiksēt pēc iespējas strukturēti, fiksētos laukos ar vienīgajām vērtībām, nevis brīvā tekstā, lai tos vēlāk būtu vieglāk pārsūtīt uz jebkuru formātu. Tad ir gudri gaidīt ar faktiskā tehniskā savienojuma vai API uzbūvi, jo tekstilam paredzētās prasības vēl nav noteiktas; enerģija, kas tagad tiek ieguldīta specifiskā savienojumā, var pēc delegētā akta publicēšanas prasīt pielāgošanu. Kas jau darbojas, ir datu nodošana tā, kā tas tagad ir pieejams: manuāli, faila veidā vai ar vienkāršu eksportu no esošās sistēmas. Texpas sagatavo pasi no datiem, ko nodrošina ražotājs vai importieris, un šobrīd apstrādā šo nodošanu bez tiešā savienojuma. Tiklīdz tekstilam ir pieejams tehniskais rāmis, var izskatīt, vai direktāks savienojums no ERP vai krājuma sistēmas ir noderīgs.

Uz ko tas ir balstīts: ESPR 10. un 11. pants

Interoperabilitātes prasība un mašīnlasāmības prasība digitālajam produktu pasam izriet no ESPR (Regulas (ES) 2024/1781) 10. panta, kurš nosaka vispārējās pases prasības. Tās pašas regulas 11. pants apraksta pases tehnisko dizainu un darbību, tostarp to, kā dati tiek digitāli reģistrēti un apmainīti. Abi panti veido ietvaru, kurā vēlākajai produktspecifiskajai tekstila tiesību aktiem jāpilda tehniskus detaļas; šī aizpilde tekstilam un apģērbam vēl nav pieejama.

Ja jūs jau tagad strukturēti reģistrējat datus par sastāvu, izcelsmi un apkopi savā sistēmā, jums vēlāk tas nav jāsāk no jauna, neatkarīgi no tā, kādu tehnisko formu iegūs savienojums. Lai uzzinātu par deleģētā akta pašreizējo stāvokli un precīzo grafiku, Eiropas Komisijas oficiālais avots ir vieta, kuru jāpratvēra.

Uz ko tas ir balstīts

Paša Regula ir pieejama EUR-Lex. Mēs atsaucamies uz katru apgalvojumu; jums mums nav jātic.

Ko jums konkrēti jāizdara

Ko no jums tiek sagaidīts

Pasportam jāspēj saņemt datus no avota sistēmām

ESPR 10. pants (Regula (ES) 2024/1781) nosaka prasības tam, kādi dati jāietver digitālajā produkta pasportā un kā tie jāpiedāvā. Šie dati nav no nekurienes: tie jau atrodas esošajās sistēmās, piemēram, ERP paketē, PLM sistēmā vai krājumu pārvaldības paketē — materiāla sastāvs, piegādātāju dati, partijas numuri, aprūpes norādījumi. Uzņēmumam ar 10–100 darbiniekus tas praktiski nozīmē, ka jābūt savienojumam starp sistēmu, kurā šie dati jau ir, un sistēmu, kas pasportu sagatavo un publicē. Tas var būt automatizēts savienojums, bet arī periodiska eksporta, kuru manuāli augšupielādē. Abi ir principā iespējami; kāda forma ir praktiski piemērota, ir atkarīga no produktu un variantu daudzuma un no tā, cik bieži dati mainās.

Tehniskā darbība jāsaslēdz ar noteiktajiem standartiem

ESPR 11. pants (Regula (ES) 2024/1781) apraksta pasporta tehnisko dizainu un darbību, tostarp to, kā notiek datu apmaiņa. Tas tieši ietekmē jautājumu par to, kā tehniskā izlaidumā tiek iestatīts savienojums: ne katrs eksporta formāts no patvaļīgas ERP sistēmas bez apstrādes neatbilst tam, ko pasparta sistēma sagaida. Vidējā lieluma uzņēmumam tas nozīmē, ka nepieciešama tulkošana starp paša datu struktūru un formātu, kas paredzēts pasportam. Tas ir tehnisks jautājums, nevis juridisks — bet tas tomēr skar jautājumu kas ir GS1 Digital Link un vai tas ir nepieciešams produkta pasportam, jo daļa no paredzamās standartizācijas notiek šādu sistēmu ietvaros.

Katrs produkts jāvar izsekot līdz pareiziem pasporta datiem

Savienojums ar ERP vai krājumu sistēmu darbojas tikai tad, ja ir skaidrs veids, kā saskaņot fizisko produktu ar pareizo pasportu. Tas prasa konsekventu atslēgu starp sistēmām: tāds pats artikula numurs, tāds pats partijas kods vai tāda pati variantu identifikācija ERP sistēmā, kāda ir pasportā. Bez šī savienojuma rodas risks, ka savienotā sistēma gan nosūta datus, bet uz nepareizo pasportu, vai ka izmaiņa vienā sistēmā neatspīlējas otrā. Tas cieši saistās ar to, kā katrs produkts saņem unikālu identifikācijas kodu; bez skaidras identifikācijas loģikas savienojums starp sistēmām ir maz vērts.

Kur praktiski kļūdās

Pirmā situācija, kas bieži parādās: uzņēmumam ir ERP sistēma, kurā artikuli ir reģistrēti pēc stila, bet ne pēc krāsas vai izmēra. Pasportam tomēr jāatbilst variantu līmenim, un tad izrādās, ka savienojums nosūta datus, kas vienai izmēram der, bet otrai nē.

Otrā situācija: dati tiek pārsūtīti vienreiz, kad kollekcija tiek palaista klajā, bet vēlāka izmaiņa ERP sistēmā — piemēram, cits piegādātājs daļai no partijas — netiek automātiski pārsūtīta uz publicēto pasportu. Pasports tā paliek atdalīts no realitātes, nemanāmi, līdz kāds atklāj kļūdu un jautā, vai publicēts produkta pasports vēl var tikt koriģēts.

Trešā situācija: savienojums tehniskā ziņā tiek iestatīts no ārējās IT puses, bet neviens uzņēmumā neseko līdzi tam, vai dati, kas nonāk pasportā, tiešām atbilst tam, kas ir uz etiķetes vai iepakojuma. Savienojums, kas tehnikā darbojas, nav automātiski savienojums, kas ir pareizs.

Ceturtā situācija: krājumu sistēma tiek izmantota, lai automātiski noraidītu pasportus, tiklīdz produkts ir pārdots, neņemot vērā jautājumu par to, cik ilgi pasportam jābūt pieejamam. Tas var izraisīt neatbilstību starp to, kas operacionāli ir ērti krājumu administrācijai, un to, ko sagaida ņemot vērā cik ilgi produkta pase jāpaliek pieejama.

Piektais situācija: apvienošanās, uzņemšanas vai uzņēmuma struktūrvienības slēgšanas gadījumā savienojums tiek atvienots, neizvērtējot, kurš pēc tam pārvalda datus, kas atkal atbilst jautājumam ko darīt ar produkta pasi, ja uzņēmums pārtrauc darbību.

Ko varat fiksēt

Pārskats par to, kuri sistēmas piegādā kuras pasporta datus: ERP materiāla un izcelsmes gadījumam, krājumu sistēma pieejamības gadījumam, PLM projektēšanas un montāžas datu gadījumam.
Dokumentēta vienošanās par sinhronizācijas biežumu: reāllaikā savienojums, ikdienas eksports vai manuāls atjauninājums katrai kolekcijai.
Dokuments, kurā aprakstīta identifikācijas atslēga, ko izmanto produkta sasaistīšanai ERP sistēmā ar pareizo pasportu — ieskaitant to, kā tas darbojas variantu gadījumā pēc izmēra vai krāsas.
Atbildīga funkcija vai persona, kas pārbauda, vai dati, kas nonāk caur savienojumu, patiešām ir pareizi, pirms pasports tiek publicēts vai atjaunināts.
Procedūra tam, kas notiek, ja bronsistēmā tiek veiktas izmaiņas: kurš par to signalizē un kā izmaiņa tiek ieviesta publicētajā pasportā.
Vienošanās ar IT piegādātāju vai iekšējo IT nodaļu par savienojuma tehnisko formātu, ieskaitant to, kas notiek sistēmas maiņas vai migrācijas gadījumā.
Pārskats par to, kuri dati caur savienojumu tiek piegādāti automātiski un kuri joprojām tiek papildināti manuāli, lai starp to, ko sistēma mēģina nosūtīt, un to, kas patiešām atrodas pasportā, nepazustu.

Šis nav juridisks padoms. Šī lapa sniedz vispārīgu informāciju par tiesību aktiem, par kuriem ir šī platforma. Mēs nezinām jūsu situāciju. Ja domājat par savu gadījumu, konsultējieties ar juristu vai kompetento uzraudzības iestādi.

Rakstīts ar AI, pamatojoties uz iepriekš minētajiem avotiem, cilvēks pārbaudīja 2026-08-22. Kaut kas nav pareizi? Dodiet mums zināt — labojumi tiek uzskatīti par prioritāru.