Digitaler Produktpass: drei Regelwerke, drei Zeitpläne, ein Datensatz

Auf Messen heißt es seit Jahren, der digitale Produktpass komme. Wer daraufhin in seinem System ein Feld „DPP“ anlegt, hat nichts gewonnen: Es gibt nicht einen Pass, sondern drei Regelwerke mit drei Zeitplänen und drei Inhaltsverzeichnissen. Für einen Verwerter oder Teilehändler ist die einzige nützliche Frage, welches davon sein Teil betrifft — und welche Daten er dafür heute schon erfassen muss.

Drei Regelwerke, sauber getrennt

Was heute schon gilt: die Batterie

Die Batterie ist das einzige Bauteil mit festem Datum. Der Batteriepass nach Artikel 77 der Verordnung (EU) 2023/1542 wird ab dem 18. Februar 2027 über einen QR-Code erreichbar sein; er gilt für Batterien leichter Verkehrsmittel, Industriebatterien über 2 kWh und Elektrofahrzeugbatterien. Schon seit dem 18. August 2024 verlangt Artikel 14, dass das Batteriemanagementsystem Daten zum Alterungszustand und zur voraussichtlichen Lebensdauer bereithält — genau die Daten, die einen Weiterverkauf erst belegbar machen. Wie man sie liest und dokumentiert, steht in State of Health: was der Prozentwert nicht sagt.

Was ein Betrieb jetzt tun sollte

1. Identität vor Inhalt. Jeder Pass hängt an einer eindeutigen Kennung. Wer heute OE-Nummern normalisiert und Fahrzeuge über die VIN führt, hat die Klammer schon; wer Freitext führt, migriert später zweimal.
2. Exemplar von Typ trennen. Ein Teiletyp hat eine OE-Nummer, ein einzelnes Stück hat eine Seriennummer. Passdaten hängen an beidem — im Bestand müssen beide Ebenen getrennt bleiben.
3. Belege statt Bewertungen speichern. Prüfprotokoll, Messwert, Datum, Prüfer. Aus Belegen lässt sich später jede geforderte Kennzahl bilden; aus einer Kennzahl kein Beleg.
4. Herkunft mitschreiben. Spenderfahrzeug, Ausbaudatum, Bearbeitungsschritte. Das ist die Angabe, die im Nachhinein nicht zu rekonstruieren ist.
5. Kein DPP-Feld auf Vorrat. Solange die Pflichtinhalte der eigenen Produktgruppe nicht feststehen, ist ein leeres Passfeld eine Einladung, es mit Vermutungen zu füllen.

Wo tapinomahub in diesen Datensatz passt

Die Plattform stellt keinen Produktpass aus und ist dafür auch nicht die richtige Stelle. Sie liefert die Bausteine, die später in jeden Pass wandern: GET /parts/oe/normalize und GET /parts/oe/{oeNumber} machen aus einer abgetippten Zeichenfolge eine bestätigte Teileidentität mit Bezeichnung, Fahrzeugzuordnung und Ersetzungskette, GET /vin/{vin}/vehicle liefert die Herkunft mit Typ, Bauzeitraum und Schlüsselnummern, POST /vision/part/quality eine Zustandsstufe mit Einzelkriterien, und POST /vision/identifiers/redact hält instanzbezogene Kennungen aus öffentlichen Bildern heraus, solange sie nicht in den Pass gehören.

Grenzen

• Der Rahmen steht, die Inhalte nicht. Welche Felder eine Produktgruppe füllen muss, entsteht erst in delegierten Rechtsakten. Ein heute gebautes Pflichtfeld kann morgen falsch heißen.
• Ein Pass ist kein Verkaufsargument. Er ist eine Pflicht und eine Datenstruktur, keine Zusicherung von Qualität.
• Zugriffsrechte sind Teil der Aufgabe. Nicht jede Angabe ist öffentlich; Seriennummern und Diagnosedaten brauchen eine Zugriffsstufe, bevor sie erfasst werden.
• Nationale Umsetzung kommt hinzu. Die deutsche Seite der Altfahrzeugbehandlung beschreibt Altfahrzeugverordnung: Pflichten für Halter und Demontagebetriebe; sie bleibt maßgeblich für den Betriebsalltag.

Die ehrliche Zusammenfassung: Für Batterien läuft die Uhr, für Fahrzeuge gilt ein eigenes Regelwerk mit gestaffeltem Start, und für alles andere entscheidet die Produktgruppe. Wer bis dahin Identität, Herkunft und Prüfbelege sauber führt, ist vorbereitet — unabhängig davon, wie die Felder am Ende heißen.

Dieser Beitrag ist eine allgemeine fachliche Einordnung und ersetzt keine Rechtsberatung. Maßgeblich sind der jeweils geltende Gesetzestext und die Auflagen Ihrer zuständigen Behörde.