Skip to content

AI translation

This page was translated from German with AI. If in doubt, the German original applies.

Roles

DIWASS models the transboundary shipment of waste through a fixed set of roles, defined by Regulation (EU) 2024/1157 and technically specified by Implementing Regulation (EU) 2025/1290. The ZEDAL API and the SDK mirror these roles.

If you come from the national waste record procedure under the Nachweisverordnung (NachwV), the German ordinance on waste records, read the terms carefully: the mapping is not one-to-one, and the obvious translation is usually wrong.

With the .NET SDK

The code for this guide is shown in Roles and permissions in the SDK.

Overview

Role EU term German designation Slot in SubmissionType Acts in
Notifier Notifier Notifizierender Notifier (WasteOperatorType) notification, creating the movement
WasteProducer Waste Producer Abfallerzeuger WasteProducer (WasteProducerType, repeatable) data slot only, no operations of its own
Carrier Carrier Beförderer Carrier (CarrierType, repeatable) movement (taking charge of the transport)
Consignee Consignee Empfänger Consignee (WasteOperatorType) movement (receipt of the waste)
RecoveryDisposalFacility Recovery / Disposal Facility Verwertungs-/Entsorgungsanlage RecoveryDisposalFacility (RecoveryDisposalFacilityType, repeatable) movement (acceptance, completion), Article 15 certificate
Authority Competent Authority (CA) Zuständige Behörde no slot acknowledgment of receipt, request for additional information, signals, decision, take-back

The enum values are available in the SDK as Zedal.Sdk.Apis.Diwass.Permissions.Role. All parties except the authority are operators in the sense of the DIWASS directory; the authority is not.

Cardinalities: what the schema says and what the server requires

Role cardinalities are the most common source of errors on the first submission — because the schema lets through far more than DIWASS accepts.

Role XSD cardinality Server rule Error code on violation
Notifier minOccurs=0, maxOccurs=1 mandatory NOTIFIER-OPERATOR-IS-REQUIRED
Consignee minOccurs=0, maxOccurs=1 mandatory CONSIGNEE-OPERATOR-IS-REQUIRED
Carrier minOccurs=0, maxOccurs=unbounded at least one CARRIER-OPERATOR-IS-REQUIRED
WasteProducer minOccurs=0, maxOccurs=unbounded at least one WASTE-PRODUCER-OPERATOR-IS-REQUIRED
RecoveryDisposalFacility minOccurs=1, maxOccurs=unbounded already mandatory in the schema schema violation

“Optional” only means “schema-optional” here

Four of the five party slots are minOccurs=0 in the XSD. A document without a notifier is therefore schema-valid — and is still rejected by DIWASS. If you build your pre-validation against the schema, you are checking the wrong layer.

The same pattern runs through the entire data model: PartyType.Contact is also schema-optional for each party and mandatory per role on the server side (NOTIFIER-CONTACT-IS-REQUIRED, CARRIER-CONTACT-IS-REQUIRED, …). The complete list of mandatory fields beyond the schema is in the field rules.

There is nothing to count for the authority: it is not a party slot. How many authorities are attached to a case follows from the countries concerned — see Competent authority.

The roles in detail

Notifier (Notifier)

The central actor: creates the notification, signs it, corresponds with the authorities and, once consent has been given, creates the movements.
Per case one. The slot is optional in the schema, mandatory on the server side and not repeatable
Type WasteOperatorType — PartyUuid and OperatorInternalId are both mandatory
After submission the notifier, the countries concerned and the authorities concerned can no longer be changed

Operations on NotificationDocumentHandler and MovementDocumentHandler:

Method Purpose
CreateSubmission Create the notification
SetSubmission Update the notification — only permitted while a request for additional information is open
SetReplyToRequestInformation Reply to a request for additional information
SetRequestForChangeAfterConsent Request a change after consent has been given
CreateMovementTemplate / SetMovementTemplate Create / update a movement
SubmitNotificationSignal Cancellation or withdrawal of the notification
SubmitMovementSignal Cancellation of a movement (MovementCancelled)
GetNextSequenceNumber Determine the next free sequence number for a movement

