---
title: "Javítási adatok július 31-től: A termékútlevél felkészítése a javítási folyamatra — qr3.app Blog"
description: "2026. július 31-től alkalmazandó az uniós javítási irányelv. Így strukturálhatják a vállalatok a termék-, pótalkatrész- és folyamatadatokat a megbízható javítási folyamatokhoz."
canonical: "https://qr3.app/hu/blog/right-to-repair-data-path-2026/"
lang: "hu"
robots: "index,follow,max-image-preview:large,max-snippet:-1"
---

# Javítási adatok július 31-től: A termékútlevél felkészítése a javítási folyamatra — qr3.app Blog

> 2026. július 31-től alkalmazandó az uniós javítási irányelv. Így strukturálhatják a vállalatok a termék-, pótalkatrész- és folyamatadatokat a megbízható javítási folyamatokhoz.

Canonical: <https://qr3.app/hu/blog/right-to-repair-data-path-2026/>

[← Blog](/hu/blog/) [Oktatóanyagok](/hu/blog/category/tutorials/)

2026. július 28. 5 perc olvasás [Oktatóanyagok](/hu/blog/category/tutorials/) [reparaturrecht](/hu/blog/tag/reparaturrecht/)[reparaturdaten](/hu/blog/tag/reparaturdaten/)[produktpass](/hu/blog/tag/produktpass/)[ersatzteile](/hu/blog/tag/ersatzteile/)[qr-code](/hu/blog/tag/qr-code/)

# Javítási adatok július 31-től: A termékútlevél felkészítése a javítási folyamatra

2026. július 31-től alkalmazandó az uniós javítási irányelv. Így strukturálhatják a vállalatok a termék-, pótalkatrész- és folyamatadatokat a megbízható javítási folyamatokhoz.

szerző: **QR3 Redaktion**

![Javítási adatok július 31-től: A termékútlevél felkészítése a javítási folyamatra](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/right-to-repair-data-path-2026/hero.png)

## Július 31-től a javítási folyamat számít

