WasteX EU specification v0.02

Federal Ministry of Agriculture and Forestry, Climate and Environmental Protection, Regions and Water Management (BMLUK)

Stubenbastei 5, 1010 Vienna, Austria

• Introduction
  • Specification stability disclaimer
  • Scope and Context - "WasteX EU", "WasteX" and "DIWASS API"
    • Data exchange interfaces and their characteristics
    • Covered data transmissions
    • Naming
  • Notation
  • Domain background
    • Waste shipment business processes
    • Waste shipment handling by the Austrian authority
  • The new EU Waste Shipment Regulation and DIWASS
    • Introduction
    • DIWASS use in Austria - EDM as a Austria's local system
    • Practical implications of EDM as Austria's local system on waste shipment use cases
  • Relationship to the DIWASS API specification and documentation
    • Overview
    • Maintenance and Updates
  • Intended audience
  • Contact
• Architecture overview
  • Type of web service
  • Web service environments and endpoints
  • Technologies and standards stack
• Specification package
  • Description of files and folders in the package
• Technical specification and organizational requirements
  • Party and site identification
    • Overview
    • Referencable parties and sites
    • Matching TRACES.NT operator registrations and IDs with existing party and site data
    • Main identifier for Austrian EOs
  • Transmissions for other parties
    • Overview
    • Supported transmissions
    • Unsupported transmissions
  • Identification, Authentication and Authorization
    • Used Standard - UsernameToken
    • Registration and credentials
    • Authorization
  • Attachments
    • Background: Attachments in the DIWASS API
    • Handling of attachments in WasteX EU
    • Intended route, points of exit and entry
  • Codelists
  • Specific handling of transmitted content
  • Synchronous operations
  • Transport layer security TLS
  • UTF-8 encoding
    • UTF-8 character encoding provisions
    • Testing recommendation
  • XSD validity of operation inputs and outputs
  • Value ranges and precision
    • Upper size limits
    • Other value range restrictions and checks
    • Accuracy and Precision
  • Bulk transmissions
  • Sender and receiver side responsibilities
  • SOAP Faults
    • SOAP version
    • SOAP faults
  • Transmission retries
    • Automatic retries
    • Manual retries
  • Recommended reactions to certain EDI behaviour
  • Service Levels and Operational Characteristics
    • Service level
    • DIWASS API dependency
    • Handling of outages
    • Supported load
• Web service operations
  • Introduction
  • Operations
• Message formats
  • Introduction
  • WasteX EU extension
  • Occurrence information
  • Contents
  • XML structures
    • CreateMovementTemplateRequest
    • MovementTemplateOperationResponse
    • UpdateMovementTemplateRequest
    • MovementOperationResponse
    • CreateConsigneeReceptionRequest
    • UpdateConsigneeReceptionRequest
    • CreateFacilityReceptionRequest
    • UpdateFacilityReceptionRequest
    • CreateFacilityCompletionRequest
    • UpdateFacilityCompletionRequest
    • SubmitMovementSignalRequest
    • SubmitMovementSignalResponse
    • SubmitFacilityCompletionUnderArticle15Request
    • SubmitFacilityCompletionUnderArticle15Response
    • CreateAnnex7DocumentTypeRequest
    • Annex7DocumentTypeResponse
    • UpdateAnnex7DocumentTypeRequest
    • CreateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest
    • Annex7MovementDocumentTypeResponse
    • UpdateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest
    • CreateAnnex7FacilityCertificateOfWasteReceiptTypeRequest
    • UpdateAnnex7FacilityCertificateOfWasteReceiptTypeRequest
    • CreateAnnex7CertificateOfWasteCompletionTypeRequest
    • UpdateAnnex7CertificateOfWasteCompletionTypeRequest
    • CreateAnnex7SignalTypeRequest
• Definitions and References
  • Terms and Definitions
  • Acronyms
  • References
• Specification history of changes
  • History of changes

Introduction

Disclaimer

	WasteX EU v0.02 DRAFT

	Copyright (C) 2026 Environment Agency Austria
	Commissioned by the Austrian Federal Ministry of Environment (BMLUK)

	Contact: edm-helpdesk@umweltbundesamt.at

	Reuses parts of the DIWASS API specification created and published by the European Commission.

	Licensed under the EUPL, Version 1.2 or – as soon they will be approved
	by the European Commission – subsequent versions of the EUPL (the "Licence");

	You may not use this work except in compliance with the Licence.

	You may obtain a copy of the Licence at: http://joinup.ec.europa.eu/software/page/eupl

	Unless required by applicable law or agreed to in writing, work distributed under the licence is distributed
	on an "AS IS" basis, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

	See the Licence for the specific language governing permissions and limitations under the Licence.

Specification stability disclaimer

This specification builds on the European Commission's [DIWASS API] specification. See Relationship to the DIWASS API specification and documentation for details on the interrelationship.

The European Commission published the [DIWASS API] specification by the end of January 2026.

With regard to the stability of this specification, the following applies:

• The Austrian Competent Authority for Shipments of Waste, BMLUK, regards the specification as stable in the sense that it has no plans of changing the specification other than adding the following contents:
  1. Formal validation rules applied to transmitted content (such as verifying that the mass of waste is not negative);
  2. Description of Specific handling of transmitted content for GLW (Annex VII).
• It should be noted that updates to the [DIWASS API] specification by the European Commission will likely require corresponding updates to the WasteX EU specification by the Austrian Competent Authority.

Scope and Context - "WasteX EU", "WasteX" and "DIWASS API"

Data exchange interfaces and their characteristics

WasteX EU is a data exchange interface the Austrian competent authority (CA) for shipments of waste offers for use by Austrian economic operators starting from 2026.

As there are other waste shipment related data exchange interfaces, for the sake of clarity this interface description starts with listing these different interfaces and describing how they are different from each other and in which ways they overlap.

WasteX EU	WasteX	DIWASS API	Characteristic
✔	✔	✗	A data exchange interface provided by the Austrian competent authority (CA) for waste shipments, for use by Austrian economic operators (EO)
✗	✗	✔	A data exchange interface provided by the European Commission, for use by competent authorities (CA) and economic operators (EO)
✗	✔	✗	Offered for data exchanges that fall under the "old"  [EU Waste Shipment Regulation 1013/2006]
✔	✗	✔	Offered for data exchanges that fall under the "new" [EU Waste Shipment Regulation 2024/1157]

Covered data transmissions

	Availability period	Covered data transmissions
WasteX EU	From 2026	Business-to-administration transmissions of movement document contents according to Art. 15 and 16 [EU Waste Shipment Regulation 2024/1157] Business-to-administration transmissions of green listed waste (GLW) consignment information contents according to Art. 18 [EU Waste Shipment Regulation 2024/1157]
WasteX	From 2022 Until at least 2027	Business-to-administration transmissions of movement document contents according to Art. 15 and 16 [EU Waste Shipment Regulation 1013/2006]
DIWASS API	From 2026	[EU Waste Shipment Regulation 2024/1157] related data exchanges (central repository, sharing across stakeholders including competent authorities and economic operators): Notification and consent data exchanges Movement document data exchanges Green listed waste (GLW) consignment information data exchange Operator and site registration related data exchange

Naming

The Austrian CA chose the name WasteX EU for the new [EDM] waste shipments data exchange interface for Austrian EOs for these two reasons:

1. WasteX EU eventually replaces WasteX
   • The WasteX EU interface serves a similar purpose for the [EU Waste Shipment Regulation 2024/1157] as the [WasteX] interface does/did for the [EU Waste Shipment Regulation 1013/2006] (except for supporting green-listed wastes, which is a new feature in WasteX EU)
2. The WasteX EU specification replicates/reuses parts of the DIWASS API to the greatest extent possible
   • In order to keep implementation, testing and maintenance simple, the WasteX EU specification follows the DIWASS API specification to the greatest extent possible

Notation

This specification uses the terms and acronyms defined in Definitions and References, and bases on the technical standards and legal regulations listed therein.

Domain background

Waste shipment business processes

Transboundary movements of waste, also called shipments of waste, carry the risk of adverse effects to human health and the environment.

The Basel Convention [BC] is an international treaty aimed at protecting human health and the environment against such adverse effects by strict control. The EU Waste Shipment Regulation [WSR] has the same goal and contains additional control provisions defined for the EU on top of the [BC] provisions.

Among the core provisions of [BC] and [WSR] are the following business-to-administration (B2A) business processes with information interchanges between economic operators (EOs) and competent authorities (CAs):

Amber shipments - shipments requiring prior written notification and consent

Notification and consent business process

Main steps:

1. EO submits notification to CA, Art. 5 [WSR]
2. (Optional): CA requests additional information from EO, Art. 8 [WSR]
3. CA of DEST, TRANS acknowledges receipt of a properly carried out notification, Art. 8 [WSR]
4. CA of DEST acknowledges receipt of a properly completed notification, Art. 8 [WSR]
5. CA issues consent, consent with conditions or objection, Art. 9 [WSR]

Information business process for each individual amber shipment ("movement document" process), requires a consented notification as prerequisite

Main steps:

1. movement announcement: EO announces the shipment to CAs and other EOs, Art. 16(2) [WSR]
2. (Optional, upon inspection): EO provides consent and individual shipment information to authorities upon inspection and customs controls, Art. 16(3) [WSR]
3. carrier confirmation: carrier confirms taking charge of a shipment of waste, in accordance with Article 16 of the [WSR], as well as Annex IB block 8
4. confirmation of waste receipt: EO confirms the receipt of waste to CAs and other EOs, Art. 16(5) and 15(3) [WSR]
5. confirmation of the completion of waste treatment: EO confirms the completion of treatment of the shipped waste to CAs and other EOs, Art. 16(6) and 15(4) [WSR]
6. confirmation of the completion of all subsequent waste treatment: Art. 15(5) [WSR]

Green shipments - shipments that do not require prior written notification and consent

Information business process for each individual green shipment ("consignment information" process)

Main steps:

1. The arranger prepares information to accompany the shipment of waste, Art. 18(1) [WSR]
2. (Optional, upon inspection): Provision of prepared information to authorities upon request, Art. 18(2) [WSR]
3. The laboratory or recovery facility confirms the receipt of waste, Art. 18(8) [WSR]
4. The laboratory or recovery facility confirms the completion of recovery or disposal of waste, Art. 18(9) [WSR]

Waste shipment handling by the Austrian authority

Austria has a single designated CA for shipments of waste, the Ministry of Environment (BMLUK), department V/1. Since 2006, the Austrian CA has used the e-government solution edm.gv.at [EDM] to manage waste shipment data and processes. [EDM] is an interconnected system of IT applications and databases by the Austrian public administration to support environment-related business processes.

EOs can exchange structured electronic waste shipment information with the Austrian CA via the [EDM] web application, and/or via [EDM] web services.

Since 2006, the Austrian CA handles all waste shipment data as structured electronic data in the [EDM]. Where needed, the CA types in data that it receives by e-mail, fax, or mail. EOs can use structured electronic data exchange with the Austrian CA instead of e-mail, fax or mail, such as via [EDM] web application online forms. The Austrian CA deals with around 1.000 notifications and around 50.000 individual waste shipments per year, with a total of around 4.000 EOs (notifiers, carriers, consignees, waste treatment parties, ...).

With the 2021 Circular Economy amendment to the Austrian Federal Act on sustainable waste management [AWG 2021], by 2022 Austrian EOs became obliged to exchange waste shipment information as structured electronic data with the Austrian CA. Structured electronic data provision was no longer optional for Austrian CAs, and the Austrian CA no longer accepted e-mail, fax or mail for many of the data exchanges with Austrian EOs.

In order to support EOs in fulfilling these obligations, from 2022 onwards the Austrian CA accepted movement document contents according to Art. 15 and 16 [EU Waste Shipment Regulation 1013/2006] not only by submission via the [EDM] web application online form, but in addition offered an alternative way of submitting such data to the CA, namely by electronic data interchange. The [EDM] web service for these business-to-administration data exchanges is known by the name [WasteX]. The WasteX specification is available online.

The new EU Waste Shipment Regulation and DIWASS

Introduction

The "new" WSR [EU Waste Shipment Regulation 2024/1157] replaces (repeals) the "old" WSR [EU Waste Shipment Regulation 1013/2006].

From 21 May 2026, all actors involved in waste shipments, where an EU Member State is concerned, will have the means to comply with the Regulation’s obligation to submit and exchange waste shipment-related information and documents via electronic means.

