Movement (Company-Rolle)¶
Diese Anleitung zeigt, wie eine konsentierte Notification operativ durchgeführt wird — vom Anlegen des Movement-Dokuments bis zur Abschlussmeldung der Anlage.
Voraussetzungen:
- Konsentierte Notification: alle beteiligten Behörden (Versand, Bestimmung, Transit) haben Consent erteilt — die Notifizierung steht im Status
CONSENT. Ohne Consent kann kein Movement angelegt werden. - Angemeldeter Zugang zu ZEDAL — siehe Erste Schritte.
- Verständnis der DiWaSS-Rollen und des Lebenszyklus.
Was diese Anleitung nicht abdeckt:
- Behördliche Stages (
SetMovementTakeBack,MovementCancelledSignal) — siehe Authority. - Der Notification-Pfad davor — siehe Notification (Company).
Diese Anleitung zeigt Auszüge pro Stage
Die Beispiele sind auf den jeweiligen Schritt fokussiert und lassen Felder aus, die für das Verständnis der Stage nichts beitragen. Was an Feldern und Werten vollständig gilt, steht in den Feldregeln und den Codelisten.
Lauffähige Beispiele für Notifizierung und Movement: Beispiele.
Mit dem .NET SDK
Den Code zu dieser Anleitung zeigt Movement mit dem SDK.
Akteure pro Stage¶
Im Movement wechselt der ausführende Account je Stage. Wer welche Stage anstößt, ergibt sich aus den in der Submission eingetragenen Operator-Identitäten:
| Stage | Akteur (Rolle) | Hinweis |
|---|---|---|
CreateMovementTemplate |
Notifier | Identisch zum Notifier der Notification |
SetCarrierTransport |
Carrier | Wenn mehrere Carrier beteiligt sind, jeweils der zuständige |
SetConsigneeReception |
Consignee | |
SetFacilityReception |
RecoveryDisposalFacility | |
SetFacilityCompletion |
RecoveryDisposalFacility | Pro Anlage; bei Zwischenlager + Endbehandlung jeweils eigener Aufruf |
Werden mehrere Rollen vom selben Operator wahrgenommen (z.B. Notifier auch Carrier), erfolgen die Aufrufe trotzdem aus derselben Session — entscheidend ist die Slot-Zuordnung in der Notification, nicht die Anzahl der Accounts.
Stage 1 — CreateMovementTemplate¶
Der Notifier legt das Movement-Dokument auf Basis der konsentierten Notification an. Es enthält die geplanten Mengen und den geplanten Versandzeitpunkt; die operativen Daten (tatsächliche Abfahrt, Übernahme) werden in den folgenden Stages ergänzt.
Jedes Movement trägt eine SequenceNumber — die laufende Nummer der Verbringung innerhalb der Notification. Zusammen mit der NotificationId bildet sie die MovementId. Anders als die NotificationId wird sie nicht serverseitig reserviert; der Integrator bestimmt sie selbst. Nutze dafür GetNextMovementSequenceNumber(notificationId) — sonst kollidieren wiederholt angelegte Movements auf derselben Notification.
Status nach erfolgreichem Push: ANNOUNCED. SaveToZedal() und SendToDiwass() haben keine Rückgabewerte — Zustand siehe handler.ZedalDocumentId, handler.LastTransferLogId, handler.DiwassNotificationId.
Zwei Nummern-Formate — nicht verwechseln
Dieselbe fachliche Sequenz erscheint in zwei Schreibweisen:
- ZEDAL-Transportpapiernummer —
<NotificationId>.<Sequenz>, z.B.DE0126999901i.00002(max. 5-stellig, ohneMOV-Suffix). So steht die Nummer in der Liste der Transportdokumente (QueryApi); darauf setztGetNextMovementSequenceNumberauf. - DiWaSS-MovementId —
<NotificationId>.<Sequenz>MOV, z.B.DE0126999901i.000001MOV. Das ist der Wert inhandler.DiwassNotificationId.
GetNextMovementSequenceNumber liefert den reinen Integer, den du in SequenceNumber einträgst — nicht die formatierte Papier- oder Movement-Nummer.
Die Zahl der Verbringungen ist kontingentiert
Die Notifizierung nennt in Block 4 die beabsichtigte Gesamtzahl der Verbringungen, und mehr Begleitformulare als diese Zahl lässt das System nicht zu. Enthält eine behördliche Zustimmung als Auflage eine niedrigere Zahl, gilt die niedrigere.
Entscheidend für die Implementierung: Ein angelegtes, aber nicht genutztes Begleitformular verbraucht ein Kontingent. Nur ein ordnungsgemäß annulliertes Formular wird nicht angerechnet. Wer beim Entwickeln oder Testen Movements anlegt und liegen lässt, verbraucht damit reale Verbringungen der Notifizierung — und merkt es erst, wenn der letzte echte Transport abgewiesen wird.
Sieh in deiner Anwendung deshalb einen Weg vor, ein nicht benötigtes Movement aktiv zu annullieren, statt es einfach nicht weiterzuverwenden. Rechtsgrundlage: DVO (EU) 2025/1290 Art. 17 Abs. 7 und 8.
Zusammen mit dem fehlenden Reservierungsweg heißt das: Die Nummernvergabe ist eine Aufgabe deiner Anwendung — DiWaSS hilft dir dabei nicht, aber es zählt mit.
Stage 2 — SetCarrierTransport¶
Sobald der physische Transport beginnt, erfasst der Beförderer die Transport-Daten.
Status nach Push: MOVING. Mehrere Beförderer in einer Beförderungskette werden serialisiert über getrennte SetCarrierTransport-Aufrufe abgebildet — je Beförderer ein Aufruf, in der Reihenfolge der Übergaben.
Stage 3 — SetConsigneeReception¶
Der Empfänger bestätigt den Wareneingang.
Status nach Push: RECEIVED — der Wert wird beim ersten Empfangszertifikat gesetzt, unabhängig davon, wie viele Anlagen die Kette noch führt.
Fristgebunden — und „Werktag” heißt hier Montag bis Freitag
Die Verordnung setzt für die Eingangsbestätigung eine Frist ab dem Transportbeginn. Die konkrete Länge entnimm dem geltenden Verordnungstext; sie unterscheidet sich zwischen dem Notifizierungsverfahren und dem Verfahren nach Anhang VII.
Für die Berechnung im Code ist entscheidend: Der Verordnungsbegriff „Werktag” bedeutet Montag bis Freitag und folgt nicht § 193 BGB, der den Samstag einschließt. Wer nach deutschem Rechtsverständnis rechnet, rechnet zu kurz.
Stage 3 entfällt, wenn Consignee und Facility identisch sind
Sind Empfänger und Anlage in der Notification derselbe Operator, entfällt SetConsigneeReception gemäß VO 2024/1157 — der Wareneingang wird dann unmittelbar in Stage 4 als Anlagen-Annahme bestätigt. Der Status geht dann von MOVING direkt auf RECEIVED, ohne dass ein Consignee-Zertifikat vorliegt.
Stage 4 — SetFacilityReception¶
Die Verwertungs- oder Entsorgungsanlage bestätigt die Annahme zur Behandlung. Sind Empfänger und Anlage derselbe Operator, deckt dieser eine Aufruf den gesamten nach-Transit-Schritt ab (Stage 3 entfällt — siehe Hinweis oben).
Der Status bleibt RECEIVED — er unterscheidet nicht zwischen Empfänger- und Anlagen-Annahme. Welche Anlage quittiert hat, steht im Zertifikat selbst.
Sind mehrere Anlagen beteiligt (z.B. Zwischenlager + Endbehandlung), führt jede ihre eigene Reception aus — pro Anlage ein eigener Aufruf-Strang.
Stage 5 — SetFacilityCompletion¶
Die Anlage schließt die Behandlung ab. Stage 5 markiert das Ende des regulären Lebenszyklus.
Status nach Push: COMPLETED.
Fristgebunden — und der Fristanker ist nicht die Annahme
Die Verordnung verlangt die Abschlussbescheinigung fristgebunden, aber der Fristbeginn hängt am Abschluss des Verfahrens, nicht an der Annahme der Abfälle; zusätzlich gilt eine äußere Grenze ab der Entgegennahme. Entnimm beide Werte dem geltenden Verordnungstext und rechne nicht mit einer einzigen Frist ab Annahme.
Praktische Folge für den Notifizierenden: Die Sicherheitsleistung wird erst freigegeben, wenn die zuständige Behörde die Abschlussbescheinigung erhalten hat. Eine verspätete Bescheinigung bindet also Kapital bei einem Dritten.
Was als Nächstes¶
- Notification (Company) — Wie die vorgelagerte Anmeldung funktioniert
- Lebenszyklus — State-Diagramme und vollständige Stage-Übersicht
- Rollen — Wer welche Stage ausführen darf
- Authority — Behördliche Eingriffe wie Rücknahme-Anordnung oder Stornierung