július 31-én a tagállamoknak alkalmazniuk kell az (EU) 2024/1799 irányelvet. Ennek célja az áruk javításának előmozdítása, és kiegészíti a már meglévő szavatossági szabályokat. Ez nem a digitális termékútlevélről szóló jogszabály. A gyártók, importőrök, kereskedők és javítóműhelyek számára azonban a határidő fontos mérföldkő: javítást csak akkor lehet megbízhatóan kínálni, ha a megfelelő termék-, pótalkatrész- és folyamatadatok megtalálhatók. Az irányelvet 2024. június 13-án fogadták el, 2024. július 30-án lépett hatályba, és 2026. július 31-től kell alkalmazni. Ezt az [Európai Bizottság](https://commission.europa.eu/law/law-topic/consumer-protection-law/directive-repair-goods_en) éppúgy megerősíti, mint az [irányelv 22. cikke](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1799).

Gyakorlati hiba lenne, ha a termékútlevelet pusztán megfelelőségi PDF-ként kezelnénk. A megbízható adathozzáférésnek támogatnia kell az utat egy konkrét termék azonosításától a végrehajtható javítási döntésig. Ez már most előkészíthető anélkül, hogy megelőlegeznénk egy még meg nem alkotott termékcsoport-specifikus DPP-kötelezettséget.

## Mit ír elő ténylegesen a javítási irányelv?

Az irányelv azokra a javíthatósági követelmények hatálya alá tartozó árukra vonatkozik, amelyeket az uniós jog II. melléklete felsorol. E termékeket a gyártóknak kérésre meg kell javítaniuk, amennyiben a javítás műszakilag lehetséges. A Bizottság példaként többek között hűtőszekrényeket és okostelefonokat említ. A szabályozás a törvényes szavatosságon kívül is alkalmazandó; szavatosság esetén pedig vonzóbbá kell tenni a javítást. Emellett európai javítási információs űrlapot és európai online javítási platformot hoz létre. A részleteket a [hivatalos (EU) 2024/1799 irányelv](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1799) tartalmazza.

A tervezés szempontjából fontos: az irányelv nem alakít automatikusan minden termékútlevelet javítási útlevéllé. Nem határoz meg egységes adatmodellt minden pótalkatrészre, és konkrét QR-kódot sem ír elő. Hogy a DPP-ben a jövőben mely információk lesznek kötelezőek, csak a terméktervezési rendelethez kapcsolódó, mindenkori felhatalmazáson alapuló jogi aktusokból derül ki. Aki ezt a különbséget egyértelműen elválasztja, két kockázatot kerül el: a túlzó jogi állításokat az értékesítésben és egy olyan adatarchitektúrát, amely nem illeszkedik a későbbi termékcsoport-specifikus jogi aktushoz.

## Miért a DPP mégis a megfelelő adatkapcsoló?

Az (EU) 2024/1781 ökodizájn-rendelet a digitális termékútlevelet elektronikusan hozzáférhető, termékspecifikus adatrekordként határozza meg. Kimondja, hogy egy DPP-t olyan adathordozóval kell összekapcsolni, amely tartós, egyedi termékazonosítóval rendelkezik. A későbbi, felhatalmazáson alapuló jogi aktusok meghatározhatják, hogy milyen szinten – modell, tétel vagy egyedi darab szerint – kell vezetni az adatokat, ki jogosult azok frissítésére, és meddig kell elérhetőnek maradnia az útlevélnek. Erről a rendelet [9. cikke](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng) rendelkezik.

A javítási folyamatok szempontjából különösen releváns a 11. cikk: a lehetséges jogosult szereplők között kifejezetten megnevezi a professzionális javítóműhelyeket és a független üzemeltetőket. A hozzáférés ugyanakkor nem általánosan nyilvános, hanem termékcsoport-specifikus jogosultságokhoz kötött. Ebből műszaki iránymutatás következik, nem új jogi állítás: az ügyfelek, a javítóműhelyek, a pótalkatrész-csapatok és a hatóságok számára szánt adatokat külön kell modellezni. A QR-kód megbízható azonosítóra mutathat, de nem maga legyen az érzékeny üzemi, szerződéses vagy ügyféladatok tárolási helye.

## A javítási folyamat hat adatállomása

A jó célkép nem egy irányítópulttal, hanem egy ellenőrizhető folyamattal kezdődik.

### 1. A termék biztonságos azonosítása

Beolvasáskor vagy kézi bevitelkor egyértelműnek kell lennie, hogy a megkeresés egy modellre, egy tételre vagy egy konkrét készülékre vonatkozik-e. A tartós azonosítónak stabil feloldást kell biztosítania: ne kampány-URL, ne szezonális termékoldal és ne olyan cím legyen, amely egy újraindításkor eltűnik. Dinamikus QR-kódok esetén ezért dokumentált átirányítási és visszaesési útvonalat kell beépíteni az architektúrába. A termékhez kapcsolódó DPP-végpontok műszaki bevezetését a már közzétett [qr3-útmutató a DPP API-hoz](https://qr3.app/de/blog/dpp-api-generate-passports/) ismerteti.

### 2. A javíthatóság elválasztása a diagnózis eredményétől

Egy adatlap jelezheti, hogy egy termék alapvetően javítható. Azt azonban még nem válaszolja meg, hogy a konkrét hiba, a biztonsági állapot és a rendelkezésre álló pótalkatrész lehetővé teszi-e a javítást. Ezért külön mezőket kell fenntartani a termékszabályhoz, a hibadiagnózishoz, a biztonsági figyelmeztetéshez és a javítási döntéshez. A döntéshez eredet, időbélyeg és felelős szerepkör szükséges. Így az általános kijelentésből nem lesz ellenőrizhetetlen ígéret az ügyfelekkel szemben.

### 3. A pótalkatrészek vezetése verzióval és érvényességgel

A javítócsapatoknak nemcsak cikkszámra van szükségük. Szükséges a kompatibilitás, a hardver- vagy szoftververzió, az elérhetőség, az engedélyezett alternatívák, a biztonsági és szerelési útmutatások, valamint az utolsó ellenőrzés időpontja. A beszállítási állapot változása nem írhatja felül az eredeti alkatrészt. Ehelyett modellezzük a verziókat és az érvényességi időszakokat. Ez megkönnyíti a visszahívásokat, a szervizkampányokat és a későbbi visszakövethetőséget.

### 4. Szerepkörök meghatározása általános engedélyezések helyett

A nyilvánosan látható információk közé tartozhat például a modell megnevezése, a kezelési útmutatás és a javítás kapcsolattartási pontja. A professzionális javítóműhelyeknek terméktől függően további műszaki dokumentációra van szükségük. A belső csapatoknak ennél szélesebb körű beszállítói és minőségi adatokra van szükségük. Ezt a szétválasztást már korán rögzítsük, és naplózzuk a nem nyilvános tartalmakhoz való hozzáféréseket. A ESPR a DPPs számára magas szintű biztonsági és adatvédelmi követelményeket ír elő; az ügyféladatokat kifejezett hozzájárulás nélkül nem szabad az útlevélben tárolni.

### 5. A megkeresés állapotának nyomon követhetővé tétele

Az új irányelv erősíti a javítási információkhoz való hozzáférést. Működési szempontból azonban csak akkor alakul ki bizalom, ha a megkeresések nem tűnnek el a postafiókokban. Elegendő egy minimális állapotfolyamat: megkeresés beérkezett, azonosítás vagy a készülék ellenőrizve, költségbecslés elkészült, pótalkatrész rendelkezésre áll, javítás egyeztetve, lezárva vagy indokoltan elutasítva. Minden elutasításnál rögzíteni kell a konkrét okot és a következő lehetséges lépést. Ez egyben a megbízható szolgáltatási mutatók alapja is.

### 6. Az adatok visszaírása a javítás után

Egy alkatrészcserét követően legalább a szervizelőzmény, bizonyos körülmények között pedig a konfiguráció, a szavatossági adatok vagy a biztonsági állapot is megváltozik. Határozzuk meg, ki hozhatja létre ezt a bejegyzést, milyen bizonyítékokat kell tárolni, és mely információk válnak ezt követően az egyes szerepkörök számára láthatóvá. A ESPR előírja, hogy a DPP-adatok pontosak, teljes körűek és naprakészek legyenek. Egy irányítás nélküli javítási előzmény éppen ezt a követelményt nem teljesítené.

## Mit érdemes a hét végéig ellenőrizni?

Július 31. nem ad okot elhamarkodott teljes migrációra. Inkább három konkrét kérdés ellenőrzésének megfelelő időpontja. Először: hozzá tud-e rendelni egy javítási megkeresést egyértelmű termékhez az érintett termékcsoportok esetében? Másodszor: verziózva vannak-e a pótalkatrész- és kompatibilitási adatok, és megtalálják-e azokat a jogosult javítóműhelyek? Harmadszor: bizonyítani tudja-e, hogy ki és miért módosított egy adatrekordot?

Ha valamelyik válasz hiányzik, kezdjünk egy kis pilottermékkel és egy valódi javítási esettel. A beolvasástól a megbízható döntésig eltelt időt mérjük, ne a kitöltött mezők számát. Így összekapcsolható a július 31-től érvényes javítási gyakorlat egy olyan DPP-architektúrával, amely kellően nyitott marad a jövőbeli, felhatalmazáson alapuló jogi aktusok számára.

## Források

- [Európai Bizottság: Directive on repair of goods](https://commission.europa.eu/law/law-topic/consumer-protection-law/directive-repair-goods_en) – A javítási irányelv állása és alkalmazásának időpontja.

- [EUR-Lex: (EU) 2024/1799 irányelv](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024L1799) – Hivatalos szöveg, különösen a 4., 21. és 22. cikk, valamint a II. melléklet.

- [EUR-Lex: (EU) 2024/1781 rendelet](https://eur-lex.europa.eu/eli/reg/2024/1781/oj/eng) – Digitális termékútlevél, különösen a 9–11. cikk és a III. melléklet.

## Kapcsolódó cikkek

- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/iso-iec-jtc5-dpp-framework-2026/hero.png) Iparági hírek ISO/IEC JTC 5: Az architektúra felkészítése az DPP-interoperabilitásra Az ISO/IEC JTC 5 nemzetközi DPP-keretrendszeren dolgozik. Mit jelent a még nyitott munkadokumentum ma az adatmodellek, szerepkörök és interfészek szempontjából.](/hu/blog/iso-iec-jtc5-dpp-framework-2026/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/digital-circularity-vehicle-passport-2026/hero.png) DPP a gyakorlatban Digitális jármű-körforgási útlevél: Mit kell a gyártóknak 2032-ig előkészíteniük Az EU 2026/1738 rendelete 2032-től digitális körforgási útlevelet vezet be a járművekhez. Így strukturálhatják a gyártók már ma az adatokat, a hivatkozásokat és a hozzáféréseket.](/hu/blog/digital-circularity-vehicle-passport-2026/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/eu-garan-qr-code-online-display-2026/hero.png) QR-kód technológia EU-GARAN 2026. szeptember 27-től: a QR-kód és az online áruház helyes megvalósítása 2026. szeptember 27-től uniós előírások vonatkoznak a kellékszavatossági tájékoztatóra és a GARAN-címkére. Így marad helyes a QR-kód, az online megjelenítés és a termék-hozzárendelés.](/hu/blog/eu-garan-qr-code-online-display-2026/)
- [![](https://qr3-blog-agent.meistern.workers.dev/cdn/blog/clp-digital-label-access-tracking-outage-2026/hero.png) Szabályozás CLP-digitális címke 2026 júliusától: mit kell biztosítaniuk a QR-céloldalaknak a hozzáférés, a követés és a kiesések terén 2026. július 1-jétől CLP-szabályok vonatkoznak a digitális címkézésre. Mit kell biztosítaniuk a QR-céloldalaknak a követés, a nyelvválasztás, az elérhetőség és a kiesések kezelése terén.](/hu/blog/clp-digital-label-access-tracking-outage-2026/)

[← Minden cikk](/hu/blog/) [Kezdés ingyen](https://app.qr3.app/sign-up)