The European Commission develops and operates the ⭧ central system [Digital Waste Shipment System (DIWASS)] as part of [TRACES.NT] in accordance with [WSR 2024/1157] and its complementary [EU DIWASS Implementing Regulation 2025/1290].

Competent authorities and stakeholders involved in waste shipments can access the ⭧ central system through a Graphical User Interface (GUI), i.e. a website.

[DIWASS] also allows the exchange of information and documents between the ⭧ central system and ⭧ local systems operated by certain competent authorities, as well as corporate ⭧ software or software offered by commercial software providers by interconnection via [DIWASS API].

DIWASS use in Austria - EDM as a Austria's local system

According to the [DIWASS Implementing Regulation] CAs can choose between the following two options:

1. Using a ⭧ local system connected to DIWASS via the [DIWASS API]
2. Using the DIWASS GUI directly

The Austrian CA decided for the first option.

This means:

• The Austrian CA continues using [EDM];
• The Austrian CA connects [EDM] as a ⭧ local system to the ⭧ central system [DIWASS] via the [DIWASS API];
• The Austrian ⭧ local system [EDM] automatically forwards all data submissions and updates to [DIWASS] via the [DIWASS API] in real time;
• The Austrian ⭧ local system [EDM] continously synchronizes all [DIWASS] data submissions and updates relevant to Austrian actors, so that the data available in the ⭧ local system [EDM] at any time reflects the data in the ⭧ central system [DIWASS] with at most insignificant delays.

Practical implications of EDM as Austria's local system on waste shipment use cases

Please refer to the "Abfallverbringung" publication on the BMLUK website for details, including FAQ.

The following is merely a brief overview of the situation for Austrian Economic Operators (EOs):

Use case	AT EDM GUI	AT EDM WasteX EU	DIWASS GUI	DIWASS API	Note
Carrier use cases	✗	✗	✔	✔	For carrier use cases — such as contributing the parts of the Movement Document ([WSR] Annex IB) provided by a carrier's representative — EOs must use [DIWASS], and may choose between the [DIWASS] GUI and the [DIWASS API].
Data submissions and updates other than carrier use cases	✔	partly - see below	✗	✗	For all data submissions and updates except those from carrier use cases, the Austrian EO must use the ⭧ local system [EDM], and cannot use [DIWASS] directly, neither the [DIWASS] GUI nor the API.
transmission of movement document contents (Art. 15 and 16 [WSR]) transmission of green listed waste (GLW) consignment information contents (Art. 18 [WSR])	✔	✔	✗	✗	For movement document and green listed waste consignment information data transmissions, Austrian EOs may choose between the [EDM] GUI and the WasteX EU web service.
transmission of everything else, including Notification Reply to a request for information Registration of third country operators that do not use DIWASS	✔	✗	✗	✗	For all data transmissions that are neither carrier use cases, nor movement document or consignment information, Austrian EOs must use the [EDM] GUI.
GUI read access to waste shipment data	✔	✗	(✔)	✗	Austrian EOs can access all waste shipment data they have access to via the [EDM] GUI. For Austrian EOs, other than those acting as carriers, there is no need to have [TRACES.NT] users. Though if they have such users nevertheless, they have the technical ability to access their waste shipment data also in the [DIWASS] GUI.
Retrieval of machine readable waste shipment data	✗	✗	✗	✔	Unlike [WasteX], WasteX EU does not include data retrieval operations. Machine-readable data can only be accessed via the [DIWASS API].

Relationship to the DIWASS API specification and documentation

Overview

The Austrian CA decided to base the WasteX EU web service as closely as possible on the [DIWASS API] in order to keep implementation, testing and maintenance as simple and efficient as possible.

In practice this means:

• Usage of the same technology stack, such as [SOAP], [WSDL], [XML] and [XSD];
• Vast reuse of [DIWASS API] [XSD] definitions: The WasteX EU web service requires very few [XSD] definitions to be defined on top of the [DIWASS API] [XSD] definitions, most [XSD]s are plainly reused;
• The WasteX EU interface documentation must be used in conjunction with the [DIWASS API] docs.

Maintenance and Updates

The [DIWASS API] is the basis for WasteX EU.

As a result, if the European Commission changes the [DIWASS API], these changes also need to reflect in the WasteX EU interface.

The Austrian CA commits to adopting such changes in WasteX EU, both in the specification and the implementation, and to informing WasteX EU users about such changes as far in advance as possible.

See Specification history of changes for the list of updates so far.

Intended audience

The primary audience of this specification is IT professionals—such as business analysts, developers, and testers—working for software, solution, or service providers that implement or plan to implement an EDI connection to the [EDM] WasteX EU web service interface.

In addition, this description targets waste management domain experts and decision makers at software, solution, or service providers in the field of waste management.

Contact

For any enquiries about this specification and the [EDM] WasteX EU web service get in touch with edm-helpdesk@umweltbundesamt.at.

The [EDM] Helpdesk cannot answer questions related to the [DIWASS API].

Architecture overview

Type of web service

In line with the [DIWASS API], the [EDM] WasteX EU web service is a [SOAP] web service with [XML] web service operation inputs and outputs.

The WasteX EU specification formally defines the web service operations with their inputs and outputs via [WSDL] and [XSD].

Web service environments and endpoints

To external developers, there are two environments and endpoints of the [EDM] WasteX web service:

1. Production environment (planned, to be confirmed): https://edm.gv.at/wastex_eu/wastex_eu_webservice/wastex_eu.wsdl
2. Pre-production environment (planned, to be confirmed): https://vprod.umweltbundesamt.at/wastex_eu/wastex_eu_webservice/wastex_eu.wsdl

The Austrian Environment Agency as operator of the [EDM] WasteX EU web service offers the pre-production environment to external partners - developers/operators of IT solutions - for testing web service interactions. The pre-production environment resembles the production environment, and features database contents similar to those of the production environment. Note that access to the pre-production environment and access to the production environment are different from each other - credentials and access information for one environment do not work with the other environment.

Technologies and standards stack

The web service and its specification apply the following standards:

[Base64]

The web service expects certain contents in [Base64] encoding

[HTTP]/1.1

All interactions between a web service client and the web service follow the [HTTP]/1.1 protocol. For example, a web service client invokes a web service operation with an [HTTP] request using the [HTTP] POST method, and providing certain authentication information as [HTTP] headers

[Schematron] 2016

The web service may apply formal validation to messages it receives in the input of web service operations, and will use [Schematron] as the formal language for expressing the formal validation rules

[SOAP] 1.1

The web service follows the [SOAP] protocol, such as by using [SOAP] envelope [XML] structures for all web service inputs and outputs

Note that for [DIWASS API] compatibility WasteX EU uses 1.1, whereas [WasteX] uses 1.2

[TLS] 1.2+

The web service requires [TLS] 1.2 or higher for all client server communication. This ensures confidentiality, integrity, and authenticity. Note that the communication between secure web sites (https) and browsers uses the same [TLS] encryption protocol

[UTF-8]

The web service expects all operation inputs in [UTF-8] character encoding, and delivers all operation outputs and fault information in [UTF-8] character encoding

[UUID] 

Web service clients must generate Universally Unique Identifiers ([UUID]s) and include them in certain operation inputs.

[XML] 1.0

Syntax of web service inputs and outputs, including messages and payload

[XPath] 2.0

[XPath] expressions occur in [Schematron] instances (formal validation rule source) as well as in [XSLT] instances derived thereof. They provide the means of identifying and referencing specific parts and locations within [XML] instances

[XQuery] 2.0

[XQuery] expressions occur in [Schematron] instances (formal validation rule source) as well as in [XSLT] instances derived thereof. They provide the means of accessing [XML] instance contents, such as for reading and comparing

[XSD] 1.0

This specification uses [XSD] for the formal definition of the [XML] structures and value domains of web service inputs and outputs, including messages and payload. Note that every WasteX EU web service operation quits an invocation with a [SOAP] fault if according to [XSD] validation the operation input does not comply with the structures and value domains defined by the respective [XSD] instance of this specification

[XSLT] 2.0

[Schematron] uses [XSLT]: A WasteX web service generates the formal validation results (validation protocol) for messages it receives by applying an [XSLT] transformation using an [XSLT] processor such as [RaptorXML] or [Saxon]

[WSDL] 2.0

This specification uses [WSDL] for the formal definition of the web service operations with their inputs and outputs. The [WSDL] definition uses [XSD] instances for defining structure and value domains of the inputs and outputs. There are software tools on the market which use [WSDL] instances for automating parts of web service and web service client development and testing

Specification package

Description of files and folders in the package

wastex_eu_doc.html

The main specification document. It provides all instructions and guidance on correctly implementing, testing and operating WasteX EU web service connections.

The contents include detailed descriptions of web service operations with their inputs and outputs, as well as descriptions of all files and folders contained in the specification package, such as [XSD] and [WSDL] files.

wastex_eu.wsdl

Describes the operations of a WasteX EU web service and its inputs and outputs in the formal language [WSDL].

It contains a selection of operations reproduced from the [DIWASS API].

Note that all operations are available under one WasteX EU endpoint and port, even though their corresponding operations of the [DIWASS API] are spread out across multiple web service endpoints.

Software developers may for example use the WSDL instance with [SOAP] tools such as SoapUI to automatically generate web service interactions for all WasteX web service operations.

*.xsd

The basis for the [XSD] files of the WasteX EU specification package is an automatic derivation from the [DIWASS API]. With that basis, one of the [XSD] files contains a small extension in order to support structured route information in transmissions to the Austrian CA. See WasteX EU extension for more details.

Technical specification and organizational requirements

Party and site identification

Overview

[DIWASS] functions according to the following principles:

• All parties and sites, both referred to as "operators" in [DIWASS], must be registered in [TRACES.NT]
• Only after the parties and sites are registered in [TRACES.NT] can users submit PIC notifications, PIC movement documents, GLW consignment information, etc. in [DIWASS]. The identification of parties and sites in these submissions consists primarily of references to the [TRACES.NT] operator registrations
• The same applies to the [DIWASS API]: In submissions such as movement documents the identification of parties and sites consists primarily of the ID [TRACES.NT] automatically assigned to the operator upon registration. The XML inputs and outputs typically contain this ID in elements called OperatorInternalID

As WasteX EU closely aligns with the [DIWASS API] and reuses its [XSD] definitions, the same applies to party and site identification in the WasteX EU API.

The WasteX EU web service does not support the party identifiers that are in use in [WasteX], such as Global Location Numbers (GLNs).

Instead, software that uses the [DIWASS API] or WasteX EU must use [TRACES.NT] assigned operator IDs for party and site identification.

Referencable parties and sites

[EDM] continuously synchronizes data from [TRACES.NT] and [DIWASS]. This also applies to operator (party and site) registrations.

With regard to operators, note that [EDM] only synchronizes operators which in [TRACES.NT] and [DIWASS] have a WSR activity set, and that WSR activity in status "VALID".

All parties and sites registered in [TRACES.NT] and [DIWASS] that meet the criterion of having a WSR activity in status "VALID" can be identified (referenced) in WasteX EU transmissions.

Matching TRACES.NT operator registrations and IDs with existing party and site data

When registering operators in [TRACES.NT], users can provide several types of IDs already assigned to that operator, including:

• Global Location Number (GLN)
• [EORI]
• VAT ID (Value Added Tax)

Please see the [TRACES.NT] and [DIWASS] docs for a comprehensive list of supported types of IDs.

The [DIWASS API] contains operations such as FindOperator and GetOperator which can be used for matching existing party and site data with [TRACES.NT] operator registrations, and thus for determining corresponding [TRACES.NT] assigned operator IDs based on other assigned IDs such as GLNs.

Note that the Austrian CA provides functionality for [EDM] to automatically register certain Austrian EOs and sites in [TRACES.NT]. The primary prerequisite is that a waste shipment contact person is entered in the [EDM] registration for that party.

Main identifier for Austrian EOs

According to the [DIWASS Implementing Regulation] each MS defines a main type of identifier for EOs in that MS.

For Austrian EOs the CA has selected the GLN as main identifiers. When [EDM] automatically registers Austrian EOs and sites in [TRACES.NT], it transmits the GLN as main identifier.

The EC plans implementing automatic transmissions from [DIWASS] to EU customs via the so-called CERTEX interface.

For Austrian EOs registered in the Austrian Business Register, if an EORI is provided in that registration, [EDM] synchronizes this EORI into its local registration data.

Upon automatic registration of Austrian EOs in [TRACES.NT], [EDM] transmits EORIs, independent of whether they originate from the Austrian Business Register or have been manually provided in [EDM] registration.

