AI translation

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

Movement (company role)

This guide shows how a consented notification is carried out operationally — from creating the movement document to the facility’s completion report.

Prerequisites:

• Consented notification: all authorities concerned (dispatch, destination, transit) have given consent — the notification is in status CONSENT. Without consent, no movement can be created.
• Logged-in access to ZEDAL — see Getting started.
• Understanding of the DIWASS roles and the lifecycle.

What this guide does not cover:

• Authority stages (SetMovementTakeBack, MovementCancelledSignal) — see Authority.
• The notification path that precedes it — see Notification (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 rules for fields and values are 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 Movement with the SDK.

Actors per stage

In the movement, the executing account changes from stage to stage. Who triggers which stage follows from the operator identities entered in the submission:

Stage	Actor (role)	Note
CreateMovementTemplate	Notifier	Identical to the notifier of the notification
SetCarrierTransport	Carrier	If several carriers are involved, the one responsible in each case
SetConsigneeReception	Consignee
SetFacilityReception	RecoveryDisposalFacility
SetFacilityCompletion	RecoveryDisposalFacility	Per facility; with interim storage + final treatment, a separate call for each

If several roles are performed by the same operator (e.g. the notifier is also the carrier), the calls are still made from the same session — what matters is the slot assignment in the notification, not the number of accounts.

Stage 1 — CreateMovementTemplate

The notifier creates the movement document based on the consented notification. It contains the planned quantities and the planned shipment date; the operational data (actual departure, takeover) are added in the following stages.

Every movement carries a SequenceNumber — the consecutive number of the shipment within the notification. Together with the NotificationId, it forms the MovementId. Unlike the NotificationId, it is not reserved on the server side; the integrator determines it. Use GetNextSequenceNumber(notificationId) for this — otherwise movements created repeatedly on the same notification collide.

→ Implementation with the .NET SDK

Status after a successful push: ANNOUNCED. SaveToZedal() and SendToDiwass() have no return values — for the state, see handler.ZedalDocumentId, handler.LastTransferLogId, handler.DiwassNotificationId.

Two number formats — do not confuse them

The same business sequence appears in two notations:

• ZEDAL transport paper number — <NotificationId>.<sequence>, e.g. DE0126013235i.00002 (max. 5 digits, without MOV suffix). This is how the number appears in the transport paper index; GetNextSequenceNumber builds on it.
• DIWASS MovementId — <NotificationId>.<sequence>MOV, e.g. DE0126005589i.000001MOV. This is the value in handler.DiwassNotificationId.

GetNextSequenceNumber returns the plain integer that you enter in SequenceNumber — not the formatted paper or movement number.

The number of shipments is capped

In block 4, the notification states the intended total number of shipments, and the system does not allow more movement documents than this number. If an authority’s consent contains a lower number as a condition, the lower number applies.

What matters for the implementation: A movement document that has been created but not used counts against the intended number of shipments. Only a properly canceled document is not counted. If you create movements during development or testing and leave them lying around, you use up real shipments of the notification — and only notice when the last real transport is rejected.

Therefore, provide a way in your application to actively cancel a movement that is not needed, instead of simply no longer using it. Legal basis: Implementing Regulation (EU) 2025/1290 Article 17(7) and (8).

Together with the missing reservation path, this means: assigning numbers is a task of your application — DIWASS does not help you with it, but it does keep count.

Stage 2 — SetCarrierTransport

As soon as the physical transport begins, the carrier records the transport data.

→ Implementation with the .NET SDK

Status after push: MOVING. Several carriers in a carrier chain are mapped serially through separate SetCarrierTransport calls — one call per carrier, in the order of the handovers.

Stage 3 — SetConsigneeReception

The consignee confirms receipt of the goods.

→ Implementation with the .NET SDK

Status after push: RECEIVED — the value is set with the first confirmation of receipt, regardless of how many facilities the chain still includes.

Subject to a time limit — and “working day” here means Monday to Friday

The regulation sets a time limit for the confirmation of receipt, counted from the start of transport. Take the specific length from the applicable text of the regulation; it differs between the notification procedure and the procedure under Annex VII.

What matters for the calculation in code: the regulation’s term “working day” means Monday to Friday and does not follow § 193 of the German Civil Code (Bürgerliches Gesetzbuch, BGB), which includes Saturday. If you calculate according to German legal practice, your time limit comes out too short.

Stage 3 is omitted if consignee and facility are identical

If the consignee and the facility are the same operator in the notification, SetConsigneeReception is omitted in accordance with Regulation (EU) 2024/1157 — receipt of the goods is then confirmed directly in stage 4 as acceptance by the facility. The status then goes from MOVING directly to RECEIVED, without a consignee certificate being present.

Stage 4 — SetFacilityReception

The recovery or disposal facility confirms acceptance for treatment. If the consignee and the facility are the same operator, this one call covers the entire post-transit step (stage 3 is omitted — see the note above).

→ Implementation with the .NET SDK

The status remains RECEIVED — it does not distinguish between acceptance by the consignee and by the facility. Which facility acknowledged is stated in the certificate itself.

If several facilities are involved (e.g. interim storage + final treatment), each one performs its own reception — a separate call sequence per facility.

Stage 5 — SetFacilityCompletion

The facility completes the treatment. Stage 5 marks the end of the regular lifecycle.

→ Implementation with the .NET SDK

Status after push: COMPLETED.

Subject to a time limit — and the time limit is not anchored to acceptance

The regulation requires the certificate of completed recovery or disposal within a time limit, but the time limit starts with the completion of the operation, not with the acceptance of the waste; in addition, an outer limit applies from receipt. Take both values from the applicable text of the regulation and do not calculate with a single time limit from acceptance.

Practical consequence for the notifier: the financial guarantee is released only when the competent authority has received the certificate of completed recovery or disposal. A late certificate therefore ties up capital with a third party.

What’s next

• Notification (Company) — How the upstream notification works
• Lifecycle — State diagrams and complete stage overview
• Roles — Who may perform which stage
• Authority — Authority interventions such as take-back orders or cancellation