SetReplyToRequestInformation takes a RequestInformationDocumentType

The reply to a request for additional information is transported in the same type as the request itself — there is no separate reply type. This matches the retrieval behavior: request and reply both appear in the requestInformation list; replyRequestInformation stays empty. Details under Determining the state.

The notifier is not necessarily the waste producer — see the next role.

Waste producer (WasteProducer)

The party where the waste physically arises. DIWASS keeps it as a separate, repeatable slot; it is often the same legal entity as the notifier.
Per case at least one, any number
Type WasteProducerType — extends WasteOperatorType by two mandatory fields: SiteDescription (where the waste arises) and ProcessDescription (from which process)
Own operations none. The allow list of the permission matrix is empty for this role
Access in the movement read-only

Notifier ≠ waste producer, even for the same company

Both are technically separate slots, and both must be filled — even if they point to the same OperatorInternalId. The same ID multiple times in the same role, on the other hand, is rejected (WASTE-PRODUCER-OPERATOR-DUPLICATE).

The shipment origin address is not on the producer but in Submission.ShipmentOriginAddress. The field is a choice between PartyUuid (reference to a party already entered) and AddressDetails (unstructured address) — both branches are optional in the schema, so an empty structure is schema-valid and is rejected on the server side with SHIPMENT-ORIGIN-ADDRESS-REQUIRED. In the movement, you are better off omitting the same field; the reason is in the field rules.

Carrier (Carrier)
Per case at least one, any number
Type CarrierType — extends WasteOperatorType by the mandatory field MeansOfTransportCode (A air, R road, S sea, T rail, W inland waterway), see code lists
Operation SetCarrierTransport on the MovementDocumentHandler

In practice, the notification lists several carriers as a list of possible carriers. This list authorizes the named operators; who actually carries out the transport only becomes clear from the calls on the movement.

Authorized does not mean involved

A carrier in the notification is authorized, but not necessarily deployed. If the waste changes carrier en route, further SetCarrierTransport calls come from the operators responsible at each point. The movement’s status change to “in transit” depends on the first of these calls — details in the movement guide.

Consignee (Consignee)
Per case one. Schema-optional, mandatory on the server side, not repeatable
Type WasteOperatorType
Operation SetConsigneeReception (confirmation of receipt with date and quantity balance)

Consignee and facility can be the same entity — and often are. If they are identical, the consignee confirmation is omitted and acceptance is confirmed at the facility in a single call. If the consignee is, for example, a collector who passes the waste on, there are two different operator IDs and two separate confirmations.

In retrieval, consigneeReception has exactly one entry, while facilityReception and facilityCompletion are repeatable without limit. The reason is the facility chain.

Recovery or disposal facility (RecoveryDisposalFacility)
Per case at least one, any number — the only role that is already mandatory in the schema
Type RecoveryDisposalFacilityType → FacilityType → WasteOperatorType, plus FacilityTypeCode (R recovery, D disposal)
Operations SetFacilityReception (acceptance), SetFacilityCompletion (completion with R/D code), SetFacilityCompletionUnderArticle15 (certificate from the subsequent facility)

Every facility carries FacilityType.OperationalIndicators with three mandatory booleans: InterimFacility, NextSubsequentInterimOrNonInterimFacilityInSameCountry and NextSubsequentInterimOrNonInterimFacilityInAnotherCountry. They determine whether the chain continues within the existing documentation or a new notification procedure begins. The consequences in detail: Field rules → Facility chain.

Interim storage is not a role but an indicator

InterimFacility is a boolean on the facility, not a separate role slot. SiteDescription is also mandatory on FacilityType.

SetFacilityCompletionUnderArticle15 is not on the movement but on the NotificationDocumentHandler: the Article 15 certificate is attached to the notification and references several shipments via MovementIdentifier, because a subsequent facility processes material from several transports.

Competent authority (Authority)

Authorities behave differently from all other roles: they are not an operator party. They have no OperatorInternalId, do not appear in any party slot and therefore cannot be derived from a document.

