2026 m. liepos 20 d. Europos Komisija pradėjo eksploatuoti skaitmeninių produktų pasų registrą ir jo testavimo aplinką. Taip abstrakti ESPR-komponentė tapo sistema, kurią įmonės gali iš tikrųjų išbandyti. Gamintojams dabar ypač svarbu atskirti vieną dalyką: registras yra centrinis indeksas, o pats produktų pasas lieka decentralizuotas.
Kas pradėjo veikti liepos 20 d.
Registre saugomi unikalūs produktų identifikatoriai, registracijos duomenys ir pasirinkti metaduomenys. Išsami produkto informacija ir toliau lieka atsakingo ekonominės veiklos vykdytojo arba įgalioto DPP paslaugų teikėjo žinioje. Todėl Komisija registrą aiškiai apibūdina kaip indeksavimo paslaugą, o ne centrinę turinio valdymo sistemą.
Registracija numatyta per saugią naudotojo sąsają ir API. Įmonės taip pat gali sugeneruoti elektroninį registracijos patvirtinimą. Tai svarbu B2B procesams, nes tiekėjai ir klientai taip gali įrodyti, kad pasas įregistruotas ES sistemoje, nedubliuodami viso duomenų rinkinio.
Pradžia susijusi ne tik su ESPR-produktų grupėmis. Komisija taip pat nurodo baterijas, statybos produktus, žaislus, skalbiklius ir galutiniams naudotojams skirtas paviršinio aktyvumo medžiagas, jei atitinkama Sąjungos teisė reikalauja skaitmeninio produkto paso. Pirmasis privalomas terminas tebėra 2027 m. vasario 18 d. tam tikroms baterijoms.
Registras, sprendiklis ir duomenų šaltinis – trys skirtingi sluoksniai
Patikima DPP sistema turėtų aiškiai atskirti funkcijas:
- ES registras patvirtina, kad identifikatorius ir privalomi metaduomenys yra įregistruoti.
- Sprendiklis nukreipia nuolatinį produkto identifikatorių į tinkamą išteklių.
- Tikrasis duomenų šaltinis pateikia aktualų turinį žmonėms ir mašinoms.
Šis atskyrimas nėra detalė. Jei visi duomenys saugomi tik įmonės produktų puslapyje, tai dar nereiškia integracijos su registru. Ir atvirkščiai, vien įregistravus identifikatorių dar nesukuriamas tinkamas produktų pasas. Abu elementai turi būti susieti stabiliais identifikatoriais.
Sprendimui tinka atvira, ilgalaikė nuoroda. Identifikatorių sprendiklis gali leisti pasiekti skirtingus vaizdus naudojant tą patį identifikatorių: suprantamą interneto puslapį, mašininiu būdu perskaitomus JSON-LD duomenis arba papildomą dokumentaciją. Ant produkto ar pakuotės esanti duomenų laikmena išlieka stabili, net jei tikslinės sistemos toliau tobulinamos.
Ką įmonės turėtų patikrinti testavimo aplinkoje
Testavimo aplinka skirta ne vien rankiniam paspaudimų bandymui. Į ją reikėtų žiūrėti kaip į parengiamąjį etapą prieš integravimą į gamybinę aplinką.
Organizacija ir vaidmenys
Pirmiausia reikia išsiaiškinti, kuris juridinis asmuo registruojasi, kas jam atstovauja sistemoje ir kurios komandos gali kurti ar keisti registracijas. Tai susiję su pagrindiniais duomenimis, atitiktimi, IT ir, jei reikia, išorės paslaugų teikėjais. Asmeninė bandomoji paskyra neatstoja būsimos veiklos vaidmenų modelio.
Identifikatoriai ir detalumo lygis
Produktų komanda turėtų nustatyti, ar būsimas pasas bus tvarkomas modelio, partijos ar atskiro vieneto lygmeniu. Atsakymas priklauso nuo konkretaus sektoriaus teisės aktų. Registro bandymas yra tinkamas metas susieti vidinius produkto ID, GTINs, partijų identifikatorius ir išorėje naudojamą nuolatinį identifikatorių.
API ir pakartojamumas
Gamybiniam procesui reikia daugiau nei sėkmingos POST užklausos. Registracija, atnaujinimas ir klaidų tvarkymas turi būti pakartojami ir registruojami. Tai apima idempotentines užklausas, techninius patvirtinimus ir aiškų ryšį tarp ERP įrašo, DPP ir registro įrašo. API pagrįstas DPP procesas sumažina rankinių neatitikimų tikimybę, kai produktai registruojami dideliais kiekiais.
Metaduomenų ir dalykinių duomenų atskyrimas
Registro duomenys neturėtų tapti antruoju produkto duomenų rinkiniu. Apibrėžkite, kurie laukai būtini registre, o kurie lieka decentralizuotame pase. Kiekvienai informacijai reikia pagrindinio šaltinio, atsakingo subjekto ir atnaujinimo taisyklės.
Patvirtinimas ir stebėsena
Registracijos patvirtinimus reikėtų saugoti kartu su laiko žyma, naudotu identifikatoriumi ir sistemos atsakymu. Be to, reikia atlikti sutikrinimą: ar pasas egzistuoja, ar sprendiklis pasiekiamas ir ar registro metaduomenys vis dar atitinka produkto būseną?
Kodėl muitinei reikia atskiros tikrinimo grandinės
Registras padeda muitinėms prieš išleidžiant prekes į laisvą apyvartą automatizuotai patikrinti, ar yra galiojantis įregistruotas DPP ir reikalingas prekių kodas. Importuotojams dėl to atsiranda nauja priklausomybė: produkto identifikatorius, registro įrašas ir muitinės deklaracija turi būti suderinti.
Todėl klaida paaiškėja ne tik produkto puslapyje. Ji gali paveikti sienos kirtimo procesą. Įmonės jau testavimo etape turėtų imituoti duomenų srautus nuo produkto sukūrimo iki importo dokumentų ir nustatyti, kas gali greitai ištaisyti klaidingą registraciją.
Tinkamas 30 dienų bandymų planas
- Pasirinkti realų juridinį asmenį ir nedidelį reprezentatyvų produktų asortimentą.
- Kiekvienam produktui dokumentuoti planuojamą DPP-detalumo lygį ir pagrindinius identifikatorius.
- Atlikti visą procesą per naudotojo sąsają ir, jei aktualu, API.
- Kartu suarchyvuoti registracijos patvirtinimą, sprendiklio atsakymą ir mašininiu būdu perskaitomus produkto duomenis.
- Išbandyti klaidų atvejus: pasikartojantį identifikatorių, pasenusius metaduomenis, nepasiekiamą duomenų serverį ir atšauktą produktą.
- Remiantis rezultatais, sukurti veiklos modelį su atsakomybėmis, stebėsena ir eskalavimo keliu.
Veikiantis registro režimas dar nereiškia, kad visi konkretiems sektoriams taikomi duomenų reikalavimai jau visiškai galioja. Tačiau diskusija nuo pristatymų pereina prie patikrinamų procesų. Įmonės dabar gali išsiaiškinti, ar jų identifikatoriai, vaidmenys ir API dera tarpusavyje, dar neprasidėjus pirmiesiems privalomiems terminams.
