Jeder DPP-Anbieter sagt „Integration“. Fast keiner meint es ernst.

Die eigentliche Frage, die sich Entscheidungsträger stellen

Wenn ein Compliance-Manager oder IT-Direktor eine DPP-Plattform evaluiert, beginnt das Gespräch normalerweise mit den ESPR-Anforderungen und endet irgendwo in einer Diskussion über API-Protokolle. Das ist die falsche Abstraktionsebene.

Die Frage, auf die es eigentlich ankommt, ist einfacher: Muss Ihr Team Produktdaten zweimal eingeben? Einmal in Ihrem ERP und einmal in der DPP-Plattform?

Wenn die Antwort ja lautet, haben Sie sich einen Compliance-Workflow gekauft, der parallel zu Ihrem Betrieb abläuft — und parallele Systeme divergieren. Eine Materialzusammensetzung, die in SAP aktualisiert, aber nicht im DPP wiedergegeben wird, ist nicht nur eine Unannehmlichkeit. Gemäß ESPR (Verordnung EU 2024/1781) muss das DPP den aktuellen Zustand des Produkts widerspiegeln — nicht den Zustand zum Zeitpunkt der ersten Veröffentlichung. Wenn es nicht mehr aktuell ist, sind Sie nicht mehr richtlinientreu.

Aus diesem Grund ist die Integrationsarchitektur einer DPP-Plattform wichtiger als ihre Schnittstelle.

Was „Integration“ eigentlich bedeutet

Der Markt hat die Angewohnheit, alles als Integration zu bezeichnen. Eine CSV-Vorlage wird als Integration bezeichnet. Ein Middleware-Connector eines Drittanbieters wird als Integration bezeichnet. Ein Webhook, der einmal am Tag ausgelöst wird, wird als Integration bezeichnet.

Es gibt einen Unterschied zwischen einem Plugin und einer Plattformebene.

Fluxy.One hat seine SAP-Verbindung als native Ebene innerhalb der Plattform aufgebaut — kein externer Konnektor, der zwischen zwei Systemen sitzt, keine Middleware-Abhängigkeit mit eigenen Fehlermodi und Lizenzbedingungen. Die SAP Business One-Integration ist heute live: bidirektionale Synchronisation von Produktstammdaten und Chargenaufzeichnungen, ohne manuelle Exportschritte und ohne kundenspezifische ABAP-Entwicklung auf SAP-Seite.

Für Unternehmen, die SAP ECC — die ältere, immer noch weit verbreitete Version — verwenden, wird dieselbe Architektur im zweiten Quartal 2026 eingeführt und über SAP Service Layer betrieben. Auch hier ist keine kundenspezifische Entwicklung auf beiden Seiten erforderlich. Die Plattform nimmt die Komplexität auf; Ihre SAP-Umgebung bleibt unverändert.

Odoo ist live. Der CSV- und SFTP-Import deckt jedes ERP-System ab, das einen Standardexport erstellen kann — das sind die meisten davon und für viele mittelständische Hersteller der primäre Integrationspfad für die ersten ein oder zwei Jahre. Es lohnt sich, sich ernsthaft damit zu befassen: Ein gut strukturierter CSV-Import mit Feldvalidierung und Fehlerberichterstattung ist zuverlässiger als eine schlecht implementierte API-Verbindung, und der Massenimport von Fluxy.One verarbeitet mit beiden bis zu 10.000 Datensätze pro Stapel.

Die Microsoft Dynamics-Integration wird für Juli 2026 bestätigt und ist zeitlich auf die Frist für die Zertifizierung von DPP-Dienstanbietern in der EU abgestimmt.

Was bidirektional in der Praxis eigentlich bedeutet

Nehmen wir eine konkrete Situation. Ein Hersteller aktualisiert eine Materialzusammensetzung in SAP — ein Lieferant hat eine Komponente geändert, die Stückliste wird überarbeitet, der Datensatz wird gespeichert. Bei einer unidirektionalen Integration passiert auf der DPP-Seite nichts. Jemand muss die Änderung bemerken, sich bei der DPP-Plattform anmelden, die betroffenen SKUs finden und sie manuell aktualisieren. In einem Katalog von 300 Modellen ist das ein überschaubares Ärgernis. In einem Katalog von 1.300 ist dies ein Compliance-Risiko — denn die Kluft zwischen dem, was SAP weiß, und dem, was der DPP sagt, vergrößert sich jedes Mal, wenn sich ein Datensatz ändert und niemand ihn bemerkt.