Transmissions for other parties

Overview

WasteX EU supports transmissions for other parties that comply with the [WSR] and the [DIWASS Implementing Regulation].

WasteX EU does not support transmissions for other parties that do not comply with the [WSR] and the [DIWASS Implementing Regulation].

Supported transmissions

According to the [WSR] and the [DIWASS Implementing Regulation] there are certain cases where one economic operator (EO) introduces data by another EO electronically into [DIWASS] and connected systems.

An illustratory example of such a case:

• Shipments from Austria to a country outside the EU
• The facility outside the EU does not use [DIWASS], and neither systems connected to [DIWASS]
• The facility sends confirmations, such as receipt confirmation and treatment completion confirmation, by e-mail
• The notifier introduces the information received by e-mail into [DIWASS]

WasteX EU supports such transmissions.

Unsupported transmissions

It is only specific circumstances under which parties are expected to capture data electronically for other parties.

For example, a notifier must not transmit data for a EU facility. The EU facility itself must transmit this data.

WasteX EU clients must prevent any such transmissions for other parties that would not comply with the [WSR] and the [DIWASS Implementing Regulation].

The Austrian CA uses validation rules in its WasteX EU interface in order to prevent non-compliant transmissions for other parties.

Identification, Authentication and Authorization

Used Standard - UsernameToken

The [DIWASS API] uses [XML] segments that follow the [UsernameToken] standard in its [SOAP] headers for identifying and authenticating who interacts with the API.

As WasteX EU closely aligns with the [DIWASS API] and reuses its [XSD] definitions, the same applies to the WasteX EU interface.

This means that the authentication mechanism is different from most of the other [EDM] web services, including [WasteX] which use [HTTP] headers for the transmission of authentication information.

Registration and credentials

The credentials used for WasteX EU are separate from those used for the [DIWASS API].

Software operators need to register their WasteX EU client by contacting the [EDM] helpdesk, and will receive a set of credentials, client ID and client secret, to use in their client when interacting with WasteX EU.

Different sets of credentials are required for the test and productive environments.

The client ID serves as Username when applying the [UsernameToken] standard.

The byte sequence that results from [UTF‑8] encoding the client secret is the secret byte sequence to use in constructing the [UsernameToken] token preimage, together with nonce (16 random bytes) and [UTF‑8] encoded timestamp.

Software operators can continue using client IDs and client secrets that they already use in [WasteX]. There is no need to request new credentials for WasteX EU.

Authorization

Registered clients can conduct WasteX EU transmissions for any notifier, facility, etc.

Note that with [WasteX] registered parties need to authorize clients in [EDM] to interact with [WasteX] on their behalf, and note that such authorization is not required for WasteX EU.

This simplification is made possible by the fact that, unlike [WasteX], WasteX EU cannot be used for data access and retrieval (it is necessary to use the [DIWASS API] for such purposes).

This means that it is WasteX EU clients that must verify authorizations.

This relates to the signature block contained in each of the request structures.

For example, in CreateMovementTemplateRequest the signature block is NotifierSignature.

As a result, WasteX EU client software must verify that each instance of a DIWASS WasteX createMovementTemplate call is authorized by the notifier.

A user authorized to act on behalf of the notifier can be allowed to trigger such a call, a user unrelated to the notifier must not be able to trigger such a call.

WasteX EU clients shall keep evidence of authorization, such as logs or digital signatures, for three years.

Attachments

Background: Attachments in the DIWASS API

The [DIWASS API] supports attachments in the Art. 15, 16 and 18 [WSR] transmissions, such as in MovementTemplate, FacilityReception and Annex7Document.

Note that the way of providing attachments to such transmissions is as follows:

• The attachment must already exist in [DIWASS] prior to the transmission
• Within the transmission, the attachments must be referenced in the linkedAttachments/attachmentIdentifier elements

Thus, a typical flow of [DIWASS API] interactions for Art. 15, 16 and 18 [WSR] transmissions with attachments would look like this:

1. Use the [DIWASS API] WasteAttachWebService submitAttach operation to upload PDF or JPEG files and receive attachment identifiers in response
2. Within the [DIWASS API] Art. 15, 16 and 18 [WSR] transmissions, such as in a createMovementTemplate call, use the attachment identifiers from the previous step in the linkedAttachments/attachmentIdentifier elements

Handling of attachments in WasteX EU

The following applies to the WasteX EU web service:

• It offers neither a submitAttach operation nor a functional equivalent
• Like the [DIWASS API], with the Art. 15, 16 and 18 [WSR] transmission operations, such as createMovementTemplate and updateMovementTemplate, it supports referencing attachments in the linkedAttachments/attachmentIdentifier elements

For cases that require attachments in the Art. 15, 16 and 18 [WSR] transmissions from Austrian EOs to the Austrian CA, this is done as follows:

First step: Use the DIWASS API for attachment upload

Use the [DIWASS API] WasteAttachWebService submitAttach operation for uploading PDF or JPEG files, and get attachment idenitifers in response.

Note that the Austrian CA connecting the local system [EDM] to [DIWASS] does not impact (prevent) [DIWASS API] attachment uploads for Austrian EOs.

Second step: Use the attachment identifiers in WasteX EU transmissions

Within the WasteX EU Art. 15, 16 and 18 [WSR] transmissions, such as in a createMovementTemplate call, use the attachment identifiers from the previous step in the linkedAttachments/attachmentIdentifier elements.

Intended route, points of exit and entry

The Austrian CA supports transmitting structured information on points of exit and points of entry for an individual shipment in the WasteX EU web service. See WasteX EU extension.

Providing such route information for an individual shipment to the Austrian CA does hence not require an attachment.

If multiple of the involved CAs expect route information per shipment, this does however require an attachment, potentially in addition to the structured point of exit and point of entry data.

Codelists

The WasteX EU web service uses the same codelists and encodings as the [DIWASS API].

• For some of the encodings, the European Commission makes them available as enumerations within the [XSD] files of the [DIWASS API] specification;
• For others, the European Commission publishes them as tables under a Repositories folder of the [DIWASS API] specification package.

Many of the codes, such as recovery or disposal type codes, are derived from [Basel Convention] and [WSR], and thus have not changed compared to the [WasteX] web service.

Software developers may want to use the codelists the Austrian CA publishes on the [EDM] portal edm.gv.at as a source for German language names and descriptions.

Specific handling of transmitted content

The WasteX EU web service processes some of the transmittable contents in specific ways.

The following table lists the contents and the type of processing that applies to each.

Note that in v0.01 of the WasteX EU specification the table does not yet cover GLW (Annex VII).

Message	Element	Type	Facets	Processing by WasteX EU
All messages: FacilityReception FacilityCompletion	InterimFacility	xs:boolean	none	[EDM] ignores this data, and relies on data from the notification instead.
All messages: FacilityReception FacilityCompletion	FacilityTypeCode	FacilityTypeCode	enum=R, D	[EDM] ignores this data, and relies on data from the notification instead.
All messages: FacilityReception FacilityCompletion FacilityCompletionUnderArticle15	WasteTypeCode (incl. @listID)	Token64OrEmpty	maxLength=64	[EDM] ignores this data, and relies on data from the notification instead.
All messages: MovementTemplate ConsigneeReception FacilityReception FacilityCompletion FacilityCompletionUnderArticle15	Contact Name TelephoneCompleteNumber FaxCompleteNumber EmailURI WebsiteURI	ContactType	none	[EDM] ignores this data, and relies on data from the notification instead.

Synchronous operations

All web service operations are synchronous. Each request is processed immediately, and the corresponding response contains the complete result of the operation. No asynchronous processing or deferred result retrieval is supported.

Note that this replicates the [DIWASS API] design, but is different from how [WasteX] works.

Transport layer security TLS

WS clients and the WasteX WS must use transport layer security (encryption) by applying/supporting [TLS] 1.2, and optionally applying/supporting higher versions of [TLS], such as 1.3.

UTF-8 encoding

UTF-8 character encoding provisions

The WS client must use [UTF‑8] character encoding for all input to WasteX EU WS operations, i.e., for [HTTP] POST request bodies and headers.

The WasteX EU WS must deliver all operation outputs in [UTF‑8] character encoding.

Testing recommendation

Note that with different types of character encodings, such as [UTF‑8] and [Latin‑1], software can automatically determine (distinguish) in many, but not all cases whether or not its counterpart applied the correct type of encoding. There are cases where the encoding appears technically correct, but is actually different from the agreed encoding, which typically results in weird looking texts containing uncommon characters.

This observation leads to the following recommendation for those implementing a WasteX EU connection:

1. Have character encoding related test cases with the transmission of "special characters", such as ä, ö, ü, Ä, Ö, Ü or ß
2. For character encoding related test cases, do not only check for successful transmission (no errors/warnings/infos), but also check the correct interpretation of characters at the receiver's end, such as in GUIs at the receiver's end. For example, verify that a transmitted »ä« indeed shows up as »ä« at the receiver's end

XSD validity of operation inputs and outputs

The WasteX EU web service automatically rejects any operation invocation with an operation input that is invalid with respect to the [XSD] definitions. It does so with a [SOAP] Fault (exception).

Vice versa, every WasteX EU web service operation output must be valid with respect to the [XSD] definitions. Web service clients can automatically reject any operation output that does not comply with this provision.

Value ranges and precision

Upper size limits

The [DIWASS API] defines size limits for many of the data elements contained in operation inputs and outputs.

The following are examples for such size limits:

• The maximum number of characters for a character string
• The maximum number of decimal digits for a decimal number

The [DIWASS API] specification encodes these upper size limits in its [XSD]s.

The WasteX EU web service reuses the [DIWASS API] [XSD]s.

The impact of this is as follows:

• The same upper size limits that apply to the [DIWASS API] also apply to the WasteX EU web service
• When operation input contains content that exceeds any of these size limits, this results in an [XSD] validation error, which the operation reports back as [SOAP] Fault (exception)

The upper size limits are important for interoperability across different software implementations.

Developers of software solutions that participate in data interchange over the [DIWASS API] and the WasteX EU web service shall adhere to these size limits as much as possible, such as at database level.

This ensures interoperability by preventing both of the following:

1. Lack of interoperation due to the occurrence of automatic rejections caused by data instances exceeding size limits
2. Loss of data/precision in data transmissions, such as by truncating texts

Other value range restrictions and checks

For some data elements, the WasteX EU specification defines value range restrictions other than upper size limits. For example, most waste mass values must be greater than 0.

Where the [DIWASS API] specification does not encode such value range restrictions in the [XSD]s, the WasteX EU specification uses [Schematron] formal validation rules for checking compliance with the restrictions.

The WasteX EU WS informs about [Schematron] validation errors in regular responses. This is different from [XSD] validation errors, which result in [SOAP] Faults.

The difference is on purpose:

• An [XSD] validation error indicates a technical incompatibility, and is always a software implementation issue, never the user's fault
• In most cases [Schematron] validation rule violations are caused by user mistakes, such as misplacing a comma

As a result, there are the following options for developers of software solutions that use the WasteX EU web service:

1. Basic solution: Leave adhering to such other value range restrictions entirely to users. If a WasteX EU transmission violates any such a other value range restrictions, then users learn about the violation from the web service response, and can subsequently correct and re-transmit data
2. User friendly solution: Develop the software solution in a way that helps users with adhering to value range restrictions, such as by preventing certain input in GUIs or by pointing users to violations in GUIs prior to any web service transmission

Accuracy and Precision

Data from different sources shall be well-suited for comparisons and aggregation. Numeric data shall have identical or similar accuracy and precision.

Even though the [WSR] does not define minimum accuracy and precision for data such as waste mass values, CAs typically expect certain minimum accuracy and precision for measured values.

Any measurement result in WasteX EU transmissions shall contain only digits that are known exactly plus a final digit for which the associated uncertainty is at most ± 1.

Example:

The FacilityReception contains the mass of received waste. The mass value supports between 0 and 5 fractional digits. The following applies:

• For a measured received mass of waste provided without fractional digits, the maximum acceptable uncertainty is ± 1 metric ton. Rounding to 10 t, i.e., just distinguising between 10 t, 20 t, 30 t, etc., would thus be insufficient!
• For a measured received mass of waste provided with one fractional digit, the maximum acceptable uncertainty is ± 0.1 metric tons
• For a measured received mass of waste provided with five fractional digits, the maximum acceptable uncertainty is ± 0.00001 metric tons

Bulk transmissions

