Kann ich das Produktpass mit meinem ERP- oder Lagerverwaltungssystem verknüpfen?
Kopplung ist möglich, die Form ist nicht gesetzlich festgelegt
Ja, ein digitales Produktpass kann in der Praxis an ein ERP- oder Bestandsverwaltungssystem gekoppelt werden, aber die ESPR schreibt nicht vor, wie diese Kopplung aussieht. Die Verordnung stellt jedoch Anforderungen an den Pass selbst: er muss technisch so aufgebaut sein, dass Daten maschinenlesbar sind und dass Systeme sie automatisch auslesen und verarbeiten können, auf der Grundlage offener Standards statt geschlossener, markengebundener Formate (Artikel 11 der ESPR, Verordnung (EU) 2024/1781). Diese Anforderung bezieht sich auf den Pass und den Datenträger, nicht auf die internen Systeme eines Reifenimporteurs, Großhändlers oder Fuhrparkmanagers. Ob und wie eine Kopplung mit einem bestimmten ERP-Paket funktioniert, ist daher eine Frage der technischen Ausgestaltung bei der Partei, die den Pass zusammenstellt und hostet — in diesem Fall eine Plattform wie tyrepas.eu — und nicht etwas, das das Gesetz im Detail regelt.
Für wen dies relevant ist und für wen nicht
Diese Frage stellt sich besonders bei Parteien, die große Mengen an Reifen verarbeiten und bei denen Produktdaten bereits irgendwo in einem System vorhanden sind: Importeure, die Artikelnummern, Chargendaten und technische Spezifikationen verwalten, Großhändler, die Bestände nach Reifentyp führen, und Fuhrparkmanager, die Reifen mit Fahrzeugen verknüpfen. Für diese ist eine Kopplung vor allem praktisch: Daten müssen dann nicht doppelt eingegeben werden, und Passinformationen können in das eigene System zurückfließen.
Für Endnutzer, die nur einen Reifen kaufen und den QR-Code scannen, spielt eine Kopplung mit einem ERP-System keine Rolle — sie lesen den Pass, sie füttern ihn nicht. Und für kleinere Parteien ohne eigenes System ist eine Kopplung auch nicht relevant: Der Pass kann dann ebenso gut manuell eingereicht und abgerufen werden, ohne dass dies die Gültigkeit beeinträchtigt. Die technischen Anforderungen aus Artikel 11 beziehen sich zudem auf den Pass als solchen, nicht auf die Frage, ob ein Pasportdienst-Anbieter eine spezifische Kopplung mit einem bestimmten ERP-Anbieter anbieten muss.
Noch kein festes Datum, aber ein klares Arbeitsprogramm
Der genaue Zeitpunkt, zu dem die Verpflichtung zu einem digitalen Produktpass für Reifen in Kraft tritt, steht noch nicht fest. Im Arbeitsprogramm der ESPR für den Zeitraum 2025-2030 wird eine delegierte Handlung für Reifen im Jahr 2027 erwartet; erst mit deren Veröffentlichung wird ein konkreter Stichtag bekannt. Bis dahin gelten für Reifen keine verbindlichen Anforderungen an den Pass selbst und daher auch nicht an die Art und Weise, wie Daten eingereicht oder ausgetauscht werden.
Das heißt nicht, dass es nichts zu tun gibt. Die allgemeinen Anforderungen aus Artikel 10 und Artikel 11 der ESPR sind bereits als Rahmen festgelegt, in den die delegierte Handlung für Reifen weiter ausgearbeitet wird: Maschinenlesbarkeit, offene Standards und Interoperabilität sind keine neue Erfindung, die erst 2027 auftaucht, sondern das Fundament, auf dem die reifenspezifischen Vorschriften aufgebaut werden. Wer jetzt bereits über eine Kopplung nachdenkt, baut daher nicht auf treibsand, auch wenn das endgültige Datum noch fehlt.
Wie dies in der Praxis umgesetzt wird
Der erste Schritt besteht darin, zu überprüfen, welche Daten bereits im ERP- oder Bestandsverwaltungssystem vorhanden sind und später in einem Pass enthalten sein müssen: Artikelnummer, Chargen- oder Losnummer, Produktionsdatum, technische Spezifikationen pro Reifentyp. Viele dieser Daten existieren bereits, sind aber noch nicht strukturiert für einen Pass aufbereitet.
Der zweite Schritt besteht darin, herauszufinden, welches Format die Partei, die den Pass zusammenstellt und hostet, als Eingabe akzeptiert. Da tyrepas.eu den Pass aus Daten des Herstellers oder Importeurs aufbaut, besteht die praktische Frage weniger darin, ob eine Kopplung möglich ist, sondern eher in welcher Form die Dateneingabe am sinnvollsten verläuft: ein regelmäßiger Export aus dem ERP-System, eine strukturierte Datei oder ein anderer Übermittlungsweg.
Der dritte Schritt besteht darin, die umgekehrte Richtung zu bedenken: die Rückmeldung von Passdaten an das eigene System, beispielsweise damit ein Flottenmanager Passinformationen mit einer Fahrzeugregistrierung verknüpfen kann, ohne das Passdokument selbst über den QR-Code suchen zu müssen. Auch dies ist eine Frage der technischen Abstimmung zwischen dem ERP-System und der Plattform, nicht einer gesetzlichen Verpflichtung.
Abschließend ist es wichtig, die Laufzeit zu berücksichtigen: Ein Passdokument wird für einen Zeitraum von zehn Jahren gehostet. Wer eine Verknüpfung einrichtet, tut gut daran, sich auch über Updates während dieses Zeitraums Gedanken zu machen — beispielsweise wenn sich Produktdaten ändern — damit die Verknüpfung nicht nur bei der ersten Datenlieferung funktioniert, sondern auch bei späteren Änderungen.
Die gesetzliche Grundlage: Artikel 10 und 11 ESPR
Die Anforderungen an das digitale Produktpassdokument selbst sind in Artikel 10 der ESPR (Verordnung (EU) 2024/1781) festgelegt, das die allgemeinen Anforderungen für das Passdokument festlegt. Artikel 11 derselben Verordnung befasst sich speziell mit der technischen Ausgestaltung und dem Betrieb des Passdokuments, mit Schwerpunkt auf Interoperabilität und offene Standards, damit Daten maschinenlesbar und austauschbar sind. Beide Artikel beziehen sich auf das Passdokument als Produkt, nicht auf die internen Informationssysteme von Importeuren, Großhändlern oder Flottenmanagern — die Verknüpfung damit ist eine technische Umsetzung, die darüber hinausgeht.
Wer jetzt schon vorausplanen möchte, sollte am besten damit beginnen, die eigenen Produktdaten zu erfassen und Kontakt mit der Partei aufzunehmen, die das Passdokument für Reifen zusammenstellen und hosten wird, um zu besprechen, welche Lieferroute am besten zum bestehenden ERP- oder Lagerverwaltungssystem passt.
Worauf dies basiert
- Verordnung (EU) 2024/1781 (ESPR), Artikel 11 (technisches Design und Funktionsweise des digitalen Produktpasses)
- Verordnung (EU) 2024/1781 (ESPR), Artikel 10 (Anforderungen an den digitalen Produktpass)
Die Verordnung selbst finden Sie auf EUR-Lex. Wir verweisen pro Aussage; Sie müssen uns nicht glauben.
Was Sie konkret tun müssen
Was von Ihnen erwartet wird
Der Produktpass muss Daten aus einem Quellsystem empfangen können
Ein Produktpass wird nicht manuell in ein separates Formular eingegeben — die Daten stammen von irgendwoher: aus einem ERP-System, einem Lagerverwaltungspaket, einem Excel-Export des Herstellers oder einer Kombination davon. Artikel 10 der ESPR (Verordnung (EU) 2024/1781) legt fest, welche Daten im Produktpass stehen müssen und wie diese zugänglich sind, schreibt aber nicht vor, über welches System ein Unternehmen diese Daten übermittelt. Für einen Reifenimporteur oder Großhändler mit 10 bis 100 Mitarbeitern bedeutet dies in der Praxis, dass es eine fest etablierte, wiederholbare Methode geben muss, um Produktdaten aus dem eigenen System in den Produktpass zu übertragen — nicht eine einmalige manuelle Dateneingabe, die beim nächsten Reifenposten aufs Neue erfunden werden muss.
Die Verknüpfung muss zu einem eindeutigen Identifikationscode pro Produkt passen
Artikel 11 der ESPR beschreibt, wie der digitale Produktpass technisch funktionieren muss, einschließlich der Verknüpfung zwischen einem Produkt und seinem Produktpass über einen Identifikationscode. Ein ERP- oder Lagerverwaltungssystem arbeitet üblicherweise mit eigenen Artikelnummern, SKUs oder internen Codes. Für die Verknüpfung mit dem Produktpass muss dieser interne Code mit dem Identifikationscode übereinstimmen, den der Produktpass verwendet, oder in diesen übersetzt werden. Unternehmen, die für jede Reifengröße oder jeden Produktionslos bereits einen klaren, eindeutigen Code in ihrem Lagerverwaltungssystem führen, haben hier einen Vorteil; Unternehmen, die mit Sammelposten oder allgemeinen Modellbezeichnungen arbeiten, stellen oft erst bei der Verknüpfung fest, dass ihre interne Verwaltung nicht granular genug ist. Mehr über diesen grundlegenden Schritt finden Sie in wie gebe ich jedem Produkt einen eindeutigen Identifikationscode?
Änderungen im Quellsystem müssen sich im Produktpass widerspiegeln
Ein Lagerverwaltungssystem ist niemals statisch: Preise ändern sich, Spezifikationen werden aktualisiert, ein Lieferant passt eine Zusammensetzung an. Artikel 10 geht von einem Produktpass aus, der den aktuellen Stand der Dinge widerspiegelt, soweit die Datenkategorie dies erfordert. Für ein Unternehmen bedeutet dies, dass eine Verknüpfung mit dem eigenen System nicht nur bei der ersten Eingabe funktionieren muss, sondern auch bei späteren Änderungen — andernfalls entsteht ein Produktpass, der zum Zeitpunkt der Veröffentlichung korrekt war, aber jetzt nicht mehr.
Die Verknüpfung muss auf die Quelle zurückführbar sein
Ein Produktpass, der Daten anzeigt, ohne dass noch nachzuverfolgen ist, aus welchem System, welchem Export oder welcher Version diese Daten stammen, ist bei einer Kontrolle schwer zu rechtfertigen. Dies ergibt sich nicht aus einem spezifischen Artikel, sondern aus der praktischen Seite von Artikel 10 und 11 zusammen: Daten müssen korrekt sein UND überprüfbar. Für Unternehmen mit einer Verknüpfung zu ihrem ERP bedeutet dies, dass eine Form von Protokollierung oder Versionskontrolle wünschenswert ist — wann wurde welcher Datensatz übertragen und von wem.
Wo es in der Praxis schiefgeht
Ein Großhändler verknüpft das Lagerverwaltungsmodul des ERP-Systems einmalig bei der Einführung mit dem Produktpass, vergisst aber, dass neue Reifengrößen, die später hinzugefügt werden, nicht automatisch berücksichtigt werden — der Produktpass bleibt beim Sortiment des Startdatums stecken.
Ein Importeur verwendet im ERP-System einen Sammelcode für eine ganze Produktlinie ("175/65R14 Sommerreifen, verschiedene Marken"), während der Produktpass pro eindeutigem Identifikationscode funktionieren muss. Die Verknüpfung liefert dann einen Produktpass für Produkte, die eigentlich je ihren eigenen Produktpass benötigen — siehe auch wie verhält sich die Reifengröße zur eindeutigen Identifikationscode?
Ein Wagenparkbetreiber erhält einen Export des Herstellers in einem Format, das nicht zu seinem eigenen Lagerverwaltungssystem passt, und die Daten werden manuell in eine Zwischendatei abgetippt. Bei der nächsten Lieferung wird diese Zwischendatei nicht aktualisiert, wodurch der Produktpass eine ältere Version der Spezifikationen anzeigt, als tatsächlich im Lager vorhanden ist.
Ein Unternehmen verknüpft das ERP-System direkt mit dem Produktpass ohne Zwischenschritt, und ein Fehler in einem Exportfeld (beispielsweise eine verwechselte Spalte mit Reifengrößen) gelangt ungesehen in mehrere Produktpässe, weil niemand die verknüpften Daten nach der Übertragung noch überprüft.
Ein Importeur denkt, dass eine einmalige Kopplung für alle künftigen Varianten eines Modells ausreichend ist, während eigentlich für jede Größe oder Ausführung separate Daten erforderlich sind — die Frage, ob Daten für unterschiedliche Bandgrößen desselben Modells wiederverwendet werden dürfen, wird dann zu spät behandelt, siehe kann ich dieselben Daten für mehrere Bandgrößen desselben Modells verwenden?
Was Sie dokumentieren können
- Eine Übersicht, welches System (ERP, Bestandsverwaltung, Lieferantenportal) die Quelle für welches Datenfeld im Paspoort ist, damit bei einer Frage oder Kontrolle sofort klar ist, woher eine Zahl oder Spezifikation stammt.
- Ein festes Verfahren für die Übertragung von Daten bei neuen Produkten, einschließlich des Zeitpunkts, zu dem der eindeutige Identifikationscode vergeben und gekoppelt wird.
- Eine Absprache darüber, wer verantwortlich ist für die Aktualisierung des Pasports, wenn sich Daten im Quellsystem ändern — und innerhalb welcher Arbeitsweise dies geschieht.
- Ein Kontrollschritt nach jeder Kopplung oder jedem Export, in dem stichprobenartig überprüft wird, ob die Daten im Pasport mit dem Quellsystem übereinstimmen.
- Ein Protokoll oder eine Versionshistorie darüber, was übertragen wurde und wann, damit eine Änderung nachträglich nachverfolgbar ist.
- Dokumentation der technischen Kopplung selbst (welche Exportformate, welche Felder werden zugeordnet, welche Software oder Zwischenschicht wird verwendet), verwendbar als Anlage zu internen Audits.
Für Unternehmen, die noch bestimmen müssen, ob ihre Reifen überhaupt unter diese Verpflichtung fallen, ist das ein logischer vorgelagerter Schritt — siehe gilt das digitale Produktpaspoort für meine Reifen? Wer mehr über die Rolle des Pasports in der gesamten Kette erfahren möchte und wo die Kopplung mit einem eigenen System passt, findet eine allgemeine Erklärung in was ist ein digitales Produktpassport für Reifen?
Dies ist keine Rechtsberatung. Diese Seite bietet allgemeine Informationen über die Verordnung, auf der diese Plattform basiert. Wir kennen Ihre Situation nicht. Im Zweifelsfall über Ihren Fall konsultieren Sie bitte einen Juristen oder die zuständige Aufsichtsbehörde.
Mit KI geschrieben auf der Grundlage der obigen Quellen, von einem Menschen am 2026-08-22 überprüft. Stimmt etwas nicht? Lassen Sie es uns wissen — Korrektionen haben Vorrang.