Notification (Company-Rolle)

Diese Anleitung zeigt Stage für Stage, wie eine Notification aus Sicht der Company-Rolle (Notifizierender) bei DiWaSS angemeldet, mit Behörden korrespondiert und ggf. nach Consent geändert oder storniert wird.

Voraussetzungen:

• Angemeldeter Zugang zu ZEDAL — siehe Erste Schritte.
• Verständnis der DiWaSS-Rollen und des Lebenszyklus.
• App-Token (vom ZEDAL-Support bezogen).

Was diese Anleitung nicht abdeckt:

• Behördliche Aktionen (SetRequestInformation, SetDecision, Signals) — siehe Authority.
• Operativer Movement-Pfad — siehe Movement (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 Notifizierung mit dem SDK.

Stage 1 — CreateNotification

Die Submission ist das initial vom Notifier eingereichte Dokument. Sie listet alle beteiligten Parteien (Notifier, WasteProducer, Carrier, Consignee, RecoveryDisposalFacility), Abfallart und -menge sowie Versand- und Bestimmungsort.

Empfohlener Ablauf: zuerst über EORI-Nummern die DiWaSS-Operator-Kennungen (OperatorInternalId) der Geschäftspartner ermitteln, dann die Submission zusammenbauen, lokal über SaveToZedal ablegen und mit SendToDiwass an die Plattform pushen.

Die Verschachtelung des Dokuments

Bevor Code kommt, ein Blick auf den Aufbau — hier vertut man sich am schnellsten. Die Beteiligten und Sachdaten liegen nicht direkt im Dokument, sondern zwei Ebenen tiefer:

SubmissionDocumentType
└── Base : BaseSubmissionDocumentType      ← frame: TakeBackIndication, IllegalActivityIndication
    └── Submission : SubmissionType        ← all parties and shipment data live here
        ├── Notifier    : WasteOperatorType
        ├── Consignee   : WasteOperatorType
        ├── Carrier[]   : CarrierType
        ├── WasteProducer[] : WasteProducerType
        ├── RecoveryDisposalFacility[] : RecoveryDisposalFacilityType
        ├── ShipmentPeriod, TotalWasteMeasurement, Packaging
        ├── WasteClassification, DisposalRecoveryOperations
        └── ExportState, ImportState, TransitState[]

Die Feldtypen sind Protobuf-Wrapper (StringField, BoolField, Int32Field, DoubleField, TimestampField) und keine .NET-Primitiven. Das SDK bringt Kurzkonstruktoren dafür mit.

→ Umsetzung mit dem .NET SDK

Stage 3 — Reaktion auf Nachforderung

Trifft eine RequestInformation einer Behörde ein (Stage 2 im Lebenszyklus, Akteur: Authority), kann der Notifizierende eine der zwei folgenden Aktionen ausführen:

• ReplyToRequestInformation — die Submission bleibt unverändert, der Notifizierende beantwortet die Nachforderung textuell oder mit Anhängen.
• UpdateSubmission — die Submission wird inhaltlich angepasst (z.B. korrigierte Mengen) und neu eingereicht.

In beiden Fällen wird zuerst der aktuelle Handler-Stand aus ZEDAL geladen.

Decision abwarten

Nach Stage 3 ist die Notification wieder im Status SUBMITTED. Bevor die Decision gefällt werden kann, setzen die Versand-Behörde das Signal ProperlyCarriedOut und die Bestimmungs-Behörde das Signal ProperlyCompleted — diese Vorbedingungs-Signale stellen sicher, dass alle beteiligten Behörden ihre Decision auf gemeinsamem Stand bilden. Sind beide Signale gesetzt, ist die Notifizierung konsent-fähig. Der Statuswert bleibt dabei SUBMITTED — „Signale liegen vor” ist kein eigener Status, sondern wird aus den vorhandenen Signal-Blöcken abgeleitet.

Anschließend treffen die beteiligten Behörden ihre Entscheidung; alle beteiligten CAs (Versand, Bestimmung, Transit) müssen Consent geben, damit die Notifizierung in den Status CONSENT übergeht. Aus Notifizierender-Sicht ist die gesamte Sequenz (Signale + Decisions) ein passiver Wartezustand — siehe Lebenszyklus für die vollständige Stage-Reihenfolge.

Aus Company-Sicht erkennst du den Übergang durch Nachladen: mit LoadFromZedalByNotificationId(notificationId) periodisch nachladen und den Decision-Block prüfen. Einen Push-Kanal gibt es derzeit nicht — siehe Webhooks.

Erst im Status CONSENT darf das Movement angelegt werden — siehe Movement (Company).

Stage 5 — SetRequestForChangeAfterConsent (optional)

Tritt nach erteilten Consents Änderungsbedarf auf (z.B. Anpassung der genehmigten Menge gemäß Art. 7 VO 2024/1157), reicht der Notifizierende einen Änderungsantrag ein.

→ Umsetzung mit dem .NET SDK

Der Antrag muss anschließend von jeder beteiligten Behörde einzeln beantwortet werden (Stage 6 — Authority). Erst nach allen Antworten kennt der Notifizierende den Ausgang. Ablehnung einer einzelnen CA reicht aus, um den Antrag zu kippen.

Stage 8 — SubmitNotificationSignal (optional)

Solange die Notification nicht bereits im Endzustand CANCELLED ist, kann der Notifizierende sie stornieren (Art. 6(2)). Stornierung und andere Notifier-Signale (z.B. Rückzug vor Consent) erfolgen über SubmitNotificationSignal.

→ Umsetzung mit dem .NET SDK

Eine stornierte Notification kann nicht reaktiviert werden — gegebenenfalls ist eine neue Notification anzulegen.

Was als Nächstes

• Movement (Company) — Operative Durchführung der konsentierten Notification
• Lebenszyklus — Zustands-Diagramme und Stage-Reihenfolgen
• Authority — Behördliche Aktionen (Acknowledge, RequestInformation, Decision, Signals)