Skip to content

AI translation

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

Notification (company role)

This guide shows stage by stage how, from the perspective of the company role (notifier), a notification is registered with DIWASS, how you correspond with authorities, and how the notification is changed after consent or canceled if necessary.

Prerequisites:

  • Logged-in access to ZEDAL — see Getting started.
  • An understanding of the DIWASS roles and the lifecycle.
  • App token (obtained from ZEDAL support).

What this guide does not cover:

  • Authority actions (SetRequestInformation, SetDecision, Signals) — see Authority.
  • The operational movement path — see Movement (Company).

This guide shows excerpts per stage

The examples focus on the respective step and leave out fields that contribute nothing to understanding the stage. The complete set of fields and values is described in the field rules and the code lists.

A fully runnable reference project is currently not publicly available. If you need one, ask ZEDAL support.

With the .NET SDK

The code for this guide is shown in Notification with the SDK.

Stage 1 — CreateNotification

The submission is the document initially submitted by the notifier. It lists all parties involved (Notifier, WasteProducer, Carrier, Consignee, RecoveryDisposalFacility), the type and quantity of waste, and the places of dispatch and destination.

Recommended flow: first determine the business partners’ ZEDAL-internal operator IDs via their EORI numbers, then assemble the submission, store it locally via SaveToZedal and push it to the platform with SendToDiwass.

The nesting of the document

Before the code, a look at the structure — this is where mistakes happen most easily. The parties and the shipment data are not directly in the document, but two levels further down:

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[]

The field types are protobuf wrappers (StringField, BoolField, Int32Field, DoubleField, TimestampField), not .NET primitives. The SDK comes with short constructors for them.

→ Implementation with the .NET SDK

Stage 3 — Responding to a request for additional information

When a RequestInformation from an authority arrives (stage 2 in the lifecycle, actor: Authority), the notifier can perform one of the following two actions:

  • ReplyToRequestInformation — the submission remains unchanged; the notifier answers the request for additional information in text or with attachments.
  • UpdateSubmission — the content of the submission is adjusted (e.g. corrected quantities) and resubmitted.

In both cases, the current handler state is loaded from ZEDAL first.

Waiting for the decision

After stage 3, the notification is back in status SUBMITTED. Before the decision can be made, the competent authority of dispatch sets the signal ProperlyCarriedOut and the competent authority of destination sets the signal ProperlyCompleted — these precondition signals ensure that all authorities concerned form their decision on a common basis. Once both signals are set, the notification is ready for consent. The status value remains SUBMITTED — “signals present” is not a status of its own, but is derived from the existing signal blocks.

The authorities concerned then make their decision; all competent authorities concerned (dispatch, destination, transit) must give Consent for the notification to move to status CONSENT. From the notifier’s perspective, the entire sequence (signals + decisions) is a passive waiting state — see Lifecycle for the complete stage order.

From the company perspective, there are two ways to detect the transition:

  • Polling: reload periodically with LoadFromZedalByNotificationId(notificationId) and check the decision block.
  • Webhooks: as soon as events are available in the ZEDAL platform, a webhook can be registered for the status change — see Webhooks.

The movement may only be created in status CONSENT — see Movement (Company).

Stage 5 — SetRequestForChangeAfterConsent (optional)

If changes become necessary after consent has been given (e.g. adjusting the approved quantity under Article 7 of Regulation 2024/1157), the notifier submits a request for change.

→ Implementation with the .NET SDK

The request must then be answered by each authority concerned individually (stage 6 — Authority). Only after all replies does the notifier know the outcome. A rejection by a single CA is enough to defeat the request.

Stage 8 — SubmitNotificationSignal (optional)

As long as the notification is not already in the final state CANCELLED, the notifier can cancel it (Article 6(2)). Cancellation and other notifier signals (e.g. withdrawal before consent) are sent via SubmitNotificationSignal.

→ Implementation with the .NET SDK

A canceled notification cannot be reactivated — if necessary, a new notification has to be created.

What’s next

  • Movement (Company) — operational execution of the consented notification
  • Lifecycle — state diagrams and stage orders
  • Authority — authority actions (Acknowledge, RequestInformation, Decision, Signals)