Die bidirektionale Integration schließt diese Lücke strukturell, nicht prozessual. Wenn sich ein Produktdatensatz im ERP ändert, sieht dies die DPP-Plattform. Wenn ein DPP veröffentlicht, validiert, archiviert oder durch eine Konformitätsprüfung gekennzeichnet wird, spiegelt das ERP diesen Status wider. Das Betriebsteam stellt die Wartung von zwei Versionen desselben Produkts ein.

Da Fluxy.One nativ auf GS1-Standards basiert — nicht als Ebene über einem proprietären Datenmodell — werden Statusänderungen mithilfe von EPCIS 2.0, dem GS1-Standard für Lieferkettenereignisdaten, aufgezeichnet. EPCIS 2.0 (Electronic Product Code Information Services) erfasst, was wo, wann und warum mit einem Produkt passiert ist — in einem Format, das andere GS1-konforme Systeme, Zollbehörden und Marktüberwachungsbehörden direkt lesen können. Das bedeutet, dass es sich bei der Ereignisaufzeichnung eines DPP, das veröffentlicht, aktualisiert oder archiviert wird, nicht um ein plattformspezifisches Protokoll handelt. Es handelt sich um einen standardisierten, interoperablen Event-Stream. Für Unternehmen, die auf mehreren Märkten oder Handelspartnern tätig sind, ist diese Unterscheidung wichtig.

Dies ist insbesondere im Rahmen der ESPR von Bedeutung, da die Verordnung vorschreibt, dass das DPP den aktuellen Zustand des Produkts widerspiegelt — nicht den Zustand zum Zeitpunkt der ersten Veröffentlichung. Ein DPP, das im Januar korrekt und im März falsch war, ist im März kein konformes DPP. Die bidirektionale Synchronisation ist keine praktische Funktion. Auf diese Weise halten Sie den Datensatz auf dem neuesten Stand, ohne die Anzahl der Mitarbeiter zu erhöhen.

Eine praktische Grenze, die es wert ist, genannt zu werden: ERP-Systeme speichern Produktstammdaten gut. Sie enthalten die Materialzusammensetzung, Chargenkennungen, Codes von Produktionsanlagen und Variantenstrukturen. Was sie normalerweise nicht enthalten, sind DPP-spezifische Daten — Prozentsätze des recycelten Gehalts in dem von ESPR vorgeschriebenen Format, GLNs (Global Location Numbers) von Lieferanten, wie von GS1 definiert, oder Aufzeichnungen über Lebenszyklusereignisse wie Reparatur und Eigentumsübertragung. Diese Daten müssen separat zur DPP-Ebene hinzugefügt werden, in der Regel beim Onboarding und bei der Erfassung der Lieferantendaten. Die Integration automatisiert, was das ERP bereits weiß. Der Rest ist eine einmalige Bereicherung, keine fortlaufende manuelle Eingabe.

DPP-Daten fließen raus, nicht nur rein

Die meisten Hersteller, die über DPP nachdenken, konzentrieren sich auf das Eingabeproblem — die Aufnahme von Produktdaten in den Reisepass, ohne ihren Betrieb neu aufbauen zu müssen. Das ist der richtige Ort, um anzufangen. Aber das ist nicht das ganze Bild.

ESPR erfordert die Erfassung strukturierter, validierter Daten zu jedem Produkt in Ihrem Katalog: Materialherkunft pro Charge, Lieferantenkennungen, recycelter Inhalt, Aufzeichnungen der Produktionsstätte, Ereignisse im Lebenszyklus. Diese Daten müssen maschinenlesbar und abfragbar sein und mindestens zehn Jahre lang aufbewahrt werden. Es handelt sich um eine Compliance-Verpflichtung.

Es handelt sich auch um einen Datensatz, den die meisten Unternehmen derzeit nicht in dieser Form haben — er ist zentral gespeichert, anhand eines regulatorischen Schemas validiert und mit einzelnen SKUs und Produktionschargen verknüpft.

