kādā formātā jāiesniedz produktu pasporta dati

Ko konkrēti jums jādara

Ko no jums tiek sagaidīts

Jautājums par to, kurš failu formāts ir obligāts — JSON, XML, PDF, konkrēta API struktūra — nāk pie katra importētāja un ražotāja, tiklīdz IT nodaļa sāk veidot. Atbilde, pamatojoties uz pašreizējo ESPR tekstu, ir vienkārša: konkrēts failu formāts verordienā nav noteikts. Direktīvas ESPR (Direktīva (EU) 2024/1781) 10. un 11. pants nosaka prasības, kas jāizpilda digitālajam produktu pasem, bet tas notiek funkcionālo un tehnisko prasību līmenī, nevis līmenī, kurā norādīts "izmantojiet JSON-LD" vai "iesniedziet XML failu atbilstoši šai shēmai". Tās īstenošana ir paredzēta deleģēto un izpildes aktu veidā pa produktu grupām.

Savstarpējību centrā, nevis viens konkrēts formāts

ESPR 10. pants nosaka savstarpējību kā galveno prasību: pase ir jāveido tā, lai dažādu pušu sistēmas — pārraudzības iestādes, tirgus dalībnieki, patērētāji — varētu izlasīt datus. Praktiskiem nolūkiem uzņēmumam no 10 līdz 100 darbiniekiem tas nozīmē, ka lēmums par uzglabāšanas un datu apmaiņas formātu var pieņemt ar drošību tikai pēc tam, kad ir pieņemts deleģētais akts attiecīgajai produktu kategorijai. Līdz tam ieteicams strādāt ar strukturētiem datiem (piemēram, vērtībām datu bāzē vai ERP sistēmā), nevis datus glabāt tikai brīvā dokumenta vai PDF failā, lai vēlāka iesniegšana gala formātā prasa mazāk pārlabošanas.

Pases ir jābūt lasāmai, izmantojot QR datu nesēju

ESPR 11. pants apraksta pases tehnisko darbību, tostarp savienojumu ar datu nesēju uz produkta. Tas nozīmē, ka pamatā esošos datus, neatkarīgi no formāta, ir jāvar atklāt brīdī, kad kāds skenē kodu. Kā šis savienojums tehniski darbojas un kādi identifikācijas standarti tajā piedalās, ir aprakstīts lapā par kā QR kods produktu pasem nonāk uz manu elektroniku. Uzņēmumiem, kas jau strādā ar GS1 svītrkodam, ir svarīgs jautājums par to, vai esošo identifikācijas struktūru varētu pārizmantot — šis temats tiek aplūkots lapā par ko ir GS1 Digital Link un vai tas ir nepieciešams produktu pasem.

Katram produktam jābūt unikāli identificējamam neatkarīgi no failu formāta

Neatkarīgi no tā, kāds tehniskais formāts tiks noteikts, pamatprasība ir tāda, ka katrs produkts saņem unikālu identifikācijas kodu. Tā ir atsevišķa prasība, kas nemainās, ja faila formāts vēlāk tiks noteikts. Uzņēmumi, kuri jau tagad sāk strukturēt savus produktu datus, ieteicams šo identifikāciju iekļaut kā pastāvīgu daļu. Kā tas praktiski tiek veidots, ir izskaidrots lapā par kā jūs katram produktam piešķirat unikālu identifikācijas kodu.

Reģistrā iesniedzamie dati prasa atsevišķu formu

13. pants ESPR ievieš digitālo produktu pasu reģistru, kurā tiek ierakstīti noteikti dati par pasi. Arī šeit vēl nav noteikts, kādā tieši faila formātā šī iesniegšana jāveic — to precizēs vēlāk. Ir skaidrs, ka šis reģistrs ir atsevišķa iesniegšanas plūsma blakus pasam, kas ir pieejams caur QR kodu. Vairāk par to, kas tur jāietver, ir lapā par kas ir digitālo produktu pasu reģistrs un kas tur jāietver.

Kur praksē pietrūkst saskaņas.

Pārāk agri noteikt rigīdā formātā. Daži uzņēmumi jau tagad laiž veidot PDF pasi, jo tas ir ātri un pazīstams, bet galīgā prasība iespējams prasa strukturētus, mašīnlasāmus datus. PDF ir lasāms cilvēkiem, bet tas nav automātiski piemērots starpsavienojamībai, ko 10. pants ESPR paredz.

Dati izkliedēti vairākās sistēmās bez savienojuma. Produktinformācija bieži atrodas daļēji ERP sistēmā, daļēji mārketinga dokumentos, daļēji ārējā piegādātāja vietnē. Bez plāna šos datus apvienot, tiks sarežģīts ātri pārslēgties, tiklīdz zināms obligātais formāts. Uzņēmumi, kuri apsvēr sava sistēma iesaistīšanu, var uzzināt vairāk par iespējām lapā par produktu pasu savienošanu ar savu ERP vai krājumu sistēmu.

Neskaidrības starp pasu un reģistru. Pase, kas ir pieejama caur QR kodu, un dati, kas nonāk reģistrā, ne obligāti ir identiski pēc formas vai formāta. Pieņēmums, ka viens fails abiem mērķiem ir pietiekams, ir risks, kas kļūst redzams tikai tad, kad izpildpadomniecības pavisam konkrētas.

Ņemot vērā vairākus produktu līmeņus. Produktiem, kas tiek pārdoti kombinētajos iepakojumos vai kad aparāts sastāv no vairākiem komponentiem ar savu pasi, jautājums par to, kā datu formāti savstarpēji saistās, ir vēl sarežģītāks. Tas attiecas, piemēram, uz kastīti ar vairākiem aparātiem iekšā un uz produktiem, kuriem nepieciešami vairāki produktu pasi.

Nepietiekami uzmanības digitālo pasu ilgmūžībai. Faila formāts, kas tagad ir pieņemts, ne obligāti paliks tāds ilgāku laiku. Tā kā pasam jāpaliek pieejamam noteiktu laiku, faila formāta izvēle ir arī jautājums par noturību — sk. paskaidrojumu par cik ilgi produkta pase jāpastāv pieejama.

Ko jūs varat dokumentēt

• Pārskats par to, kur produktu dati pašlaik tiek ierakstīti (ERP, PIM, izklājlapas, piegādātāja dokumenti) un kādā formātā.
• Saraksts ar obligātajiem datu avotiem katrai produktu kategorijai, tiklīdz attiecīgā deleg­ētā handeling ir publicēta.
• Vienošanās ar piegādātājiem un apakšpiegādātājiem par formātu, kādā viņi iesniedz savus produktu datus, lai vēlāk būtu vienkāršāka saistība.
• Iekšējš atbildīgais vai komanda, kas seko tehnisko standartu attīstībai, jo 10. pants ESPR par to vēl saņems tālākus norādījumus.
• Dokumentācija par izvēlēto identifikācijas metodi katram produktam, neatkarīgi no galīgā faila formāta.
• Pārskats par hostinga un pieejamības prasībām, kas kopā ar formātu nosaka, kā pase tehniskā skaitā tiek iestatīta — sk. lapu par kādas hosting prasības attiecas.