Rollen¶

DiWaSS modelliert die grenzüberschreitende Abfallverbringung über eine feste Menge von Rollen, definiert durch die Verordnung (EU) 2024/1157 und technisch ausgeformt durch die Durchführungsverordnung (EU) 2025/1290. Die ZEDAL-API und das SDK bilden diese Rollen nach.

Wer aus der Welt des nationalen Nachweisverfahrens (NachwV) kommt, sollte die Begriffe sorgfältig lesen: Die Zuordnung ist nicht deckungsgleich, und die naheliegende Übersetzung ist meist falsch.

Mit dem .NET SDK

Den Code zu dieser Anleitung zeigt Rollen und Berechtigungen im SDK.

Übersicht¶

`Role`	EU-Begriff	Deutsche Bezeichnung	Slot in `SubmissionType`	Handelt in
`Notifier`	Notifier	Notifizierender	`Notifier` (`WasteOperatorType`)	Notifizierung, Anlegen des Movements
`WasteProducer`	Waste Producer	Abfallerzeuger	`WasteProducer` (`WasteProducerType`, wiederholbar)	nur Datenslot, keine eigenen Vorgänge
`Carrier`	Carrier	Beförderer	`Carrier` (`CarrierType`, wiederholbar)	Movement (Transportübernahme)
`Consignee`	Consignee	Empfänger	`Consignee` (`WasteOperatorType`)	Movement (Wareneingang)
`RecoveryDisposalFacility`	Recovery / Disposal Facility	Verwertungs-/Entsorgungsanlage	`RecoveryDisposalFacility` (`RecoveryDisposalFacilityType`, wiederholbar)	Movement (Annahme, Abschluss), Artikel-15-Bescheinigung
`Authority`	Competent Authority (CA)	Zuständige Behörde	kein Slot	Eingangsbestätigung, Nachforderung, Signale, Entscheidung, Rücknahme

Die Enum-Werte stehen im SDK als Zedal.Sdk.Apis.Diwass.Permissions.Role. Alle Beteiligten außer der Behörde sind Operatoren im Sinne des DiWaSS-Verzeichnisses; die Behörde ist es nicht.

Kardinalitäten: was das Schema sagt und was der Server verlangt¶

Die Rollen-Kardinalitäten sind die häufigste Fehlerquelle beim ersten Einreichen — weil das Schema deutlich mehr durchlässt als DiWaSS akzeptiert.

Rolle	XSD-Kardinalität	Serverregel	Fehlercode bei Verstoß
`Notifier`	`minOccurs=0`, `maxOccurs=1`	Pflicht	`NOTIFIER-OPERATOR-IS-REQUIRED`
`Consignee`	`minOccurs=0`, `maxOccurs=1`	Pflicht	`CONSIGNEE-OPERATOR-IS-REQUIRED`
`Carrier`	`minOccurs=0`, `maxOccurs=unbounded`	mindestens einer	`CARRIER-OPERATOR-IS-REQUIRED`
`WasteProducer`	`minOccurs=0`, `maxOccurs=unbounded`	mindestens einer	`WASTE-PRODUCER-OPERATOR-IS-REQUIRED`
`RecoveryDisposalFacility`	`minOccurs=1`, `maxOccurs=unbounded`	schon im Schema Pflicht	Schema-Verstoß

„Optional” heißt hier nur „schema-optional”

Vier der fünf Beteiligten-Slots sind im XSD minOccurs=0. Ein Dokument ohne Notifizierenden ist also schema-valide — und wird von DiWaSS trotzdem abgelehnt. Wer seine Vorprüfung gegen das Schema baut, prüft die falsche Ebene.

Dasselbe Muster zieht sich durch das ganze Datenmodell: Auch PartyType.Contact ist je Beteiligtem schema-optional und serverseitig rollenweise Pflicht (NOTIFIER-CONTACT-IS-REQUIRED, CARRIER-CONTACT-IS-REQUIRED, …). Die vollständige Liste der Pflichtfelder jenseits des Schemas steht in den Feldregeln.

Bei der Behörde gibt es nichts zu zählen: Sie ist kein Beteiligten-Slot. Wie viele Behörden am Vorgang hängen, ergibt sich aus den betroffenen Ländern — siehe Zuständige Behörde.

Die Rollen im Detail¶

Notifizierender (`Notifier`)¶

Der zentrale Akteur: erstellt die Notifizierung, signiert sie, korrespondiert mit den Behörden und legt nach erteilter Zustimmung die Movements an.