Ein Hersteller, der diese Infrastruktur ordnungsgemäß aufbaut, hat am Ende etwas Nützliches, das über den QR-Code auf dem Produkt hinausgeht. Materialzusammensetzung im gesamten Katalog an einem Ort. Herkunft der Lieferanten nach Chargen, nicht in einem Beschaffungssystem verdeckt. Ereignisse im Lebenszyklus — Reparaturen, Wiederverkäufe, Eigentumsübertragungen —, die im Laufe der Zeit von autorisierten Akteuren hinzugefügt und als EPCIS 2.0-Ereignisse aufgezeichnet wurden. Beim letzten Punkt lohnt es sich, innezuhalten: Jede Statusänderung im Lebenszyklus des Produkts wird in ein unveränderliches, standardisiertes Ereignisprotokoll geschrieben, das zusammen mit der Produktkennzeichnung übertragen wird, nicht zusammen mit der Plattform. Eine Werkstatt in Polen und ein Recyclingunternehmen in den Niederlanden können beide an dieselbe Kette von Ereignissen anhängen, und zwar in einem Format, das jedes GS1-konforme System lesen kann. So sieht die Rückverfolgbarkeit der Lieferkette aus, wenn sie auf offenen Standards und nicht auf dem proprietären Schema eines Anbieters basiert.

So sieht das heute in der Praxis aus: Fluxy.One bietet Zugriff auf die DPP-Datenschicht über Standard-Google-APIs. Unternehmen, die bereits Looker Studio oder andere Tools im Google-Ökosystem verwenden, können ohne kundenspezifische Entwicklung eine Verbindung herstellen und ihre eigenen Berichte auf der Grundlage der Live-DPP-Daten erstellen. Es handelt sich nicht um ein Analysepaket — es handelt sich um den API-Zugriff auf einen validierten, strukturierten Datensatz, und was Sie damit erstellen, hängt davon ab, welche Fragen Sie stellen.

Vor Ende 2026 wird die Plattform eine dedizierte Analytics-API und eine Entwickler-Sandbox für benutzerdefinierte Integrationen und Tests hinzufügen. Zu diesem Zeitpunkt wird die Datenschicht für Teams außerhalb des Google-Ökosystems richtig programmierbar.

Die Unternehmen, die DPP als Dateninfrastruktur und nicht als Compliance-Checkbox behandeln, sind diejenigen, die von dem Prozess etwas zurückbekommen. Die Verordnung zwingt Sie, die Daten zu sammeln. Was Sie danach damit machen, ist optional — aber die Option ist da.

Fünf Fragen, die jeder DPP-Anbieter zur Integration stellen sollte

1 — Ist die ERP-Verbindung in die Plattform integriert oder hängt sie von einem Drittanbieter-Connector oder einer Middleware ab? Konnektoren von Drittanbietern stellen ihre eigenen Anforderungen an Zuverlässigkeit, Wartung und Lizenzierung.

2 - Ist die Synchronisation bidirektional oder fließen Daten nur in eine Richtung? Einweg-Import bedeutet, dass Ihr ERP nie weiß, was auf der DPP-Seite passiert.

3 — Was passiert, wenn sich ein Produktdatensatz in Ihrem ERP ändert, nachdem das DPP veröffentlicht wurde? Gibt es einen automatisierten Aktualisierungspfad oder muss ihn jemand manuell auslösen?

4 - Ist die Integration im Abonnement enthalten oder handelt es sich um eine separate Implementierungsgebühr? Der Umfang benutzerdefinierter Integrationen erweitert sich häufig.

5 - Können Sie für Ihre eigenen Analysen auf die DPP-Datenschicht zugreifen, oder ist sie in der plattformeigenen Berichtsoberfläche gesperrt?

Die Antworten werden das Feld erheblich einschränken.

Erfahren Sie, wie Fluxy.One sich mit Ihrer bestehenden ERP-Infrastruktur verbindet — und was Sie mit den Daten machen können, sobald sie da sind. Holen Sie sich eine kostenlose Beratung.

Fluxy.One ist eine Plattform für den digitalen Produktpass der EU ESPR für Hersteller, Importeure und Händler, die sich auf die EU-Produktvorschriften vorbereiten. Die Plattform deckt den gesamten DPP-Lebenszyklus ab — von Produktstammdaten und GS1 Digital Link-QR-Codes bis hin zur Überprüfung der Einhaltung gesetzlicher Vorschriften und der Rückverfolgbarkeit der Lieferkette — mit nativen Integrationen für SAP Business One, SAP ECC, Odoo und Microsoft Dynamics sowie einer GS1-nativen EPCIS 2.0-Event-Layer für die standardisierte Aufzeichnung von Ereignissen in der Lieferkette. Unternehmenskunden können bereits heute bestehende BI-Tools über Standard-Google-APIs verbinden. Eine dedizierte Analytics-API und eine Sandbox für Entwickler sind für das vierte Quartal 2026 geplant. Dieser Artikel spiegelt die regulatorische und plattformspezifische Position im Mai 2026 wider. Die ESPR-Durchführungsrechtsakte werden ständig weiterentwickelt; dieser Artikel dient der Orientierung, nicht der Rechtsberatung.