A client to a WasteX EU WS may have multiple messages waiting for transmission. This specification calls an operation on a queue/backlog of messages waiting for transmission bulk transmission. The term refers to the (intended) transmission of a potentially larger number of messages within a short period of time, such as a few minutes or hours.

The WasteX EU specification defines means for real time data interchange and for the transmission of individual messages. Data shall be exchanged when it is “finalized” and ready for transmission, independent of when that is (which day of the week, in the morning, in the night, etc.).

This means that the WasteX EU specification does not focus on bulk transmissions. Instead, the correct usage of the WasteX EU web service is keeping bulk transmissions to a minimum, and only using bulk transmissions when necessary.

The following two are scenarios in which bulk transmissions can become necessary in WasteX EU data interchange:

1. Late transmissions for “catching up” after an interruption of the data exchange, such as after an outage of the [EDM] WasteX EU WS (see handling of outages)
2. Timed transmissions, such as movement announcement transmissions that automatically trigger once a day prior to reaching the transmission deadline

For the implementation of bulk transmissions, it is important to comply with the limits regarding the maximum number of transactions per unit of time, as described under supported load. Depending on the number of messages to transmit, it may become necessary to spread the transmissions out to multiple hours of the day (transmission of n messages per hour, for each hour until all messages waiting for transmission have been sent), or even to multiple days.

For keeping bulk transmissions to a minimum, timed transmissions shall trigger at least once per day.

Sender and receiver side responsibilities

The following applies to responsibilities in relation to failed (auto-rejected) WasteX EU transmissions:

1. It is the web service operator's responsibility to keep the web service up and running and to keep downtimes as short as possible
2. Senders at the client side are responsible for initiating all attempts at resolving failed transmissions. Senders at the client side cannot and must not rely on the receiver at the web service side to initiate any such steps
3. If a transmission fails due to an operational issue or downtime at the web service side, then the sender side's attempt at resolving the issue shall start with simply re-attempting transmission at a later point in time, so as to check if the web service has resumed full operation
4. Depending on the type of issue, the sender at the client side may need to get in touch with the the web service operator or the intended transmission recipient for resolving failed transmissions, such as for entering or correcting data (user level), or for re-establishing regular operation of the web service (technical operation level) prior to re-transmission

SOAP Faults

SOAP version

The [DIWASS_API] is a [SOAP] 1.1 web service.

To make WasteX EU and the [DIWASS_API] as interchangeable as possible, the WasteX EU web service is also a [SOAP] 1.1 web service.

Note that the [WasteX] web service uses SOAP 1.2.

SOAP faults

Each interaction with the WasteX EU web service can result in a [SOAP] fault.

If the web service responds with a [SOAP] fault, it always does so in combination with the [HTTP] status code 500 Internal Server Error, regardless of the type of fault and the content of the fault message.

The WasteX EU web services uses primarily the following SOAP fault contents:

faultcode

One of the [SOAP] 1.1 defined values, namely Client or Server.

faultstring

Natural language description of the error.

Note that this description contains technical error information that can help IT personnel identify the cause of the error and resolve it. This text is not intended for end users and should either be hidden or displayed only with appropriate context (e.g., advising them to contact IT support).

Transmission retries

Automatic retries

For transmissions that fail due to an operational issue or downtime at the receiver side, the sending software instance (client software) shall keep track of such failed submissions (queue), and shall attempt automatic re-transmission at intervals such as the following:

• 20 minutes after the sending software instance first learns about the operational issue at the receiver side
• after 40 minutes
• after 60 minutes
• after that, once per day

When transmissions still fail after 60 minutes, software shall use temporary fallback communication channels, in particular the sending of unstructured email, if the recipient supports this. In parallel, the software instance shall keep re-trying WasteX EU transmissions as indicated above.

Manual retries

Software connected to the WasteX EU interface shall provide the following functionality to (certain) users:

• Manual triggering of a re-transmission attempt for an individual message
• Manual triggering of a re-transmission attempt for all transmissions waiting for automatic re-transmission (see automatic retries)

Recommended reactions to certain EDI behaviour

Timeout / No response / network errors

This can occur under regular circumstances, such as during a scheduled downtime (deploy of a new version of a WasteX EU web service)

Sender side software reaction:

• • Automatic retries
  • Use of temporary fallback communication channels, in particular unstructured email, after 60 minutes, if the recipient supports this
  • Interrupt bulk transmission if the error occurs during bulk transmission

Sender side user reaction:

Typically no reaction required. Users may want to check back after a while if regular EDI transmissions have resumed

Sender side IT support reaction:

None required

SOAP fault

This occurs as an exception, such as in response to a malformed (non XML Schema compliant) request or in response to failed authentication

Sender side software reaction:

• • Display information to users that a technical problem requires IT support
  • If this occurs in bulk transmissions: end/interrupt bulk transmission

Sender side user reaction:

Pass issue to sender side IT support

Sender side IT support reaction:

Try resolving the issue without getting in touch with receiver side IT support, such as by improving message generation or authentication. Only get in touch with receiver side IT support if this turns out necessary 

Rejection (without SOAP fault)

This can occur under regular circumstances, such as when critical data is missing in transmitted messages

Sender side software reaction:

• • Display transmission status information to users

  • Alert users that the transmission was unsuccessful and that they need to take steps (interact with the software) to resolve the cause and initiate a re-transmission attempt

Sender side user reaction:

• • Based on the information received by the software, resolve the cause of transmission failure and initiate a re-transmission attempt
  • If needed, get in touch with receiver side users, for example, if notification/consent information is missing or wrong at the receiver side

Sender side IT support reaction:

Typically none required

Acceptance with INFO or WARNING formal validation result

This can occur under regular circumstances, such as when there are inconsistencies in transmitted messages

Sender side software reaction:

• • Display transmission status information to users

  • Alert users that software validation has yielded hints at potentially problematic content, and advise users to review data, and – if necessary – to update and re-transmit data

Sender side user reaction:

• • Review data based on the information received, and, if needed, add/edit data and initiate a re-transmission

  • If needed, get in touch with receiver side users. For example, a user may find that the cause of a hint is wrong or missing data at receiver side, such as a missing consent, or a carrier missing from the consent. In such a case, the sender side user attempts re-transmission after the receiver side user has confirmed that receiver side data is fixed

Sender side IT support reaction:

None required

Acceptance signal with OK formal validation result

This occurs under regular circumstances

Sender side software reaction:

Display transmission status information to users (confirmation of successful transmission)

Sender side user reaction:

None required

Sender side IT support reaction:

None required

Service Levels and Operational Characteristics

Service level

The Austrian Environment Agency operates the [EDM] WasteX EU web service under the general [EDM] service level conditions. See edm.gv.at, “Technische und organisatorische Spezifikationen”, “Allgemeine Betriebsbedingungen”.

In particular, the web service can become unavailable temporarily due to scheduled maintenance on Tuesdays and Thursdays from 18:00 local time (CET/CEST).

DIWASS API dependency

The Austrian CA implements WasteX EU such that transmissions are only possible while the [DIWASS API] is up, running and working correctly.

[DIWASS API] outages may thus result in the temporary blocking of transmission overs the WasteX EU web service.

Handling of outages

When a WS client attempts transmission to the web service, the web service may not be available. For example, a timeout may occur because of planned maintenance of the [EDM] WasteX EU web service.

Note that this section applies to neither of the following:

• regular reactions to web service interactions (regular [SOAP] response messages)
• receipt of signal messages indicating automated rejection

The following list contains recommendations for handling such outages. The recommendations mainly target WasteX EDI IT developers, but also affect WasteX EDI users:

1. Attempt automatic re-transmissions, rather than requiring users to re-trigger transmissions manually, for transmissions that the WS client cannot conduct due to a WasteX EU WS outage
2. Transmissions such as MovementTemplate may need to be conducted within a short period of time (a few hours, the same day) for meeting legal requirements. For [EDM] WasteX EU WS outages that lasts longer than 60 minutes, software can email the information to wastex@bmk.gv.at automatically, i.e., without user interaction. Note:
   
   • The email body shall contain the information as natural language plaintext
   • The email must not contain attachments, such as PDFs
   • This only applies to time critical transmissions
3. The purpose of emails to wastex@bmk.gv.at is transmitting in time. Emails to wastex@bmk.gv.at do not replace electronic structured data transmissions, such as those via the [EDM] WasteX EU web service. Instead, when the web service returns into an operational state, the client shall conduct all previously delayed transmissions, independent of whether or not it has sent emails to wastex@bmk.gv.at for the respective transmissions

Supported load

The WasteX EU specification defines means for real time data interchange and for the transmission of individual messages, such as individual movement announcements. For the sake of a simple and clean web service with low maintenance costs, the WasteX EU specification does not define means for transmitting multiple messages at once.

As a result, the number of waste shipments that EOs conduct within a particular period of time can directly (linearly) reflect in the number of interactions with the [EDM] WasteX EU web service.

The [EDM] WasteX EU WS supports the following number of interactions per WS client and unit of time:

	per hour	per day
total number of operation calls	5.000	20.000

Exceeding these limits can result in interaction rejections, in particular [SOAP] faults.

Web service operations

Introduction

All WasteX EU web service operations replicate [DIWASS API] operations.

Please refer to the [DIWASS API] documentation for details on the operations, including their inputs and outputs.

Operations

Operation	Input Element	Output Element
createMovementTemplate	CreateMovementTemplateRequest	MovementTemplateOperationResponse
updateMovementTemplate	UpdateMovementTemplateRequest	MovementOperationResponse
createConsigneeReception	CreateConsigneeReceptionRequest	MovementOperationResponse
updateConsigneeReception	UpdateConsigneeReceptionRequest	MovementOperationResponse
createFacilityReception	CreateFacilityReceptionRequest	MovementOperationResponse
updateFacilityReception	UpdateFacilityReceptionRequest	MovementOperationResponse
createFacilityCompletion	CreateFacilityCompletionRequest	MovementOperationResponse
updateFacilityCompletion	UpdateFacilityCompletionRequest	MovementOperationResponse
submitMovementSignal	SubmitMovementSignalRequest	SubmitMovementSignalResponse
submitFacilityCompletionUnderArticle15	SubmitFacilityCompletionUnderArticle15Request	SubmitFacilityCompletionUnderArticle15Response
submitAnnex7Document	CreateAnnex7DocumentTypeRequest	Annex7DocumentTypeResponse
updateAnnex7Document	UpdateAnnex7DocumentTypeRequest	Annex7DocumentTypeResponse
submitAnnex7ConsigneeCertificateOfWasteReceipt	CreateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest	Annex7MovementDocumentTypeResponse
updateAnnex7ConsigneeCertificateOfWasteReceipt	UpdateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest	Annex7MovementDocumentTypeResponse
submitAnnex7FacilityCertificateOfWasteReceipt	CreateAnnex7FacilityCertificateOfWasteReceiptTypeRequest	Annex7MovementDocumentTypeResponse
updateAnnex7FacilityCertificateOfWasteReceipt	UpdateAnnex7FacilityCertificateOfWasteReceiptTypeRequest	Annex7MovementDocumentTypeResponse
submitAnnex7CertificateOfWasteCompletion	CreateAnnex7CertificateOfWasteCompletionTypeRequest	Annex7MovementDocumentTypeResponse
updateAnnex7CertificateOfWasteCompletion	UpdateAnnex7CertificateOfWasteCompletionTypeRequest	Annex7MovementDocumentTypeResponse
createAnnex7Signal	CreateAnnex7SignalTypeRequest	Annex7MovementDocumentTypeResponse

Message formats

Introduction

Note that all structures and definitions are replicated from the [DIWASS API].

Please refer to the [DIWASS API] documentation for details on the operation inputs and outputs, lists and repositories, enumerations, etc.

In the leaf tables, hover over the leaf name to see full XML path and multiplicity information.

WasteX EU extension

WasteX EU contains the following extensions compared to the [DIWASS API] formats:

• CreateMovementTemplateRequest and UpdateMovementTemplateRequest: Added possibility to provide structured route information (intended route for that specific shipment), element Route, with entry point and exit point names per country.

Note that structured route information is available to the Austrian CA only. If other involved CAs also expect route information per shipment, it is necessary to transmit this route information as attachment, in addition to the structured information.

Occurrence information

The following XML structure tables contain occurrence information.

[XSD] files define the minimum and maximum number of occurrences for each element.

The numbers in square brackets indicate this occurrence information, with the left hand number representing the minimum number of occurrences, and the right hand number representing the maximum number of occurrences.

