Vanaf 31 juli telt het reparatietraject
Op 31 juli 2026 moeten de lidstaten Richtlijn (EU) 2024/1799 toepassen. Deze richtlijn moet reparaties van goederen bevorderen en vormt een aanvulling op de bestaande garantieregels. Dit is geen wet inzake het Digital Product Passport. Voor fabrikanten, importeurs, handelaren en reparatiebedrijven is de datum toch een goed ijkpunt: een reparatie kan alleen betrouwbaar worden aangeboden als de juiste product-, reserveonderdelen- en procesgegevens vindbaar zijn. De richtlijn werd op 13 juni 2024 aangenomen, trad op 30 juli 2024 in werking en moet vanaf 31 juli 2026 worden toegepast. Dat bevestigt zowel de Europese Commissie als artikel 22 van de richtlijn.
De praktische fout zou nu zijn om de productpas te behandelen als niet meer dan een compliance-pdf. Betrouwbare gegevenstoegang moet het traject ondersteunen van de identificatie van een concreet product tot een uitvoerbare reparatiebeslissing. Dat kan nu al worden voorbereid, zonder te anticiperen op een nog niet vastgestelde productspecifieke DPP-verplichting.
Wat de reparatierichtlijn daadwerkelijk vereist
De richtlijn heeft betrekking op goederen waarvoor het Unierecht eisen aan repareerbaarheid stelt en die in bijlage II zijn opgenomen. Voor deze producten moeten fabrikanten op verzoek reparaties uitvoeren, voor zover reparatie technisch mogelijk is. De Commissie noemt onder meer koelkasten en smartphones als voorbeelden. De regeling geldt ook buiten de wettelijke garantie; tijdens de garantie moet reparatie aantrekkelijker worden. Daarnaast creëert de richtlijn een Europees formulier voor reparatie-informatie en een Europees onlineplatform voor reparaties. De details staan in de officiële Richtlijn (EU) 2024/1799.
Belangrijk voor de planning: de richtlijn maakt niet automatisch van elke productpas een reparatiepas. Ze schrijft geen uniform gegevensmodel voor alle reserveonderdelen voor en evenmin een bepaalde QR-code. Welke informatie in een DPP in de toekomst verplicht zal zijn, volgt pas uit de desbetreffende gedelegeerde handelingen bij de verordening inzake ecologisch ontwerp. Wie dit onderscheid zorgvuldig maakt, vermijdt twee risico’s: overdreven juridische claims in de verkoop en een gegevensarchitectuur die niet aansluit op de latere productgroepverordening.
Waarom de DPP toch het juiste gegevensanker is
Verordening (EU) 2024/1781 inzake ecologisch ontwerp definieert het Digitale Productpaspoort als een elektronisch toegankelijk productspecifiek gegevensbestand. De verordening bepaalt dat een DPP via een gegevensdrager met een persistente unieke productidentificatie moet worden verbonden. De latere gedelegeerde handelingen kunnen bepalen op welk niveau – model, batch of afzonderlijk exemplaar – gegevens worden bijgehouden, wie ze mag bijwerken en hoelang de pas beschikbaar blijft. Dit staat in artikel 9 van de verordening.
Voor reparatieprocessen is vooral artikel 11 relevant: daarin worden professionele reparatiebedrijven en onafhankelijke exploitanten uitdrukkelijk genoemd als mogelijke bevoegde actoren. Tegelijkertijd is de toegang niet zonder meer openbaar, maar gekoppeld aan productspecifieke rechten. Daaruit volgt een technische richtlijn, geen nieuwe juridische claim: gegevens voor klanten, reparatiebedrijven, teams voor reserveonderdelen en autoriteiten moeten afzonderlijk worden gemodelleerd. Een QR-code mag verwijzen naar een betrouwbare identificatie; hij mag niet zelf de opslagplaats zijn van gevoelige bedrijfs-, contract- of klantgegevens.
Het reparatietraject in zes gegevensstations
Een goed doelbeeld begint niet met een dashboard, maar met een controleerbaar proces.
1. Het product betrouwbaar identificeren
Bij het scannen of handmatig invoeren moet duidelijk worden of de aanvraag betrekking heeft op een model, een batch of een afzonderlijk apparaat. De persistente identificatie moet stabiel kunnen worden opgelost: geen campagne-URL, geen seizoensgebonden productpagina en geen adres dat bij een herlancering verdwijnt. Bij dynamische QR-codes hoort daarom een gedocumenteerd doorstuur- en terugvalpad in de architectuur. Een technische introductie tot productspecifieke DPP-eindpunten biedt de al gepubliceerde qr3-handleiding voor de DPP-API.
2. Repareerbaarheid loskoppelen van het diagnoseresultaat
Een gegevensblad kan aangeven dat een product in principe repareerbaar is. Het beantwoordt nog niet de vraag of de concrete fout, de veiligheidstoestand en het beschikbare reserveonderdeel een reparatie mogelijk maken. Houd daarom afzonderlijke velden bij voor productregel, foutdiagnose, veiligheidswaarschuwing en reparatiebeslissing. De beslissing moet herkomst, tijdstempel en verantwoordelijke rol bevatten. Zo wordt een algemene uitspraak geen niet-controleerbare belofte aan klanten.
3. Reserveonderdelen met versie en geldigheid bijhouden
Reparatieteams hebben meer nodig dan alleen een onderdeelnummer. Nodig zijn compatibiliteit, hardware- of softwareversie, beschikbaarheid, toegestane alternatieven, veiligheids- en montage-instructies en het tijdstip van de laatste controle. Een wijziging in de leveringsstatus mag het oorspronkelijke onderdeel niet overschrijven. Modelleer in plaats daarvan versies en geldigheidsperioden. Dat vergemakkelijkt terugroepacties, servicecampagnes en latere traceerbaarheid.
4. Rollen definiëren in plaats van algemene vrijgaven
Openbaar zichtbare informatie kan bijvoorbeeld de modelaanduiding, onderhoudsinstructies en het contactpunt voor reparaties omvatten. Professionele reparatiebedrijven hebben afhankelijk van het product aanvullende technische documentatie nodig. Interne teams hebben verdergaande leveranciers- en kwaliteitsgegevens nodig. Leg deze scheiding vroeg vast en registreer de toegang tot niet-openbare inhoud. De ESPR vereist voor DPPs een hoge veiligheids- en gegevensbeschermingsstandaard; klantgegevens mogen zonder uitdrukkelijke toestemming niet in de pas worden opgeslagen.
5. De status van de aanvraag traceerbaar maken
De nieuwe richtlijn verbetert de toegang tot reparatie-informatie. Operationeel ontstaat vertrouwen echter pas wanneer aanvragen niet in mailboxen verdwijnen. Een minimale statusstroom volstaat: aanvraag ontvangen, identiteit of apparaat gecontroleerd, kostenraming opgesteld, reserveonderdeel beschikbaar, reparatie afgesproken, afgerond of gemotiveerd afgewezen. Elke afwijzing moet de concrete reden en de volgende mogelijke stap vastleggen. Dit vormt ook de basis voor betrouwbare servicekengetallen.
6. Gegevens na de reparatie terugschrijven
Na het vervangen van een onderdeel veranderen in elk geval de servicehistorie en mogelijk ook de configuratie, garantiegegevens of veiligheidsstatus. Definieer wie deze registratie mag aanmaken, welke bewijsstukken moeten worden opgeslagen en welke informatie vervolgens voor welke rol zichtbaar wordt. De ESPR vereist dat DPP-gegevens nauwkeurig, volledig en actueel zijn. Een reparatiehistorie zonder governance zou juist niet aan deze eis voldoen.
Wat deze week nog moet worden gecontroleerd
31 juli is geen aanleiding voor een overhaaste volledige migratie. Het is een zinvol ijkpunt voor drie concrete vragen. Ten eerste: kunt u voor de betrokken productgroepen een reparatieaanvraag aan een uniek product koppelen? Ten tweede: zijn gegevens over reserveonderdelen en compatibiliteit voorzien van versies en vindbaar voor bevoegde reparatiebedrijven? Ten derde: kunt u aantonen wie een gegevensrecord heeft gewijzigd en waarom?
Als een antwoord ontbreekt, begin dan met een klein pilotproduct en een echte reparatiezaak. Meet de tijd van de scan tot een betrouwbare beslissing, niet het aantal ingevulde velden. Zo verbindt u de vanaf 31 juli geldende reparatiepraktijk met een DPP-architectuur die voldoende open blijft voor toekomstige gedelegeerde handelingen.
Bronnen
- Europese Commissie: Directive on repair of goods – Stand en toepassingsdatum van de reparatierichtlijn.
- EUR-Lex: Richtlijn (EU) 2024/1799 – officiële tekst, met name de artikelen 4, 21 en 22 en bijlage II.
- EUR-Lex: Verordening (EU) 2024/1781 – Digitaal Productpaspoort, met name de artikelen 9 tot en met 11 en bijlage III.
