WasteX EDI protocol v1.08
Annex to the Description
Federal Ministry for Climate Action, Environment, Energy, Mobility, Innovation and Technology (BMK)
Stubenbastei 5, 1010 Vienna, Austria
Files and folders of the specification package
Introduction on the static and dynamic usage of codelists
Codelists which the specification uses statically
Codelists which the specification uses dynamically
Web service operations (from wastex_webservice.wsdl)
Inputs and Outputs of the web service operations (from wastex_webservice_types.xsd)
Message formats (from wastex_message.xsd)
Formal validation rules (from wastex_formalvalidationrules.sch)
Specification history of changes
Detailed changes (diff) compared to version 1.07
WasteX v1.08 - simple EDI for waste shipments Copyright (C) 2023 Environment Agency Austria Commissioned by the Austrian Federal Ministry of Environment (BMK) Contact: edm-helpdesk@umweltbundesamt.at 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.
In this version of the specification package, the WasteX description consists of these two parts:
The main description in PDF format provides background information and explanations on numerous details, such as authentication and handling of outages.
This annex to the description contains detailed definitions of the web service operations and the [XML] formats. The specification authors have generated the majority of contents in this annex in an automated way, including from the annotated [WSDL] and [XSD] files contained in the specification package. Annotated [WSDL] and [XSD] files contain textual descriptions of the web service operations and data elements.
xml_example_msg/
Contains exactly one sample message for each of the types of messages defined in the specification package.
The sample messages follows these criteria:
xml_example_service_input_output/
Contains exactly one sample input and sample output for each operation of the packaging 3.0 web service. Also contains an example [SOAP] fault.
z_descr_img/
For the folders whose names begin with "z_", it is usually not useful to look through them individually. Rather, the description links to contents of these folders.
The folder z_descr_img contains the image files used in this [HTML] description.
z_val_a_xml_example_msg_base/; z_val_b_xml_example_msg_ruletest/; z_val_c_results/
The files in these folders relate to the formal validation rules. The specification package contains a specification of formal validation rules in Schematron file wastex_formalvalidationrules.sch. Section Formal validation rules (from wastex_formalvalidationrules.sch) describes the formal validation rules via example rule violations and contains links to the contents of these folders.
The folder z_val_a_xml_example_msg_base/ contains sample input for the formal validations. These are the sample messages from the folder xml_example_msg/, enriched with so-called ValidationContext. Software receiving a message reads data related to the message at its receiving end of the transmission, e.g. company master data, reference data, or data from previously transmitted messages. The software passes this data as ValidationContext to the formal validation. For the files contained in the folder z_val_a_xml_example_msg_base/, both message contents and ValidationContext contain fictitious data. The folder z_val_a_xml_example_msg_base/ contains sample input that satisfies all formal validation rules and thus does not trigger any validation report entries.
The folder z_val_a_xml_example_msg_ruletest/ also contains sample input for the formal validation rules. The specification authors have designed these sample files as modifications of the sample files from z_val_a_xml_example_msg_base/ to specifically trigger or not trigger certain formal validation rules.
The folder z_val_c_results/ contains the results of applying the formal validation rules defined in the Schematron file wastex_formalvalidationrules.sch to the [XML] sample files from the two folders z_val_a_xml_example_msg_base/ and z_val_a_xml_example_msg_ruletest/. The results are available in the Schematron Validation Report Language (SVRL) [XML] data format, as well as in a [HTML] representation. In section Formal validation rules (from wastex_formalvalidationrules.sch), this description provides an overview of the formal validation rules specified in Schematron file wastex_formalvalidationrules.sch by means of a compilation of validation results from z_val_c_results/.
svrl.xsd
Defines the Schematron Validation Report Language (SVRL) data format for formal validation reports in the formal language [XSD].
wastex_message.xsd and wastex_message_annot.xsdusesvrl.xsd, so they have a dependency on svrl.xsd. When copying the files wastex_message.xsd or wastex_message_annot.xsd, it is therefore necessary in most cases to also copy the file svrl.xsd into the target directory.
wastex_doc.pdf
The instructions for the correct application of the WasteX specification.
wastex_doc_annex.html
Annex to the interface description. Describes web service operations, inputs and outputs, message formats and formal validation rules in detail. The specification authors have created many of the contents of this description annex in an automated way, such as from the annotated WSDL and XSD files contained in the specification.
wastex_formalvalidationrules.sch
"Source code" of the formal validations rules defined for the WasteX EDI protocol in the formal language [Schematron].
The specification authors use [SchXslt] to create the wastex_formalvalidationrules.xsl file from this source text.
By providing this "source code", the formal validation rules that the WasteX web service applies to business-to-authority-transmissions are open and transparent. For example, IT staff working on a WasteX web service connection can search the Schematron source code of the formal validation rules for errors.
wastex_formalvalidationrules.xsl
XSLT instance with which a WasteX web service applies formal validation to received messages. For this purpose, the WasteX web service first enriches a received message with a ValidationContext - this is data read out on the web service (recipient) side - and applies the transformation wastex_formalvalidationrules.xsl to this "enriched message". This transformation provides the formal validation protocol in SVRL (Schematron Validation Report Languagee) format, which the WasteX web service delivers to the web service clients as part of signal messages.
The specification authors have generated wastex_formalvalidationrules.xsl automatically from the "Schematron source code" wastex_formalvalidationrules.sch via [SchXslt].
The WasteX web service applies the Schematron based formal validation to received messages only in the case that the received message and the web service operation input comply with the [XML] formats (XML Schema Definitions) defined in this specification - see wastex_message.xsd and wastex_webservice_types.xsd.
wastex_message.xsd; wastex_message_annot.xsd
Defines, via formal language [XSD], the [XML] message formats used in the WasteX EDI protocol. When receiving messages, a WasteX web service checks these messages - as part of the validation of operation inputs - for validity with respect to the message format defined by wastex_message.xsd. Such validity is a technical prerequisite for a WasteX web service to be able to process transmitted messages.
Conversely, software connected to a WasteX web service can rely on the validity of messages delivered by the web service in operation outputs with respect to the XML message formats defined via wastex_message.xsd, and can conduct XML Schema validation for ascertaining this validity.
wastex_message.xsd differs from wastex_message_annot.xsd only by omitting the annotations (description texts). The two files are therefore equivalent in content, i.e., they define the same set of valid XML data instances. The specification authors have generated the Message formats (from wastex_message.xsd) section of this description in an automated way from the file wastex_message_annot.xsd.
wastex_webservice_types.xsd; wastex_webservice_types_annot.xsd
Defines, via formal language [XSD], the [XML] formats for inputs and outputs of WasteX web service operations. Has a direct dependency on wastex_message.xsd, and thus also an indirect dependency on svrl.xsd.
The validity of operation inputs with respect to the XML formats defined in wastex_webservice_types.xsd is a technical prerequisite for a WasteX web service to successfully process a web service interaction.
Conversely, software connected to a WasteX web service can rely on the validity of web service operation outputs with respect to the XML formats defined in wastex_webservice_types.xsd, and can conduct XML Schema validation for ascertaining this validity.
wastex_webservice.wsdl; wastex_webservice_types_annot.xsd
Describes the operations of a WasteX web service and its inputs and outputs in the formal language [WSDL]. Uses wastex_webservice_types.xsd directly, and thus wastex_message.xsd and svrl.xsd indirectly.
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.
The following characterises the static use of codelists by this specification:
The following characterises the dynamic use of codelists by this specification:
The WasteX specification uses ↗codelist 3862, the list of countries, dynamically. This is because new countries can come into existence, and existing countries can vanish (such as when two countries unite into one new country) independent of any changes to the Waste Shipment Regulation or other waste shipment specific provisions. Hence software with waste shipment data exchange capabilities must be quickly and efficiently adaptable to new sets of countries.
Description of the web service operations defined by ↗wastex_webservice.wsdl. wastex_webservice.wsdl describes the web service operations with the standardised formal language ↗Web Services Description Language (WSDL) 2.0.
This description is auto-generated from ↗wastex_webservice_annot.wsdl. As an alternative to using this description it is therefore possible to use the annotated WSDL file directly, such as with a text editor.
The ShareMessage operation serves the following purposes:
Note 1: Web service clients may implement a unidirectional connection with edm.gv.at. Such clients do not share signal messages with edm.gv.at.
Note 2: The ShareMessage operation exhibits an ASYNCHRONOUS behaviour upon transmitting a USER MESSAGE. It exhibits a synchronous behaviour upon transmitting a signal message. When receiving a USER MESSAGE, the edm.gv.at WasteX web service reacts by sharing a signal message with the client. It is however not the ShareMessage output which contains the Signal Message. Instead, the web service client needs to poll the edm.gv.at WasteX web service for getting access to the Signal Message. The web service client polls using the QueryUpdate operation.
Example: It may take the edm.gv.at WasteX web service 7 minutes to create and disseminate a signal message in response to a received user message. If the web service client polls every 5 minutes, then it is only the second or third polling instance after disseminating the user message by which the web service client receives the corresponding signal message.
Note 3: The use of the ShareMessage operation for the transmission of corrections or additions is NOT different from the use for the initial transmission to the competent authority. The web service automatically interprets transmitted content as correction or addition, for example if all of message type, notification number and serial number correspond to those of an already submitted movement announcement.
Note 4: The use of the ShareMessage operation for the transmission of corrections or additions also does NOT differ from the use for the initial transmission in the sense that the operation expects COMPLETE messages. In the case of corrections and additions, web service clients must transmit complete messages contents, potentially including contents that have not changed since the previous transmission.
Port Type | WasteMovementServicePortType |
Input | The input of the ShareMessage operation essentially consists of the User Message (UserMessage element) with the contents to transmit to the authority or the signal message (SignalMessage element) to share with edm.gv.at. |
Output | The output of the ShareMessage operation is essentially empty. Upon sharing a user message, web service clients access the edm.gv.at WasteX web service's reaction by polling, using the QueryUpdate operation. Note: Even with regular processing of a ShareMessage user message sharing call, i.e., if the web service does NOT react with a SOAP fault but with ShareMessageResponse, it is possible that the transmission to the authority was NOT successful. An example for this is the case when the formal validation of the transmitted data leads to an automatic rejection. The SignalID value from the Signal Message indicates whether or not the transmission to the authority was successful (ACCEPTED for successful, REJECTED for unsuccessful). |
Fault | If an error occurs during the processing of the ShareMessage call, the web service responds with a SOAP 1.2 Fault. The web service may use one or more of the following fault elements defined in SOAP 1.2 to describe the error in more detail:
|
The InitSync operation translates a timestamp into an ID that the web service client can use as input to the first QueryUpdate call in a sequence of QueryUpdate calls.
Note: The InitSync operation is for the use on rare occasions, such as the initalisation or re-initialisation of polling. Once the web service client has initialised polling, it uses the QueryUpdate operation only, such as in 5 or 10 minute intervals. There the web service client uses the ID found in the output of one QueryUpdate call as input to the next QueryUpdate call.
Port Type | WasteMovementServicePortType |
Input | The input of the InitSync operation essentially consists of a timestamp. With this timestamp the web service client indicates its interest in polling all updates "newer" than the timestamp. |
Output | The output of the InitSync operation essentially consists of an update UUID that best matches the timestamp criterion from the InitSync input. The web service client typically uses this update UUID in the first of a sequence of QueryUpdate polling calls. |
Fault | If an error occurs during the processing of the InitSync call, the web service responds with a SOAP 1.2 Fault. The web service may use one or more of the following fault elements defined in SOAP 1.2 to describe the error in more detail:
|
Synchronise a client with updates available at the web service, i.e., poll for updates.
Note 1: The edm.gv.at WasteX web service handles access rights: Web service clients only get to know about selected updates, those which they are allowed to access. The web service determines access rights based on the following:
Note 2: See the web service description for permitted polling frequencies.
Port Type | WasteMovementServicePortType |
Input | The input of the QueryUpdate operation essentially consists of the UUID of the latest update already known to the web service client. Note: The web service client takes this UUID from the output of the most recent preceding QueryUpdate call(s), except upon (re-)initialising synchronisation, when it takes this UUID from the output of an InitSync call. |
Output | The output of the QueryUpdate operation essentially consists of an ordered list of updates, in ascending order by occurrence timestamp. Each update is either a User Message or a Signal Message. Note 1: If there are no updates available for the web service client at the edm.gv.at WasteX web service, then the QueryUpdate output contains 0 updates, i.e., no Update element. Note 2: If there are updates available, then the web service client uses the update UUID from the last (most recent) Update element contained in the QueryUpdate output as input to the subsequent QueryUpdate call. |
Fault | If an error occurs during the processing of the QueryUpdate call, the web service responds with a SOAP 1.2 Fault. The web service may use one or more of the following fault elements defined in SOAP 1.2 to describe the error in more detail:
|
Description of the data formats defined by the XML Schema Definition wastex_webservice_types.xsd. The description covers:
This description is auto-generated from wastex_webservice_types_annot.xsd. As an alternative to using this description it is therefore possible to use the annotated XSD file directly, e.g. with an XML Schema tool or a text editor.
FailureTypeIdentifierContentType
PredeterminedScopeReferenceIdentifierType
Input to the ShareMessage operation.
Name/Type | min..max | Definition |
---|---|---|
ClientInterfaceVersionID | 1..1 | AUTO Constant passed by the client to the web service, indicating the version of the web service specification implemented at client side. |
ClientVersionID | 1..1 | AUTO Version of the client software conducting the web service operation call. Note: This is solely for debugging purposes in cases of impaired operation. |
TransactionUUID | 1..1 | AUTO A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation generated by the web service client specifically for this web service operation call. Note 1: This serves as a reference, such as in signalling the reception status (backward sharing). Note 2: A new UUID is needed for each new operation call. This includes cases in which the call is effectively used for updating previously transmitted information, or for re-attempting a previously failed operation call. Note 3: If the client provides a UUID that has already been used before the operation call will typically fail (SOAP fault). The set of supported values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: 113f2554-3048-4306-9eb6-baa6d234f88f |
UserMessage | 0..1 | The message to be shared. Note 1: A user message is a message containing waste shipment related information shared by one party at one point in time, such as movement announcement or confirmation of waste receipt. Note 2: The purpose of sharing the respective message can be one of the following: 1. Initial sharing of information, i.e., sharing of information that has not yet been shared previously. 2. Update of information Example: In this example a movement announcement for a particular combination of notification number and sequential number is shared two times: 1. The first time, in this example 8 days prior to the planned shipment start date, for actually announcing the shipment to competent authorities and the consignee. 2. Later on a second time, in this example 4 days prior to the planned shipment start date, in order to add or correct information compared to the initially transmitted announcement. |
SignalMessage | 0..1 | The message to be shared. Note: A signal message is an EDI node's automatically generated reaction to receiving a user message. It could for example be an acknowledgement of receiving the message. |
ShareMessageRequestType usage occurrences: 🠖ShareMessage
Output of the ShareMessage operation.
Note: The ShareMessage operation works asnychronously. As a result, clients do not receive status information on a ShareMessage call in the response to that call. Instead, the client gets status information either as response to the QueryUpdate (polling) operation, or as SOAP fault information.
Name/Type | min..max | Definition |
---|---|---|
ServiceInterfaceVersionID | 1..1 | Constant passed by the web service to the client, indicating the version of the web service specification implemented at web service side. |
ServiceVersionID | 1..1 | Version of the web service instance software. Note: This is solely for debugging purposes in cases of impaired operation. |
ShareMessageResponseType usage occurrences: 🠖ShareMessage
InitSyncRequestType
Input to the InitSync operation.
Name/Type | min..max | Definition |
---|---|---|
ClientInterfaceVersionID | 1..1 | Constant passed by the client to the web service, indicating the version of the web service specification implemented at client side. |
ClientVersionID | 1..1 | Version of the client software conducting the web service operation call. Note: This is solely for debugging purposes in cases of impaired operation. |
StartFromUTCTimestamp | 1..1 | A UTC timestamp indicating the reference point in time for updates to query from the web service, for querying updates "newer" than indicated by the timestamp. Note: EDI web service nodes following this specification are NOT required to keep updates for more than 7 weeks. Older updates may not be available anymore. Setting the timestamp further in the past may not yield additional updates. |
InitSyncRequestType usage occurrences: 🠖InitSync
InitSyncResponseType
Output of the InitSync operation.
Name/Type | min..max | Definition |
---|---|---|
ServiceInterfaceVersionID | 1..1 | Constant passed by the web service to the client, indicating the version of the web service specification implemented at web service side. |
ServiceVersionID | 1..1 | Version of the web service instance software. Note: This is solely for debugging purposes in cases of impaired operation. |
UpdateUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) used by the web service for the appropriate update given the UTC timestamp in the InitSync input. This UUID is meant to be used as initial input in a new sequence of QueryUpdate calls. Example value: da626250-f25c-44eb-9928-c48ff7608450 |
InitSyncResponseType usage occurrences: 🠖InitSync
QueryUpdateRequestType
Input to the QueryUpdate operation.
Name/Type | min..max | Definition |
---|---|---|
ClientInterfaceVersionID | 1..1 | Constant passed by the client to the web service, indicating the version of the web service specification implemented at client side. |
ClientVersionID | 1..1 | Version of the client software conducting the web service operation call. Note: This is solely for debugging purposes in cases of impaired operation. |
UpdateRangeStartUUID | 1..1 | The lower bound (exclusive) of the ID range of updates to be queried. Note 1: In the regular case this must be the transaction UUID of the latest update known to the client from a previous QueryUpdate operation call. In the special re-sync or init-sync case this must be a transaction UUID retrieved by a InitSync call. The update with that transaction UUID will NOT be included in the response to the QueryUpdate operation call. Note 2: Web services following this specification are NOT required to keep updates for more than 7 weeks. Older updates may not be available anymore. Example value: da626250-f25c-44eb-9928-c48ff7608450 |
QueryUpdateRequestType usage occurrences: 🠖QueryUpdate
QueryUpdateResponseType
Output of the QueryUpdate operation.
Name/Type | min..max | Definition |
---|---|---|
ServiceInterfaceVersionID | 1..1 | Constant passed by the web service to the client, indicating the version of the web service specification implemented at web service side. |
ServiceVersionID | 1..1 | Version of the web service instance software. Note: This is solely for debugging purposes in cases of impaired operation. |
AdditionalUpdatesIndicator | 1..1 | An indication of whether or not updates in addition to those contained in this response are immediately available from the web service. 'true' means that additional updates are immediately available. Note: This is meant to be used to keep the byte size of the response to each QueryUpdate call reasonably low. In this specification, the web service is meant to deliver a maximum of 256 updates at once. |
Update | 0..256 | One or more updates the web service delivers to the web service client. A single update is one of the following: 1. User message, such as confirmation of waste receipt 2. Signal message, i.e., i.e., an EDI node's automatically generated reaction - such as acknowledgement - to receiving a user message Note 1: The web service informs the client only about those updates to which the client / database instance is allowed to have access. See the specification PDF. Note 2: The order of Update elements in the QueryUpdate response reflects the chronological order. |
QueryUpdateResponseType usage occurrences: 🠖QueryUpdate
FailureResponseType
Information on an exceptional error that occurred during the processing of an operation call and led to terminating/aborting the processing.
Note: This information is meant to be used in testing and debugging, and is not meant to be displayed to common users.
Name/Type | min..max | Definition |
---|---|---|
FailureTypeID | 0..1 | The type of failure. |
FailureResponseType usage occurrences: 🠖InitSync, 🠖QueryUpdate, 🠖ShareMessage
SignalMessageType
A signal message, i.e., an EDI node's automatically generated reaction to receiving a user message.
Note: When the EDI works as expected, then this message serves as an acknowledgement of receipt. Both upon successful receipt of a message as well as upon the rejection of a message, a signal message can contain validation report information meant to be displayed to users.
Name/Type | min..max | Definition |
---|---|---|
wxm:WasteMovementSignalMessage | 1..1 | Results of the validation of a waste shipment user message at a receiving EDI node. |
SignalMessageType usage occurrences: ShareMessageRequestType, UpdateEventType
UpdateEventType
Information on an event, such as new messages being available from the web service.
Name/Type | min..max | Definition |
---|---|---|
UpdateUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) used by the web service for this update. Note 1: The order of Update elements in the QueryUpdate response reflects the chronological order of updates. If there are updates available to a web service client in a call to the QueryUpdate operation, then the number of Update elements contained in the response is greater than or equal to 1, and the web service client uses the UpdateUUID of the LAST Update element contained in the response as input to the UpdateRangeStartUUID element in subsequent calls of the QueryUpdate operation. Note 2: For updates initiated by a client to this web service, such as through a ShareMessage call, the UUID used by the web service for the update is the transaction UUID passed by the client to the web service. Example value: 71ffe8e5-5978-482a-9558-f262397783ef |
UpdateUTCTimestamp | 1..1 | A UTC time stamp created by the web service and assigned to this update. |
UserMessage | 0..1 | A message containing waste shipment related information shared by one party at one point in time, such as a movement announcement or a confirmation of waste receipt. |
SignalMessage | 0..1 | An EDI node's automatically generated reaction to receiving a user message. Examples:
|
UpdateEventType usage occurrences: QueryUpdateResponseType
UserMessageType
A user message, i.e., waste shipment related information shared by one party at one point in time, such as a movement announcement.
Name/Type | min..max | Definition |
---|---|---|
wxm:WasteMovementUserMessage | 1..1 | The user message, i.e., waste shipment related information shared by one party at one point in time, such as movement announcement or confirmation of waste receipt. |
UserMessageType usage occurrences: ShareMessageRequestType, UpdateEventType
FailureTypeIdentifierContentType
Name/Type | min..max | Definition |
---|---|---|
FailureTypeIdentifierContentType xs:token | 1..1 | Enumeration of failure types. The set of supported values:
|
FailureTypeIdentifierContentType usage occurrences: FailureResponseType
IndicatorContentType
Name/Type | min..max | Definition |
---|---|---|
IndicatorContentType xs:boolean | 1..1 | Yes/No value (Yes: property applies; No: property does not apply). |
IndicatorContentType usage occurrences: QueryUpdateResponseType
PredeterminedScopeReferenceIdentifierType
Name/Type | min..max | Definition |
---|---|---|
PredeterminedScopeReferenceIdentifierType | 1..1 | Reference with an identifier from an identification scheme that is predetermined and therefore not explicitely contained in the data. |
PredeterminedScopeReferenceIdentifierType usage occurrences: InitSyncRequestType, InitSyncResponseType, QueryUpdateRequestType, QueryUpdateResponseType, ShareMessageRequestType, ShareMessageResponseType
Token64Type
Name/Type | min..max | Definition |
---|---|---|
Token64Type xs:token | 1..1 | String consisting of a maximum of 64 characters and a minimum of 1 character, which does not contain carriage return (#xD), line feed (#xA) or tab (#x9), does not begin or end with a space, and does not contain two or more consecutive spaces. |
Token64Type usage occurrences: PredeterminedScopeReferenceIdentifierType
UUIDIdentifierContentType
Name/Type | min..max | Definition |
---|---|---|
UUIDIdentifierContentType xs:string | 1..1 | A Universally Unique Identifier (UUID) in canonical representation. The set of supported values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: aeca8c2d-523a-431a-812e-abd8a2475722 |
UUIDIdentifierContentType usage occurrences: QueryUpdateRequestType, ShareMessageRequestType, UpdateEventType
VersionIdentifierType
Name/Type | min..max | Definition |
---|---|---|
VersionIdentifierType xs:token | 1..1 | Version information. The following properties must apply:
|
VersionIdentifierType usage occurrences: InitSyncRequestType, InitSyncResponseType, QueryUpdateRequestType, QueryUpdateResponseType, ShareMessageRequestType, ShareMessageResponseType
Description of the data formats defined by the XML Schema Definition wastex_message.xsd. The description covers:
This description is auto-generated from wastex_message_annot.xsd. As an alternative to using this description it is therefore possible to use the annotated XSD file directly, e.g. with an XML Schema tool or a text editor.
DatabaseInstancePartyCollection
LatestConfirmationOfWasteReceipt
LatestConfirmationOfWasteTreatment
ValidationNodeAggregatedChangeData
ValidationNodeAggregatedContentData
VolumeValueAssignmentStatement
CountryTwoLetterIdentifierContent
EconomicOperatorRegisterIdentifierContent
MovementAnnouncementStatusIdentifierContent
MovementAnnouncementUpdateStatusIdentifierContent
PartyRegisterIdentifierContent
QuantificationTypeIdentifierContent
TransportModeIdentifierContent
TreatmentScopeIdentifierContent
UserMessageTypeIdentifierContent
ValidationResultIdentifierContent
WasteMovementUserMessage
Waste shipment related information provided by one party at one point in time.
This can be either:
Note: With the Austrian EDM WasteX interface, the Austrian Competent Authority for shipments of waste cannot currently accept/access carrier confirmations. See validation 🠖R725. Sharing carrier confirmations by EDI with the Austrian competent authority will be enabled in future revisions of the EDM WasteX interface.
Name/Type | min..max | Definition |
---|---|---|
MessageUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation assigned to this particular message instance by the software upon the message creation (marshalling). Note 1: This element is mainly for debugging purposes. Note 2: The WasteX EDI protocol does NOT expect or require software to implement message receipt related logic based on the message UUID. Note 3: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »7870d594-fbb4-49c3-ac23-39a5cf82df80« |
MessageCreationUTCTimestamp | 1..1 | A UTC timestamp indicating the point in time when software generated (marshalled) this message XML instance. Note 1: This element is mainly for debugging purposes. Note 2: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. Note 3: This message element is subject to WasteX formal validation. For example, validation 🠖R114 automatically rejects a received user message if the message creation timestamp lies in the future. Supported lexical representations and values:
Example value: »2022-10-25T11:01:35.524380Z« |
MessageCreationDataFormatVersionID | 1..1 | Identification of the WasteX data format version with which the message creation software's message creation implementation complies. Note 1: Software with a role in WasteX EDI must not let regular users edit this information. Note 2: In "forwarding" scenarios (information dissemination over multiple data interchange nodes) this information must remain unchanged. Note 3: This is a static value written by the message creation software. It is NOT an indication of whether or not the specific message actually uses "new" message format features, such as "new" message elements. Example: For the software creating the user message, the implementation of the user message creation complies with v1.04 of the data format specification. The user message therefore contains a MessageCreationDataFormatVersionID value of 1.04. The particular user message MAY however, by coincidence, comply with lower versions of the data format, such as 1.02, as the user message may not use any of the data elements and values introduced with newer versions of the format. Note 4: See the data format description PDF document for more information on the handling of data format versions and version transformations. Supported lexical representations and values:
Example value: »1.01« |
MessageTransformationDataFormatVersionID | 0..1 | Identification of the WasteX data format version to which the original message was converted in the electronic data interchange. Note 1: Software with a role in WasteX EDI must not let regular users edit this information. Note 2: Software must newly include this element in a generated user message if and only it applies a version transformation. Note 3: Software with a role in WasteX EDI applies version transformation if and only if the recipient node in a data interchange does not support the version of the data format in which the message is available at the sender node, but supports a lower version only. Consequently, for each user message that features a MessageTransformationDataFormatVersionID, the MessageTransformationDataFormatVersionID must be lower than the MessageCreationDataFormatVersionID. Note 4: See the data format description PDF document for more information on the handling of data format versions and version transformations. Supported lexical representations and values:
Example value: »1.00« |
MessageCreationPartyID | 1..1 | Identification of the party that assembles/administrates/fills in the waste shipment information contained in the message. Note 1: In "forwarding" scenarios (information dissemination over multiple data interchange nodes), this information must remain unchanged. Note 2: In the forwarding of information, the message sender is different from the message creator. Note 3: The WSR defines who has to provide which information to whom at which point in the processes. Note 4: A party may instruct someone else to prepare and send the information for him. For example, a provider of waste shipment related services may prepare and send the movement announcement for the notifier. In this example the service provider acts on behalf of the notifier (represents the notifier). In such a case of representation, it is always the INFORMATION ON THE REPRESENTED PARTY (in the example: the notifier) that is expected in the data element, and NEVER information on the representative. Note 5: It is a sender side responsibility to ascertain that the party identified as message creator has actually created the message. See the interface description PDF for more details. Note 6: In the representation case described in note 4, it is also a sender side responsibility to ascertain that the represented party has authorized the representing party with its representation. Note 7: In user interfaces users typically must not be able to edit this information. It is information derived from aspects such as the following: The authenticated user (natural person), whom the authenticated user is authorized to represent, and whom the authenticated user actually represents. Note 8: This message element is subject to WasteX formal validation. For example, validation 🠖R279, 🠖R497 and 🠖R967 automatically reject a received user message if the message creation party does not match one of the parties with the respective role, such as notifier, carrier or waste treatment party, identified within the message and/or identified in the notification data at the validating EDI node. Supported lexical representations and values:
Example value: »9110015228588« in combination with @registerID attribute »GLN.AT« for the identification of company »Remondis Austria GmbH« |
MovementAnnouncement | 0..1 | Announcement of an individual shipment of waste, in accordance with Article 16(b) of the WSR ("prior information regarding actual start of shipment"). |
MovementAnnouncementStatus | 0..1 | Status of the announcement of an individual shipment of waste, in accordance with Article 16(b) of the WSR ("prior information regarding actual start of shipment"). With a MovementAnnouncementStatus message, a party (notifier) informs about the CANCELLATION of a previously announced shipment of waste. |
CarrierConfirmation | 0..1 | Carrier's confirmation of taking charge of a shipment of waste, in accordance with Article 16 of the WSR, as well as Annex IB block 8 and Annex IC paragraphs 6 and 32. |
ConfirmationOfWasteReceipt | 0..1 | Confirmation of the receipt of an individual shipment of waste, in accordance with Article 16(d) or Article 15(c) of the WSR. |
ConfirmationOfWasteTreatment | 0..1 | Confirmation of the completion of the treatment of an individual shipment of waste, in accordance with Article 16(e), Article 15(e) or Article 15(d) of the WSR. Note: The WasteX protocol does NOT support the exchange of information on the completion of the treatment of waste at INDIVDUAL subsequent treatment facilities. |
InformationFromVersionTransformationText | 0..1 | Textual content generated by software in the translation of a data instance compliant with a higher version of the data format to a data instance compliant with a lower version of the data format. Note 1: Software with a role in WasteX EDI must not let regular users edit this information. Note 2: This can contain codified information, such as recovery disposal codes, textual information automatically created from codified information (in English), or the reproduction of textual information (in the natural language that has been used for the textual information). Therefore this element can contain a mix of natural languages. Fictitious example: If in v1.81 of the data format there is a new data element TreatmentTypeID which v1.80 of the data format did not contain, then the translation of a data instance from version 1.81 of the data format to version 1.80 of the data format removes the TreatmentTypeID element, but writes textual information on the treatment in the InformationFromVersionTransformationText data element. Note 3: Software newly fills this element if and only if it conducts a version transformation whereby information would get lost without inclusion in InformationFromVersionTransformationText. Note 4: See the data format description PDF document for more information on the handling of data format versions and version transformations. Supported lexical representations and values:
Example value: »Treatment type (TreatmentTypeID): Regeneration of acids or bases (R6)« |
WasteMovementUserMessage usage occurrences: MessageValidationContext, 🠖UserMessageType
WasteMovementSignalMessage
Information related to the processing and validation of a WasteMovementUserMessage at an electronic data interchange (EDI) node.
Note: It is software that automatically generates ALL the contents in a waste movement signal message. There is no direct involvement of users in the generation of a waste movement signal message.
Name/Type | min..max | Definition |
---|---|---|
SignalMessageUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation assigned to this particular message instance by the software upon the message creation (marshalling). Note 1: This element is mainly for debugging purposes. Note 2: The WasteX EDI protocol does NOT expect or require software to implement any message receipt related logic based on the message UUID. Note 3: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »2987137d-5379-4f2b-950c-1f4387fddfdd« |
SignalMessageCreationUTCTimestamp | 1..1 | A UTC timestamp indicating the point in time when software generated (marshalled) this signal message XML instance. Note 1: This element is mainly for debugging purposes. Note 2: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. Supported lexical representations and values:
Example value: »2022-10-25T11:01:35.524380Z« |
ValidationNodeName | 1..1 | A short name by which the node that conducted the validation of a waste movement message is known to users. Note: This name should be the same as the one that occurs in validation report texts for referring to the node conducting the validation (see also MessageValidationContext/ValidationNodeName in the validation context data format). Supported lexical representations and values:
Example values:
|
SignalMessageCreationDataFormatVersionID | 1..1 | Identification of the WasteX data format version with which the message creation software's signal message creation implementation complies. Note 1: Software with a role in WasteX EDI must not let regular users edit this information. Note 2: In "forwarding" scenarios (information dissemination over multiple data interchange nodes) this information must remain unchanged. Note 3: This is a static value written by the message creation software. It is NOT an indication of whether or not the specific message actually uses "new" message format features, such as "new" message elements. Example: For the software creating the signal message, the implementation of the signal message creation complies with v1.04 of the data format specification. The message therefore contains a SignalMessageCreationDataFormatVersionID value of 1.04. The particular message MAY however, by coincidence, comply with lower versions of the data format, such as 1.02, as the signal message may not use any of the data elements and values introduced with newer versions of the format. Note 4: See the data format description PDF document for more information on the handling of data format versions and version transformations. Supported lexical representations and values:
Example value: »1.01« |
SignalMessageTransformationDataFormatVersionID | 0..1 | Identification of the data format version to which the original message was converted in the electronic data interchange. Note 1: Software with a role in WasteX EDI must not let regular users edit this information. Note 2: Software must newly include this element in a generated signal message if and only it applies a version transformation. Note 3: Software with a role in WasteX EDI applies version transformation if and only if the recipient node in a data interchange does not support the version of the data format in which the message is available at the sender node, but supports a lower version only. Consequently, for each signal message that features a SignalMessageTransformationDataFormatVersionID, the SignalMessageTransformationDataFormatVersionID must be lower than the SignalMessageCreationDataFormatVersionID. Note 4: See the data format description PDF document for more information on the handling of data format versions and version transformations. Supported lexical representations and values:
Example value: »1.00« |
ReferredAnnouncementIdentity | 1..1 | The announcement identity referred to in the validated waste movement user message. Note: The EDI node conducting the formal validation copies the announcement identity (notification number and serial number) contained in the validated waste movement user message to this element of the signal message. |
ReferredUserMessageUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation which refers to the waste movement user message to which this validation result applies. Note: The EDI node conducting the formal validation copies the message UUID contained in the validated waste movement user message, originally assigned by the software that created the waste movement user message, to this element of the signal message. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »7870d594-fbb4-49c3-ac23-39a5cf82df80« |
ReferredUserMessageTypeID | 1..1 | The type of the validated waste movement user message. Note: The EDI node conducting the formal validation fills this element based on which of the MovementAnnouncement, MovementAnnouncementStatus, CarrierConfirmation, ConfirmationOfWasteReceipt or ConfirmationOfWasteTreatment elements is used in the validated waste movement user message. The set of supported lexical representations and values:
|
ReferredTransactionUUID | 0..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation which refers to the transaction that triggered the waste movement user message validation. Note 1: The EDI node conducting the formal validation copies the transaction UUID from the transaction by which it received the validated waste movement user message. Note 2: The WasteX message format is designed to be reusable across different EDI protocols. Whether or not there are transaction UUIDs used for the transaction of WasteX waste movement user messages depends on the type of EDI protocol used for the exchange of the messages. For example, in an extremely basic usage of the messages they could be transferred by email. In that case there wouldn't be any transaction UUID to which the signal message could refer. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »113f2554-3048-4306-9eb6-baa6d234f88f« |
SignalID | 1..1 | The overall result of receiving a user message at an EDI node. The set of supported lexical representations and values:
Note 1: In the »REJECTED« case, for users on the receiving side of the user message transmission it is as if the transmission never happened. Consequently, in this case the sending side needs to initiate any potential further actions. Note 2: An exception occurring at the EDI node receiving a user message MAY be the cause for the »REJECTED« case. |
ReceiverFailureIndicator | 0..1 | The indication of whether or not the rejection of the received user message is caused by the EDI node receiving the user message. Note 1: A signal message MUST contain a ReceiverFailureIndicator if the SignalID is set to »REJECTED«. It MUST NOT contain a ReceiverFailureIndicator in other cases. Note 2: With a ReceiverFailureIndicator set to »true«, an EDI node receiving a user message attributes rejection to the receiver side. Example: Rejection caused by the unavailability of a database or service at the receiving EDI node. A signal message with a ReceiverFailureIndicator set to »true« is comparable with a SOAP 1.2 Fault with a Fault/Code set to value »soap12:Receiver«. With a ReceiverFailureIndicator set to »false«, an EDI node receiving a user message attributes rejection to the receiver side. stands for an automated message rejection that the receiving EDI node attributes to the receiver side, indicating that it occurs independent of the sender, including independent of a sent messages's contents. An example for a rejection reason attributed to the receiver side is a rejection caused by the unavailability of a database or service at the receiving EDI node. Note 3: With a ReceiverFailureIndicator set to »false«, an EDI node receiving a user message attributes rejection to the sender side. Example: Rejection caused by unacceptable content contained in the transmitted message, such as negative mass values or message contents that contradict each other (inconsistencies). Note 4: Part of formal validation is consistency checks between contents of transmitted messages and contents of receiver side databases. Important potential causes of such inconsistencies: (a) contents of the transmitted message, (b) contents of a receiver side database, or (c) a combination of the two. In most cases software will need to leave it to users to figure out which of these causes applies. Not least for this reason, the purpose of ReceiverFailureIndicator value is providing LIKELIHOOD information with regard to the need of involving the receiver side, guiding the sender side with regard to dealing with transmission issues:
The set of supported lexical representations and values:
|
SignalDescription | 0..1 | A natural language description of the signal. Note 1: This element is for natural language content NOT resulting from formal message validation, as the latter is contained in the element MessageFormalValidationReport. Note 2: Like the natural language texts in MessageFormalValidationReport, any such SignalDescription text is meant to be displayed to users. Supported lexical representations and values:
Example value: »Internal error at edm.gv.at, contact IT support« |
MessageFormalValidationResultID | 0..1 | The overall result from a formal validation of a WasteX waste movement user message by a receiving EDI node (see also EUDIN ↗codelist 6099). The set of supported lexical representations and values:
Note 1: If the signal is rejection of the user message, and if the rejection is NOT caused by the formal validation, then there MUST NOT be a MessageFormalValidationResultID element in the signal message. Note 2: On the combination of INFO, WARNING and ERROR elements in the validation report entries (MessageFormalValidationReport element) and the resulting overall result (MessageFormalValidationResultID):
Note 3: A message validation ERROR status leads to the rejection of a received message. A message validation ERROR status in element MessageFormalValidationResultID can therefore only occur in combination with content REJECTED in element SignalID. Note 4: The opposite implication of Note 3 does NOT apply. A rejection may occur for other reasons than an ERROR resulting from formal user message validation, such as the database not being available. Therefore REJECTED values in SignalID can occur WITHOUT an ERROR value in MessageFormalValidationResultID. |
MessageFormalValidationReport | 0..1 | The detailed validation results in Schematron Validation Report Language (SVRL) format. Note 1: If the signal is rejection of the user message, and if the rejection is NOT caused by the formal validation, then there MUST NOT be a MessageFormalValidationReport element in the signal message. Note 2: The WasteX specification recommends XSLT processing - using the WasteX formal validation XSLT - for implementing message validation at EDI nodes. EDI nodes MAY however implement formal validation in a different way. Independent of the way of implementing formal validation, EDI nodes MUST represent validation results in SVRL format for WasteX EDI. |
WasteMovementSignalMessage usage occurrences: 🠖SignalMessageType
MessageValidationContext
A WasteX message together with contextual information, such as from the notification, used as basis for formal validation of the WasteX message.
Note 1: The WasteX EDI protocol does NOT use this structure, i.e., this structure does NOT occur in the inputs and outputs of a WasteX web service. Accordingly, this structure does not play a direct role for the implementation of a connection to a WasteX web service. It does however play a role in the implementation of formal validation at a WasteX EDI node.
Note 2: A WasteX EDI node fills a validation context XML structure in preparation for formal validation of a received WasteX user message. A WasteX EDI node fills the first element in the MessageValidationContext XML structure, WasteMovementUserMessage, with the received user message. It fills the other elements with data from other sources, such as constants or configuration information (e.g. ValidationNodeProtocolVersionID) or data from a database at the validating EDI node (e.g. ValidationNodeIndividualData).
Note 3: The following is a general principle for the MessageValidationContext XML structure and formal validation based on MessageValidationContext instances. It applies to all non-repeatable elements from the validation context other than elements from the received WasteX user message, i.e., other than sub-elements of WasteMovementUserMessage. The principle is that formal validation uses the available elements and "ignores" missing elements. This means that formal validation is "tolerant" with respect to content missing from the validation context. It is "tolerant" in the sense that formal validation rules which depend on a specific valdiation context element do not trigger if the validation context instance does not contain this respective element. The main aim of this "tolerant" and "graceful" behaviour is simplifying the implementation and testing of formal validation in EDI nodes. It makes it possible to implement the generation of validation context data step by step, element by element, and to verify the correct functioning of formal validation at each of these steps - the principle assures that formal validation reports only contain meaningful content in each of these steps.
Note 4: For the implementation of generating a MessageValidationContext instance it is important to note that validating EDI nodes must fill certain validation context elements dependent on contents from the received WasteX user message. For example, an EDI node must fill the elements NotificationInDatabaseIndicator and Notification under ValidationNodeIndividualData with data based on notification/consent information available at the validating EDI node's database FOR A SPECIFIC NOTIFICATION, namely the notification the received user message references in element AnnouncementIdentity/NotificationID. The definition texts for the validation context elements explain any such interdependencies in detail.
Note 5: Several of the definition texts for validation context elements contain Pseudo-SQL statements. These Pseudo-SQL statements illustrate how an EDI node may access the data needed for filling the respective validation context element. Actual query expressions used in WasteX EDI node implementations depend on the technological means and the database model used at the EDI node. Notation in Pseudo-SQL statements:
Name/Type | min..max | Definition |
---|---|---|
WasteMovementUserMessage | 1..1 | A WasteX user message that the validating EDI node includes in the validation context XML instance for subsequently applying WasteX formal validation on the message. Note: It is a prerequisite for applying WasteX formal validation to a WasteX user message that the user message is valid with respect to the WasteX XML Schema Definition (XSD). EDI nodes MUST NOT apply WasteX formal validation (XSL transformation of a validation context XML instance) to user messages that are not valid with respect to the WasteX XML Schema Definition. Applying WasteX formal validation (XSL transformation of a validation context XML instance) to a WasteX user message which violates the WasteX Schema Definition yields undefined behaviour and results. |
InteractingEDINodeID | 0..1 | The ID of the 'external' EDI node out of whose interaction with the validating EDI node the WasteX user message included in the WasteMovementUserMessage element originates. Note: For the WasteX "Basic" EDI protocol, the validating EDI node must fill this with the ID part (first part) from the credentials content contained in authentication related HTTP headers. Supported lexical representations and values:
Example value: »AXIANS.CLOUD« |
EDIInteractionUTCTimestamp | 0..1 | A UTC timestamp generated by the validating EDI node for the point in time of receiving the shared user message (contained in the validation context in the WasteMovementUserMessage element). Supported lexical representations and values:
Example value: »2022-10-25T11:03:51.821450Z« |
ValidationNodeName | 0..1 | A short name users know/recognize the EDI node that prepares and conducts the formal validation of a WasteX user message. Note: This name is used in validation report texts for referring to the node conducting the validation, and therefore for giving users an idea on the origin of validation report content. Supported lexical representations and values:
Example values:
|
ValidationNodeProtocolVersionID | 0..1 | The version of the WasteX (Basic) protocol that the validating EDI node implements. Supported lexical representations and values:
Example value: »1.01« |
ValidationNodeIndividualData | 0..1 | Individual records of data available in the database at the EDI node prior to receiving a WasteX message and related to that message, i.e., related to the notification number and serial number contained in the message. Examples:
|
ValidationNodeAggregatedContentData | 0..1 | An aggregation of RECORD CONTENTS available at the EDI node database prior to the receipt of the new message (contained in the validation context), for records related to the newly received message, such as by referring to the same consent. Note 1: "Record" refers to database records on movement announcements, confirmations of waste receipt, and the like. Note 2: Unless specified differently for the individual data element, the aggeragtion must take into account ALL records matching the specified criteria, including records unrelated to WasteX EDI, such as records created via a GUI entry. |
ValidationNodeAggregatedChangeData | 0..1 | An aggregation of record CHANGES that occurred at the EDI node database prior to the receipt of the new message (contained in the validation context), for records related to newly received message, such as records referring to the same notification number, serial number and content type. Note 1: "Record" refers to database records on movement announcements, confirmations of waste receipt, and the like. Note 2: In order for an EDI node to be capable of aggregating record change information, it must - in the absence of other solutions - keep a log on record entries and updates. Aggregating record change information does however NOT depend on the archiving of records/contents, such as the archiving of the original movement announcements contents when there is an update/correction of the movement announcement. Note 3: Unless specified differently for the individual data element, the aggeragtion must take into account ALL record changes matching the specified criteria, including changes unrelated to WasteX EDI, such as changes via a GUI. |
ValidationNodeReferenceData | 0..1 | Reference data used at the EDI node receiving a WasteX message and conducting the validation. Example:
|
DatabaseInstancePartyCollection
Identification of parties which use a specific registered database instances.
Note: This is intended to be used as an "allow list" for EDI. Operators of EDI node A send such a list to operators of another EDI node B, so that EDI node B can accept EDI node A to "represent" certain parties.
Name/Type | min..max | Definition |
---|---|---|
DatabaseInstancePartyList | 1..4096 | Each DatabaseInstancePartyList element contains the list of parties which use one specific database instance. |
WithdrawalMarkCollection
TODO Identification of waste movement announcements for which all exchanged data shall be marked as withdrawn by EDI partners, potentially including confirmations of waste receipt and confirmations of waste treatment.
Note 1: Exchanging a WithdrawalMarkCollection XML instance serves the purpose of letting EDI partners know of an erroneous use of notification number and waste shipment announcement serial number combinations in EDI transmissions.
Note 2: Evidently, WasteX EDI partners avoid erroneous use of notification number and waste shipment announcement serial number combinations to the greatest extent possible in the first place, as any such erroneous usage results in significant mis-information of partners with potentially severe consequences.
Note 3: The erroneous use of ID combinations can lead to one of the following:
Examples: todo The following two examples illustrate the two cases of Note 3. In both examples, EDI partners exchange information in relation to notifications »AT 1«, »AT 2« and »AT 3«. The EDI partners have already correctly exchanged the following number of movement announcements for the notifications: 64 for »AT 1«, 0 for »AT 2«, 32 for »AT 3«.
Note 3: The EDI protocol does NOT use this structure, i.e. this structure does NOT occur in the inputs and outputs of a WasteX web service. Accordingly, this structure does not play a direct role for the implementation of a connection to a WasteX web service.
With WasteX, EDI partners exchange WithdrawalMarkCollection XML instances (a) only upon the special occasion of "undoing" erroneous EDI transmissions, and (b) only "manually", such as by e-mail.
Name/Type | min..max | Definition |
---|---|---|
WithdrawalMarkList | 1..16384 | Each WithdrawalMarkList element contains the list of serial numbers to mark as withdrawn for one specific notification. |
MovementAnnouncement
Announcement of an individual shipment of waste, in accordance with Article 16(b) of the WSR ("prior information regarding actual start of shipment").
Note 1: A party (notifier) can update a previously transmitted announcement by disseminating a new WasteX MovementAnnouncement message with the same combination of notification number and serial number as in the originally transmitted announcement.
Note 2: The WSR expects economic operators to only transmit final information to competent authorities, rather than transmitting updates and corrections incrementally or in real-time. This also applies to WasteX EDI transmissions. Competent authorities expect economic operators to use EDI transmissions such that updates and corrections are the exception rather than the rule. Even though the WasteX EDI protocol defines few hard limits on updates and corrections, failure to comply with these principles can result in competent authorities' countermeasures directed at economic operators and/or developers/operators of WasteX EDI nodes. See also formal validation 🠖R342.
Name/Type | min..max | Definition |
---|---|---|
AnnouncementIdentity | 1..1 | A tuple of identifiers by which the notifier announces/announced the individual shipment of waste to competent authorities. Pursuant to the WSR, this tuple consists of (a) the notification number identifying the notification and consent(s), and (b) a serial number. The notifier uses serial number 1 for the first individual shipment of waste announced for a specific notification/consent, and increments the serial number for each subsequent announced shipment of waste under the same consent. Note: This message element is subject to WasteX formal validation. For example, validation 🠖R170 automatically triggers a warning if the serial number exceeds the total intended/consented number of shipments according to the corresponding notification/consent data at the validating EDI node. |
MovementUUID | 0..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation, identifying the individual shipment of waste. Note 1: This data element serves the following purpose: Multiple announcements may be needed for what economic operators regard as a single shipment of waste under their commercial contracts, due to constraints on the way competent authorities expect movement announcements to be used. For example, a planned shipment of waste may be delayed by two weeks. Competent authorities may require the cancellation of the original movement announcement in that case, and the issuance of a new movement announcement with a new serial number. Via the movement UUID it is possible to transmit information expressing that different announcements refer to the same shipment of waste from the economic operators' point of view. Note 2: This information is typically not of relevance to competent authorities. Note 3: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »45c35151-f38b-42d4-ac3e-0a6d2659dbe6« |
WasteProductionPartySite | 0..256 | The waste production/generation party and site from which the shipped waste originates. Note 1: Corresponds to block 9 of Annex IB WSR. Note 2: Each party and site must correspond to a waste production party and site combination from the notification. See formal validation 🠖R259. |
WasteMass | 0..1 | The mass of waste to be shipped. UN03000214 Note 1: Corresponds to block 5 of Annex IB WSR. Note 2: The MovementAnnouncement message contains the mass of waste intended to be shipped according to the notifier. A MovementAnnouncement message MUST NOT contain the received mass of waste, such as the mass determined at the end of a shipment via a weighbridge. This applies to all MovementAnnouncement message EDI, independent of the point in time at which the EDI transmission occurs - before, during or after the shipment (note that under regular circumstances parties conduct MovementAnnouncement message EDI before the shipment only, but not during or after the shipment). Likewise, this applies to both initial EDI transmissions and update transmissions of MovementAnnouncement messages. With WasteX, it is only messages of type ConfirmationOfWasteReceipt that contain the "received mass of waste". In particular, when a notifier eventually learns about the received mass of waste for a shipment, such as by the consignee's or facility's dissemination of a WasteX ConfirmationOfWasteReceiptMessage, the notifier MUST NOT disseminate an updated MovementAnnouncement message in which it replaces the "mass of waste intended to be shipped" with the "received mass of waste". Example: A notifier intends to ship 20t of waste in a single shipment, and announces this with a MovementAnnouncement message. A facility receives 17t of waste for that shipment, and dissmeninates this information with a ConfirmationOfWasteReceiptMessage. The notifier MUST NOT disseminate an updated MovementAnnouncement message which updates/corrects the mast of waste to be shipped from 20t to 17t. Note 3: This message element is subject to WasteX formal validation. For example, validation 🠖R207 automatically triggers a warning if the total mass of waste announced/received exceeds the total mass of waste notified/consented, and 🠖R530 and 🠖R557 automatically trigger an error if the waste mass value is negative or zero respectively. Example value: NumericValue »20« with @unitID attribute »t« and QuantificationTypeID »E« for "Estimated" |
WasteVolume | 0..1 | The volume of waste to be shipped. UN03000215 Note 1: Corresponds to block 5 of Annex IB WSR. Note 2: Compare notes on WasteMass: This element contains the volume of waste intended to be shipped according to the notifier. It MUST NOT contain the received volume of waste. This also applies to the transmission of MovementAnnouncement message updates. Note 3: This message element is subject to WasteX formal validation. For example, validation 🠖R837 automatically triggers a warning if the total volume of waste announced/received exceeds the total volume of waste notified/consented. Example value: NumericValue »55« with @unitID attribute »m3« and QuantificationTypeID »C« for "Calculated" |
PackageCount | 0..1 | The total number of packages in the specified shipment of waste. UN01005138 Note 1: Corresponds to block 7 of Annex IB WSR. Note 2: This message element is subject to WasteX formal validation. For example, validation 🠖R837 automatically triggers a warning if the MovementAnnouncement message lacks the total number of packages. Supported lexical representations and values:
Example value: »20« |
PackageTypeID | 0..16 | The types of packages used in the specified shipment of waste (see also EUDIN ↗codelist 6524). UN01005139 Note 1: Corresponds to block 7 of Annex IB WSR. Note 2: Each movement announcement MUST contain package type information. See formal validation 🠖R378. Note 3: Each package type MUST NOT occur more than once within a single movement announcement message. See formal validation 🠖R519. Note 4: The WasteX movement announcement data format does NOT contain a package description on purpose. The notification rather than the movement announcement shall contain detailed information on package types, especially with "other" package types. In case there is a need for additional package information in relation to the individual shipment, the WasteX movement announcement message Remark element shall carry such information. Note 5: This message element is subject to WasteX formal validation. For example, validation 🠖R479 automatically rejects a received user message if a package type is not among the notified and consented package types according to the notification/consent data at the validating EDI node. The set of supported lexical representations and values:
|
StartDate | 0..1 | The day at which the shipment will start/depart according to the notifier's plans. UN03000223 Note 1: Corresponds to block 6 of Annex IB WSR. Note 2: Each movement announcement MUST contain a start date. See formal validation 🠖R439. Note 3: This identifies the LOCAL departure date at the departure location. Note 4: This message element is subject to WasteX formal validation. For example, validation 🠖R158 and 🠖R576 automatically trigger a warning if the shipment start date is not within the consented shipment period according to the corresponding notification/consent data at the validating EDI node. Supported lexical representations and values:
Example value: »2022-10-31« |
TransportMovement | 0..256 | The transport movements for the shipment of waste, with information on the carriers. UN03000226 Note 1: Corresponds to block 8 of Annex IB WSR. Note 2: Each movement announcement MUST contain data on carriers. See formal validation 🠖R798. Note 3: This message element is subject to WasteX formal validation. For example, validation 🠖R732 automatically triggers a warning for every combination of carrier and transport mode in the movement announcement not consented according to the corresponding notification/consent data at the validating EDI node. |
NationalRoute | 0..128 | Countries with their points of entry and points of exit for the shipment of waste. UN03000238 Note 1: As required by Annex II, Part 2 (5) of the WSR. Note 2: The order of entries must reflect the order of traversing the countries. In particular, the first entry must be for the country of dispatch, and the last entry for the country of destination. Note 3: For countries of transit and the country of destination, the movement announcement message MUST contain point of entry information, whereas it MUST NOT contain point of entry information for the country of dispatch. See formal validation 🠖R686 and 🠖R606. Likeweise, for countries of dispatch and countries of transit the movement announcement message MUST contain point of exit information, whereas it MUST NOT contain point of exit information for the country of destination. See formal validation 🠖R705 and 🠖R959. Note 4: The names of point of exit/entry must be specified such that the combination of point of exit from one country and the point of entry from the subsequent country uniquely identifies a border-crossing. Note 5: This message element is subject to WasteX formal validation. For example, validation 🠖R824 automatically rejects a movement announcement if it refers to a country which the corresponding notification/consent data at the validating EDI node does not list as country of dispatch/transit/destination, and validation 🠖R446 automatically rejects a movement announcement if two consecutive countries are identical. Example: Country »040« (AT, Austria) with point of exit »Kufstein« and subsequent country »276« (DE, Germany) with point of entry »Kiefersfelden«. |
Remark | 0..1 | A remark by the originator/creator of this waste shipment announcement related information. Note 1: Corresponds largely to block 16 of Annex IB WSR. Note 2: It is on purpose that the WasteX message format does NOT support providing language metdata, such as ISO 639 language codes like »en« for English or »de« for German. With WasteX EDI, parties must provide natural language information in a single language appropriate for all the other parties related to the shipment, economic operators and competent authorities. If a waste shipment passes through different language areas, then in many cases competent authorities expect waste shipment parties to provide textual information in English. Supported lexical representations and values:
Example value: »Multimodal - rail from Verona to Leipzig.« |
MovementAnnouncement usage occurrences: WasteMovementUserMessage
MovementAnnouncementStatus
Status of the announcement of an individual shipment of waste, in accordance with Article 16(b) of the WSR ("prior information regarding actual start of shipment"). With a MovementAnnouncementStatus message, a party (notifier) informs about the CANCELLATION of a previously announced shipment of waste.
Note: Parties can NOT undo cancellations via WasteX EDI. See the WasteX specification PDF, in particular the "regular data operations principle", for the reasoning behind this WasteX EDI design.
Name/Type | min..max | Definition |
---|---|---|
AnnouncementIdentity | 1..1 | A tuple of identifiers by which the notifier announces/announced the individual shipment of waste to competent authorities. Pursuant to the WSR, this tuple consists of (a) the notification number identifying the notification and consent(s), and (b) a serial number. The notifier uses serial number 1 for the first individual shipment of waste announced for a specific notification/consent, and increments the serial number for each subsequent announced shipment of waste under the same consent. Note: This message element is subject to WasteX formal validation. For example, validation 🠖R688 automatically triggers a warning if the validating EDI node does not have a movement announcement in its database for the combination of notification number and serial number. |
StatusID | 1..1 | The status of the movement announcement. The set of supported lexical representations and values:
|
Remark | 0..1 | A remark by the originator/creator of this waste shipment announcement status related information. Note 1: This would typically contain an explanation of the reasons for a cancellation. Note 2: It is on purpose that the WasteX message format does NOT support providing language metdata, such as ISO 639 language codes like »en« for English or »de« for German. With WasteX EDI, parties must provide natural language information in a single language appropriate for all the other parties related to the shipment, economic operators and competent authorities. If a waste shipment passes through different language areas, then in many cases competent authorities expect waste shipment parties to provide textual information in English. |
MovementAnnouncementStatus usage occurrences: WasteMovementUserMessage
CarrierConfirmation
Carrier's confirmation of taking charge of a shipment of waste, in accordance with Article 16 of the WSR, as well as Annex IB block 8 and Annex IC paragraphs 6 and 32.
Name/Type | min..max | Definition |
---|---|---|
AnnouncementIdentity | 1..1 | Identification of shipment of waste by notification number and serial number of the announcement. Note: The carrier confirms taking charge of one specific shipment of waste that has previously been announced by the notifier. |
CarrierConfirmationUUID | 1..1 | A Version 4 (random) Universally Unique Identifier (UUID) in canonical representation, identifying the carrier's confirmation. Note 1: For a single shipment of waste (under one notification number and one serial number), one carrier may cover multiple transport legs, even with the same mode of transport. This means that there can be multiple carrier confirmations by a single carrier for a single shipment of waste. Whether a transmitted carrier confirmation is an additional confirmation, or an update to a previously transmitted confirmation, is determined by the carrier confirmation UUID (same UUID: update; different UUID: additional confirmation). Note 2: The notification number and serial number used in combination with a Carrier Confirmation UUID is fixed (frozen) with the first Carrier Confirmation containing this combination of IDs. Subsequently, the Carrier Confirmation UUID cannot be used with a different notification number or a different serial number. Note 3: Software with a role in WasteX EDI shall NOT display this information to regular users, and must not let regular users edit this information. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »5e7d1d2e-d896-4f49-914a-31850e5195aa« |
CarrierPartyID | 1..1 | The carrier taking charge of the shipment of waste. UN03000313 Note 1: Corresponds to block 8 of Annex IB WSR. Note 2: The carrier must correspond to a carrier specified in the notification and in the movement announcement. |
TransportModeID | 0..1 | The mode of transport used by the carrier for moving the shipment of waste (see also EUDIN ↗codelist 8149). UN03000312 Note: Corresponds to block 8 of Annex IB WSR. Referred to as "means of transport" in the WSR. The set of supported lexical representations and values:
|
TransportMeansID | 0..1 | An identification number from the registration of the transport means used by the carrier for moving the shipment of waste. Example: Identifier from the license plate of a truck. Note: The WSR does not require transport means IDs to be specified. |
Date | 0..1 | The day at which the carrier took charge of the shipment of waste. Note: Corresponds to block 8 of Annex IB WSR. Referred to as "date of transfer" in the WSR. |
Remark | 0..1 | A remark by the originator/creator of this confirmation, i.e., by the carrier. Note 1: Corresponds largely to block 16 of Annex IB WSR. Note 2: It is on purpose that the WasteX message format does NOT support providing language metdata, such as ISO 639 language codes like »en« for English or »de« for German. With WasteX EDI, parties must provide natural language information in a single language appropriate for all the other parties related to the shipment, economic operators and competent authorities. If a waste shipment passes through different language areas, then in many cases competent authorities expect waste shipment parties to provide textual information in English. |
CarrierConfirmation usage occurrences: WasteMovementUserMessage
ConfirmationOfWasteReceipt
Confirmation of the receipt of waste, in accordance with Article 16(d) or Article 15(c) of the WSR.
Note: Corresponds largely to WSR Annex IB Block 18 or Block 17 in the case of confirmation by a consignee that is not a disposal/recovery facility.
Name/Type | min..max | Definition |
---|---|---|
AnnouncementIdentity | 1..1 | Identification of the shipment announcement to which the waste receipt confirmation refers. Note: The recipient confirms the receipt of one specific shipment of waste that has previously been announced by the notifier. |
ReceiverPartySite | 1..1 | Party by which the waste shipment was received and, for receipt at treatment facilities, site at which the waste shipment was received. |
ReceiptDate | 0..1 | The day at which the shipped waste arrived at the recipient, i.e. at which the recipient took charge of the shipped waste. UN01005199 |
ReceivedWasteMass | 0..1 | The mass of waste received for the specified shipment. UN01005202 |
ReceivedWasteVolume | 0..1 | The volume of waste received for the specified shipment. UN01005203 |
RejectionIndicator | 0..1 | The indication of whether or not the received waste is rejected by the recipient. UN01005200 Note: This indication is expected to be set to true for full rejection only. Partial rejection cannot be expressed with structured data in this data format, but rather needs to be described through natural language text - see Remark element. |
PlannedTreatmentCompletionDate | 0..1 | The day at which the treatment (recovery or disposal) of waste is expected to be completed at the treatment facility that received the waste. UN01005181 Note 1: If only an interim treatment operation is applied at the facility, this date refers to the completion of the interim treatment, but not to the completion of subsequent treatment operations. Note 2: In both of the following two cases the data instance is expected to NOT contain the date at which the treatment is expected to be completed: 1. The recipt of waste is confirmed by a party other than a waste treatment facility 2. The recipient expresses full rejection of the received waste by providing a RejectionIndicator set to true. |
Remark | 0..1 | A remark by the originator/creator of this receipt of waste information on the receipt of waste. Note 1: Corresponds largely to block 16 of Annex IB WSR. Note 2: It is on purpose that the WasteX message format does NOT support providing language metdata, such as ISO 639 language codes like »en« for English or »de« for German. With WasteX EDI, parties must provide natural language information in a single language appropriate for all the other parties related to the shipment, economic operators and competent authorities. If a waste shipment passes through different language areas, then in many cases competent authorities expect waste shipment parties to provide textual information in English. |
ConfirmationOfWasteReceipt usage occurrences: WasteMovementUserMessage
ConfirmationOfWasteTreatment
Confirmation of the completion of treatment of waste, in accordance with Article 16(e), Article 15(e) or Article 15(d) of the WSR.
Note: Corresponds largely to WSR Annex IB Block 19.
Name/Type | min..max | Definition |
---|---|---|
AnnouncementIdentity | 0..1 | Identification of the shipment announcement to which the waste treatment confirmation refers. Note: The facility confirms the treatment of one specific shipment of waste that has previously been announced by the notifier. |
TreatmentPartySite | 0..1 | The treatment party and site most relevant with respect to the described treatment of the shipped waste. Note 1: For the confirmation of the completion of treatment for a shipment NOT entailing subsequent treatment, pursuant to WSR Art. 16(e), this must be the one treatment party and site specified in the notification. Note 2: For the confirmation of the completion of an interim treatment, pursuant to WSR Art. 15(d), this must be the treatment party and site that has carried out the interim treatment. Note 3: For the confirmation of the completion of the entire treatment in the country of destination, pursuant to WSR Art. 15(e), this should typically be the party and site carrying out the first non-interim treatment. |
ScopeID | 1..1 | The scope of the waste treatment confirmed for the specified shipment of waste: The set of supported lexical representations and values:
Note 1: For Art. 15(e), »ENTIRE« refers to the certification described in Annex 4 Paragraph 5 of the Correspondents' Guidelines No 3: "Once the interim disposal or recovery facility has obtained the last certificate(s) from a subsequent non-interim facility, it is to certify the following: “The non-interim disposal or recovery of the waste shipped under the notification referred to in block 1 and the shipment(s) referred to in block 2 and delivered for subsequent interim or non-interim recovery or disposal in the country of destination has been completed.”" Note 2: The WasteX protocol does NOT support the exchange of information on the completion of the treatment of waste at INDIVDUAL subsequent treatment facilities. |
TreatmentCompletionDate | 0..1 | The day at which the described treatment (recovery or disposal) of the waste from the specified shipment has been completed. UN01005144 Note: Depending on the scope of the described treatment, as indicated in the ScopeID element, this is either (a) the date at which the entire treatment in the country of destination has been completed, or (b) the date at which the treatment at a single treatment facility has been completed, without taking any subsequent treatment into account. |
Remark | 0..1 | A remark by the originator/creator of this treatment of waste related information. Note 1: Corresponds largely to block 16 of Annex IB WSR. Note 2: It is on purpose that the WasteX message format does NOT support providing language metdata, such as ISO 639 language codes like »en« for English or »de« for German. With WasteX EDI, parties must provide natural language information in a single language appropriate for all the other parties related to the shipment, economic operators and competent authorities. If a waste shipment passes through different language areas, then in many cases competent authorities expect waste shipment parties to provide textual information in English. |
ConfirmationOfWasteTreatment usage occurrences: WasteMovementUserMessage
AnnouncementIdentity
Identification of a movement announcement, consisting of notification number and serial number.
Name/Type | min..max | Definition |
---|---|---|
NotificationID | 1..1 | The identifier of the notification/consent as assigned by the competent authority of dispatch Supported lexical representations and values:
Example value: »AT 034567« |
SequenceNumberID | 1..1 | The serial number (sequential number) of the announced shipment for the specified notification. Example: Serial number 1 must be assigned to the first shipment announcement for a specific notification, serial number 2 to the second announced shipment, etc. Supported lexical representations and values:
Note: Even though this element uses solely xs:integer compliant lexical presentations, the base for this element is xs:string, so that it is simple for software to remain in control over the actual lexical representation generated at message creation (marshalling). Example value: »17« |
AnnouncementIdentity usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement, MovementAnnouncementStatus, WasteMovementSignalMessage
CarrierEconomicOperator
Information on a carrier.
Name/Type | min..max | Definition |
---|---|---|
PartyID | 0..1 | The WasteX relevant ID of the economic operator. |
RecipientSpecificPartyID | 0..1 | An ID of the economic operator specific to the message transmission recipient. Note: For the edm.gv.at web service, this is the GLN used as main party identifier in edm.gv.at. |
PartyName | 1..1 | The economic operator's name, such as the registered company name. |
PartyAddressText | 0..1 | The registered office address of the economic operator, provided as single string. Example: "Saatwinkler Damm 42/43, 13627 Berlin, Germany" |
TransportModeID | 0..5 | The modes of transport consented for this carrier (see also EUDIN ↗codelist 8149). The set of supported lexical representations and values:
|
CarrierEconomicOperator usage occurrences: LatestNotification
CountryList
A list of countries identified by ISO 3166-1 3-digit codes.
Name/Type | min..max | Definition |
---|---|---|
ListElement | 0..512 | An element of the list of countries. |
CountryList usage occurrences: ValidationNodeReferenceData
CountryListElement
An entry in a reference list of country codes.
Name/Type | min..max | Definition |
---|---|---|
CountryID | 1..1 | An ISO 3166-1 3-digit country code. Examples:
|
CountryTwoLetterID | 0..1 | The ISO 3166-1 two letter country code ("alpha-2"). Examples:
|
ValidityStartDate | 0..1 | The date at which the entry becomes valid, i.e., at which the country comes into existence according to ISO 3166-1. Note: The ValidityStartDate MUST be omitted for entries to which no start of validity is recorded. |
ValidityEndDate | 0..1 | The date at which the entry becomes invalid, i.e., at which the country ceases to exist according to ISO 3166-1. Note: The ValidityEndDate MUST be omitted for entries to which no end of validity is recorded. |
CountryListElement usage occurrences: CountryList
DatabaseInstancePartyList
Identification of parties which use a specific registered database instance.
Note: This is intended to be used as an "allow list" for EDI. Operators of EDI node A send such a list to operators of another EDI node B, so that EDI node B can accept EDI node A to "represent" certain parties.
Name/Type | min..max | Definition |
---|---|---|
DatabaseInstanceRegistrationID | 1..1 | An identifier by which the database instance is registered at other EDI nodes. |
PartyID | 1..16384 | Identification of parties using the specified database instance. |
DatabaseInstancePartyList usage occurrences: DatabaseInstancePartyCollection
EconomicOperator
Information on an economic operator.
Name/Type | min..max | Definition |
---|---|---|
PartyID | 0..1 | The WasteX relevant ID of the economic operator. |
RecipientSpecificPartyID | 0..1 | An ID of the economic operator specific to the message transmission recipient. Note: For the edm.gv.at web service, this is the GLN used as main party identifier in edm.gv.at. |
PartyName | 1..1 | The economic operator's name, such as the registered company name. |
PartyAddressText | 0..1 | The registered office address of the economic operator, provided as single string. Example: "Saatwinkler Damm 42/43, 13627 Berlin, Germany" |
EconomicOperator usage occurrences: LatestNotification
EconomicOperatorSite
Information on an economic operator in combination with a site.
Note: Site is either a waste production site or a waste treatment site.
Name/Type | min..max | Definition |
---|---|---|
PartyID | 0..1 | The WasteX relevant ID of the economic operator. |
RecipientSpecificPartyID | 0..1 | An ID of the economic operator specific to the message transmission recipient. Note: For the edm.gv.at web service, this is the GLN used as main party identifier in edm.gv.at. |
PartyName | 1..1 | The economic operator's name, such as the registered company name. |
PartyAddressText | 0..1 | The registered office address of the economic operator, provided as single string. Example: "Saatwinkler Damm 42/43, 13627 Berlin, Germany" |
SitePostalAreaID | 1..1 | The post code of the area within which the site is located. Example: "13627" |
SiteName | 0..1 | The name of the site. |
SiteAddressText | 0..1 | The site address, provided as single string. Example: "Saatwinkler Damm 42/43, 13627 Berlin, Germany" |
EconomicOperatorSite usage occurrences: LatestNotification
EconomicOperatorSiteIdentity
Identification of an economic operator in combination with a site.
Examples:
Name/Type | min..max | Definition |
---|---|---|
PartyID | 1..1 | An identification of the party. Supported lexical representations and values:
Example value: »DE140462045« in combination with @registerID attribute »VAT.EU« for the identification of company »P-D Industriegesellschaft mbH, Wilsdruffer Straße 11, 01723 Wilsdruff, Germany« |
SitePostalAreaID | 0..1 | The post code of the area within which the site is located. Supported lexical representations and values:
Example value: »02699« for a »P-D Industriegesellschaft mbH« site located in »Wetro-Siedlung 13-22, 02699 Puschwitz, Germany« |
EconomicOperatorSiteIdentity usage occurrences: ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement
FormalValidationReport
Results of the formal validation of a WasteX user message in Schematron Validation Report Language format.
Name/Type | min..max | Definition |
---|---|---|
svrl:schematron-output svrl:schematron-output | 1..1 | Results of the formal validation of a WasteX user message in Schematron Validation Report Language format. Note: SVRL supports rich text formatting in validation report texts (svrl:text elements), e.g. emph elements to highlight certain words in the text. The WasteX EDI protocol does NOT make use of such rich text formatting, i.e. all validation report texts are plain text without markup. For this reason, and to simplify the implementation of WasteX EDI, WasteX uses an svrl.xsd Schema Definition adapted in order to NOT support rich text markup. |
FormalValidationReport usage occurrences: WasteMovementSignalMessage
LatestCarrierConfirmation
Latest carrier confirmation available at the EDI node for the notification number, serial number and carrier confirmation UUID referred to in the validation context message.
Name/Type | min..max | Definition |
---|---|---|
TransportModeID | 0..1 | The mode of transport used by the carrier for moving the shipment of waste (see also EUDIN ↗codelist 8149). UN03000312 Note: Corresponds to block 8 of Annex IB WSR. Referred to as "means of transport" in the WSR. The set of supported lexical representations and values:
Pseudo-SQL: select TRANSPORT_MODE_ID from CARRIER_CONFIRMATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and CONFIRMATION_UUID=msg.CarrierConfirmationUUID |
Date | 0..1 | The day at which the carrier took charge of the shipment of waste. Note: Corresponds to block 8 of Annex IB WSR. Referred to as "date of transfer" in the WSR. Pseudo-SQL: select DATE from CARRIER_CONFIRMATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and CONFIRMATION_UUID=msg.CarrierConfirmationUUID |
LatestCarrierConfirmation usage occurrences: ValidationNodeIndividualData
LatestConfirmationOfWasteReceipt
Latest confirmation of waste receipt information available at the EDI node for the notification number and serial number referred to in the validation context message.
Name/Type | min..max | Definition |
---|---|---|
ReceiptDate | 0..1 | The day at which the shipped waste arrived at the recipient, as specified in the confirmation of waste receipt with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select RECEIPT_DATE from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
ReceivedWasteMass | 0..1 | The mass of waste received, as specified in the confirmation of waste receipt with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select RECEIVED_WASTE_MASS from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
ReceivedWasteVolume | 0..1 | The volume of waste received, as specified in the confirmation of waste receipt with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select RECEIVED_WASTE_VOLUME from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
RejectionIndicator | 0..1 | The indication of whether or not the received waste is rejected by the recipient, as specified in the confirmation of waste receipt with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select REJECTION_INDICATOR from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
PlannedTreatmentCompletionDate | 0..1 | The day at which the treatment (recovery or disposal) of waste is expected to be completed at the treatment facility that received the waste, as specified in the confirmation of waste receipt with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select TREATMENT_COMPLETION_DATE from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
LatestConfirmationOfWasteReceipt usage occurrences: ValidationNodeIndividualData
LatestConfirmationOfWasteTreatment
Latest confirmation of waste treatment information available at the EDI node for the notification number and serial number referred to in the validation context message.
Name/Type | min..max | Definition |
---|---|---|
TreatmentCompletionDate | 0..1 | The day at which the treatment (recovery or disposal) of the waste has been completed, as specified in the confirmation of waste treatment with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select TREATMENT_COMPLETION_DATE from CONFIRMATION_OF_TREATMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and SCOPE_ID="ENTIRE"/"FACILITY" |
LatestConfirmationOfWasteTreatment usage occurrences: ValidationNodeIndividualData
LatestMovementAnnouncement
Latest movement announcement information available at the EDI node for the notification number and serial number referred to in the validation context message.
Name/Type | min..max | Definition |
---|---|---|
StatusID | 0..1 | The status of the movement announcement with the combination of notification number and serial number to which the message in the validation context refers. Note: Status information recorded in the database at the EDI node must be mapped to one of the three values supported in this data format. The set of supported lexical representations and values:
Pseudo-SQL: select STATUS_ID from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
WasteMass | 0..1 | The mass of waste to be shipped as specified in the movement announcement with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select WASTE_MASS from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
WasteVolume | 0..1 | The volume of waste to be shipped as specified in the movement announcement with the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select WASTE_VOLUME from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
StartDate | 0..1 | The shipment start date specified in the movement announcement for the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select START_DATE from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
TransportMovement | 0..256 | The transport movements specified in the movement announcement for the combination of notification number and serial number to which the message in the validation context refers. Pseudo-SQL: select TRANSPORT_MOVEMENT from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
LatestMovementAnnouncement usage occurrences: ValidationNodeIndividualData
LatestNotification
Latest notification information available at the EDI node for the notification number referred to in the validation context message.
Name/Type | min..max | Definition |
---|---|---|
MovementPermissionStatusIndicator | 0..1 | An indication of whether or not a status is recorded for the notification under which waste shipments are actually permitted. "true" stands for a status under which waste shipments can be conducted, if the conditions set by competent authorities are met. Pseudo-SQL: select case when EFFECTIVE_STATE in ('CONSENTED','TACIT_CONSENT') then 1 else 0 end as MOVEMENT_PERMISSION_STATUS from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID Example: A movement announcement may refer to a notification DE 123. The database at the EDI node receiving this message may actually contain information on a notification 123. The data on notification 123 in the database may however indicate a status in which shipments of waste are not permitted under the notification. The data may for example indicate that the notification has been submitted to CAs, but that there are not yet consents from all involved CAs. In such a case the MovementPermissionStatusIndicator will be set to false. |
ValidityStartDate | 0..1 | The start date of the period of validity for this notification, i.e., the first day at which shipments are permitted according to the authorities' consent. Note: Effective validity start date as derived from the individual CAs' consents, corresponding to block 20 of Annex IA WSR (»consent valid from«). Pseudo-SQL: select VALIDITY_START_DATE from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
ValidityEndDate | 0..1 | The end date of the period of validity for this notification, i.e., the last day at which shipments are permitted according to the authorities' consent. Note: Effective validity end date as derived from the individual CAs' consents, corresponding to block 20 of Annex IA WSR (»consent valid until«). Pseudo-SQL: select VALIDITY_END_DATE from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
WasteMass | 0..1 | The maximum amount of waste to be shipped (sum over all individual shipments) as consented by the authorities for the notification. Note: Corresponds to block 5 of Annex IA WSR. Pseudo-SQL: select WASTE_MASS from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
WasteVolume | 0..1 | The maximum total volume of waste to be shipped (sum over all individual shipments) consented by the authorities for the notification. Pseudo-SQL: select WASTE_VOLUME from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
PackageTypeID | 0..16 | The types of packages consented by the authorities for the notification (see also EUDIN ↗codelist 6524). Pseudo-SQL: select PACKAGE_TYPE_ID from NOTIFICATION_PACKAGE where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID The set of supported lexical representations and values:
|
MovementCount | 0..1 | The maximum total number of waste shipments as consented by the authorities in the notification. Note: Corresponds to block 4 of Annex IA WSR. Pseudo-SQL: select MOVEMENT_COUNT from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
Country | 0..128 | The consented countries of dispatch, transit and destination. Note: The first entry must identify the country of dispatch. That last entry must identify the country of destination. All other entries must identify transit countries. |
PartyIdentifierCompleteIndicator | 0..1 | An indication whether or not the following applies: In the database at the validating EDI node, for all parties from the notification/consent, the identifier required for matching party references from WasteX messages, such as VAT.EU, is available in the database. "true" stands for the availability of all identifiers, "false" stands for missing identifiers. Note 1: The validating EDI node shall set this to false if and only if it has to omit parties and/or party-site-combinations from the notification validation context (WasteProductionPartySite, NotifierParty, CarrierParty, ConsigneeParty, WasteTreatmentPartySite, SubsequentWasteTreatmentPartySite) due to missing WasteX relevant IDs. Note 2: This must only be filled by validating EDI nodes that require a matching with parties from the notification. PartyIdentifierCompleteIndicator set to "false" automatically leads to the rejection of transmitted WasteX messages, INDEPENDENT of whether or not individual look-ups (carrier, waste producer, etc.) fail. |
WasteProductionPartySite | 0..256 | The waste producers and waste production sites as specified in the notification. Note 1: Corresponds to block 9 of Annex IA and Annex IC, point 20 of the WSR: »If the waste has been produced by more than one producer, append a list providing the requested information for each producer«. Note 2: The combination of PartyID and SitePostalAreaID must be unique within all waste production party/sites. Pseudo-SQL: select distinct WASTE_PRODUCTION_PARTY_SITE from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
NotifierParty | 0..1 | The notifier as specified in the notification. Note: Corresponds to block 1 of Annex IA WSR. Pseudo-SQL: select NOTIFIER_PARTY from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
CarrierParty | 0..256 | The carriers as specified in the notification. Note: Corresponds to block 8 of Annex IA and Annex IC, point 19 of the WSR: »If more than one carrier is involved, append to the notification document a complete list giving the required information for each carrier«. Pseudo-SQL: select distinct CARRIER_PARTY from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
ConsigneeParty | 0..1 | The consignee as specified in the notification. Note: Corresponds to block 2 of Annex IA WSR. Pseudo-SQL: select CONSIGNEE_PARTY from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
WasteTreatmentPartySite | 0..1 | The waste treatment parties and waste treatment sites as specified in the notification. Note 1: Corresponds to block 10 of Annex IA WSR. Note 2: In case of treatment at subsequent facilities in the country of destination, this is the first interim treatment facility from which - after interim treatment - the waste is moved to subsequent treatment facilities. In cases without treatment at subsequent facilities this is the one (non-interim) facility from the notification in the country of destination. Note 3: The combination of PartyID and SitePostalAreaID must be unique within all waste treatment party/sites (both WasteTreatmentPartySite and SubsequentWasteTreatmentPartySite). Pseudo-SQL: select WASTE_TREATMENT_PARTY_SITE from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
SubsequentWasteTreatmentPartySite | 0..256 | Waste treatment parties and waste treatment sites at which subsequent treatment is carried out, as specified in the notification. Note 1: Corresponds to Annex IC, point 21 of the WSR: »In the case of subsequent treatment, information on the subsequent facility or facilities, where any subsequent interim treatment operation or operations takes or take place or may take place should be provided in an annex«. Note 2: The combination of PartyID and SitePostalAreaID must be unique within all waste treatment party/sites (both WasteTreatmentPartySite and SubsequentWasteTreatmentPartySite). Pseudo-SQL: select distinct SUBSEQUENT_WASTE_TREATMENT_PARTY_SITE from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
AnnouncemenEaseIndicator | 0..1 | An indication of whether or not all competent authorities have agreed to a simplified handling of movement announcements for the notification. "true" stands for authorities accepting simplified handling. Under a simplified handling, competent authorities accept the transmission of movement announcements up until the start of the shipment rather than up until 3 or 1 working days prior to the shipment. Pseudo-SQL: select case when ANNOUNCEMENT_EASE_INDICATOR from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
LatestNotification usage occurrences: ValidationNodeIndividualData
LatestTransportMovement
Details on a single transport movement, such as carrier and mode of transport.
Name/Type | min..max | Definition |
---|---|---|
CarrierPartyID | 0..1 | The WasteX relevant ID of the carrier conducting the transport movement. UN03000313 Note 1: Corresponds to block 8 of Annex IB WSR. Note 2: This message element is subject to WasteX formal validation. For example, validation 🠖R521 automatically rejects a received user message if a carrier party is not among the notified and consented carriers according to the corresponding notification/consent data at the validating EDI node. Supported lexical representations and values:
Example value: »DE188158403« in combination with @registerID attribute »VAT.EU« for the identification of carrier »DB Cargo AG, Rheinstraße 2, 55116 Mainz, Germany« |
RecipientSpecificCarrierPartyID | 0..1 | A carrier ID specific to the message transmission recipient. Note: For the edm.gv.at web service, this is the GLN used as main party identifier in edm.gv.at. |
TransportModeID | 0..1 | The mode of transport for this transport movement (see also EUDIN ↗codelist 8149). UN03000312 Note 1: According to the WSR the carriers provide mode of transport information. The WasteX message format makes it however possible that the notifier provides mode of transport information in advance. Note 2: This message element is subject to WasteX formal validation. For example, validation 🠖R732 automatically triggers a warning if a combination of carrier party and transport mode is not among the notified and consented carrier and transport mode combinations according to the corresponding notification/consent data at the validating EDI node. The set of supported lexical representations and values:
|
LatestTransportMovement usage occurrences: LatestMovementAnnouncement
MassValueAssignmentStatement
A mass value assignment statement, e.g. "has a mass of 20t".
Name/Type | min..max | Definition |
---|---|---|
NumericValue | 1..1 | The mass expressed as a numeric value in combination with a unit in attribute @unitID, e.g. "20t". Note 1: Due to the use of a numeric data type, the precision/uncertainty of results (significant digits) CANNOT be expressed via the notation of the numeric value. For example, the two literals 30.00 and 30.0 are interpreted as the same numerical value. Supported lexical representations and values for the NumericValue content:
Example value: »20.1« Note 2: A case sensitive ISO/UCUM code identifies the unit in attribute @unitID, e.g. "t". See EUDIN ↗codelist 9184. The set of supported values for attribute @unitID:
|
QuantificationTypeID | 0..1 | The type of quantification used for determining the waste mass (see also EUDIN ↗codelist 7299). The set of supported lexical representations and values:
|
MassValueAssignmentStatement usage occurrences: ConfirmationOfWasteReceipt, LatestConfirmationOfWasteReceipt, LatestMovementAnnouncement, MovementAnnouncement
NationalRoute
Details on the section of a transport route within a particular country.
Name/Type | min..max | Definition |
---|---|---|
CountryID | 1..1 | The country within which this route section lies, identified by an ISO 3166-1 3-digit code. UN01005197 Note 1: EUDIN ↗codelist 3862, which reproduces the entries of ISO 3166-1, defines the set of supported values. Note 2: The WasteX specification uses the ↗codelist 3862 dynamically. This means that developers must prepare software reading and writing WasteX compliant data instances for changes in the codelist, especially the addition of entries, independent of any changes to the WasteX message format. The latest version of the EUDIN ↗codelist 3862 is available from edm.gv.at and through a codelist web service. See the WasteX specification PDF for more details. Note 3: The WasteX specification uses ISO 3166-1 3-digit codes instead of the more commonly known two-letter codes as ISO ascertains uniqueness over longer periods of time, such as multiple years, only for the 3-digit codes. Such uniqueness does not in all cases apply to two-letter codes. For example, ISO has assigned the two-letter code CS to both Czechoslovakia (until 1993) and to Serbia and Montenegro (from 2003 to 2006). Note 4: This message element is subject to WasteX formal validation. For example, validation 🠖R824 automatically rejects a movement announcement if it refers to a country which the corresponding notification/consent data at the validating EDI node does not list as country of dispatch/transit/destination. Example value: »276« for Germany. |
EntryPointName | 0..1 | The name of the point of entry into the country specified in CountryID. UN01005160/UN01005223 Note: The message MUST contain point of entry information for countries of transit and country of destination, and MUST NOT contain point of entry information for the country of dispatch. See formal validation 🠖R686 and 🠖R606. Supported lexical representations and values:
Example value: »Kiefersfelden« |
ExitPointName | 0..1 | The name of the point of exit from the country specified in CountryID. UN01005161/UN01005223 Note: The message MUST contain point of exit information for the country of dispatch and countries of transit, and MUST NOT contain point of exit information for the country of destination. See formal validation 🠖R705 and 🠖R959. Supported lexical representations and values:
Example value: »Kufstein« |
NationalRoute usage occurrences: MovementAnnouncement
NotificationCountry
Details of a notification/consent on a particular country (country of dispatch, transit or destination).
Name/Type | min..max | Definition |
---|---|---|
CountryID | 1..1 | The country identified by an ISO 3166-1 3-digit code. Example: Code "276" for Germany. Note: The set of supported values is defined by EUDIN ↗codelist 3862, which reproduces the entries of ISO 3166-1. |
EntryPointName | 0..32 | The names of consented points of entry into the respective country. |
ExitPointName | 0..32 | The names of consented points of exit from the respective country. |
NotificationCountry usage occurrences: LatestNotification
TransportMovement
Details on a single transport movement, such as carrier and mode of transport.
Name/Type | min..max | Definition |
---|---|---|
CarrierPartyID | 0..1 | The WasteX relevant ID of the carrier conducting the transport movement. UN03000313 Note 1: Corresponds to block 8 of Annex IB WSR. Note 2: This message element is subject to WasteX formal validation. For example, validation 🠖R521 automatically rejects a received user message if a carrier party is not among the notified and consented carriers according to the corresponding notification/consent data at the validating EDI node. Supported lexical representations and values:
Example value: »DE188158403« in combination with @registerID attribute »VAT.EU« for the identification of carrier »DB Cargo AG, Rheinstraße 2, 55116 Mainz, Germany« |
TransportModeID | 0..1 | The mode of transport for this transport movement (see also EUDIN ↗codelist 8149). UN03000312 Note 1: According to the WSR the carriers provide mode of transport information. The WasteX message format makes it however possible that the notifier provides mode of transport information in advance. Note 2: This message element is subject to WasteX formal validation. For example, validation 🠖R732 automatically triggers a warning if a combination of carrier party and transport mode is not among the notified and consented carrier and transport mode combinations according to the corresponding notification/consent data at the validating EDI node. The set of supported lexical representations and values:
|
TransportMovement usage occurrences: MovementAnnouncement
ValidationNodeAggregatedChangeData
An aggregation of record CHANGES that occurred at an EDI node database.
Name/Type | min..max | Definition |
---|---|---|
ShipmentRecordContentUpdateCount | 0..1 | The number of record content updates (not counting record entry and record status updates) in the EDI node database, prior to the receipt of the new message (contained in the validation context), for the combination of the following: 1. notification number EQUAL to that of the message in the validation context 2. serial number EQUAL to that of the message in the validation context 3. type of content EQUAL to that of the validation context message (see also the note below on status update messages) Note 1: For newly received status update messages, this element must be filled for the underlying content message type. For example, for a newly received "MovementAnnouncementStatus" message, this element must be filled for "MovementAnnouncement" records. See also the pseudo SQL below. Analogously, the EDI node must interpret/log status updates as interactions on records of the underlying content type. Note 2: This aggregation must take into account ALL records matching the above criteria, independent of entry through data interface or GUI, and independent of origin. Pseudo-SQL: select COUNT(*) from RECORD_CHANGE_LOG where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and INTERACTION_TYPE_ID="content_update" and RECORD_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') |
ShipmentRecordEarliestUTCTimestamp | 0..1 | The timestamp of the earliest record interaction (initial entry) at the EDI node database, prior to the receipt of the new message, for records with a combination of the following: a. notification number EQUAL to that of the message in the validation context b. serial number EQUAL to that of the message in the validation context c. type of content EQUAL to that of the validation context message (see also the note below on status update messages) Note 1: For newly received status update messages, this element must be filled for the underlying content message type. For example, for a newly received "MovementAnnouncementStatus" message, this element must be filled for "MovementAnnouncement" records. See also the pseudo SQL below. Analogously, the EDI node must interpret/log status updates as interactions on records of the underlying content type. Note 2: This aggregation must take into account ALL records matching the above criteria, independent of entry through data interface or GUI, and independent of origin. Pseudo-SQL (assuming logging of record entries/updates in the EDI node DB): select min(UTCTIMESTAMP) from RECORD_CHANGE_LOG where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') Supported lexical representations and values:
Example value: »2022-04-21T11:01:35.524380Z« |
ShipmentRecordLatestUTCTimestamp | 0..1 | The timestamp of the latest record interaction (latest update, or initial entry if there are no updates) at the EDI node database, prior to the receipt of the new message, for records with a combination of the following: a. notification number EQUAL to that of the message in the validation context b. serial number EQUAL to that of the message in the validation context c. type of content EQUAL to that of the validation context message (see also the note below on status update messages) Note 1: For newly received status update messages, this element must be filled for the underlying content message type. For example, for a newly received "MovementAnnouncementStatus" message, this element must be filled for "MovementAnnouncement" records. See also the pseudo SQL below. Analogously, the EDI node must interpret/log status updates as interactions on records of the underlying content type. Note 2: This aggregation must take into account ALL records matching the above criteria, independent of entry through data interface or GUI, and independent of origin. Note 3: If there is exactly one record interaction (initial entry) that matches the criteria listed above, then the records' latest timestamp equals the earliest timestamp. Pseudo-SQL: select max(UTCTIMESTAMP) from RECORD_CHANGE_LOG where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') Supported lexical representations and values:
Example value: »2022-10-25T11:01:35.524380Z« |
SoftwareProductInteractionCount | 0..1 | The number of EDI node interactions to which ALL of the following applies: 1. The interaction is by an external EDI node, and the software product part of that EDI node's ID EQUALS that of the EDI node that submitted the message contained in the validation context 2. The content type, such as movement announcement, EQUALS that of the message contained in the validation context (see also the note below on status update messages) 3. The interaction timestamp is greater than or equal to the receipt timestamp of the validation context message minus 60 days Note 1: For newly received status update messages, this element must be filled for the underlying content message type. For example, for a newly received "MovementAnnouncementStatus" message, this element must be filled for "MovementAnnouncement" records. See also the pseudo SQL below. Analogously, the EDI node must interpret/log status updates as interactions on records of the underlying content type. Note 2: This aggregation must take into account ALL record interactions matching the above criteria, independent of origin party, notification number and serial number. Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and substr(EDI_NODE_ID,1,instr(EDI_NODE_ID,'.')-1)=substring-before(InteractingEDINodeID,'.') AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') |
SoftwareProductContentUpdateCount | 0..1 | This content of this element is similarly defined as that of SoftwareProductInteractionCount. The sole difference: In contrast to SoftwareProductInteractionCount, rather than counting all interactions, SoftwareProductContentUpdateCount only counts interactions of type "content update". Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and substr(EDI_NODE_ID,1,instr(EDI_NODE_ID,'.')-1)=substring-before(InteractingEDINodeID,'.') AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') and INTERACTION_TYPE_ID="content_update" |
SoftwareProductStatusUpdateCount | 0..1 | This content of this element is similarly defined as that of SoftwareProductInteractionCount. The sole difference: In contrast to SoftwareProductInteractionCount, rather than counting all interactions, SoftwareProductStatusUpdateCount only counts interactions of type "status update". Note 1: In its current version, the EDI protocol supports status updates only for movement announcements. For content types other than movement announcement (status), this element shall not be provided. Note 2: In its current version, the only type of status update the EDI protocol supports is the cancellation (of movement announcements). This count is hence a count of cancellations. Note 3: This count must only include successful status updates (cancellations). The count must not include unsuccessful cancellation attempts, such as the cancellation of previosuly cancelled announcements. Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and substr(EDI_NODE_ID,1,instr(EDI_NODE_ID,'.')-1)=substring-before(InteractingEDINodeID,'.') AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') and INTERACTION_TYPE_ID="status_update" |
CreationPartyInteractionCount | 0..1 | This content of this element is similarly defined as that of SoftwareProductInteractionCount. The sole difference: In contrast to SoftwareProductInteractionCount, rather than counting all interactions related to a specific EDI node, CreationPartyInteractionCount counts the interactions related to a specific message/record creation party. Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and CREATION_PARTY_ID=//MessageCreationPartyID AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') |
CreationPartyContentUpdateCount | 0..1 | This content of this element is similarly defined as that of CreationPartyInteractionCount. The sole difference: In contrast to CreationPartyInteractionCount, rather than counting all interactions, CreationPartyContentUpdateCount only counts interactions of type "content update". Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and CREATION_PARTY_ID=//MessageCreationPartyID AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') and INTERACTION_TYPE_ID="content_update" |
CreationPartyStatusUpdateCount | 0..1 | This content of this element is similarly defined as that of CreationPartyInteractionCount. The sole difference: In contrast to CreationPartyInteractionCount, rather than counting all interactions, CreationPartyStatusUpdateCount only counts interactions of type "status update". See also the notes on SoftwareProductStatusUpdateCount. Pseudo-SQL: select count(*) from RECORD_CHANGE_LOG where CONTENT_TYPE_ID=replace(local-name(//MessageCreationPartyID/following-sibling::*),'Status','') and CREATION_PARTY_ID=//MessageCreationPartyID AND UTCTIMESTAMP>=adjust-dateTime-to-timezone(current-dateTime(), xs:dayTimeDuration('PT0H'))-xs:dayTimeDuration('P60D') and INTERACTION_TYPE_ID="status_update" |
ValidationNodeAggregatedChangeData usage occurrences: MessageValidationContext
ValidationNodeAggregatedContentData
An aggregation of DATA (record CONTENTS) available in the database at a WasteX EDI node.
Name/Type | min..max | Definition |
---|---|---|
TotalWasteMass | 0..1 | The total mass of shipped waste as calculated from "active" movement announcements and waste receipt confirmations with a notification number EQUAL to that from the message in the validation context and a serial number NOT EQUAL to the serial number from the message in the validation context. Note 1: "active" refers to a state of not being cancelled, not being withdrawn, etc, and to the availability of at least one of the types of messages (MA, CaC, CoWR, CoWD) for the respective serial number. Note 2: The received mass of waste has precedence over the announced mass of waste. I.e., for all shipments for which a received mass of waste is available, it is the received mass of waste that is used in the sum. See also the Pseudo-SQL statement below. Pseudo-SQL: select sum(case when WASTE_MASS_RECEIVED is not null then WASTE_MASS_RECEIVED else WASTE_MASS_ANNOUNCED) from SHIPMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID!=//AnnouncementIdentity/SequenceNumberID and STATUS_ID="active" |
TotalWasteVolume | 0..1 | The total volume of shipped waste as calculated from "active" movement announcements and waste receipt confirmations with a notification number EQUAL to that from the message in the validation context and a serial number NOT EQUAL to the serial number from the message in the validation context. Note 1: "active" refers to a state of not being cancelled, not being withdrawn, etc, and to the availability of at least one of the types of messages (MA, CaC, CoWR, CoWD) for the respective serial number. Note 2: The received volume of waste has precedence over the announced volume of waste. I.e., for all shipments for which a received volume of waste is available, it is the received volume of waste that is used in the sum. See also the Pseudo-SQL statement below. Pseudo-SQL: select sum(case when WASTE_VOLUME_RECEIVED is not null then WASTE_VOLUME_RECEIVED else WASTE_VOLUME_ANNOUNCED) from SHIPMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID!=//AnnouncementIdentity/SequenceNumberID and STATUS_ID="active" |
MovementCount | 0..1 | The total number of "active" shipments (serial numbers) with a notification number EQUAL to that from the message in the validation context and with a serial number NOT EQUAL to the serial number from the message in the validation context. Note: "active" refers to a state of not being cancelled, not being withdrawn, etc, and to the availability of at least one of the types of messages (MA, CaC, CoWR, CoWD) for the respective serial number. Pseudo-SQL: select count(SEQUENCE_NUMBER_ID) from SHIPMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID!=//AnnouncementIdentity/SequenceNumberID and STATUS_ID="active" |
MaximumSequenceNumberID | 0..1 | The highest already-used serial number occuring in shipment data (MA, CaC, CoWR, CoWT) with a notification number EQUAL to that from the message in the validation context and a serial number LOWER THAN the serial number to which the message in the validation context refers. Note 1: "Highest" refers to numerical ordering of the serial numbers. Note 2: In contrast to many of the other aggregated values, the calculation MUST take "inactive" shipments, such as cancelled shipments, into account. Note 3: A serial number counts as "already used" when at least one of MA, CaC, CoWR, CoWT is available for that serial number. Pseudo-SQL: select max(SEQUENCE_NUMBER_ID) from SHIPMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID<//AnnouncementIdentity/SequenceNumberID |
ValidationNodeAggregatedContentData usage occurrences: MessageValidationContext
ValidationNodeIndividualData
Individual records of data available in the database at an EDI node prior to receiving a WasteX message and related to that message, i.e., related to the notification number and serial number contained in the message.
Examples:
Name/Type | min..max | Definition |
---|---|---|
NotificationInDatabaseIndicator | 0..1 | The indication of whether or not a notification with the notification number contained in the received message is found at the data interchange node conducting the validation. "true" stands for found in the database. Pseudo-SQL: select count(*) from NOTIFICATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID |
Notification | 0..1 | Latest notification information read from the database at the EDI node, for the notification to which the WasteX message refers. |
MovementAnnouncementInDatabaseIndicator | 0..1 | The indication of whether or not a movement announcement with the combination of notification number and serial number as contained in the received message is found at the data interchange node conducting the validation. "true" stands for found in the database. Pseudo-SQL: select count(*) from MOVEMENT_ANNOUNCEMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
MovementAnnouncement | 0..1 | Latest movement announcement information read from the database at the EDI node for the notification number and serial number referred to in the validation context message. |
CarrierConfirmationInDatabaseCount | 0..1 | The number of distinct carrier confirmations, with the combination of notification number and serial number as contained in the received message, found in the database at the data interchange node conducting the validation. Pseudo-SQL: select count(distinct CONFIRMATION_UUID) from CARRIER_CONFIRMATION where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
CarrierConfirmation | 0..1 | Latest carrier confirmation read from the database at the EDI node for the notification number, serial number and carrier confirmation UUID referred to in the validation context message. |
ConfirmationOfWasteReceiptInDatabaseIndicator | 0..1 | The indication of whether or not a confirmation of waste receipt with the combination of notification number and serial number contained in the received message is found at the data interchange node conducting the validation. "true" stands for found in the database. Pseudo-SQL: select count(*) from CONFIRMATION_OF_RECEIPT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID |
ConfirmationOfWasteReceipt | 0..1 | Latest confirmation of waste receipt information read from the database at the EDI node for the notification number and serial number referred to in the validation context message. |
FacilityConfirmationOfWasteTreatmentInDatabaseIndicator | 0..1 | The indication of whether or not a confirmation of the completion of interim waste treatment at the facility NOT covering subsequent treatment, with the combination of notification number and serial number as contained in the received message, is found at the data interchange node conducting the validation. "true" stands for found in the database. Pseudo-SQL: select count(*) from CONFIRMATION_OF_TREATMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and SCOPE_ID="FACILITY" |
FacilityConfirmationOfWasteTreatment | 0..1 | Latest confirmation of waste treatment information read from the database at the EDI node for the notification number and serial number referred to in the validation context message, and for a SCOPE_ID matching the "FACILITY" value, i.e., for the completion of interim treatment NOT covering subsequent treatment. |
EntireConfirmationOfWasteTreatmentInDatabaseIndicator | 0..1 | The indication of whether or not a confirmation of the completion of the ENTIRE waste treatment in the country of destination, with the combination of notification number and serial number as contained in the received message, is found at the data interchange node conducting the validation. "true" stands for found in the database. Pseudo-SQL: select count(*) from CONFIRMATION_OF_TREATMENT where NOTIFICATION_NR=//AnnouncementIdentity/NotificationID and SEQUENCE_NUMBER_ID=//AnnouncementIdentity/SequenceNumberID and SCOPE_ID="ENTIRE" |
EntireConfirmationOfWasteTreatment | 0..1 | Latest confirmation of waste treatment information read from the database at the EDI node for the notification number and serial number referred to in the validation context message, and for a SCOPE_ID matching the "ENTIRE" value, i.e., for the completion of all non-interim recovery or disposal in the country of destination. |
ValidationNodeIndividualData usage occurrences: MessageValidationContext
ValidationNodeReferenceData
Reference data used at the EDI node receiving a WasteX message and conducting the validation.
Example:
Name/Type | min..max | Definition |
---|---|---|
CountryList | 0..1 | The list of ISO 3166-1 3-digit country codes "known" at the validating node. "Known" means that software can look these codes up and for example translate them into country names, such as for displaying these names in user interfaces. Note 1: The set of values supported in the WasteX message format is defined by EUDIN ↗codelist 3862, which reproduces the entries of ISO 3166-1. Nodes in the exchange of WasteX messages should therefore keep country codelists in synch with EUDIN ↗codelist 3862. A codelist web service is available for this synchronisation. Note 2: In the WasteX message formats, country IDs only occur in Movement Announcement messages in relation to point of exit and point of entry for each country. Therefore, for message types other than Movement Announcement, there is no need to fill the ValidationNodeCountryIDList element. Note 3: An EDI node conducting formal validation via XSL transformation MAY increase the validation efficiency by filling the validation context ValidationNodeCountryIDList element only with values that occur BOTH in the validated message AND in the list of values "known" to the validating EDI node (intersection of the two sets of values). The pseudo-sql below illustrates the non-optimized version, in which the element is filled with ALL values "known" to the validating EDI node. Pseudo-SQL: select ISO3611_3DIGIT_ID, VALIDITY_START_DATE, VALIDITY_END_DATE from REF_COUNTRIES |
ValidationNodeReferenceData usage occurrences: MessageValidationContext
VolumeValueAssignmentStatement
A volume value assignment statement, e.g. "80 m³".
Name/Type | min..max | Definition |
---|---|---|
NumericValue | 1..1 | The volume expressed as number in combination with a unit, e.g. "80m³". Note 1: Due to the use of a numeric data type, the precision/uncertainty of results (significant digits) CANNOT be expressed via the notation of the numeric value. For example, the two literals 30.00 and 30.0 are interpreted as the same numerical value. Supported lexical representations and values for the NumericValue content:
Example value: »80.1« Note 2: A case sensitive ISO/UCUM code identifies the unit in attribute @unitID, e.g. "m3". See EUDIN ↗codelist 4472. The set of supported values for attribute @unitID:
|
QuantificationTypeID | 0..1 | The type of quantification used for determining the waste volume (see also EUDIN ↗codelist 7299): The set of supported lexical representations and values:
|
VolumeValueAssignmentStatement usage occurrences: ConfirmationOfWasteReceipt, LatestConfirmationOfWasteReceipt, LatestMovementAnnouncement, MovementAnnouncement
WithdrawalMarkList
Identification of waste movement announcements for which all exchanged data should be marked as withdrawn by an EDI partner, potentially including confirmations of waste receipt and confirmations of waste treatment.
Note 1: This serves the purpose of letting EDI partners know that certain IDs, especially waste shipment announcement serial numbers, have been used erronously in EDI transmissions.
Note 2: As erronous use of identifiers is expected to prevented as much as possible in the first place, marking EDI transmissions as withdrawn should occur in rare exceptions only.
Name/Type | min..max | Definition |
---|---|---|
NotificationID | 1..1 | The identifier of the notification as assigned by the competent authority of dispatch Note: The identified notification is the permit for the announced shipment of waste. |
SequenceNumberID | 1..16384 | The serial number (sequential number) of the announced shipment for the specified notification. Example: Serial number 1 must be assigned to the first shipment announcement for a specific notification, serial number 2 to the second announced shipment, etc. |
WithdrawalMarkList usage occurrences: WithdrawalMarkCollection
CountContent
Name/Type | min..max | Definition |
---|---|---|
CountContent xs:integer | 1..1 | Number (decimal). The following properties must apply:
|
CountContent usage occurrences: LatestNotification, MovementAnnouncement, ValidationNodeAggregatedChangeData, ValidationNodeAggregatedContentData, ValidationNodeIndividualData
CountIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
CountIdentifierContent xs:nonNegativeInteger | 1..1 | A sequential number used as an identifier. The following properties must apply:
|
CountIdentifierContent usage occurrences: AnnouncementIdentity, WithdrawalMarkList
CountryIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
CountryIdentifierContent xs:string | 1..1 | Identification of a country via an ISO 3166-1 3-digit-identifier. Examples:
|
CountryIdentifierContent usage occurrences: CountryListElement, NationalRoute, NotificationCountry
CountryTwoLetterIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
CountryTwoLetterIdentifierContent xs:string | 1..1 | Identification of a country via an ISO 3166-1 two-letter identifier ("alpha-2"). Examples:
|
CountryTwoLetterIdentifierContent usage occurrences: CountryListElement
DateContent
Name/Type | min..max | Definition |
---|---|---|
DateContent xs:date | 1..1 | Date, i.e. identification of a day, without time zone indication. Note: This date datatype is used for providing local dates. For example, for the date of receipt of waste, this is the current local date at the location where the waste was received at the point in time when the waste was received. |
DateContent usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, CountryListElement, LatestCarrierConfirmation, LatestConfirmationOfWasteReceipt, LatestConfirmationOfWasteTreatment, LatestMovementAnnouncement, LatestNotification, MovementAnnouncement
DescriptionContent
Name/Type | min..max | Definition |
---|---|---|
DescriptionContent xs:string | 1..1 | Description text. The following properties must apply to description texts:
|
DescriptionContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, WasteMovementSignalMessage
EconomicOperatorIdentifier
Name/Type | min..max | Definition |
---|---|---|
EconomicOperatorIdentifier | 1..1 | Identification of an economic operator, together with the identification of the type of identifier in the registerID attribute. Example: Identification of a legal entity such as a company. Note 1: This datatype is not used for the identification of competent authorities. There is a separate identifier datatype for this purpose. Note 2: In this data format the type of identifiers to use for parties is determined by the country in which the legal entity has its registered office. Example: Economic operators that have their registered office in Austria must be identified by GLN.AT, the Austrian public administration Global Location Number ("GLN der öffentlichen Verwaltung"). The full information on which types of identifiers MUST be used in which cases is provided in the data format description document (PDF). |
@registerID | 1..1 | Identification of the registration process through which the identifier has been assigned to the party. Note: In this data format the type of identifiers to use for parties is determined by the country in which the legal entity has its registered office. This means that the set of supported register identifiers (see below) determines the set of countries supported in the data format. Only legal entities that have their registered office in one of these countries can be referenced in the data instances. This data format can only be used for data interchange if all the companies involved in the shipments have their registered office in one of the supported countries. The list of supported registers and thus countries will be extended with coming versions of the data format. Examples of supported values (see EUDIN ↗codelist 2237 for the full list):
|
EconomicOperatorIdentifier usage occurrences: CarrierConfirmation, CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, EconomicOperatorSiteIdentity, LatestTransportMovement, TransportMovement, WasteMovementUserMessage
EconomicOperatorRegisterIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
EconomicOperatorRegisterIdentifierContent xs:string | 1..1 | Identification of a registration process through which an identifier has been assigned to an economic operator (EUDIN ↗codelist 2237). Example values:
|
EconomicOperatorRegisterIdentifierContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorIdentifier, EconomicOperatorSite, LatestTransportMovement
IndicatorContent
Name/Type | min..max | Definition |
---|---|---|
IndicatorContent xs:boolean | 1..1 | Yes/No value (Yes: property applies; No: property does not apply). |
IndicatorContent usage occurrences: ConfirmationOfWasteReceipt, LatestConfirmationOfWasteReceipt, LatestNotification, ValidationNodeIndividualData, WasteMovementSignalMessage
MassNumericValue
Name/Type | min..max | Definition |
---|---|---|
MassNumericValue | 1..1 | A mass quantity expressed as numerical value in combination with a metrological unit, such as in "20t". |
@unitID | 1..1 | The metrological unit to which the numerical value refers in the specification of the mass. Note: The metrological unit is expressed by a case sensitive Unified Code for Units of Measure (UCUM). The set of supported lexical representations and values:
|
MassNumericValue usage occurrences: LatestNotification, MassValueAssignmentStatement, ValidationNodeAggregatedContentData
MassUnitIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
MassUnitIdentifierContent xs:string | 1..1 | Enumeration of quantity units for mass quantities. Note: The metrological unit is expressed by a case sensitive Unified Code for Units of Measure (UCUM). The set of supported lexical representations and values:
|
MassUnitIdentifierContent usage occurrences: MassNumericValue
MovementAnnouncementStatusIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
MovementAnnouncementStatusIdentifierContent xs:string | 1..1 | Movement announcement status enumeration:
|
MovementAnnouncementStatusIdentifierContent usage occurrences: LatestMovementAnnouncement
MaxLen1000TextContent
Name/Type | min..max | Definition |
---|---|---|
MaxLen1000TextContent xs:string | 1..1 | Text consisting of a maximum of 1000 characters. The following properties must apply:
|
MaxLen1000TextContent usage occurrences: WasteMovementUserMessage
MovementAnnouncementUpdateStatusIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
MovementAnnouncementUpdateStatusIdentifierContent xs:string | 1..1 | Movement announcement status enumeration:
|
MovementAnnouncementUpdateStatusIdentifierContent usage occurrences: MovementAnnouncementStatus
NameContent
Name/Type | min..max | Definition |
---|---|---|
NameContent xs:token | 1..1 | Name. The following properties must apply to names:
|
NameContent usage occurrences: CarrierEconomicOperator, EconomicOperator, EconomicOperatorSite, NationalRoute, NotificationCountry
PackageTypeIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
PackageTypeIdentifierContent xs:string | 1..1 | Enumeration of types of packages, pursuant to WSR Annex IA and IB. See also EUDIN ↗codelist 6524. Note: In the definition of this data format, the list of types of packages is defined as a static list on purpose. This means that new codes can only be supported through updates of the data format specification, and are not supported independent of the data format specification. The set of supported lexical representations and values:
|
PackageTypeIdentifierContent usage occurrences: LatestNotification, MovementAnnouncement
PartyIdentifier
Name/Type | min..max | Definition |
---|---|---|
PartyIdentifier | 1..1 | Identification of a party, together with the identification of the type of identifier in the registerID attribute. Example: Identification of a legal entity such as a company. Note 1: This datatype is used for both economic operators and competent authorities. Note 2: In this data format the type of identifiers to use for economic operators is determined by the country in which the legal entity has its registered office. Example: Economic operators that have their registered office in Austria must be identified by GLN.AT, the Austrian public administration Global Location Number ("GLN der öffentlichen Verwaltung"). The full information on which types of identifiers MUST be used in which cases is provided in the data format description document (PDF). |
@registerID | 1..1 | Identification of the registration process through which the identifier has been assigned to the party. The set of supported values for authorities:
Examples of supported values for economic operators (see EUDIN ↗codelist 2237 for the full list):
|
PartyIdentifier usage occurrences: DatabaseInstancePartyList
PartyRegisterIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
PartyRegisterIdentifierContent xs:string | 1..1 | Identification of a registration process through which an identifier has been assigned to a party. The set of supported values for authorities:
Examples of supported values for economic operators (see EUDIN ↗codelist 2237 for the full list):
|
PartyRegisterIdentifierContent usage occurrences: PartyIdentifier
PostalAreaIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
PostalAreaIdentifierContent xs:token | 1..1 | Postcode. The following properties must apply to postcodes:
|
PostalAreaIdentifierContent usage occurrences: EconomicOperatorSite, EconomicOperatorSiteIdentity
QuantificationTypeIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
QuantificationTypeIdentifierContent xs:string | 1..1 | Enumeration of types of quantification. See also EUDIN ↗codelist 7299. The set of supported lexical representations and values:
|
QuantificationTypeIdentifierContent usage occurrences: MassValueAssignmentStatement, VolumeValueAssignmentStatement
RelaxedIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
RelaxedIdentifierContent xs:token | 1..1 | Value range to which all tokens consisting of a maximum of 64 characters belong. Exception: The string consisting of 0 characters. Note: A token is a string that does not contain carriage return (#xD), line feed (#xA) or tab (#x9) characters, does not begin or end with spaces (#x20), and does not contain a sequence of two or more consecutive spaces. |
RelaxedIdentifierContent usage occurrences: AnnouncementIdentity, CarrierConfirmation, DatabaseInstancePartyList, EconomicOperatorIdentifier, MessageValidationContext, PartyIdentifier, WithdrawalMarkList
RemarkContent
Name/Type | min..max | Definition |
---|---|---|
RemarkContent xs:string | 1..1 | Remark text. The following properties must apply to annotation texts:
|
RemarkContent usage occurrences: CarrierConfirmation, ConfirmationOfWasteReceipt, ConfirmationOfWasteTreatment, MovementAnnouncement, MovementAnnouncementStatus
ShortNameContent
Name/Type | min..max | Definition |
---|---|---|
ShortNameContent xs:token | 1..1 | Short name. The following properties must apply to short names:
|
ShortNameContent usage occurrences: MessageValidationContext, WasteMovementSignalMessage
SignalIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
SignalIdentifierContent xs:string | 1..1 | Enumeration of signals sent by an EDI node as a response to receiving a user message. The set of supported lexical representations and values:
|
SignalIdentifierContent usage occurrences: WasteMovementSignalMessage
TimestampContentType
Name/Type | min..max | Definition |
---|---|---|
TimestampContentType xs:dateTime | 1..1 | Timestamp (date and time), with fraction of a second, with time zone indication for UTC. Note: This information is generated automatically by software. Users must not be able to edit this information. |
TimestampContentType usage occurrences: MessageValidationContext, ValidationNodeAggregatedChangeData, WasteMovementSignalMessage, WasteMovementUserMessage, 🠖InitSyncRequestType, 🠖UpdateEventType
TransportModeIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
TransportModeIdentifierContent xs:string | 1..1 | Enumeration of modes of transport, pursuant to WSR Annex IA and IB. Ssee also EUDIN ↗codelist 8149. The set of supported lexical representations and values:
|
TransportModeIdentifierContent usage occurrences: CarrierConfirmation, CarrierEconomicOperator, LatestCarrierConfirmation, LatestTransportMovement, TransportMovement
TreatmentScopeIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
TreatmentScopeIdentifierContent xs:string | 1..1 | Enumeration of scopes of waste treatment. The set of supported lexical representations and values:
|
TreatmentScopeIdentifierContent usage occurrences: ConfirmationOfWasteTreatment
UserMessageTypeIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
UserMessageTypeIdentifierContent xs:string | 1..1 | Enumeration of types of WasteX waste movement user messages. The set of supported lexical representations and values:
|
UserMessageTypeIdentifierContent usage occurrences: WasteMovementSignalMessage
UUIDIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
UUIDIdentifierContent xs:string | 1..1 | A Universally Unique Identifier (UUID) in canonical representation. The set of supported lexical representations and values: Character strings that are a canonical representation of a version 4 (random) Universally Unique Identifier (UUID). Note that each such character string consists of exactly 36 characters. Any character string of a length other than 36 is hence not one of the supported values. Example value: »aeca8c2d-523a-431a-812e-abd8a2475722« |
UUIDIdentifierContent usage occurrences: CarrierConfirmation, MovementAnnouncement, WasteMovementSignalMessage, WasteMovementUserMessage, 🠖InitSyncResponseType
ValidationResultIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
ValidationResultIdentifierContent xs:string | 1..1 | Enumeration of results of waste movement user message validation. The set of supported lexical representations and values:
|
ValidationResultIdentifierContent usage occurrences: WasteMovementSignalMessage
ValueContent
Name/Type | min..max | Definition |
---|---|---|
ValueContent xs:decimal | 1..1 | Decimal number, e.g. measured, calculated or fixed value. The following properties must apply:
|
ValueContent usage occurrences: MassNumericValue, VolumeNumericValue
VersionIdentifier
Name/Type | min..max | Definition |
---|---|---|
VersionIdentifier xs:token | 1..1 | Version information. The version information consists of a maximum of 8 characters. It is composed of the following parts: "Major Version", followed by a dot (#x2E), followed by the "Minor Version". Both "Major Version" and "Minor Version" consist exclusively of digits. "Minor Version" consists of exactly 2 digits. |
VersionIdentifier usage occurrences: MessageValidationContext, WasteMovementSignalMessage, WasteMovementUserMessage
VolumeNumericValue
Name/Type | min..max | Definition |
---|---|---|
VolumeNumericValue | 1..1 | A volume expressed as numerical value in combination with a metrological unit, such as in "80m³". |
@unitID | 1..1 | The metrological unit to which the numerical value refers in the specification of the volume. Note: The metrological unit is expressed by a case sensitive Unified Code for Units of Measure (UCUM). The set of supported lexical representations and values:
|
VolumeNumericValue usage occurrences: LatestNotification, ValidationNodeAggregatedContentData, VolumeValueAssignmentStatement
VolumeUnitIdentifierContent
Name/Type | min..max | Definition |
---|---|---|
VolumeUnitIdentifierContent xs:string | 1..1 | Enumeration of quantity units for volume quantities. Note: The metrological unit is expressed by a case sensitive Unified Code for Units of Measure (UCUM). The set of supported lexical representations and values:
|
VolumeUnitIdentifierContent usage occurrences: VolumeNumericValue
Description of the formal validation rules that the WasteX web service applies to User Message transmissions.
Contains one or more sample validation protocol entries for each of the defined formal validation rules.
The interface specification authors have created this description in an automated way, based on the sample XML files included in the specification package and the formal validation rules defined per Schematron file wastex_formalvalidationrules.sch.
Each of the validation report entries contains a link to the respective validation result in Schematron Validation Report Language (SVRL) format. These SVRL instances result from applying wastex_formalvalidationrules.xsl to the respective linked sample user messages. Applying an additional XSL transformation yields the HTML representations.
WasteX web services deliver the results of formal validation in SVRL format, as part of Signal Messages in the MessageFormalValidationReport element.
The specification authors have conducted all XSL transfromations with the ↗Saxon XSLT processor.
Validated XML File | IDs of violated rules | Result ID | Main validation report entry text | Validation report HTML and SVRL files |
example_A_MovementAnnouncement.xml | OK | .html / .xml | ||
example_B_MovementAnnouncementStatus.xml | OK | .html / .xml | ||
example_C_CarrierConfirmation.xml | OK | .html / .xml | ||
example_D_ConfirmationOfWasteReceipt.xml | OK | .html / .xml | ||
example_E_ConfirmationOfWasteTreatment.xml | OK | .html / .xml | ||
OK_aa_A_MovementAnnouncement.xml | OK | .html / .xml | ||
OK_ab_A_MovementAnnouncement.xml | OK | .html / .xml | ||
OK_ac_A_MovementAnnouncement.xml | OK | .html / .xml | ||
OK_ad_C_CarrierConfirmation.xml | OK | .html / .xml | ||
violate_R011a_C_CarrierConfirmation.xml | R011 | WARNING | The carrier confirmation message refers to the combination of notification number »IT 347203« and serial number »3«. The transmission of the carrier confirmation message is late because for this combination of notification number and serial number the database at »EDM.GV.AT« already contains the following: confirmation of waste receipt, confirmation of the completion of waste treatment. | .html / .xml |
violate_R013a_A_MovementAnnouncement.xml | R013 | WARNING | The movement announcement message refers to the combination of notification number »IT 347203« and serial number »4«. The transmission of the movement announcement message is late because for this combination of notification number and serial number the database at »EDM.GV.AT« already contains the following: carrier confirmation, confirmation of waste receipt, confirmation of the completion of waste treatment. | .html / .xml |
violate_R017a_A_MovementAnnouncement.xml | R017 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks information on the waste production (WasteProductionPartySite elements). | .html / .xml |
violate_R044a_A_MovementAnnouncement.xml | R044 | INFO | In the route information with points of exit and points of entry (NationalRoute elements) contained in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the following countries, represented with their ISO 3166-1 3-digit codes and two-letter-codes, occur more than once: 380 (IT). | .html / .xml |
violate_R044b_A_MovementAnnouncement.xml | R044 | INFO | In the route information with points of exit and points of entry (NationalRoute elements) contained in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the following countries, represented with their ISO 3166-1 3-digit codes and two-letter-codes, occur more than once: 380 (IT), 040 (AT). | .html / .xml |
violate_R044c_A_MovementAnnouncement.xml | R044 | INFO | In the route information with points of exit and points of entry (NationalRoute elements) contained in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the following countries, represented with their ISO 3166-1 3-digit codes, occur more than once: 380, 040. | .html / .xml |
violate_R047a_D_ConfirmationOfWasteReceipt.xml | R047 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the waste receipt date (ReceiptDate element). | .html / .xml |
violate_R060a_C_CarrierConfirmation.xml | R060 | ERROR | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« lacks transport mode information (TransportModeID element). | .html / .xml |
violate_R066a_A_MovementAnnouncement.xml | R066 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains country entry point and exit point information for a single country only. | .html / .xml |
violate_R074a_D_ConfirmationOfWasteReceipt.xml | R074 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains the planned date of waste treatment completion »2023-04-23«. The message also contains the waste receipt date »2023-04-27«. According to this data, the treatment is completed 4 days before waste receipt. This error triggers for a waste treatment completion that is 2 or more days before waste receipt, leaving 1 day tolerance for time zone date progression differences. | .html / .xml |
violate_R081a_A_MovementAnnouncement.xml | R081 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the post code (SitePostalAreaID element) for waste production site no. 1, which refers to the waste production party with ID »IT02795790241« (»VAT.EU«). | .html / .xml |
violate_R081b_A_MovementAnnouncement.xml | R081 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the post code (SitePostalAreaID element) for waste production site no. 2, which refers to the waste production party with ID »IT02795790241« (»VAT.EU«). | .html / .xml |
violate_R085a_A_MovementAnnouncement.xml | R085 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a waste production party with ID »IT02795790241« (»VAT.EU«) in combination with a production site with post code »25071«. The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« contains multiple waste production party and site combinations matching this party ID and site post code. As a result, the movement announcement does not uniquely reference a waste production entry of the notification. | .html / .xml |
violate_R100a_D_ConfirmationOfWasteReceipt.xml | R100 | ERROR | The confirmation of waste receipt message refers to notification number »IT 347203« and serial number »3«. In the database at »EDM.GV.AT« the movement announcement for this combination of notification number and serial number is recorded as cancelled. As a result, »EDM.GV.AT« cannot accept new messages referring to this combination of notification number and serial number. | .html / .xml |
violate_R112a_A_MovementAnnouncement.xml | R112 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the exit point name (ExitPointName element) for route part no. 1 in country IT (ID »380«). | .html / .xml |
violate_R114a_E_ConfirmationOfWasteTreatment.xml | R114 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains creation timestamp »2023-04-29T13:28:27.415427Z« which lies in the future, i.e., it is greater than message receipt timestamp »2023-04-27T13:28:26.273487Z«. | .html / .xml |
violate_R118a_A_MovementAnnouncement.xml | R118 | ERROR | In the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the following combinations of waste production party ID and waste production site postcode (WasteProductionPartySite elements) occur more than once: IT02795790241, 25071. | .html / .xml |
violate_R129a_E_ConfirmationOfWasteTreatment.xml | R129 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« lacks treatment party and site information (TreatmentPartySite element). | .html / .xml |
violate_R136a_D_ConfirmationOfWasteReceipt.xml | R136 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the post code for the waste receipt site (SitePostalAreaID element). | .html / .xml |
violate_R148a_C_CarrierConfirmation.xml | R148 | WARNING | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« refers to the carrier party with ID »IT00623920212« (»VAT.EU«). This does not match any of the carriers in the movement announcement information for the combination of notification number »IT 347203« and serial number »3« in the database at »EDM.GV.AT«. Note that for party IDs to match, the transmitted message must contain the correct type of ID (WasteX relevant ID or recipient specific ID), and »EDM.GV.AT« must contain unique party IDs with the correct types as well. | .html / .xml |
violate_R158a_A_MovementAnnouncement.xml | R158 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains shipment start date »2023-05-01«. The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« defines »2023-04-28« as the last day at which shipments are permitted. According to these records, the shipment will take place after the consented shipment period. | .html / .xml |
violate_R170a_A_MovementAnnouncement.xml | R170 | WARNING | The movement announcement message refers to notification number »IT 347203« and serial number »1001«. In the database at »EDM.GV.AT« the notification/consent entry for »IT 347203« the total consented number of shipments is »1000«, which the serial number »1001« exceeds. | .html / .xml |
violate_R200a_D_ConfirmationOfWasteReceipt.xml | R200 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains creation timestamp »2023-04-19T13:28:27.564030Z«. According to this message creation timestamp and the message receipt timestamp »2023-04-27T13:28:26.226612Z« more than 7 days have elapsed between message creation and message receipt. This warning triggers for time differences of 5 or more days. | .html / .xml |
violate_R207a_A_MovementAnnouncement.xml | R207 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to 25.0t of waste. According to the notification in the database at »EDM.GV.AT« the total consented amount of waste is 10,000.0t. According to the shipment information in the database at »EDM.GV.AT« a total of 9,990.0t has already been announced or confirmed in receipt previously. As a result, the movement announcement exceeds the total consented amount of waste. | .html / .xml |
violate_R219a_A_MovementAnnouncement.xml | R219 | ERROR | 2023-04-25The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains shipment start date »2023-04-23«. The message receipt timestamp is »2023-04-27T13:28:26.088980Z«, which means that more than 4 days have elapsed between shipment start date and message receipt. This error triggers for a time difference of more than 1 day. Note that pursuant to provisions such as the WSR the information must be exchanged as an announcement, i.e., BEFORE the start of the shipment. | .html / .xml |
violate_R226a_E_ConfirmationOfWasteTreatment.xml | R226 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« refers to treatment at one facility, NOT including subsequent treatment (value »FACILITY« in element ScopeID). According to the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, there is NO subsequent treatment of waste for shipments under this consent. Confirmations of the completion of waste treatment must therefore refer to the completion of the ENTIRE treatment in the country of destination (Art. 16(e) WSR), by featuring the value »ENTIRE« in the ScopeID element. | .html / .xml |
violate_R241a_A_MovementAnnouncement.xml | R241 | INFO | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to an entry point name »Kiefersfelden« for country DE (ID »276«). This does not match any of the entry point names - »Achenpass« - from the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«. | .html / .xml |
violate_R247a_A_MovementAnnouncement.xml | R247 | ERROR | In the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the first part of the route information refers to the country AT (ID »040«). The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« contains country of dispatch IT (ID »380«). The route must start in the country of dispatch. | .html / .xml |
violate_R249a_D_ConfirmationOfWasteReceipt.xml | R249 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks information on the received volume of waste (ReceivedWasteVolume element), despite the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« containing a consented maximum total volume of waste. | .html / .xml |
violate_R253a_C_CarrierConfirmation.xml | R253 | ERROR | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« contains transfer date »2023-03-26«. The message receipt timestamp is »2023-04-27T13:28:26.174753Z«, which means that more than 32 days have elapsed between transfer date and message receipt. This error triggers for a time difference of more than 30 days. Note that there are many provisions in practice, such as WSR or consent provisions, that can require transmissions sooner than within 30 days. | .html / .xml |
violate_R253b_D_ConfirmationOfWasteReceipt.xml | R253 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains waste receipt date »2023-03-26«. The message receipt timestamp is »2023-04-27T13:28:26.226612Z«, which means that more than 32 days have elapsed between waste receipt date and message receipt. This error triggers for a time difference of more than 30 days. Note that there are many provisions in practice, such as WSR or consent provisions, that can require transmissions sooner than within 30 days. | .html / .xml |
violate_R253c_E_ConfirmationOfWasteTreatment.xml | R253 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains treatment completion date »2023-03-26«. The message receipt timestamp is »2023-04-27T13:28:26.273487Z«, which means that more than 32 days have elapsed between treatment completion date and message receipt. This error triggers for a time difference of more than 30 days. Note that there are many provisions in practice, such as WSR or consent provisions, that can require transmissions sooner than within 30 days. | .html / .xml |
violate_R259a_A_MovementAnnouncement.xml | R259 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a waste production party with ID »IT02244220212« (»VAT.EU«) in combination with a production site with post code »25071«. This does not match any of the waste production party-site-combinations in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«. Note that for party IDs to match, the transmitted message must contain the correct type of ID (WasteX relevant ID or recipient specific ID), and »EDM.GV.AT« must contain unique party IDs with the correct types as well. | .html / .xml |
violate_R259b_A_MovementAnnouncement.xml | R259 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a waste production party with ID »IT02795790241« (»VAT.EU«) in combination with a production site with post code »25070«. This does not match any of the waste production party-site-combinations in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«. Note that for party IDs to match, the transmitted message must contain the correct type of ID (WasteX relevant ID or recipient specific ID), and »EDM.GV.AT« must contain unique party IDs with the correct types as well. | .html / .xml |
violate_R279a_D_ConfirmationOfWasteReceipt.xml | R279 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« refers to the waste receiver party with ID »IT02244220212« (»VAT.EU«). This does not match the message creation party with ID »DE140462045« (»VAT.EU«). | .html / .xml |
violate_R305a_E_ConfirmationOfWasteTreatment.xml | R305 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« refers to the completion of the ENTIRE treatment in the country of destination (value »ENTIRE« in element ScopeID). According to the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, there is subsequent treatment of waste for shipments under this consent. This version of the WasteX specification does NOT support confirmations of the completion of subsequent treatment (Art. 15(e) WSR), but rather supports confirmations of the completion of interim treatment only (Art. 15(d) WSR). For the confirmation of the completion of interim treatment, the ScopeID element must feature the value »FACILITY«. | .html / .xml |
violate_R307a_D_ConfirmationOfWasteReceipt.xml | R307 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the planned date of completing waste treatment (PlannedTreatmentCompletionDate element). | .html / .xml |
violate_R323a_C_CarrierConfirmation.xml | R323 | ERROR | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« contains transfer date »2023-05-01« which lies in the future, i.e., it is greater than message receipt timestamp »2023-04-27T13:28:26.174753Z«. | .html / .xml |
violate_R323b_D_ConfirmationOfWasteReceipt.xml | R323 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains waste receipt date »2023-04-29« which lies in the future, i.e., it is greater than message receipt timestamp »2023-04-27T13:28:26.226612Z«. | .html / .xml |
violate_R323c_E_ConfirmationOfWasteTreatment.xml | R323 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains treatment completion date »2023-04-29« which lies in the future, i.e., it is greater than message receipt timestamp »2023-04-27T13:28:26.273487Z«. | .html / .xml |
violate_R342a_A_MovementAnnouncement.xml | R342 | INFO | The movement announcement message refers to notification number »IT 347203« and serial number »4«. Content of the respective type already exists in the database at »EDM.GV.AT« and has been updated at least once prior to the receipt of the new message. The WasteX protocol expects single transmissions of 'final' information as the standard case, and the avoidance of update/correction-transmissions to the greatest extent possible. | .html / .xml |
violate_R356a_C_CarrierConfirmation.xml | R356 | ERROR | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« refers to the carrier with ID »IT00623920212« (»VAT.EU«). This does not match any of the carriers in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«. Note that for party IDs to match, the transmitted message must contain the correct type of ID (WasteX relevant ID or recipient specific ID), and »EDM.GV.AT« must contain unique party IDs with the correct types as well. | .html / .xml |
violate_R369a_A_MovementAnnouncement.xml | R369 | ERROR | The route information in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a country with ISO 3166-1 3-digit code »383«. A country with this ID does not exist in the reference data at »EDM.GV.AT«. | .html / .xml |
violate_R378a_A_MovementAnnouncement.xml | R378 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks packaging type information (PackageTypeID elements). | .html / .xml |
violate_R387a_A_MovementAnnouncement.xml | R387 | ERROR | In the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the last part of the route information refers to the country AT (ID »040«). The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« contains country of destination DE (ID »276«). The route must end in the country of destination. | .html / .xml |
violate_R418a_C_CarrierConfirmation.xml | R418 | WARNING | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« lacks a transport means identifier, such as a license plate number (TransportMeansID element). | .html / .xml |
violate_R426a_E_ConfirmationOfWasteTreatment.xml | R426 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains treatment completion date »2023-04-22«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains waste receipt information with receipt date »2023-04-25«. According to this data, the treatment completion date is 3 days before the receipt date. This error triggers for a treatment completion date that is 2 or more days before the receipt date, leaving 1 day tolerance for time zone date progression differences. | .html / .xml |
violate_R439a_A_MovementAnnouncement.xml | R439 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the shipment start date (StartDate element). | .html / .xml |
violate_R446a_A_MovementAnnouncement.xml | R446 | ERROR | The route information with points of exit and points of entry in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to the same country AT (ID »040«) in two consecutive route parts, no. 2 and 3. | .html / .xml |
violate_R470a_D_ConfirmationOfWasteReceipt.xml | R470 | INFO | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains a waste mass value of »0.0«. | .html / .xml |
violate_R470b_D_ConfirmationOfWasteReceipt.xml | R470 | INFO | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains a waste volume value of »0.0«. | .html / .xml |
violate_R473a_A_MovementAnnouncement.xml | R473 | WARNING | The route information in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to country CS (ID »891«). According to the reference data at »EDM.GV.AT« this country ceased to exist at 2006-06-02, and therefore should NOT be referenced in the movement announcement with start date 2023-05-01. | .html / .xml |
violate_R479a_A_MovementAnnouncement.xml | R479 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to the packaging type with code »8«. In the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« the type with code »8« is not among the consented packaging types. | .html / .xml |
violate_R489a_D_ConfirmationOfWasteReceipt.xml | R489 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks information on the received mass of waste (ReceivedWasteMass element), despite the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« containing a consented maximum total mass of waste. | .html / .xml |
violate_R493a_E_ConfirmationOfWasteTreatment.xml | R493 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« lacks the treatment completion date (TreatmentCompletionDate element). | .html / .xml |
violate_R495a_A_MovementAnnouncement.xml | R495 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks information on the mass of waste to be shipped (WasteMass element), despite the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« containing a consented maximum total mass of waste. | .html / .xml |
violate_R497a_A_MovementAnnouncement.xml | R497 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a message creation party with ID »IT02795790241« (»VAT.EU«). This is different from the notification party reference in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, which contains WasteX relevant ID »IT33333333302« (»VAT.EU«). | .html / .xml |
violate_R497b_B_MovementAnnouncementStatus.xml | R497 | ERROR | The movement announcement status message for the combination of notification number »IT 347203« and serial number »4« refers to a message creation party with ID »IT02795790241« (»VAT.EU«). This is different from the notification party reference in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, which contains WasteX relevant ID »IT33333333302« (»VAT.EU«) and recipient specific ID »9008391486114«. | .html / .xml |
violate_R519a_A_MovementAnnouncement.xml | R519 | ERROR | In the packaging type information (PackageTypeID elements) contained in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« the following packaging types occur more than once: 8. | .html / .xml |
violate_R521a_A_MovementAnnouncement.xml | R521 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to a carrier party with ID »IT02795790241« (»VAT.EU«). This does not match any of the carrier parties in the notification/consent entry for »IT 347203« at the »EDM.GV.AT« database. Note that for party IDs to match, the transmitted message must contain the correct type of ID (WasteX relevant ID or recipient specific ID), and »EDM.GV.AT« must contain unique party IDs with the correct types as well. | .html / .xml |
violate_R522a_A_MovementAnnouncement.xml | R522 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the total number of packages (PackageCount element). | .html / .xml |
violate_R526a_A_MovementAnnouncement.xml | R526 | INFO | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to an exit point name »Kufstein« for country AT (ID »040«). This does not match any of the exit point names - »Achenwald«, »Kössen« - from the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«. | .html / .xml |
violate_R530a_A_MovementAnnouncement.xml | R530 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains a negative waste mass value »-23.0«. | .html / .xml |
violate_R530b_A_MovementAnnouncement.xml | R530 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains a negative waste volume value »-5.3«. | .html / .xml |
violate_R530c_D_ConfirmationOfWasteReceipt.xml | R530 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains a negative waste mass value »-16.7«. | .html / .xml |
violate_R530d_D_ConfirmationOfWasteReceipt.xml | R530 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains a negative waste volume value »-3.8«. | .html / .xml |
violate_R533a_E_ConfirmationOfWasteTreatment.xml | R533 | WARNING | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains treatment completion date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains waste receipt information with receipt date »2022-03-23«. According to this data, the treatment completion date is 400 days after the waste receipt date. This warning triggers for a treatment completion date that is more than 366 days after the waste receipt date. | .html / .xml |
violate_R557a_A_MovementAnnouncement.xml | R557 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains a waste mass value of »0.0«. | .html / .xml |
violate_R557b_A_MovementAnnouncement.xml | R557 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains a waste volume value of »0.0«. | .html / .xml |
violate_R564a_D_ConfirmationOfWasteReceipt.xml | R564 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« refers to the waste receiver party with ID »DE140462045« (»VAT.EU«) and receipt site with post code »02699«. The waste treatment party and site in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« has WasteX relevant ID »IT33333333302« (»VAT.EU«) and post code »02699«, which does not match. The consignee party in the notification/consent has WasteX relevant ID »IT44444444408« (»VAT.EU«), which does not match either. | .html / .xml |
violate_R564b_D_ConfirmationOfWasteReceipt.xml | R564 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« refers to the waste receiver party with ID »DE140462045« (»VAT.EU«) and receipt site with post code »02699«. The waste treatment party and site in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« has WasteX relevant ID »DE140462045« (»VAT.EU«) and post code »63720«, which does not match. The consignee party in the notification/consent has WasteX relevant ID »IT44444444408« (»VAT.EU«), which does not match either. | .html / .xml |
violate_R576a_A_MovementAnnouncement.xml | R576 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains shipment start date »2023-05-01«. The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« defines »2023-05-27« as the first day at which shipments are permitted. According to these records, the shipment takes place before the consented shipment period. | .html / .xml |
violate_R602a_E_ConfirmationOfWasteTreatment.xml | R602 | ERROR | The confirmation of waste treatment message for notification number »IT 347203« refers to serial number »0«. The serial number must be geater or equal to 1. | .html / .xml |
violate_R606a_A_MovementAnnouncement.xml | R606 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains the entry point name »Hirtsbecken« for the first part of the route in country IT (ID »380«). The first part of the route must not contain an entry point name. | .html / .xml |
violate_R614a_B_MovementAnnouncementStatus.xml | R614 | ERROR | The movement announcement cancellation (movement announcement status message) refers to the combination of notification number »IT 347203« and serial number »4«. »EDM.GV.AT« cannot accept/process the cancellation, as for this combination of notification number and serial number, the database at »EDM.GV.AT« already contains the following: carrier confirmation, confirmation of waste receipt. | .html / .xml |
violate_R614b_B_MovementAnnouncementStatus.xml | R614 | ERROR | The movement announcement cancellation (movement announcement status message) refers to the combination of notification number »IT 347203« and serial number »4«. »EDM.GV.AT« cannot accept/process the cancellation, as for this combination of notification number and serial number, the database at »EDM.GV.AT« already contains the following: carrier confirmation, confirmation of waste receipt, confirmation of the completion of waste treatment. | .html / .xml |
violate_R631a_C_CarrierConfirmation.xml | R631 | WARNING | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« contains transfer date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains movement announcement information with shipment start date »2023-05-01«. According to this data, the transfer date is 4 days before the shipment start date. This warning triggers for a transfer date that is 2 or more days before the shipment start date, leaving 1 day tolerance for time zone date progression differences. | .html / .xml |
violate_R631b_D_ConfirmationOfWasteReceipt.xml | R631 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains waste receipt date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains movement announcement information with shipment start date »2023-05-01«. According to this data, the waste receipt date is 4 days before the shipment start date. This warning triggers for a waste receipt date that is 2 or more days before the shipment start date, leaving 1 day tolerance for time zone date progression differences. | .html / .xml |
violate_R631c_E_ConfirmationOfWasteTreatment.xml | R631 | WARNING | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« contains treatment completion date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains movement announcement information with shipment start date »2023-05-01«. According to this data, the treatment completion date is 4 days before the shipment start date. This warning triggers for a treatment completion date that is 2 or more days before the shipment start date, leaving 1 day tolerance for time zone date progression differences. | .html / .xml |
violate_R651a_D_ConfirmationOfWasteReceipt.xml | R651 | WARNING | The confirmation of waste receipt message refers to the combination of notification number »IT 347203« and serial number »3«. The transmission of the confirmation of waste receipt message is late because for this combination of notification number and serial number the database at »EDM.GV.AT« already contains the following: confirmation of the completion of waste treatment. | .html / .xml |
violate_R684a_A_MovementAnnouncement.xml | R684 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks information on the volume of waste to be shipped (WasteVolume element), despite the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« containing a consented maximum total volume of waste. | .html / .xml |
violate_R686a_A_MovementAnnouncement.xml | R686 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the entry point name (EntryPointName element) for route part no. 2 in country AT (ID »040«). | .html / .xml |
violate_R688a_B_MovementAnnouncementStatus.xml | R688 | WARNING | The movement announcement status message (announcement cancellation) refers to notification number »IT 347203« and serial number »4«. In the database at »EDM.GV.AT« there is no movement announcement for this combination of notification number and serial number. As a result, »EDM.GV.AT« ignores the message. | .html / .xml |
violate_R705a_A_MovementAnnouncement.xml | R705 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks country entry point and exit point information (NationalRoute elements). | .html / .xml |
violate_R712a_A_MovementAnnouncement.xml | R712 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains shipment start date »2025-04-30«. The message receipt timestamp is »2023-04-27T13:28:26.088980Z«, which means that from the time of message receipt it still takes more than 2 years until the shipment starts. This error triggers for a time difference of 1 or more years. | .html / .xml |
violate_R715a_E_ConfirmationOfWasteTreatment.xml | R715 | WARNING | The confirmation of waste treatment message refers to notification number »IT 347203« and serial number »3«. In the database at »EDM.GV.AT« there is no confirmation of waste receipt for this combination of notification number and serial number at the time of confirmation of waste treatment message receipt. | .html / .xml |
violate_R725a_C_CarrierConfirmation.xml | R725 | INFO | AT: Note that for the time being the WasteX interface of the Austrian competent authority cannot store carrier confirmations. The competent authority will not have access to transmitted carrier confirmations. | .html / .xml |
violate_R726a_D_ConfirmationOfWasteReceipt.xml | R726 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the indication of whether or not the received waste was rejected (RejectionIndicator element). | .html / .xml |
violate_R732a_A_MovementAnnouncement.xml | R732 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to the combination of transport mode »T« and carrier party with ID »DE188158403« (»VAT.EU«). The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« does NOT contain this combination of transport mode and carrier party. The notification/consent contains the following transport modes for the party: S, W | .html / .xml |
violate_R767a_E_ConfirmationOfWasteTreatment.xml | R767 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« refers to the waste treatment party with ID »DE140462045« (»VAT.EU«) and treatment site post code »02699«. The waste treatment party and site in the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« has WasteX relevant ID »IT33333333302« (»VAT.EU«) and post code »02699«, which does not match. | .html / .xml |
violate_R780a_A_MovementAnnouncement.xml | R780 | ERROR | The movement announcement message refers to notification number »IT 347203«. A notification with that number does not exist in the database at »EDM.GV.AT«. | .html / .xml |
violate_R780b_D_ConfirmationOfWasteReceipt.xml | R780 | ERROR | The confirmation of waste receipt message refers to notification number »IT 347203«. A notification with that number does not exist in the database at »EDM.GV.AT«. | .html / .xml |
violate_R795a_C_CarrierConfirmation.xml | R795 | WARNING | The carrier confirmation message refers to notification number »IT 347203« and serial number »3«. In the database at »EDM.GV.AT« there is no movement announcement for this combination of notification number and serial number at the time of carrier confirmation message receipt. | .html / .xml |
violate_R795b_D_ConfirmationOfWasteReceipt.xml | R795 | WARNING | The confirmation of waste receipt message refers to notification number »IT 347203« and serial number »3«. In the database at »EDM.GV.AT« there is no movement announcement for this combination of notification number and serial number at the time of confirmation of waste receipt message receipt. | .html / .xml |
violate_R795c_E_ConfirmationOfWasteTreatment.xml | R795 | WARNING | The confirmation of waste treatment message refers to notification number »IT 347203« and serial number »3«. In the database at »EDM.GV.AT« there is no movement announcement for this combination of notification number and serial number at the time of confirmation of waste treatment message receipt. | .html / .xml |
violate_R797a_D_ConfirmationOfWasteReceipt.xml | R797 | ERROR | The confirmation of waste receipt message refers to notification number »IT 347203« and serial number »3«. The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« lacks party identifiers needed for looking up party references contained in WasteX messages. This applies to one or more of the following parties: Notifier, waste producers, carriers, consignee and/or waste treatment parties. | .html / .xml |
violate_R798a_A_MovementAnnouncement.xml | R798 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks carrier information (TransportMovement elements). | .html / .xml |
violate_R804a_B_MovementAnnouncementStatus.xml | R804 | WARNING | The movement announcement status message refers to notification number »IT 347203« and serial number »4«. For this combination of notification number and serial number, the database at »EDM.GV.AT« contains latest movement announcement information with start date »2023-04-23«. The receipt timestamp for the movement announcement status message is »2023-04-27T13:28:26.137850Z«, which means that more than 4 days have elapsed between shipment start date and message receipt. This warning triggers for a posteriori announcement status updates (cancellations) with a time difference of more than 1 day. Note that pursuant to provisions such as the WSR the information must be exchanged as an announcement, i.e., BEFORE the start of the shipment. | .html / .xml |
violate_R808a_A_MovementAnnouncement.xml | R808 | ERROR | The movement announcement message for notification number »IT 347203« and serial number »4« contains the number of packages »-1«. The number of packages must be greater or equal to 0. | .html / .xml |
violate_R824a_A_MovementAnnouncement.xml | R824 | ERROR | The route information in the movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to country SC (ID »690«). According to the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, this country is neither country of dispatch, nor country of transit, nor country of destination. The route information must match country of dispatch, countries of transit and country of destination from the notification/consent. | .html / .xml |
violate_R827a_E_ConfirmationOfWasteTreatment.xml | R827 | WARNING | The confirmation of waste treatment message refers to notification number »IT 347203« and serial number »3«. According to the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« the status of the notification and consent procedure is such that shipments are not or not yet permitted. | .html / .xml |
violate_R837a_A_MovementAnnouncement.xml | R837 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to 55.0m3 of waste. According to the notification in the database at »EDM.GV.AT« the total consented amount of waste is 22,000.0m3. According to the shipment information in the database at »EDM.GV.AT« a total of 21,990.0m3 has already been announced or confirmed in receipt previously. As a result, the movement announcement exceeds the total consented amount of waste. | .html / .xml |
violate_R849a_D_ConfirmationOfWasteReceipt.xml | R849 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains the planned date of waste treatment completion »2025-03-27«. The message also contains the waste receipt date »2023-04-27«. According to this data, the treatment is completed 700 days after the waste receipt. This warning triggers for a waste treatment completion that is more than 366 days after the waste receipt date. | .html / .xml |
violate_R852a_D_ConfirmationOfWasteReceipt.xml | R852 | ERROR | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« refers to the waste receiver party with ID »DE140462045« (»VAT.EU«). This matches the consignee party from the notification/consent entry for »IT 347203« in the database at »EDM.GV.AT«, but does NOT match the waste treatment party. This version of the WasteX specification does NOT support Annex IB Block 17 WSR confirmations by consignees, but rather only supports Annex IB Block 18 confirmations by waste treatment parties. | .html / .xml |
violate_R899a_E_ConfirmationOfWasteTreatment.xml | R899 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« refers to the waste treatment party with ID »IT02244220212« (»VAT.EU«). This does not match the message creation party with ID »DE140462045« (»VAT.EU«). | .html / .xml |
violate_R902a_E_ConfirmationOfWasteTreatment.xml | R902 | ERROR | The confirmation of waste treatment message for the combination of notification number »IT 347203« and serial number »3« lacks the treatment site post code (SitePostalAreaID element). | .html / .xml |
violate_R952a_A_MovementAnnouncement.xml | R952 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the quantification type (QuantificationTypeID element) in the mass information. This means that it lacks the information whether the value is measured, calculated or estimated. | .html / .xml |
violate_R952b_A_MovementAnnouncement.xml | R952 | WARNING | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« lacks the quantification type (QuantificationTypeID element) in the volume information. This means that it lacks the information whether the value is measured, calculated or estimated. | .html / .xml |
violate_R952c_D_ConfirmationOfWasteReceipt.xml | R952 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the quantification type (QuantificationTypeID element) in the mass information. This means that it lacks the information whether the value is measured, calculated or estimated. | .html / .xml |
violate_R952d_D_ConfirmationOfWasteReceipt.xml | R952 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« lacks the quantification type (QuantificationTypeID element) in the volume information. This means that it lacks the information whether the value is measured, calculated or estimated. | .html / .xml |
violate_R959a_A_MovementAnnouncement.xml | R959 | ERROR | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« contains the exit point name »Aach im Allgäu« for the last part of the route in country DE (ID »276«). The last part of the route must not contain an exit point name. | .html / .xml |
violate_R967a_C_CarrierConfirmation.xml | R967 | ERROR | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« refers to the carrier with ID »DE811617242« (»VAT.EU«). This does not match the message creation party with ID »IT00623920212« (»VAT.EU«). | .html / .xml |
violate_R971a_C_CarrierConfirmation.xml | R971 | WARNING | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« refers to the combination of transport mode »R« and carrier party with ID »IT00623920212« (»VAT.EU«). The notification/consent entry for »IT 347203« in the database at »EDM.GV.AT« does NOT contain this combination of transport mode and carrier party. The notification/consent contains the following transport modes for the party: S, W | .html / .xml |
violate_R979a_C_CarrierConfirmation.xml | R979 | WARNING | The carrier confirmation message for the combination of notification number »IT 347203« and serial number »3« contains transfer date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains movement announcement information with shipment date »2022-07-01«. According to this data, the transfer date is 300 days after the shipment start date. This warning triggers for a transfer date that is 200 days or more after the shipment start date. | .html / .xml |
violate_R979b_D_ConfirmationOfWasteReceipt.xml | R979 | WARNING | The confirmation of waste receipt message for the combination of notification number »IT 347203« and serial number »3« contains waste receipt date »2023-04-27«. For the combination of notification number »IT 347203« and serial number »3«, the database at »EDM.GV.AT« contains movement announcement information with shipment date »2022-07-01«. According to this data, the waste receipt date is 300 days after the shipment start date. This warning triggers for a waste receipt date that is 200 days or more after the shipment start date. | .html / .xml |
violate_R987a_A_MovementAnnouncement.xml | R987 | INFO | The movement announcement message for the combination of notification number »IT 347203« and serial number »4« refers to 50.0t of waste. A waste mass greater or equal to 35t is considered unusually high for a single shipment of waste with transport on road. | .html / .xml |
Basel Convention on the control of transboundary movements of hazardous wastes and their disposal
HTML 5
Hypertext Markup Language, Web Hypertext Application Technology Working Group (WHATWG) and W3C Recommendation
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
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
SOAP 1.2
Lightweight protocol intended for exchanging structured information in a decentralized, distributed environment, W3C Recommendation
Variable-width Unicode encoding form that preserves ASCII transparency by making use of 8-bit code units, The Unicode Consortium
WSDL 2.0
Web Services Description Language, an [XML] language for describing web services, W3C Recommendation
XML 1.0
Extensible Markup 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
Version | Date | Description / Changes |
---|---|---|
1.08 | 2023-04-27 | Changes:
|
1.07 | 2023-02-15 | Changes:
|
1.06 | 2023‑02‑14 | Changes:
|
1.05 | 2023-01-23 | Changes:
|
1.04 | 2023-01-20 | Changes:
|
1.03 | 2022-12-21 | Changes:
|
1.02 | 2022-09-21 | Changes:
|
1.01 | 2022-03-29 | Changes:
|
1.00 | 2022-02-24 | Initial release |