Notes:

• An asterisk on the right hand side stands for unbounded, which means that the element is repeatable, and that the [XSD] does not define a maximum number of repetitions;
• The occurrence information provides a first insight, but cannot fully reflect all possible [XSD] defined constraints. For example, an [XSD] xs:choice indicates that exactly one of the child elements must be provided. The square bracket occurrence notation cannot reflect this, for an xs:choice all child elements appear with minimum occurrence 0;
• Minimum and maximum occurrences are purely technical constraints:
  • [XML] files that violate these constraints are considered invalid and software cannot process such files in most cases;
  • These constraints do not imply any legal or business requirements. For example, an element may be technically optional (minimum occurrence of 0) but legally required.

Contents

• CreateMovementTemplateRequest
• MovementTemplateOperationResponse
• UpdateMovementTemplateRequest
• MovementOperationResponse
• CreateConsigneeReceptionRequest
• UpdateConsigneeReceptionRequest
• CreateFacilityReceptionRequest
• UpdateFacilityReceptionRequest
• CreateFacilityCompletionRequest
• UpdateFacilityCompletionRequest
• SubmitMovementSignalRequest
• SubmitMovementSignalResponse
• SubmitFacilityCompletionUnderArticle15Request
• SubmitFacilityCompletionUnderArticle15Response
• CreateAnnex7DocumentTypeRequest
• Annex7DocumentTypeResponse
• UpdateAnnex7DocumentTypeRequest
• CreateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest
• Annex7MovementDocumentTypeResponse
• UpdateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest
• CreateAnnex7FacilityCertificateOfWasteReceiptTypeRequest
• UpdateAnnex7FacilityCertificateOfWasteReceiptTypeRequest
• CreateAnnex7CertificateOfWasteCompletionTypeRequest
• UpdateAnnex7CertificateOfWasteCompletionTypeRequest
• CreateAnnex7SignalTypeRequest

XML structures

CreateMovementTemplateRequest