Pro Vorgang	einer. Der Slot ist im Schema optional, serverseitig Pflicht und nicht wiederholbar
Typ	`WasteOperatorType` — `PartyUuid` und `OperatorInternalId` sind beide Pflicht
Nach dem Einreichen	Notifizierender, beteiligte Länder und beteiligte Behörden sind nicht mehr änderbar

Vorgänge auf NotificationDocumentHandler und MovementDocumentHandler:

Methode	Zweck
`CreateSubmission`	Notifizierung anlegen
`SetSubmission`	Notifizierung aktualisieren — nur bei offener Nachforderung zulässig
`SetReplyToRequestInformation`	Nachforderung beantworten
`SetRequestForChangeAfterConsent`	Änderung nach erteilter Zustimmung beantragen
`CreateMovementTemplate` / `SetMovementTemplate`	Movement anlegen / aktualisieren
`SubmitNotificationSignal`	Stornierung oder Rückzug der Notifizierung
`SubmitMovementSignal`	Stornierung eines Movements (`MovementCancelled`)

Die nächste freie Sequenznummer für ein Movement liefert client.DocumentNumbers.GetNextMovementSequenceNumber.

SetReplyToRequestInformation nimmt einen RequestInformationDocumentType

Die Antwort auf eine Nachforderung wird im selben Typ transportiert wie die Nachforderung selbst — es gibt keinen eigenen Reply-Typ. Das passt zum Retrieval-Verhalten: Nachforderung und Antwort erscheinen beide in der Liste requestInformation; replyRequestInformation bleibt leer. Details unter Zustand bestimmen.

Der Notifizierende ist nicht zwangsläufig der Abfallerzeuger — siehe nächste Rolle.

Abfallerzeuger (`WasteProducer`)¶

Die Partei, an der der Abfall physisch entsteht. DiWaSS führt sie als eigenen, wiederholbaren Slot; häufig ist es dieselbe juristische Person wie der Notifizierende.


Pro Vorgang	mindestens einer, beliebig viele
Typ	`WasteProducerType` — erweitert `WasteOperatorType` um zwei Pflichtfelder: `SiteDescription` (wo der Abfall entsteht) und `ProcessDescription` (aus welchem Prozess)
Eigene Vorgänge	keine. Die Allow-Liste der Permission-Matrix ist für diese Rolle leer
Zugriff im Movement	nur lesend

Notifizierender ≠ Abfallerzeuger, auch bei identischer Firma

Beide sind technisch getrennte Slots, und beide müssen befüllt sein — auch wenn sie auf dieselbe OperatorInternalId zeigen. Dieselbe Kennung mehrfach in derselben Rolle wird dagegen abgelehnt (WASTE-PRODUCER-OPERATOR-DUPLICATE).

Die Absendeadresse steht nicht am Erzeuger, sondern in Submission.ShipmentOriginAddress. Das Feld ist eine Wahl aus PartyUuid (Verweis auf eine bereits eingetragene Partei) oder AddressDetails (unstrukturierte Adresse) — beide Zweige sind im Schema optional, eine leere Struktur ist deshalb schema-valide und wird serverseitig mit SHIPMENT-ORIGIN-ADDRESS-REQUIRED abgelehnt. Im Movement lässt du dasselbe Feld besser weg; warum, steht in den Feldregeln.

Beförderer (`Carrier`)¶


Pro Vorgang	mindestens einer, beliebig viele
Typ	`CarrierType` — erweitert `WasteOperatorType` um das Pflichtfeld `MeansOfTransportCode` (`A` Luft, `R` Straße, `S` See, `T` Schiene, `W` Binnenschiff), siehe Codelisten
Vorgang	`SetCarrierTransport` auf dem `MovementDocumentHandler`

In der Praxis trägt die Notifizierung mehrere Beförderer als Liste möglicher Transporteure ein. Diese Liste autorisiert die genannten Operatoren; wer den Transport tatsächlich durchführt, ergibt sich erst aus den Aufrufen am Movement.

Autorisiert heißt nicht beteiligt

Ein Beförderer in der Notifizierung ist zugelassen, aber nicht zwingend im Einsatz. Wechselt der Abfall unterwegs den Beförderer, kommen weitere SetCarrierTransport-Aufrufe von den jeweils zuständigen Operatoren. Der Statuswechsel des Movements nach „unterwegs” hängt am ersten dieser Aufrufe — Details im Movement-Guide.

Empfänger (`Consignee`)¶


