EUDR-ERP-Integration: Datenhoheit, Idempotenz und Nachweise

„EUDR im ERP“ ist zuerst eine Frage der Daten- und Verantwortungsgrenzen. Ein ERP kann Produkte, Aufträge und Chargen führen, ein PLM technische Spezifikationen und ein Lieferantenportal Erklärungen oder Geodateien. Der EUDR-Prozess muss diese Eingaben verbinden, ohne stillschweigend festzulegen, welches System für jedes Feld maßgeblich ist.

Dieser Beitrag beschreibt ein belastbares Integrationsmuster. Eine Integration allein macht ein Unternehmen nicht konform; Umfang, Nachweise und Due-Diligence-Entscheidungen bleiben in der Verantwortung des Betreibers. Für den regulatorischen Ausgangspunkt eignet sich die EUDR-Seite der Europäischen Kommission.

Erst die Datenhoheit festlegen

Vor dem Mapping sollte eine Eigentümertabelle stehen. Das ERP kann für SKU und Sendungsnummer zuständig bleiben, ein Lieferantensystem für Kontaktdaten, ein Geoprozess für akzeptierte Geometrien und der Nachweisdatensatz für Herkunft, Prüfung und Entscheidungsstand. Die Compliance-Schicht referenziert diese Quellen, statt sie unbemerkt zu überschreiben.

So wird sichtbar, ob eine Änderung fachlich harmlos oder prüfungsrelevant ist. Eine neue Produktbezeichnung ist etwas anderes als eine geänderte Warengruppe oder eine neue Zuordnung zu einem Erzeugungsgebiet.

Idempotenz verhindert doppelte Arbeit

Jede Nachricht braucht einen stabilen Schlüssel aus Quellsystem, Quellobjekt und Revision. Der Empfänger speichert Schlüssel und Payload-Hash und entscheidet deterministisch zwischen Anlegen, Aktualisieren oder „bereits verarbeitet“. Ein Timeout und anschließender Retry dürfen keine zweite Charge, kein doppeltes Gebiet und keine zweite Nachweisanforderung erzeugen.

Idempotenz bedeutet nicht „der letzte Schreibvorgang gewinnt“. Wenn zwei Quellen dasselbe Feld beanspruchen, sollte der Konflikt mit einer nachvollziehbaren Begründung in eine Klärung gehen. Ein wiedereinspielbares Importprotokoll zeigt, was wann eingegangen ist und warum eine Projektion geändert wurde.

Beziehungen an der Grenze prüfen

Die Prüfung darf nicht bei der JSON-Struktur enden. Eine Charge muss ein bekanntes Produkt und einen Lieferanten referenzieren. Eine Geometrie muss das erwartete Format haben. Ein Dokument muss zeigen, welche Entität und welchen Zeitraum es stützt. Eine Sendung darf nicht automatisch Nachweise einer anderen Charge erben.

Für große Importe gehören Checkpoints, begrenzte Batches, Zeitüberschreitungen und Backoff dazu. Akzeptierte Datensätze müssen nachvollziehbar bleiben, während abgelehnte Datensätze mit einem Korrekturhinweis zurückgegeben werden.

Die Compliance-Projektion versionieren

Die Projektion sollte Verbindungen zwischen Produkt oder Charge, Lieferant, Ursprung, Gebiet, Nachweis, Prüfung und Erklärungsvorbereitung zeigen. Sie bewahrt Quell-IDs und Revisionen, macht aus einer operativen Zeile aber keinen unveränderlichen Nachweis. Nach einer Prüfung sollte feststehen, welche Eingaben und welcher Entscheidungsstand verwendet wurden. Eine spätere Quellenänderung muss einen neuen Prüfpfad auslösen oder die alte Projektion nach einer dokumentierten Regel als veraltet markieren.

Der EUDR-Überblick ordnet diese Architektur in den größeren Nachweiskontext ein. Die zentrale Frage lautet: Kann ein Prüfer den Status bis zu den Quellen und Nachweisen zurückverfolgen?

Checkliste

• Verantwortliche Quellen für Produkt, Lieferant, Charge, Gebiet, Dokument und Prüfung benennen.
• Idempotenzschlüssel, Revisionen und Konfliktbehandlung vor dem Import definieren.
• Quell-IDs, Zeitstempel und Hashes für Wiederholung und Analyse bewahren.
• Unvollständige Beziehungen zurückweisen oder isolieren.
• Veraltete Projektionen nach wesentlichen Änderungen sichtbar machen.
• Retry-, Duplikat-, Reihenfolge- und Teilausfallfälle testen.

Eine belastbare Integration macht Datenhoheit und Änderungen sichtbar.