Nuo liepos 31 d. svarbus remonto kelias
2026 m. liepos 31 d. valstybės narės turi pradėti taikyti Direktyvą (ES) 2024/1799. Ja siekiama skatinti prekių remontą ir papildyti galiojančias garantijos taisykles. Tai nėra skaitmeninio produkto paso įstatymas. Vis dėlto gamintojams, importuotojams, prekybininkams ir remonto įmonėms ši data yra geras atskaitos taškas: patikimai pasiūlyti remontą galima tik tada, kai reikiami produkto, atsarginių dalių ir proceso duomenys yra lengvai randami. Direktyva priimta 2024 m. birželio 13 d., įsigaliojo 2024 m. liepos 30 d. ir turi būti taikoma nuo 2026 m. liepos 31 d. Tai patvirtina ir Europos Komisija, ir Direktyvos 22 straipsnis.
Praktinė klaida būtų produkto pasą laikyti tik atitikties PDF dokumentu. Patikima prieiga prie duomenų turi padėti pereiti nuo konkretaus produkto identifikavimo iki įgyvendinamo sprendimo dėl remonto. Tam galima pasirengti jau šiandien, nebandant iš anksto taikyti dar nepriimto konkrečioms produktų grupėms skirto DPP reikalavimo.
Ko iš tikrųjų reikalauja remonto direktyva
Direktyva taikoma prekėms, kurioms pagal Sąjungos teisę nustatyti taisomumo reikalavimai ir kurios išvardytos II priede. Šių produktų gamintojai, gavę prašymą, turi juos remontuoti, jei remontas techniškai įmanomas. Komisija kaip pavyzdžius nurodo, be kita ko, šaldytuvus ir išmaniuosius telefonus. Reglamentavimas taikomas ir pasibaigus įstatymuose nustatytam garantijos laikotarpiui, o garantijos laikotarpiu remontas turėtų tapti patrauklesnis. Direktyva taip pat sukuria europinę remonto informacijos formą ir europinę internetinę remonto platformą. Išsami informacija pateikta oficialioje Direktyvoje (ES) 2024/1799.
Planuojant svarbu žinoti: direktyva automatiškai nepaverčia kiekvieno produkto paso remonto pasu. Ji nenustato nei vieningo visų atsarginių dalių duomenų modelio, nei konkretaus QR kodo. Kokia informacija DPP ateityje bus privaloma, paaiškės tik priėmus atitinkamus deleguotuosius teisės aktus pagal Ekologinio projektavimo reglamentą. Aiškiai atskyrus šiuos dalykus išvengiama dviejų rizikų: pernelyg plačių teisinių teiginių pardavimo procese ir duomenų architektūros, kuri neatitiktų vėliau priimto konkrečios produktų grupės akto.
Kodėl DPP vis dėlto yra tinkamas duomenų atskaitos taškas
Ekologinio projektavimo reglamente (ES) 2024/1781 skaitmeninis produkto pasas apibrėžiamas kaip elektroniniu būdu pasiekiamas konkretaus produkto duomenų rinkinys. Jame nustatyta, kad DPP turėtų būti susietas su duomenų laikmena, kurioje pateikiamas nuolatinis unikalus produkto identifikatorius. Vėlesniais deleguotaisiais teisės aktais gali būti nustatyta, kokiu lygmeniu – modelio, partijos ar atskiro vieneto – duomenys tvarkomi, kas gali juos atnaujinti ir kiek laiko pasas turi būti prieinamas. Tai nustatyta Reglamento 9 straipsnyje.
Remonto procesams ypač svarbus 11 straipsnis: tarp galimų teisę turinčių subjektų jame aiškiai nurodomos profesionalios remonto įmonės ir nepriklausomi operatoriai. Kartu prieiga nėra visiems vienodai vieša – ji priklauso nuo konkrečiai produktų grupei nustatytų teisių. Iš to kyla techninė gairė, o ne naujas teisinis teiginys: klientams, remonto įmonėms, atsarginių dalių komandoms ir institucijoms skirti duomenys turėtų būti modeliuojami atskirai. QR kodas gali nukreipti į patikimą identifikatorių, tačiau pats neturėtų būti neskelbtinų veiklos, sutartinių ar klientų duomenų saugojimo vieta.
Remonto kelias per šešias duomenų stoteles
Geras tikslinis modelis prasideda ne nuo skydelio, o nuo patikrinamos eigos.
1. Saugiai identifikuoti produktą
Nuskaičius kodą arba įvedus duomenis rankiniu būdu turi būti aišku, ar užklausa susijusi su modeliu, partija, ar atskiru įrenginiu. Nuolatinis identifikatorius turi būti stabiliai susiejamas: tai neturėtų būti kampanijos URL, sezoninio produkto puslapis ar adresas, kuris išnyks atnaujinus svetainę. Todėl naudojant dinaminius QR kodus architektūroje turi būti dokumentuotas peradresavimo ir atsarginis kelias. Techninis įvadas į su produktais susijusius DPP galinius taškus pateikiamas jau paskelbtame qr3 vadove apie DPP API.
2. Atskirti taisomumą nuo diagnozės rezultato
Duomenų lape gali būti nurodyta, kad produktą iš esmės galima remontuoti. Tačiau tai dar neatsako, ar konkretus gedimas, saugos būklė ir turima atsarginė dalis leidžia atlikti remontą. Todėl numatykite atskirus produkto taisyklės, gedimo diagnozės, saugos įspėjimo ir sprendimo dėl remonto laukus. Sprendime turi būti nurodyta kilmė, laiko žyma ir atsakingas vaidmuo. Taip bendras teiginys netampa nepatikrinamu pažadu klientams.
3. Tvarkyti atsargines dalis pagal versiją ir galiojimą
Remonto komandoms reikia ne tik dalies numerio. Būtina nurodyti suderinamumą, aparatinės ar programinės įrangos versiją, prieinamumą, leistinas alternatyvas, saugos ir montavimo instrukcijas bei paskutinio patikrinimo laiką. Pakeitus tiekimo būseną ankstesnė dalis neturėtų būti perrašoma. Vietoj to modeliuokite versijas ir galiojimo laikotarpius. Tai palengvina atšaukimus, techninės priežiūros kampanijas ir vėlesnį atsekamumą.
4. Apibrėžti vaidmenis, o ne bendrus leidimus
Viešai matoma informacija gali apimti, pavyzdžiui, modelio pavadinimą, priežiūros instrukcijas ir kontaktą dėl remonto. Profesionalios remonto įmonės, priklausomai nuo produkto, gali būti papildomai aprūpinamos technine dokumentacija. Vidinėms komandoms reikia išsamesnių tiekėjų ir kokybės duomenų. Šį atskyrimą nustatykite anksti ir registruokite prieigas prie neviešo turinio. ESPR reikalauja, kad DPPs būtų taikomi aukšti saugumo ir duomenų apsaugos standartai; klientų duomenys be aiškaus sutikimo negali būti saugomi pase.
5. Padaryti užklausos būseną atsekamą
Naujoji direktyva gerina prieigą prie remonto informacijos. Tačiau veiklos požiūriu pasitikėjimas atsiranda tik tada, kai užklausos nepradingsta pašto dėžutėse. Pakanka minimalaus būsenų srauto: užklausa gauta, tapatybė arba įrenginys patikrintas, parengta išlaidų sąmata, atsarginė dalis prieinama, remontas suderintas, užbaigtas arba pagrįstai atmestas. Kiekviename atmetime turėtų būti nurodyta konkreti priežastis ir kitas galimas veiksmas. Tai taip pat yra patikimų paslaugų rodiklių pagrindas.
6. Po remonto grąžinti duomenis į sistemą
Pakeitus dalį mažiausiai pasikeičia techninės priežiūros istorija, o tam tikrais atvejais – konfigūracija, garantijos duomenys ar saugos būsena. Nustatykite, kas gali sukurti šį įrašą, kokius įrodymus reikia išsaugoti ir kokia informacija vėliau turi būti matoma kiekvienam vaidmeniui. ESPR reikalauja, kad DPP-duomenys būtų tikslūs, išsamūs ir aktualūs. Remonto istorija be valdymo mechanizmų šio reikalavimo tikrai neatitiktų.
Ką reikėtų patikrinti iki savaitės pabaigos
Liepos 31-oji nėra priežastis skubiai visiškai perkelti visas sistemas. Tai tinkamas kontrolinis taškas trims konkretiems klausimams. Pirma: ar galite konkrečių produktų grupių remonto užklausą susieti su vienareikšmiškai identifikuotu produktu? Antra: ar atsarginių dalių ir suderinamumo duomenys versijuojami ir prieinami teisę turinčioms remonto įmonėms? Trečia: ar galite įrodyti, kas ir kodėl pakeitė duomenų rinkinį?
Jei į vieną iš klausimų atsakymo nėra, pradėkite nuo nedidelio bandomojo produkto ir tikro remonto atvejo. Matuokite laiką nuo nuskaitymo iki patikimo sprendimo, o ne užpildytų laukų skaičių. Taip nuo liepos 31 d. taikomą remonto praktiką susiesite su DPP architektūra, kuri išliks pakankamai lanksti būsimiems deleguotiesiems teisės aktams.
Šaltiniai
- Europos Komisija: Directive on repair of goods – remonto direktyvos būklė ir taikymo data.
- EUR-Lex: Direktyva (ES) 2024/1799 – oficialus tekstas, ypač 4, 21 ir 22 straipsniai bei II priedas.
- EUR-Lex: Reglamentas (ES) 2024/1781 – skaitmeninis produkto pasas, ypač 9–11 straipsniai ir III priedas.