Pro Vorgang	einer. Schema-optional, serverseitig Pflicht, nicht wiederholbar
Typ	`WasteOperatorType`
Vorgang	`SetConsigneeReception` (Eingangsbestätigung mit Datum und Mengenbilanz)

Empfänger und Anlage können dieselbe Entität sein — häufig sind sie es. Sind sie identisch, entfällt die Empfängerbestätigung und die Annahme wird in einem Aufruf an der Anlage bestätigt. Ist der Empfänger etwa ein Sammler, der weiterreicht, sind es zwei verschiedene Operator-Kennungen und zwei getrennte Bestätigungen.

Im Retrieval steht consigneeReception auf genau einem Eintrag, während facilityReception und facilityCompletion unbegrenzt wiederholbar sind. Der Grund ist die Anlagenkette.

Verwertungs-/Entsorgungsanlage (`RecoveryDisposalFacility`)¶


Pro Vorgang	mindestens eine, beliebig viele — die einzige Rolle, die schon im Schema Pflicht ist
Typ	`RecoveryDisposalFacilityType` → `FacilityType` → `WasteOperatorType`, plus `FacilityTypeCode` (`R` Verwertung, `D` Beseitigung)
Vorgänge	`SetFacilityReception` (Annahme), `SetFacilityCompletion` (Abschluss mit R-/D-Code), `SetFacilityCompletionUnderArticle15` (Bescheinigung der Folgeanlage)

An jeder Anlage hängt FacilityType.OperationalIndicators mit drei Pflicht-Booleans: InterimFacility, NextSubsequentInterimOrNonInterimFacilityInSameCountry und NextSubsequentInterimOrNonInterimFacilityInAnotherCountry. Sie entscheiden, ob die Kette dokumentarisch weiterläuft oder ein neuer Notifizierungsvorgang beginnt. Die Folgen im Detail: Feldregeln → Anlagenkette.

Zwischenlagerung ist keine Rolle, sondern ein Indikator

InterimFacility ist ein Boolean an der Anlage, kein eigener Rollen-Slot. Auch SiteDescription ist an FacilityType Pflicht.

SetFacilityCompletionUnderArticle15 liegt nicht am Movement, sondern am NotificationDocumentHandler: Die Artikel-15-Bescheinigung hängt an der Notifizierung und nennt über MovementIdentifier mehrere Verbringungen, weil eine Folgeanlage Material aus mehreren Transporten verarbeitet.

Zuständige Behörde (`Authority`)¶

Behörden verhalten sich anders als alle anderen Rollen: Sie sind keine Operator-Partei. Sie haben keine OperatorInternalId, stehen in keinem Beteiligten-Slot und lassen sich deshalb nicht aus einem Dokument ableiten.

Identifiziert werden sie auf drei Ebenen:

Ebene	Feld	Werte
Rolle im Verfahren	`UserCompetentAuthorityDomainId` am jeweiligen Behördendokument	`WSRDISP` (Versand), `WSRTRAN` (Durchfuhr), `WSRDEST` (Bestimmung)
Organisation	`CompetentAuthorityType` mit `PartyUuid` und `CompetentAuthorityId`	fachlicher Behördencode, z. B. `DE014`
Beteiligung am Vorgang	`CompetentAuthority` in `ExportState`, `ImportState` und je `TransitState`	pro betroffenem Land eine Behörde

Die dritte Zeile beantwortet die Frage „wer ist beteiligt”: Die Behörde hängt am Land, nicht an der Beteiligtenliste. Deshalb wächst die Zahl der Behörden mit jedem Durchfuhrland.

Vorgänge auf AuthorityNotificationDocumentHandler / AuthorityMovementDocumentHandler: SubmitAcknowledgement, SetRequestInformation, SetDecision, ReplyToRequestForChangeAfterConsent, SubmitNotificationSignal, SetMovementTakeBack, SubmitMovementSignal. Was jeder davon voraussetzt und bewirkt, steht auf der Seite Behördenseite.

Jede beteiligte Behörde entscheidet einzeln

Ein Vorgang berührt mindestens Versand- und Bestimmungsbehörde, bei Durchfuhr je Transitland eine weitere. Jede gibt ihre Entscheidung separat ab; konsentiert ist die Notifizierung erst, wenn alle zugestimmt haben.

Die Umkehrung gilt aber nicht: Für Durchfuhrbehörden kann die Zustimmung stillschweigend eintreten. Wer „konsentiert” daran festmacht, dass er von jeder Behörde eine Zustimmung gesehen hat, blockiert zulässige Verbringungen. Siehe Behördenseite.

