Was der neue Leitfaden konkret beschreibt
Der am 30. Oktober 2026 veröffentlichte „DPP Registry – API Integration Guide for Economic Operators“, Version 1.0, beschreibt eine asynchrone Verarbeitung. Eine Antwort mit HTTP 202 bestätigt die Annahme und liefert eine Aufgabenkennung. Auch der Verarbeitungsstatus COMPLETED genügt allein nicht: Das fachliche Ergebnis kann SUCCEEDED oder FAILED sein. Für Sammelmeldungen gilt laut Leitfaden ein atomarer Ablauf. Ist ein enthaltenes Element nicht regelkonform, wird aus dieser Meldung kein DPP registriert. Die Dokumentation beschreibt bis zu 100 Elemente derselben Produktklassifikation je Meldung.
Aus einer Statusanzeige eine prüfbare Entscheidung machen
Für die interne Prozessgestaltung empfiehlt sich deshalb eine eigene Abschlussregel. Die technische Integration darf den Eingang einer Antwort dokumentieren. Ob der fachliche Vorgang erfolgreich ist, sollte sie erst nach Auswertung des dafür vorgesehenen Ergebnisses anzeigen. Ein Dashboard könnte beispielsweise „zur Verarbeitung angenommen“, „in Prüfung“, „fachlich fehlgeschlagen“ und „erfolgreich registriert“ unterscheiden. Das ist ein Vorschlag für die interne Darstellung, keine zusätzliche amtliche Statusliste. Entscheidend ist, dass jeder angezeigte Zustand auf einer nachvollziehbaren Rückmeldung beruht und dass unklare oder ausstehende Ergebnisse sichtbar bleiben.
Ein bewusst fehlerhaftes Paket testen
Ein fiktives Testbeispiel hilft bei der Abnahme: Ein Hersteller bereitet eine Sammelmeldung mit zehn Testprodukten derselben Klassifikation vor. Bei einem Produkt wird absichtlich eine unzulässige Angabe verwendet. Das erwartete Verhalten wird vor dem Test schriftlich festgelegt: Der Fehler muss dem betroffenen Produkt zugeordnet werden können, und das interne System darf keines der zehn Produkte allein wegen der angenommenen Anfrage als erfolgreich registriert kennzeichnen. Anschließend wird geprüft, ob Fachbereich und IT denselben Gesamtzustand sehen. Das Beispiel beschreibt keine mediatec-Kundeninstallation und keinen von uns ausgeführten Registertest.
Produktstand, Paket und Rückmeldung zusammenhalten
Für einen solchen Test sollte eine kleine Nachweiskette vorbereitet werden. Sie verbindet die interne Produktkennung, den zur Meldung freigegebenen Datenstand, die Zuordnung zum Meldepaket und die empfangene Aufgabenkennung. Ergänzend wird festgehalten, welche Rückmeldung wann ausgewertet wurde. Dadurch lässt sich später nachvollziehen, ob ein Ergebnis zum ursprünglichen oder bereits zu einem korrigierten Paket gehört. Legen Sie vorab fest, wo diese Zuordnung geführt wird und wer sie einsehen darf. Unkontrollierte Kopien derselben Statusliste in mehreren Teams erschweren die Klärung gerade dann, wenn einzelne Produkte inzwischen weiterbearbeitet wurden.
Korrektur und Wiederholung getrennt behandeln
Der Leitfaden verlangt einen Idempotency-Key. Eine erneute Übertragung derselben logischen Anfrage verwendet denselben Schlüssel; ein korrigierter Inhalt ist dagegen eine neue logische Anfrage mit neuem Schlüssel. Für die Arbeitsorganisation folgt daraus eine hilfreiche Unterscheidung: Wird lediglich eine unklare Übertragung erneut abgefragt beziehungsweise wiederholt, oder hat sich der freigegebene Inhalt geändert? Vereinbaren Sie, wer diese Entscheidung trifft. Eine Korrekturliste sollte den alten Paketstand, den Änderungsgrund, die zuständige Rolle und den neuen Freigabestand miteinander verbinden. So bleibt der vorherige Fehler nachvollziehbar, ohne mit dem Ergebnis der neuen Meldung verwechselt zu werden.
Den Fehler an die richtige Verantwortung geben
Nicht jede Ablehnung ist eine reine IT-Aufgabe. Ein falscher fachlicher Wert gehört zur verantwortlichen Datenquelle; eine nicht erreichbare Bereitstellung oder ein technischer Übertragungsfehler benötigt einen anderen Bearbeitungsweg. Definieren Sie für typische Fehlerklassen einen Empfänger, die zur Klärung benötigten Informationen und einen sichtbaren offenen Status. Ein automatisch angelegtes Ticket kann dabei helfen, ersetzt aber keine fachliche Entscheidung. Auch die Vertretung sollte geklärt sein: Ein Meldepaket darf nicht ohne erkennbaren Verantwortlichen liegen bleiben, nur weil eine einzelne Person gerade nicht verfügbar ist.
Registeranbindung und Datenbereitstellung zusammen prüfen
Das EU-Register ist ein zentraler Index. Die detaillierten Passdaten bleiben nach dem beschriebenen dezentralen Ansatz in der Verantwortung des Wirtschaftsakteurs beziehungsweise seines Dienstleisters. Deshalb gehören zwei Fragen in die Planung: Ist die Registrierung nachweisbar erfolgreich, und sind die vorgesehenen Produktinformationen über den vereinbarten Weg erreichbar? Prüfen Sie beide Aufgaben in ihrem jeweiligen Zuständigkeitsbereich. Aus einem technischen Leitfaden lässt sich keine pauschale neue DPP-Pflicht für alle Produkte ableiten; Geltungsbereich und Termine müssen anhand der jeweils anwendbaren Rechtsakte bestimmt werden.
Mit einem kleinen Abnahmeszenario beginnen
Für das erste Fachgespräch genügt eine überschaubare Skizze: eine Produktgruppe, ein beispielhafter Datenstand, ein bewusst fehlerhaftes Paket und der gewünschte Umgang mit der Rückmeldung. Bringen Sie die offenen Entscheidungen mit: Wer gibt die Daten frei, wer prüft das Gesamtergebnis und wer darf eine korrigierte Meldung anstoßen? Verwenden Sie zunächst erfundene oder anonymisierte Beispieldaten. mediatec.net beschreibt DPP als Verbindung von Produkt-, Material- und Compliance-Daten mit kontrollierten Ausgabewegen. Welche Datenmodelle, Integrationen und Prüfungen Ihr konkretes Vorhaben benötigt, klären wir anhand dieses abgegrenzten Ablaufs. Eine bereits produktive EU-Registeranbindung wird damit nicht zugesagt.
Häufige Fragen zu DPP-Sammelmeldungen
Belegt HTTP 202 eine erfolgreiche Registrierung?
Nein. Die Annahme muss von der anschließenden Verarbeitung und deren fachlichem Ergebnis unterschieden werden. Die maßgeblichen Rückmeldungen sind im aktuellen API-Leitfaden dokumentiert.
Was sollte ein Abnahmetest zeigen?
Er sollte sichtbar machen, wie eine fehlerhafte Sammelmeldung erkannt, dem richtigen Datenstand zugeordnet und nach einer kontrollierten Korrektur erneut bearbeitet wird. Technischer Status und fachliche Freigabe brauchen jeweils einen nachvollziehbaren Nachweis.
Kann ich das mit echten Produktdaten ausprobieren?
Beginnen Sie mit einem abgestimmten Testumfang und geeigneten Beispieldaten. Zugänge, Verantwortlichkeiten, Datenübermittlung und eine gegebenenfalls verwendete Testumgebung werden gesondert eingerichtet und freigegeben.
Fachliche Einordnung zum Dokumentationsstand 2. November 2026. Die beschriebenen Arbeitsschritte sind Vorschläge für die Projektvorbereitung; maßgeblich bleiben aktuelle technische Spezifikationen und anwendbare Rechtsakte.