Nr	Leaf	Type	Facets	Documentation
1	[0:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]CreateMovementTemplateRequest [1:1]movementDocumentDueToTakeBack	xs:boolean
3	[1:1]CreateMovementTemplateRequest [1:1]movementDocumentsDueToIllegalActivity	xs:boolean
4	[0:1]movementReferenceIdentifier [1:1]movementId	model:Token	minLength=1
5	[1:1]template [1:1]NotificationID	model:NotificationIdentifierType	minLength=1; maxLength=100	The number of the notification under which the shipment of waste has been consented. Note: Corresponds to block 1 of Annex IB WSR.
6	[0:1]ShipmentOriginAddress [0:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) of the party
7	[0:1]ShipmentOriginAddress [0:1]AddressDetails	model:NonStructuredAddressType	minLength=1; maxLength=250	Free-text description of the shipment origin address (e.g., "the carrier stuck at a highway").
8	[1:1]template [1:1]SequenceNumber	model:PositiveInteger8	totalDigits=8	A sequential number assigned to the shipment of waste, enumerating all the shipments of waste under one notification, with "1" assigned to the first shipment, "2" to the second, and so on. Note 1: A sequence number typically must not be reused. This also applies when shipments of waste are cancelled. The number of the cancelled shipment must not be reused for a new shipment. Note 2: Corresponds to block 2 of Annex IB WSR.
9	[1:1]template [0:1]ContainerIdentification	model:Token	minLength=1	Container identification number, if applicable.
10	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
11	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
12	[1:1]TransportAnnouncement [1:1]StartDate	xs:date		The start date of this shipment of waste. Note: Corresponds to block 6 of Annex IB WSR.
13	[1:1]Packaging [1:*]PackageTypeCode	model:PackageCodeType	enum=1, 2, 3, ...	A code specifying the type of package. Example: "6" for "composite packaging".
14	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
15	[0:1]PackageDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
16	[1:1]Packaging [0:1]SpecialHandlingRequirementIndicator	xs:boolean		An indication of whether or not special handling is required for the packages.
17	[1:1]Packaging [1:1]PackageQuantity	model:PositiveInteger8	totalDigits=8	The number of packages in this shipment of waste.
18	[1:*]Carrier [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
19	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
20	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
21	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
22	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
23	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
24	[1:*]Carrier [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
25	[1:*]Carrier [1:1]MeansOfTransportCode	model:MeansOfTransportCodeType	enum=A, R, S, ...	A code specifying the means of transport for this carrier. Example: "R" for road, "T" for train. Note: The WSR may define different codes in its various translations. In the electronic data interchange the codes from the English version of the regulation MUST be used, independent of the countries involved and independent of the language used in the document.
26	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
27	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
28	[1:1]ExportCountry [0:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of dispatch on the route.
29	[1:1]ExportCountry [0:1]ExitPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of exit in the country of dispatch.
30	[1:1]ImportCountry [0:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of destination on the route.
31	[1:1]ImportCountry [0:1]EntryPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of entry in the country of destination.
32	[0:*]TransitCountry [1:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of transit on the route.
33	[0:*]TransitCountry [0:1]EntryPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of entry in the transit country.
34	[0:*]TransitCountry [0:1]ExitPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of exit in the transit country.
35	[1:1]NotifierSignature [1:1]name	model:String256	minLength=1; maxLength=256
36	[1:1]NotifierSignature [1:1]organizationRole	xs:string
37	[1:1]NotifierSignature [1:1]timestamp	xs:dateTime
38	[1:1]NotifierSignature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
39	[1:1]NotifierSignature [0:1]signature	model:String256	minLength=1; maxLength=256
40	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

MovementTemplateOperationResponse

Nr	Leaf	Type	Facets	Documentation
1	[1:1]response [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]movementId [1:1]movementId	model:Token	minLength=1

UpdateMovementTemplateRequest

Nr	Leaf	Type	Facets	Documentation
1	[0:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]UpdateMovementTemplateRequest [1:1]movementDocumentDueToTakeBack	xs:boolean
3	[1:1]UpdateMovementTemplateRequest [1:1]movementDocumentsDueToIllegalActivity	xs:boolean
4	[0:1]movementReferenceIdentifier [1:1]movementId	model:Token	minLength=1
5	[1:1]template [1:1]NotificationID	model:NotificationIdentifierType	minLength=1; maxLength=100	The number of the notification under which the shipment of waste has been consented. Note: Corresponds to block 1 of Annex IB WSR.
6	[0:1]ShipmentOriginAddress [0:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) of the party
7	[0:1]ShipmentOriginAddress [0:1]AddressDetails	model:NonStructuredAddressType	minLength=1; maxLength=250	Free-text description of the shipment origin address (e.g., "the carrier stuck at a highway").
8	[1:1]template [1:1]SequenceNumber	model:PositiveInteger8	totalDigits=8	A sequential number assigned to the shipment of waste, enumerating all the shipments of waste under one notification, with "1" assigned to the first shipment, "2" to the second, and so on. Note 1: A sequence number typically must not be reused. This also applies when shipments of waste are cancelled. The number of the cancelled shipment must not be reused for a new shipment. Note 2: Corresponds to block 2 of Annex IB WSR.
9	[1:1]template [0:1]ContainerIdentification	model:Token	minLength=1	Container identification number, if applicable.
10	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
11	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
12	[1:1]TransportAnnouncement [1:1]StartDate	xs:date		The start date of this shipment of waste. Note: Corresponds to block 6 of Annex IB WSR.
13	[1:1]Packaging [1:*]PackageTypeCode	model:PackageCodeType	enum=1, 2, 3, ...	A code specifying the type of package. Example: "6" for "composite packaging".
14	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
15	[0:1]PackageDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
16	[1:1]Packaging [0:1]SpecialHandlingRequirementIndicator	xs:boolean		An indication of whether or not special handling is required for the packages.
17	[1:1]Packaging [1:1]PackageQuantity	model:PositiveInteger8	totalDigits=8	The number of packages in this shipment of waste.
18	[1:*]Carrier [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
19	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
20	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
21	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
22	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
23	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
24	[1:*]Carrier [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
25	[1:*]Carrier [1:1]MeansOfTransportCode	model:MeansOfTransportCodeType	enum=A, R, S, ...	A code specifying the means of transport for this carrier. Example: "R" for road, "T" for train. Note: The WSR may define different codes in its various translations. In the electronic data interchange the codes from the English version of the regulation MUST be used, independent of the countries involved and independent of the language used in the document.
26	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
27	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
28	[1:1]ExportCountry [0:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of dispatch on the route.
29	[1:1]ExportCountry [0:1]ExitPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of exit in the country of dispatch.
30	[1:1]ImportCountry [0:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of destination on the route.
31	[1:1]ImportCountry [0:1]EntryPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of entry in the country of destination.
32	[0:*]TransitCountry [1:1]CountryID	model:CountryCodeType	minLength=1; pattern	WasteX EU extension: The country of transit on the route.
33	[0:*]TransitCountry [0:1]EntryPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of entry in the transit country.
34	[0:*]TransitCountry [0:1]ExitPointName	model:NameType	minLength=1; maxLength=256	WasteX EU extension: The name of the point of exit in the transit country.
35	[1:1]NotifierSignature [1:1]name	model:String256	minLength=1; maxLength=256
36	[1:1]NotifierSignature [1:1]organizationRole	xs:string
37	[1:1]NotifierSignature [1:1]timestamp	xs:dateTime
38	[1:1]NotifierSignature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
39	[1:1]NotifierSignature [0:1]signature	model:String256	minLength=1; maxLength=256
40	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

MovementOperationResponse

Nr	Leaf	Type	Facets	Documentation
1	[1:1]response [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]movementCertificateId [1:1]movementId	model:Token	minLength=1
9	[1:1]movementCertificateId [0:1]certificateId	model:Token	minLength=1

CreateConsigneeReceptionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]CertificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]CertificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

UpdateConsigneeReceptionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]CertificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]CertificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateFacilityReceptionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]CertificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]CertificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[1:1]CertificateOfWasteReceipt [1:1]ActualSiteOfDisposalOrRecovery	model:Token	minLength=1
20	[1:1]CertificateOfWasteReceipt [1:1]InterimFacility	xs:boolean
21	[1:1]CertificateOfWasteReceipt [1:1]FacilityTypeCode	model:FacilityTypeCode	enum=R, D
22	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
23	[0:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
24	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
25	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
27	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
28	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
29	[0:1]RejectionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
30	[1:1]CertificateOfWasteReceipt [1:1]RecoveryDisposalApproximateDate	xs:date		The approximate date of recovery or disposal.
31	[1:1]CertificateOfWasteReceipt [0:*]RecoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...	A code specifying the type of recovery or disposal conducted at the facility. Example: "R2" for "Solvent reclamation/regeneration".
32	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
33	[0:1]RecoveryDisposalDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
34	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

UpdateFacilityReceptionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]CertificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]CertificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[1:1]CertificateOfWasteReceipt [1:1]ActualSiteOfDisposalOrRecovery	model:Token	minLength=1
20	[1:1]CertificateOfWasteReceipt [1:1]InterimFacility	xs:boolean
21	[1:1]CertificateOfWasteReceipt [1:1]FacilityTypeCode	model:FacilityTypeCode	enum=R, D
22	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
23	[0:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
24	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
25	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
27	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
28	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
29	[0:1]RejectionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
30	[1:1]CertificateOfWasteReceipt [1:1]RecoveryDisposalApproximateDate	xs:date		The approximate date of recovery or disposal.
31	[1:1]CertificateOfWasteReceipt [0:*]RecoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...	A code specifying the type of recovery or disposal conducted at the facility. Example: "R2" for "Solvent reclamation/regeneration".
32	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
33	[0:1]RecoveryDisposalDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
34	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateFacilityCompletionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfCompletion [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]certificateOfCompletion [1:1]ActualSiteOfDisposalOrRecovery	model:Token	minLength=1
10	[1:1]certificateOfCompletion [1:1]InterimFacility	xs:boolean
11	[1:1]certificateOfCompletion [1:1]FacilityTypeCode	model:FacilityTypeCode	enum=R, D
12	[1:1]RecoveryDisposalParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
13	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
14	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
15	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
16	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
17	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
18	[1:1]RecoveryDisposalParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
19	[1:1]certificateOfCompletion [1:1]CompletionDate	xs:date
20	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
21	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
22	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
24	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
25	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
27	[1:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
28	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
29	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
30	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

UpdateFacilityCompletionRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
2	[1:1]movementIdentifier [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfCompletion [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]certificateOfCompletion [1:1]ActualSiteOfDisposalOrRecovery	model:Token	minLength=1
10	[1:1]certificateOfCompletion [1:1]InterimFacility	xs:boolean
11	[1:1]certificateOfCompletion [1:1]FacilityTypeCode	model:FacilityTypeCode	enum=R, D
12	[1:1]RecoveryDisposalParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
13	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
14	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
15	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
16	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
17	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
18	[1:1]RecoveryDisposalParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
19	[1:1]certificateOfCompletion [1:1]CompletionDate	xs:date
20	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
21	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
22	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
24	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
25	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
27	[1:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
28	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
29	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
30	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

SubmitMovementSignalRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]SubmitMovementSignalRequest [0:1]userCompetentAuthorityDomainID	notification:AuthorityDomainBodyIdentifier	enum=WSRDISP, WSRTRAN, WSRDEST
2	[0:1]onBehalfOfCA [1:1]CompetentAuthorityID	model:Token64	minLength=1; maxLength=64
3	[0:1]onBehalfOfCA [0:1]CountryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
4	[0:1]onBehalfOfCA [1:1]CompetentAuthorityDomainID	notification:AuthorityDomainBodyIdentifier	enum=WSRDISP, WSRTRAN, WSRDEST
5	[1:1]movementIdentifier [1:1]movementId	model:Token	minLength=1
6	[1:1]signal [1:1]typeCode	notification:SignalStatementTypeCodeType	enum=ProperlyCarriedOut, ProperlyCompleted, NotificationInvalid, ...
7	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
8	[0:1]description [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
9	[0:1]signature [1:1]name	model:String256	minLength=1; maxLength=256
10	[0:1]signature [1:1]organizationRole	xs:string
11	[0:1]signature [1:1]timestamp	xs:dateTime
12	[0:1]signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
13	[0:1]signature [0:1]signature	model:String256	minLength=1; maxLength=256
14	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

SubmitMovementSignalResponse

Nr	Leaf	Type	Facets	Documentation
1	[1:1]response [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]movementId [1:1]movementId	model:Token	minLength=1

SubmitFacilityCompletionUnderArticle15Request

Nr	Leaf	Type	Facets	Documentation
1	[1:1]SubmitFacilityCompletionUnderArticle15Request [1:1]notificationId	model:Token	minLength=1
2	[1:1]SubmitFacilityCompletionUnderArticle15Request [0:1]certificateId	model:Token	minLength=1
3	[1:1]recoveryDisposalParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
5	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
6	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
7	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
8	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
9	[1:1]recoveryDisposalParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
10	[1:1]SubmitFacilityCompletionUnderArticle15Request [1:*]movementIdentifier	model:Token	minLength=1
11	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
12	[1:1]wasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
13	[1:1]SubmitFacilityCompletionUnderArticle15Request [1:1]completionDate	xs:date
14	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
15	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
16	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
17	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
18	[1:1]reusedOrRecycledQuantityArticle15 [1:*]recoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...
19	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
20	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
21	[1:1]recoveredInOtherMannerQuantityArticle15 [1:*]recoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...
22	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
24	[1:1]disposedQuantityArticle15 [1:*]recoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...
25	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
26	[0:1]wasteDesignationDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
27	[1:1]signature [1:1]name	model:String256	minLength=1; maxLength=256
28	[1:1]signature [1:1]organizationRole	xs:string
29	[1:1]signature [1:1]timestamp	xs:dateTime
30	[1:1]signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
31	[1:1]signature [0:1]signature	model:String256	minLength=1; maxLength=256
32	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

SubmitFacilityCompletionUnderArticle15Response

Nr	Leaf	Type	Facets	Documentation
1	[0:1]responseStatus [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]notificationDocumentId [1:1]notificationId	model:NotificationIdentifierType	minLength=1; maxLength=100
9	[1:1]notificationDocumentId [0:1]documentId	model:DocumentIdentifierType	minLength=1; maxLength=100

CreateAnnex7DocumentTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]CreateAnnex7DocumentTypeRequest [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]CreateAnnex7DocumentTypeRequest [1:1]takeBackIndication	xs:boolean		The flag indicates whether the Annex VII document created due to take-back.
3	[1:1]CreateAnnex7DocumentTypeRequest [1:1]illegalActivityIndication	xs:boolean		The flag indicates whether the Annex VII document created due to detection of illegal activity.
4	[1:1]CreateAnnex7DocumentTypeRequest [0:1]referenceNotificationNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The notification number assigned to the notification by the Competent Authority of Dispatch or an IT solution on its behalf. Example: "DE 030855". It can be empty if the notifier is pushing the data.
5	[1:1]CreateAnnex7DocumentTypeRequest [0:1]referenceMovementNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The movement number assigned to the movement.
6	[1:1]CreateAnnex7DocumentTypeRequest [0:1]referenceAnnexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The movement number assigned to the movement.
7	[1:1]CreateAnnex7DocumentTypeRequest [1:1]shipmentArrangerIsAlsoProducerOrCollector	xs:boolean		The flag indicates whether the person who arranges the shipment also the original waste producer, waste collector or new waste producer?.
8	[1:1]arranger [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
9	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
10	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
11	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
12	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
13	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
14	[1:1]arranger [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
15	[1:1]consignee [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
16	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
17	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
18	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
19	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
20	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
21	[1:1]consignee [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
22	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
24	[1:1]transportAnnouncement [1:1]actualDateOfShipment	xs:date		The start date of this shipment of waste. Note: Corresponds to block 4 of Annex VII WSR.
25	[1:1]transportAnnouncement [0:1]containerIdentification	model:Token	minLength=1	Container identification number, if applicable.
26	[1:1]shipmentOriginLocation [0:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) of the party
27	[1:1]shipmentOriginLocation [0:1]AddressDetails	model:NonStructuredAddressType	minLength=1; maxLength=250	Free-text description of the shipment origin address (e.g., "the carrier stuck at a highway").
28	[1:1]shipmentLocationResponsiblePerson [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
29	[1:1]shipmentLocationResponsiblePerson [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
30	[1:1]shipmentLocationResponsiblePerson [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
31	[1:1]shipmentLocationResponsiblePerson [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
32	[1:1]shipmentLocationResponsiblePerson [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
33	[1:*]carrier [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
34	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
35	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
36	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
37	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
38	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
39	[1:*]carrier [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
40	[1:*]carrier [1:1]MeansOfTransportCode	model:MeansOfTransportCodeType	enum=A, R, S, ...	A code specifying the means of transport for this carrier. Example: "R" for road, "T" for train. Note: The WSR may define different codes in its various translations. In the electronic data interchange the codes from the English version of the regulation MUST be used, independent of the countries involved and independent of the language used in the document.
41	[0:*]wasteProducer [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
42	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
43	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
44	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
45	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
46	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
47	[0:*]wasteProducer [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
48	[1:*]recoveryLaboratoryFacility [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
49	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
50	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
51	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
52	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
53	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
54	[1:*]recoveryLaboratoryFacility [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
55	[1:1]operationalIndicators [1:1]InterimFacility	xs:boolean
56	[1:1]operationalIndicators [1:1]NextSubsequentInterimOrNonInterimFacilityInAnotherCountry	xs:boolean
57	[1:1]operationalIndicators [1:1]NextSubsequentInterimOrNonInterimFacilityInSameCountry	xs:boolean
58	[1:*]recoveryLaboratoryFacility [1:1]wasteFacilityNameConfidential	xs:boolean		Indicates whether the name of the waste receiving facility is confidential and shall not be publicly disclosed.
59	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
60	[0:1]confidentialityLegalExplanation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
61	[1:*]recoveryLaboratoryFacility [1:1]facilityLaboratoryTypeCode	model:Annex7FacilityTypeCode	enum=R, L	A code specifying a type of facility. Either a Recovery or Disposal. Example: Recovery
62	[1:1]transportAnnouncement [1:*]recoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...	A code specifying the type of recovery or disposal conducted at the facility. Example: "R2" for "Solvent reclamation/regeneration".
63	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
64	[1:1]usualDescriptionOfTheWaste [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
65	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
66	[1:1]wasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
67	[1:1]transportAnnouncement [0:1]commodityCode	model:Token64OrEmpty	maxLength=64
68	[1:1]exportCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
69	[1:1]importCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
70	[0:*]transitCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
71	[1:1]declarationArranger [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
72	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
73	[1:1]Signature [1:1]organizationRole	xs:string
74	[1:1]Signature [1:1]timestamp	xs:dateTime
75	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
76	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
77	[0:*]declarationProducer [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
78	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
79	[1:1]Signature [1:1]organizationRole	xs:string
80	[1:1]Signature [1:1]timestamp	xs:dateTime
81	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
82	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
83	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

Annex7DocumentTypeResponse

Nr	Leaf	Type	Facets	Documentation
1	[1:1]response [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]Annex7DocumentTypeResponse [1:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100

UpdateAnnex7DocumentTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]UpdateAnnex7DocumentTypeRequest [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]UpdateAnnex7DocumentTypeRequest [1:1]takeBackIndication	xs:boolean		The flag indicates whether the Annex VII document created due to take-back.
3	[1:1]UpdateAnnex7DocumentTypeRequest [1:1]illegalActivityIndication	xs:boolean		The flag indicates whether the Annex VII document created due to detection of illegal activity.
4	[1:1]UpdateAnnex7DocumentTypeRequest [0:1]referenceNotificationNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The notification number assigned to the notification by the Competent Authority of Dispatch or an IT solution on its behalf. Example: "DE 030855". It can be empty if the notifier is pushing the data.
5	[1:1]UpdateAnnex7DocumentTypeRequest [0:1]referenceMovementNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The movement number assigned to the movement.
6	[1:1]UpdateAnnex7DocumentTypeRequest [0:1]referenceAnnexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100	The movement number assigned to the movement.
7	[1:1]UpdateAnnex7DocumentTypeRequest [1:1]shipmentArrangerIsAlsoProducerOrCollector	xs:boolean		The flag indicates whether the person who arranges the shipment also the original waste producer, waste collector or new waste producer?.
8	[1:1]arranger [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
9	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
10	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
11	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
12	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
13	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
14	[1:1]arranger [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
15	[1:1]consignee [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
16	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
17	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
18	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
19	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
20	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
21	[1:1]consignee [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
22	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
24	[1:1]transportAnnouncement [1:1]actualDateOfShipment	xs:date		The start date of this shipment of waste. Note: Corresponds to block 4 of Annex VII WSR.
25	[1:1]transportAnnouncement [0:1]containerIdentification	model:Token	minLength=1	Container identification number, if applicable.
26	[1:1]shipmentOriginLocation [0:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) of the party
27	[1:1]shipmentOriginLocation [0:1]AddressDetails	model:NonStructuredAddressType	minLength=1; maxLength=250	Free-text description of the shipment origin address (e.g., "the carrier stuck at a highway").
28	[1:1]shipmentLocationResponsiblePerson [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
29	[1:1]shipmentLocationResponsiblePerson [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
30	[1:1]shipmentLocationResponsiblePerson [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
31	[1:1]shipmentLocationResponsiblePerson [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
32	[1:1]shipmentLocationResponsiblePerson [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
33	[1:*]carrier [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
34	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
35	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
36	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
37	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
38	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
39	[1:*]carrier [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
40	[1:*]carrier [1:1]MeansOfTransportCode	model:MeansOfTransportCodeType	enum=A, R, S, ...	A code specifying the means of transport for this carrier. Example: "R" for road, "T" for train. Note: The WSR may define different codes in its various translations. In the electronic data interchange the codes from the English version of the regulation MUST be used, independent of the countries involved and independent of the language used in the document.
41	[0:*]wasteProducer [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
42	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
43	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
44	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
45	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
46	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
47	[0:*]wasteProducer [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
48	[1:*]recoveryLaboratoryFacility [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
49	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
50	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
51	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
52	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
53	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
54	[1:*]recoveryLaboratoryFacility [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
55	[1:1]operationalIndicators [1:1]InterimFacility	xs:boolean
56	[1:1]operationalIndicators [1:1]NextSubsequentInterimOrNonInterimFacilityInAnotherCountry	xs:boolean
57	[1:1]operationalIndicators [1:1]NextSubsequentInterimOrNonInterimFacilityInSameCountry	xs:boolean
58	[1:*]recoveryLaboratoryFacility [1:1]wasteFacilityNameConfidential	xs:boolean		Indicates whether the name of the waste receiving facility is confidential and shall not be publicly disclosed.
59	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
60	[0:1]confidentialityLegalExplanation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
61	[1:*]recoveryLaboratoryFacility [1:1]facilityLaboratoryTypeCode	model:Annex7FacilityTypeCode	enum=R, L	A code specifying a type of facility. Either a Recovery or Disposal. Example: Recovery
62	[1:1]transportAnnouncement [1:*]recoveryDisposalTypeCode	model:RecoveryDisposalCodeType	enum=R1, R2, R3, ...	A code specifying the type of recovery or disposal conducted at the facility. Example: "R2" for "Solvent reclamation/regeneration".
63	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
64	[1:1]usualDescriptionOfTheWaste [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
65	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
66	[1:1]wasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
67	[1:1]transportAnnouncement [0:1]commodityCode	model:Token64OrEmpty	maxLength=64
68	[1:1]exportCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
69	[1:1]importCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
70	[0:*]transitCountry [1:1]countryID	model:CountryCodeType	minLength=1; pattern	The ISO 3166-1 numeric 3 code specifying the country.
71	[1:1]declarationArranger [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
72	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
73	[1:1]Signature [1:1]organizationRole	xs:string
74	[1:1]Signature [1:1]timestamp	xs:dateTime
75	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
76	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
77	[0:*]declarationProducer [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
78	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
79	[1:1]Signature [1:1]organizationRole	xs:string
80	[1:1]Signature [1:1]timestamp	xs:dateTime
81	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
82	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
83	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]certificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

Annex7MovementDocumentTypeResponse

Nr	Leaf	Type	Facets	Documentation
1	[1:1]response [1:1]statusCode	notification:WasteStatusCode	enum=OK, NOTOK, WARNING
2	[0:*]errors [1:1]code	xs:string
3	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:*]errors [0:1]description	String1024	minLength=1; maxLength=1024
5	[0:*]warnings [1:1]code	xs:string
6	[0:1]description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
7	[0:*]warnings [0:1]description	String1024	minLength=1; maxLength=1024
8	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
9	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100

UpdateAnnex7ConsigneeCertificateOfWasteReceiptTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]certificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateAnnex7FacilityCertificateOfWasteReceiptTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]certificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[1:1]certificateOfWasteReceipt [1:1]InterimFacility	xs:boolean
20	[1:1]certificateOfWasteReceipt [1:1]FacilityTypeCode	model:Annex7FacilityTypeCode	enum=R, L
21	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
22	[1:1]WasteDesignationCompositionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
23	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
24	[1:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
25	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
27	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
28	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
29	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
30	[0:1]RejectionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
31	[1:1]certificateOfWasteReceipt [0:1]RecoveryLaboratoryApproximateDate	xs:date		The approximate date of recovery or laboratory.
32	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

UpdateAnnex7FacilityCertificateOfWasteReceiptTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteReceipt [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]RecipientParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
10	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
11	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
12	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
13	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
14	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
15	[1:1]RecipientParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
16	[1:1]certificateOfWasteReceipt [1:1]ReceiptDate	xs:date		The date of waste receipt.
17	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
18	[0:1]AdditionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
19	[1:1]certificateOfWasteReceipt [1:1]InterimFacility	xs:boolean
20	[1:1]certificateOfWasteReceipt [1:1]FacilityTypeCode	model:Annex7FacilityTypeCode	enum=R, L
21	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
22	[1:1]WasteDesignationCompositionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
23	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
24	[1:1]WasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
25	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
26	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
27	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
28	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
29	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
30	[0:1]RejectionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
31	[1:1]certificateOfWasteReceipt [0:1]RecoveryLaboratoryApproximateDate	xs:date		The approximate date of recovery or laboratory.
32	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateAnnex7CertificateOfWasteCompletionTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteCompletion [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]certificateOfWasteCompletion [1:1]interimFacility	xs:boolean
10	[1:1]certificateOfWasteCompletion [1:1]facilityTypeCode	model:Annex7FacilityTypeCode	enum=R, L
11	[1:1]recoveryLaboratoryParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
12	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
13	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
14	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
15	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
16	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
17	[1:1]recoveryLaboratoryParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
18	[1:1]certificateOfWasteCompletion [1:1]completionDate	xs:date
19	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
20	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
21	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
22	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
24	[1:1]wasteDesignationCompositionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
25	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
26	[1:1]wasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
27	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
28	[0:1]additionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
29	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

UpdateAnnex7CertificateOfWasteCompletionTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]movement [0:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]movement [0:1]documentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
3	[1:1]certificateOfWasteCompletion [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
4	[1:1]Signature [1:1]name	model:String256	minLength=1; maxLength=256
5	[1:1]Signature [1:1]organizationRole	xs:string
6	[1:1]Signature [1:1]timestamp	xs:dateTime
7	[1:1]Signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
8	[1:1]Signature [0:1]signature	model:String256	minLength=1; maxLength=256
9	[1:1]certificateOfWasteCompletion [1:1]interimFacility	xs:boolean
10	[1:1]certificateOfWasteCompletion [1:1]facilityTypeCode	model:Annex7FacilityTypeCode	enum=R, L
11	[1:1]recoveryLaboratoryParty [1:1]PartyUUID	model:UuidType	pattern	Universally Unique ID (UUID) automatically assigned by an IT system to a party (Notifier, Consignee, CompetentAuthority, …). Note 1: In case of a waste producer or facility, every combination of a party and site must have a different UUID to distinguish the individual sites of the same waste producer or facility. Note 2: New UUIDs are assigned per operation, including for references to the same party. Example 1: For two notifications with the same notifier, a new notifier UUID is expected to be assigned in each of the notifications. Note 3: New UUIDs are assigned per party, including for references to the same party within one notification. Example 2: For a notification where the same party acts as consignee and recovery or disposal facility, the UUID assigned to the notification’s consignee entry is expected to be different from the UUID assigned to the recovery or disposal facility entry. Example 3: For a notification where there are multiple production sites under the same waste producer party, each of the WasteProducer entries is expected to be assigned a unique UUID. Note 4: In subsequent messages under the same operation, the same party must have the same PartyUUID assigned. Example 4: In a WasteMovementDocument message, each party entry must carry the same UUID as the corresponding party entry in a previous Notification Document message.
12	[0:1]Contact [1:1]Name	model:PersonNameType	minLength=1; maxLength=100	The person's given name.
13	[0:1]Contact [0:1]TelephoneCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact phone number. Examples: +49 1 234 5678, 0049 1 234 5678
14	[0:1]Contact [0:1]FaxCompleteNumber	model:PhoneType	minLength=1; maxLength=48	The complete contact fax number.
15	[0:1]Contact [0:1]EmailURI	model:URIType	minLength=1; maxLength=200	The contact email address. Example: "office@example.com"
16	[0:1]Contact [0:1]WebsiteURI	model:URIType	minLength=1; maxLength=200	The contact website. Example: "https://www.example.com"
17	[1:1]recoveryLaboratoryParty [1:1]OperatorInternalID	xs:long		A unique internal identifier for the waste operator.
18	[1:1]certificateOfWasteCompletion [1:1]completionDate	xs:date
19	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
20	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
21	[0:1]MassMeasure [1:1]tonnes	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
22	[0:1]VolumeMeasure [1:1]volume	Decimal25Fraction5Type	totalDigits=25; fractionDigits=5
23	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
24	[1:1]wasteDesignationCompositionDescription [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
25	[1:*]WasteTypeCode [0:1]@listID	model:WasteClassificationSchemeOrCountryIdentifierType	enum=BASEL, CUST, EWL, ...; minLength=1; pattern	The code specifying the waste list. Example: "EWL" for European Waste List. Note: Instead of referencing one of the enumerated waste lists such as European Waste List this can alternatively be set to a country code for a national waste classification.
26	[1:1]wasteClassification [1:*]WasteTypeCode	Token64OrEmpty	maxLength=64	The code specifying the type of waste, together with a listID or listName attribute specifying the waste list from which the code is taken. Example: "A 1050" for "Galvanic sludges" in combination with listID set to "BASEL" (Basel Annex VIII). Note: According to the second subparagraph, point 6 of Article 4 of the WSR, only one waste code is expected, with two exceptions (see also the chapeau of para. 25 in Annex IC WSR).
27	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
28	[0:1]additionalInformation [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
29	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

CreateAnnex7SignalTypeRequest

Nr	Leaf	Type	Facets	Documentation
1	[1:1]CreateAnnex7SignalTypeRequest [1:1]annexVIIDocumentNo	model:DocumentIdentifierType	minLength=1; maxLength=100
2	[1:1]signal [1:1]typeCode	notification:SignalStatementTypeCodeType	enum=ProperlyCarriedOut, ProperlyCompleted, NotificationInvalid, ...
3	[1:*]Description [0:1]@languageID	model:LanguageIdentifierType	minLength=1; pattern	The ISO 639-1 code of the language the textual description is provided in.
4	[0:1]description [1:*]Description	String1024	minLength=1; maxLength=1024	A textual description in a specific language, together with an ISO 639-1 language code in the languageID attribute.
5	[0:1]signature [1:1]name	model:String256	minLength=1; maxLength=256
6	[0:1]signature [1:1]organizationRole	xs:string
7	[0:1]signature [1:1]timestamp	xs:dateTime
8	[0:1]signature [0:1]emailURI	model:URIType	minLength=1; maxLength=200
9	[0:1]signature [0:1]signature	model:String256	minLength=1; maxLength=256
10	[0:1]linkedAttachments [0:*]attachmentIdentifier	model:Token	minLength=1

Definitions and References

Terms and Definitions

allow list

A mechanism which explicitly allows some identified entities to access a particular privilege that is denied by default

amber shipment of waste

A ⭧ shipment of waste which, according to the [WSR], requires prior written notification and consent

See also PIC, ⭧ green shipment of waste

asynchronous web service operation

A web service operation designed so that a client has to wait for results, and distinguishing (a) initiating processing and (b) delivery of ultimate results; See also ⭧ synchronous web service operation

business process

A set of activities a party (EO or CA) can execute to achieve a desired result in pursuit of a specified objective; Source: adapted from ISO 15704:2019(en)

carrier

A party that physically transports goods from one place to another; Source: GS1 XML glossary; See also: ⭧ economic operator

central system

a digital system for shipments of waste referred to in Article 27(3) of [Regulation (EU) 2024/1157] and operated by the Commission; Source: [DIWASS IR]

Note: Known in practice as [DIWASS], part of [TRACES.NT]

competent authority (CA)

Authority/authorities designated by a country to be responsible for receiving ⭧ waste shipment ⭧ notifications and any information related to it, and for responding to such a notification; Source: [BC] and [WSR]

consignee

The EO under the jurisdiction of the country of destination to whom waste is shipped for ⭧ recovery or ⭧ disposal; Source: adapted from [WSR]

consignment information

A paper document which, pursuant to Article 18 and Annex VII [WSR], accompanies each individual ⭧ green shipment of waste, and on which all undertakings involved add certain information. EOs provide the consignment information (or copies thereof) to CAs at certain occasions

See also ⭧ movement document, ⭧ notification

database

Collection of machine-readable information organized so that it can be easily accessed, managed and updated; Source: ISO 5127:2017(en) Information and documentation – Foundation and vocabulary

data format

Formal definition providing a precise specification of the structure and representation of data, allowing for accurate interpretation and manipulation by software systems and human users; Source: Adapted from ISO/TS 27790:2009(en)

See also: ⭧ message format

disposal of waste

A waste treatment operation which is not ⭧ recovery even where the operation has as a secondary consequence the reclamation of substances or energy; Examples: landfilling, incineration; Source: [WFD]

See also: ⭧ treatment of waste, ⭧ recovery

economic operator (EO)

Legal or natural person active on the market, i.e., offering the execution of work, the supply of products or the provision of services on the market; Source: EU Directive 2014/24 on public procurement

Note: Covers all parties involved in waste shipments except CAs ; for example ⭧ notifier, ⭧ carrier and ⭧ consignee

electronic data interchange (EDI)

Structured way of transmitting data held electronically from ⭧ database to ⭧ database, usually using telecommunications networks; Source: ISO/IEC/IEEE 24765:2017(en) Systems and software engineering – Vocabulary; See also: ⭧ message

facility

[BC] and [WSR] make frequent use of the term facility, in partcular waste recovery facility and waste disposal facility. Note that for reasons of harmonization and unambiguity this specification uses the terms waste treatment party and waste treatment site instead; See also: ⭧ treatment, ⭧ site, ⭧ economic operator

formal validation

Combination of the following:

1. 1. data validation rules defined in a formal language - a formal language is machine-readable and has clearly defined syntax and semantics
   2. automated validation of received ⭧ user messages for compliance with these validation rules, yielding a validation report

Example of a formal validation rule: the mass value must be greater than or equal to 0.0. Example for an expression of this rule in a formal language: MassValue ge 0.0

green shipment of waste

A ⭧ shipment of waste which, according to the [WSR], does not require prior written notification and consent

See also GLW, ⭧ amber shipment of waste

interim treatment of waste

An operation such as accumulation, temporary storage or repackaging applied prior to submission to a subsequent ⭧ treatment of waste; Source: adapted from [WSR]

local system

a system that is operated by a competent authority in accordance with Article 27(4) of Regulation (EU) 2024/1157 and that connects with the ⭧ central system through an API; Source: [DIWASS IR]

message

Collection of information sent through an information channel as a single logical entity; Source: adapted from ISO/IEC/IEEE 21451-7:2011(en) and ISO/TS 18234-6:2006(en)

See also: ⭧ electronic data interchange

message format

⭧ data format for ⭧ messages

movement document

A document which, pursuant to Article 16 [WSR], accompanies each individual ⭧ amber shipment of waste, and on which all undertakings involved add certain information. EOs provide the movement document contents to authorities at certain occasions

See also ⭧ consignment information, ⭧ notification

notification

Prior written notification by EOs to CAs about intended ⭧ amber shipments of waste, asking for consent, pursuant to Article 4 [WSR]

See also ⭧ movement document, ⭧ consignment information

polling

A client-server interaction pattern whereby a client periodically sends a request to a server in order to get to know whether or not there is something new and relevant to the client

production of waste

Activities that produce waste (original waste production) and/or carrying out pre-processing, mixing or other operations resulting in a change in the nature or composition of waste (new waste production); Source: Adapted from [WFD]

recovery of waste

An operation the principal result of which is waste serving a useful purpose by replacing other materials which would otherwise have been used to fulfil a particular function, or waste being prepared to fulfil that function, in the plant or in the wider economy; Source: [WFD]

See also: ⭧ treatment of waste, ⭧ disposal

shipment of waste

Transport of waste destined for ⭧ recovery or ⭧ disposal in another country; Source: [WSR]

See also ⭧ amber shipment of waste and ⭧ green shipment of waste

signal message

A ⭧ message with a supporting role in establishing ⭧ message exchange patterns, non-repudiation and reliability; Source: AS4

See also: ⭧ user message, ⭧ electronic data interchange

Note: Important contents of WasteX signal messages:

1. 1. information of whether or not a recipient software instance accepted or rejected a received ⭧ user message
   2. report resulting from the ⭧ formal validation of the received ⭧ user message conducted by the recipient software instance

site

A location of carrying out waste ⭧ treatment operations or of waste ⭧ production

software

any software other than the ⭧ central system or ⭧ local system, which is used for the purpose of submitting and exchanging information and documents referred to in Article 27(1) of Regulation (EU) 2024/1157 and that connects with the central system via an API; Source: [DIWASS IR]

synchronous web service operation

A web service operation designed to deliver results to the client immediately, without distinguishing (a) initiating processing and (b) delivery of ultimate results; See also ⭧ asynchronous web service operation

treatment of waste

⭧ Recovery or ⭧ disposal operations, including preparation prior to recovery or disposal; Source: [WFD]

user

A (natural) person who interacts with a system, product or service; Source: ISO 26800:2011 Ergonomics

user message

A ⭧ message that contains business payload to be exchanged between software instances; Source: adapted from AS4

See also: ⭧ signal message

Note: For WasteX EU the business payload is waste shipment related information, such as the waste mass

waste shipment

See ⭧ shipment of waste

web service

A service designed to support interoperable machine-to-machine interaction over a network; Source: ISO/IEC 19763-7:2015(en)

XSLT processor

A software (module/library/service) capable of applying [XSLT] transformations to [XML] instances. An XSLT processor takes one or more [XML] instances plus one or more [XSLT] stylesheets (transformations) as input and processes them to generate an output

Examples: [RaptorXML], [Saxon]

Acronyms

API

application programming interface

AT

Austria

B2A

business-to-administration

⭧ business processes and data interchanges with a participaton of both ⭧ EOs and ⭧ CAs

B2B

business-to-business

⭧ business processes and data interchanges with a participation of ⭧ EOs only, i.e., without participation of ⭧ CAs

BMLUK

Austrian Federal Ministry of Environment

Full title: Austrian Federal Ministry of Agriculture and Forestry, Climate and Environmental Protection, Regions and Water Management, https://www.bmluk.gv.at/en/

CA

⭧ competent authority (for shipments of waste, if not otherwise specified)

Note: In a few sections in this specification, CA stands for Canada. This is clear from the context

EC

European Commission, https://ec.europa.eu/

EC DG ENV

European Commission, Directorate-General for Environment, https://ec.europa.eu/info/departments/environment_en

EDI

⭧ electronic data interchange

EO

⭧ economic operator

EORI

see [EORI]

GLN

Global Location Number, an identification scheme by GS1

GLW

Green listed waste: Used to refer to shipments that fall under Chapter 2 of the [WSR], and to distinguish from PIC, which refers to shipments that fall under Chapter 1 of the [WSR]

GS1

GS1 global standards organization

A neutral, global collaboration platform that brings industry leaders, government, regulators, academia, and associations together to develop standards-based solutions to address the challenges of data exchange, https://www.gs1.org/

GUI

graphical user interface

IEC

International Electrotechnical Commission, an international standards organization that prepares and publishes international standards for all electrical, electronic and related technologies, https://www.iec.ch/

IETF

Internet Engineering Task Force, a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet, which develops and promotes voluntary Internet standards, https://www.ietf.org/

ISO

International Organization for Standardization, an international standard-setting body composed of representatives from various national standards organizations, https://www.iso.org/

MS

Member state of the European Union

OASIS

Organization for the Advancement of Structured Information Standards, a non-profit international standards body offering projects – including open source projects – a path to standardization and de jure approval for reference in international policy and procurement, https://www.oasis-open.org/

PIC

Prior informed consent, also known as Prior written notification and consent: Used to refer to shipments that fall under Chapter 1 of the [WSR], and to distinguish from GLW, which refers to shipments that fall under Chapter 2 of the [WSR]

RDBMS

Relational Database Management System

RFC

Request For Comments, publication by the IETF or associated bodies. Some RFCs evolve into Internet Standards

SVRL

[Schematron] Validation Report Language, a data format for expressing the results of [Schematron] validation

UN/CEFACT

United Nations Centre for Trade Facilitation and Electronic Business, an organization open to experts nominated by UN Member States and UN recognized organisations, and working on harmonizing, standardizing and automating the exchange of information, https://unece.org/trade/uncefact

W3C

World Wide Web Consortium, an international community that develops open standards to ensure the long-term growth of the web, https://www.w3.org/

WS

⭧ web service

References

AWG 2021

2021 Circular Economy amendment to the Austrian Federal Act on sustainable waste management (Abfallwirtschaftsgesetz). Contains an obligation for EOs to exchange waste shipment data as structured electronic data with the Austrian CA

Base64

The Base16, Base32, and Base64 Data Encodings, RFC 4648, IETF Internet Official Protocol Standards

BC

Basel Convention on the control of transboundary movements of hazardous wastes and their disposal

DIWASS

Digital Waste Shipment System, operated by the European Commission as part of [TRACES.NT] in accordance with the [WSR 2024/1157 ("new WSR")] and the [DIWASS Implementing Regulation 2025/1290]. 

DIWASS API

The European Commission makes many of the [DIWASS] and [TRACES.NT] functionalities available via API (web service), as an alternative to using the DIWASS GUI, both for CAs (⭧ local system) and EOs (⭧ software)

DIWASS IR

 [WSR 2024/1157] DIWASS Implementing Regulation 2025/1290

EDM

“Electronic Data Management”: An interconnected system of IT applications and databases supporting environment-related business processes, such as reporting under reporting obligations. Part of the Austrian e-Government services offered under https://www.usp.gv.at/en/index.html.
Note: The Austrian CA for shipments of waste uses EDM for managing waste shipment processes and data

eFTI

EU Regulation 2020/1056 on electronic freight transport information

EORI

Economic Operators' Registration and Identification. An EU-wide unique identification number for companies and individuals that import or export goods to or from non-EU countries. It is mandatory for customs declarations and serves to ensure security and efficient processing in international trade.

HMAC

Keyed-Hashing for Message Authentication, RFC 2104, IETF Internet Standard

HTML 5

Hypertext Markup Language, Web Hypertext Application Technology Working Group (WHATWG) and W3C Recommendation

HTTP/1.1

Hypertext Transfer Protocol, RFC 723x, IETF Internet Standard

IMSOC

Integrated Management System for Official Controls

This refers to:

1. 1. A concept to allow EU/EC systems and MS systems to exchange information and share features, laid down in EU Regulation 2017/625 and IMSOC Commission Implementing Regulation (EU) 2019/1715
   2. IT components and systems integrated following the IMSOC concept and IMSOC regulation

See also [TRACES.NT] and https://webgate.ec.europa.eu/tracesnt

JSON

A lightweight data-interchange format; ECMA standard

See also: [XML]

Latin-1

Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin alphabet No. 1; ISO/IEC 8859-1 standard

See also: [UTF-8]

RaptorXML

An [XML] and [JSON] validation and processing software by Altova. Its features include an [XSD] validator and an [XSLT] processor

Saxon

An open source [XSLT] and [XQuery] processor developed by Saxonica Limited

Schematron 2016

Information technology, Schema Definition Languages (DSDL), Part 3: Rule-based validation, ISO/IEC 19757-3 standard

See also [XSLT]

SchXslt 1.7.1

A [Schematron] processor implemented entirely in [XSLT]. It transforms a [Schematron] schema document into an [XSLT] stylesheet that you apply to the document(s) to be validated

SHA-256

US Secure Hash Algorithms (SHA and SHA-based [HMAC] and HKDF), RFC 6234 IETF Internet Standard

SOAP 1.2

Lightweight protocol intended for exchanging structured information in a decentralized, distributed environment, W3C Recommendation

SoapUI

API testing tool for validating REST and SOAP-based web services, by SmartBear Software, https://smartbear.com/

TLS 1.2, 1.3

Transport Layer Security (TLS) Protocol, RFC 5246 and RFC 8446, IETF Internet Standard

TRACES.NT

TRAde Control and Expert System, a web-based veterinarian certification tool used by the European Union for controlling the import and export of live animals and animal products

See also [IMSOC]

Unicode

Universal character encoding designed to support the worldwide interchange, processing, and display of the written texts of the diverse languages of the world, The Unicode Consortium

UTC

Coordinated Universal Time, Standard-frequency and time-signal emissions, Recommendation ITU-R TF.460-6, International Telecommunication Union

UTF-8

Variable-width Unicode encoding form that preserves ASCII transparency by making use of 8-bit code units, The Unicode Consortium

UUID

Universally Unique ID, RFC 4122 IETF Internet Standard

WasteX

[EDM] waste shipments web service for transmitting movement document contents according to Art. 15 and 16 [EU Waste Shipment Regulation 1013/2006] ("old WSR")

WFD

EU Waste Framework Directive 2008/98

WSDL 2.0

Web Services Description Language, an [XML] language for describing web services, W3C Recommendation

WSR 1013/2006 ("old" WSR)

EU Waste Shipment Regulation 1013/2006

WSR 2024/1157 ("new" WSR)

EU Waste Shipment Regulation 2024/1157

 WSS UsernameToken Profile 1.1

Web Services Security UserName Token Profile 1.1, OASIS Standard Specification

XML 1.0

Extensible Markup Language, W3C Recommendation

XPath 2.0

[XML] Path Language, W3C Recommendation

XQuery 2.0

[XML] Query Language, W3C Recommendation

XSD 1.0

[XML] Schema Definition Language, W3C Recommendation

XSLT 2.0

Extensible Stylesheet Language Transformations, W3C Recommendation

Specification history of changes

History of changes

Version	Date	Description / Changes
0.02	2026‑03‑29	Removed the XML DSig [XSD] file from the specification, as the specification does not use any of its contents Minor HTML documentation improvements
0.01	2026‑03‑27	Initial draft This version lacks: Formal validation rules applied to received content Description of Specific handling of transmitted content for GLW (Annex VII) In April 2026, the Austrian CA publishes an updated version of this specification that includes these contents.