They are identified on three levels:

Level Field Values
Role in the procedure UserCompetentAuthorityDomainId on the respective authority document WSRDISP (dispatch), WSRTRAN (transit), WSRDEST (destination)
Organization CompetentAuthorityType with PartyUuid and CompetentAuthorityId authority code, e.g. DE014
Involvement in the case CompetentAuthority in ExportState, ImportState and in each TransitState one authority per country concerned

The third row answers the question “who is involved”: the authority is attached to the country, not to the list of parties. That is why the number of authorities grows with every country of transit.

Operations on AuthorityNotificationDocumentHandler / AuthorityMovementDocumentHandler: SubmitAcknowledgement, SetRequestInformation, SetDecision, ReplyToRequestForChangeAfterConsent, SubmitNotificationSignal, SetMovementTakeBack, SubmitMovementSignal. What each of them requires and does is described on the authority side page.

Each authority concerned decides individually

A case involves at least the competent authorities of dispatch and of destination, plus one more for each country of transit. Each of them issues its decision separately; the notification only counts as consented once all of them have consented.

The reverse does not hold, however: for competent authorities of transit, consent can be given tacitly. If you base “consented” on having seen a consent from every authority, you block permissible shipments. See Authority side.

Operator as an identity concept

Cutting across all roles is the operator: an economic actor that takes on one or more of the roles above. Operator is not a role but the representation of an identity.

Every party in the document is a WasteOperatorType with two mandatory details: PartyUuid (technical ID) and OperatorInternalId (ID in the DIWASS operator directory, xs:long). A name is not enough — you have to resolve the ID beforehand.

→ Implementation with the .NET SDK

GetOwnDiwassOperatorIds() is the starting point for any user interface that has to decide in which role the logged-in user is acting on someone else’s document — the IDs from this list feed directly into role inference.

The permitted identifier types for the search (eori, vat, ntr, gln), the other search methods and the error patterns related to operator IDs are described in the field rules.

Choreography at a glance

  1. Notifier submits the notification (slots: notifier, waste producer, carrier, consignee, facilities). Via the API, it immediately has the status “submitted” — there is no draft.
  2. Competent authority of dispatch — and initially only this authority — reviews the notification, requests additional information if necessary and sets ProperlyCarriedOut.
  3. Competent authorities of destination and of transit review it, request additional information if necessary and each set ProperlyCompleted.
  4. Each authority concerned decides individually. Only once all have consented — tacit consent included — may the shipment take place.
  5. Notifier creates the movement.
  6. Carrier enters the transport data.
  7. Consignee confirms receipt of the waste — omitted if consignee and facility are identical.
  8. RecoveryDisposalFacility confirms acceptance and completes the treatment.

The complete sequence with all optional paths — request for change after consent, cancellation, invalidation, take-back — is described in the lifecycle.

DIWASS ↔ NachwV: what is different

DIWASS (transboundary, EU-wide) and the national waste record procedure pursue similar goals, but model the parties in structurally different ways. A one-to-one translation is not reliably possible: someone who says “producer” from a NachwV perspective means, depending on the constellation, the DIWASS Notifier, the WasteProducer or both.

No binding mapping

The following points are guidance for readers experienced with the NachwV, not a reliable translation table. Before a concrete integration, each case needs to be checked individually.

  • Notifier: in DIWASS a separate slot with its own operations and a signature requirement. In the NachwV there is no directly comparable active role.
  • Producer: in DIWASS a passive slot, possible multiple times, without operations of its own — but with mandatory details on site and process. In the NachwV an active role that is unique per batch.
  • Consignee and facility: in DIWASS deliberately two separate roles, even if they are often the same entity. In the NachwV the separation is not drawn as sharply.
  • Authority: in DIWASS an active actor with its own operations. In the NachwV mainly a recipient of the data.
  • Broker: in the NachwV a role in its own right; in DIWASS not represented as a separate role.
  • Interim storage: in DIWASS an indicator on the facility; in the NachwV partly separate actors.

The NachwV itself is covered in ZEDAL by other modules and is not part of this section.

What’s next