Operator als Identitäts-Konzept¶

Quer zu allen Rollen steht der Operator: ein wirtschaftlicher Akteur, der eine oder mehrere der obigen Rollen einnimmt. Operator ist keine Rolle, sondern die Repräsentation der Identität.

Jede Partei im Dokument ist ein WasteOperatorType mit zwei Pflichtangaben: PartyUuid (technische Kennung) und OperatorInternalId (Kennung im DiWaSS-Operator-Verzeichnis, xs:long). Ein Name genügt nicht — die Kennung musst du vorher auflösen.

→ Umsetzung mit dem .NET SDK

GetOwnDiwassOperatorIds() ist der Einstieg für jede Oberfläche, die entscheiden muss, in welcher Rolle der angemeldete Benutzer an einem fremden Dokument steht — die Kennungen aus dieser Liste gehen direkt in die Rollen-Inferenz.

Die zulässigen Identifikator-Typen für die Suche (eori, vat, ntr, gln), die weiteren Suchmethoden und die Fehlerbilder rund um Operator-Kennungen stehen in den Feldregeln.

Choreographie auf einen Blick¶

Notifier reicht die Notifizierung ein (Slots: Notifizierender, Erzeuger, Beförderer, Empfänger, Anlagen). Über die API landet sie sofort im Status „eingereicht” — es gibt keinen Entwurf.
Versandbehörde — und zunächst nur sie — prüft, fordert ggf. nach und setzt ProperlyCarriedOut.
Bestimmungs- und Durchfuhrbehörden prüfen, fordern ggf. nach und setzen je ProperlyCompleted.
Jede beteiligte Behörde entscheidet einzeln. Erst wenn alle zugestimmt haben — stillschweigende Zustimmung eingeschlossen — darf verbracht werden.
Notifier legt das Movement an.
Carrier trägt die Transportdaten ein.
Consignee bestätigt den Wareneingang — entfällt, wenn Empfänger und Anlage identisch sind.
RecoveryDisposalFacility bestätigt die Annahme und schließt die Behandlung ab.

Die vollständige Sequenz mit allen optionalen Pfaden — Änderungsantrag nach Zustimmung, Stornierung, Invalidierung, Rücknahme — steht im Lebenszyklus.

DiWaSS ↔ NachwV: was anders ist¶

DiWaSS (grenzüberschreitend, EU-weit) und das nationale Nachweisverfahren verfolgen ähnliche Ziele, modellieren die Beteiligten aber strukturell unterschiedlich. Eine Übersetzung eins zu eins ist nicht zuverlässig möglich: Wer aus NachwV-Sicht „Erzeuger” sagt, meint je nach Konstellation den DiWaSS-Notifier, den WasteProducer oder beide.

Kein verbindliches Mapping

Die folgenden Punkte sind Orientierung für NachwV-Erfahrene, keine belastbare Übersetzungstabelle. Vor einer konkreten Integration gehört jeder Fall einzeln geprüft.

Notifizierender: in DiWaSS ein eigener Slot mit eigenen Vorgängen und Signaturpflicht. In der NachwV gibt es keine direkt vergleichbare aktive Rolle.
Erzeuger: in DiWaSS ein passiver Slot, mehrfach möglich, ohne eigene Vorgänge — aber mit Pflichtangaben zu Standort und Prozess. In der NachwV eine aktive, je Charge eindeutige Rolle.
Empfänger und Anlage: in DiWaSS bewusst zwei getrennte Rollen, auch wenn es häufig dieselbe Entität ist. In der NachwV ist die Trennung nicht in gleicher Schärfe angelegt.
Behörde: in DiWaSS aktiver Akteur mit eigenen Vorgängen. In der NachwV überwiegend Empfängerin der Daten.
Makler: in der NachwV eigenständige Rolle; in DiWaSS nicht als eigene Rolle abgebildet.
Zwischenlagerung: in DiWaSS ein Indikator an der Anlage; in der NachwV teils eigene Akteure.

Die NachwV selbst ist in ZEDAL über andere Module abgebildet und nicht Teil dieser Sektion.

Was als Nächstes¶

Lebenszyklus — Zustände, Stage-Reihenfolge, Versandverfahren
Notification (Company) und Movement (Company) — Schritt für Schritt mit Code
Behördenseite — was von dort kommt und wann
Feldregeln — Pflichtfelder jenseits des Schemas, Kennungen, Anlagenkette