diff --git a/UBL-Schema-summary-information.xml b/UBL-Schema-summary-information.xml index d83acd7..ee04f51 100644 --- a/UBL-Schema-summary-information.xml +++ b/UBL-Schema-summary-information.xml @@ -1033,4 +1033,22 @@ Requestor + + Waste Movement + + Waste Shipment Management + + Sender + Receiver + + + + Waste Notification + + Waste Shipment Management + + Sender + Receiver + + diff --git a/UBL.xml b/UBL.xml index ec8c86d..36f5ae9 100644 --- a/UBL.xml +++ b/UBL.xml @@ -29,11 +29,11 @@ - + - - + + @@ -83,12 +83,12 @@ - Kenneth - Bengtsson + TBD + (to be confirmed by TC) - Individual + OASIS UBL TC - kbengtsson@efact.pe + oasis-ubl@ConnectedCommunity.org Kenneth @@ -2185,6 +2185,34 @@ A Weight Statement is a transport document verifying the declared true gross mass of a packed container. Working with this knowledge avoids injury, container loss, damage to cargo, etc. Formally verifying the gross mass may be a condition for transport. +
+ Waste Shipment Management + Waste shipment management is a transport-related process used to control the movement of regulated waste, such as contaminated soil, which consists of a pre-transport notification phase (required for cross-border movements) and the execution of one or more waste movements for each consignment. + For cross-border movements, the competent authorities must be notified before transport may begin. The Waste Notification is used to provide the required information to the authorities. The notification is sent by a Sender Party, and the receiving authority reviews it, prepares a reply, and transmits an Application Response providing consent or rejection. All required consents must be received before transport can commence. The below diagram illustrates the notification and response process: +
+ Waste Notification Process + + + + + + [Waste Notification Process Diagram] + + +
+ Once any required consents have been obtained, or for domestic movements where no notification is required, a Waste Movement document is issued for each consignment of waste. The Waste Movement document may reference a related Waste Notification and accompanies the consignment throughout its transport. The Sender Party (typically the waste producer or a carrier acting on its behalf) prepares and issues the Waste Movement document and transmits it to the next party in the chain. The Receiver Party receives the document and may endorse it according to regulatory requirements. The diagram below illustrates the basic steps of issuing and receiving a Waste Movement document: +
+ Waste Movement Process + + + + + + [Waste Movement Process Diagram] + + +
+
Manifest @@ -3040,8 +3068,8 @@ xsd/common/BDNDR-CCTS_CCT_SchemaModule-1.1.xsd - This schema provides Core Component Types as defined by . These types are used to construct higher-level data types in a standardized and consistent manner. This schema is defined by UN/CEFACT and ought not be modified. It is imported by the UBL Unqualified - Data Type Schema, and its types are the basis upon which UBL’s unqualified data types are defined. + This schema provides Core Component Types as defined by . These types are used to construct higher-level data types in a standardized and consistent manner. The normative UBL version of this BDNDR schema is defined by UN/CEFACT. The endorsed UBL revision of this schema has been created by the UBL committee to reflect deprecated secondary components going forward. Neither file should be modified by the user. These files are imported by the UBL Unqualified + Data Type Schema, and their types are the basis upon which UBL’s unqualified data types are defined. UnqualifiedDataTypes @@ -3517,9 +3545,13 @@ xmlns="urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2">
Semantic definitions - The UBL Technical Committee has ascribed a definition to each of the business objects in UBL. These definitions provide important semantic context for the interpretation of the content. These definitions are found in the normative XSD Schemas. They are also transcribed into the XML model - ODS spreadsheet, XLS spreadsheet and the HTML document reports. - To facilitate interoperability, implementations SHOULD follow these definitions to ensure the successful interchange of the business information. + The UBL Technical Committee has ascribed a definition to each of the business objects in UBL. These definitions provide important semantic context for the interpretation of the content. They are found in the normative XSD Schemas and are transcribed into the XML model ODS spreadsheet, XLS spreadsheet, and HTML documentation. + From UBL 2.5 onward, these definitions form the basis for an optional semantic + conformance level, as defined in . Implementations that + declare semantic conformance shall ensure that the business content of UBL document + instances aligns with the intended meaning of each component as described in these + definitions. + Implementations that declare only syntactical conformance should also follow these semantic definitions to support meaningful interoperability and consistent interpretation of business data.
@@ -4139,6 +4171,19 @@ xmlns="urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2">
+
+ Semantic Conformance + A UBL document instance is considered semantically conformant when it correctly represents business information in accordance with the semantic definitions of the UBL data model as described in . + Semantic conformance to UBL therefore requires that: + + + Each UBL element and component is used in a manner consistent with its normative definition in the UBL schemas and accompanying documentation; and + + + The instance conveys information that is consistent with the business semantics intended by the UBL data model. + + +
Digital Signature Extension Conformance
@@ -4565,11 +4610,11 @@ xmlns="urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2">
UBL Customization - UBL provides a vocabulary that, for many user communities, can be used “as is”. However, it is recognized that some user communities need to address use cases whose requirements are not met by the UBL off-the-shelf solution. A separate OASIS Committee Specification known as - the UBL 2 Guidelines for Customization - has been published to aid such users in developing custom solutions based on UBL. - The goal of UBL customization is to maintain a common understanding of the meaning of information being exchanged between specific implementations. The factors governing when to customize may be business-driven, technically driven, or both. The decision ought to be based on real-world - needs balanced against perceived economic benefits. + UBL provides a vocabulary that, for many user communities, can be used “as is”. However, some users require a more tailored subset of the model, with additional constraints or specific business rules to support interoperability within a defined context (e.g., a company, network, or jurisdiction). + UBL allows for such specializations through the use of customizations, which are formal specifications that define how a particular community uses UBL. These customizations are identified by the CustomizationID element within a UBL document instance and typically define restrictions on allowed elements, tightened cardinalities, additional business rules, or specific semantic interpretations, all while remaining conformant with the normative UBL schemas and definitions. + In addition, the ProfileID element can be used to indicate the business process context in which a document instance is exchanged. While the CustomizationID identifies the specific technical constraints and business rules applied to the document structure, the ProfileID can express further contextual information about the document’s role in a business process (e.g., “invoice-only process”, “purchase order with invoice”, etc.). + When used, both identifiers should refer to publicly documented specifications to ensure clarity and consistent interpretation across implementations. + A separate OASIS Committee Specification known as the UBL 2 Guidelines for Customization has been published to aid such users in developing custom solutions based on UBL.
Upgrading from UBL 2.x to UBL &version; @@ -4820,16 +4865,27 @@ xmlns="urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2">
Overview of UBL 2.5 Updates Because it preserves backward compatibility with earlier versions of UBL 2.X, UBL &version; is technically a minor release, not a major one. However, it does introduce several important enhancements that significantly improve the usability, interoperability, and business alignment of the standard. - Key updates include support for collections on behalf of third parties, improved invoice status tracking, and enhanced payment referencing. Additionally, UBL 2.5 also introduces element deprecation, allowing for cleaner evolution of the standard without breaking existing implementations. + Key updates include support for collections on behalf of third parties, improved + invoice status tracking, waste transport management, and enhanced payment referencing. + Additionally, UBL 2.5 also introduces element deprecation, allowing for cleaner evolution + of the standard without breaking existing implementations.
New Document Types in UBL 2.5 - UBL &version; adds the following new document types, bringing the total number of UBL business documents to 97: + UBL &version; adds the following new document types, bringing the total number of UBL + business documents to 101:
- Added four new UBL 2.5 document types: - Delivery Note, Invoice Status Request, Invoice Status Response, Work Report, Procurement Status, Procurement Status Request + Added 8 new UBL 2.5 document types: + Delivery Note, Invoice Status Request, Invoice Status Response, Work Report, Procurement Status, Procurement Status Request, Waste Movement, Waste Notification
@@ -5127,13 +5183,13 @@ xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" Period - will be found at line 1870 and seen to contain a number of possible BBIE children, all of them optional; and the ASBIE + will be found at line 1881 and seen to contain a number of possible BBIE children, all of them optional; and the ASBIE InvoicePeriod in Invoice therefore has this structure, too. From this one could conclude that instantiations of the Period - structure (there are more than 50 of them in UBL) might not contain any of the seven optional BBIE elements specified after line 1870, + structure (there are more than 50 of them in UBL) might not contain any of the seven optional BBIE elements specified after line 1881, and indeed the corresponding declaration of the complex type PeriodType in the CAC schema ( xsd/common/UBL-CommonAggregateComponents-&version;.xsd ) shows that an empty @@ -5169,24 +5225,24 @@ xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" CustomerParty ABIE. Checking in the Common Library, it is seen that both SupplierParty - (line 2550 of the Common Library) and + (line 2571 of the Common Library) and CustomerParty (line 679 of the Common Library) can contain an ASBIE named Party (as shown in lines 2554 and 2575 and 683, respectively) and that each Party ASBIE is an instantiation of the Party - ABIE (line 1734). Therefore both parties have the same structure (the BBIEs and ASBIEs following line 1734). Thus + ABIE (line 1745). Therefore both parties have the same structure (the BBIEs and ASBIEs following line 1745). Thus AccountingSupplierParty and AccountingCustomerParty share the information components common to parties in general and differ in the information specific to suppliers and customers. Parties commonly have a PartyName - (line 1743) that derives (the Associated Object Class column) from the ABIE + (line 1754) that derives (the Associated Object Class column) from the ABIE PartyName - (line 1783), which is a wrapper for the BBIE + (line 1794), which is a wrapper for the BBIE Name - (line 1784). A conforming piece of the document instance might therefore look like this: + (line 1795). A conforming piece of the document instance might therefore look like this: @@ -5213,7 +5269,7 @@ xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" first, it is found in the Common Library to be derived from MonetaryTotal (line - 1646), which has a mandatory 1657), which has a mandatory PayableAmount BBIE. A corresponding example instance fragment might be therefore be constructed as follows: @@ -5226,7 +5282,7 @@ xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" LegalMonetaryTotal element shown above except the currencyID attribute on PayableAmount - , which does not appear explicitly in the model line for that BBIE (line 1657). This is + , which does not appear explicitly in the model line for that BBIE (line 1668). This is because UBL does not define the primitive data types upon which the model is built; instead it uses standard data type definitions from and . In the case of PayableAmount , the CCTS data type (the Data Type column) is “Amount. Type” (the space is part of the name), and that type is defined in itself (Table 8-1 of the CCTS 2.01 specification). There it will be seen that “Amount. Type” has two diff --git a/art/UBL-2.5-WasteMovementProcess.png b/art/UBL-2.5-WasteMovementProcess.png new file mode 100644 index 0000000..1b31c50 Binary files /dev/null and b/art/UBL-2.5-WasteMovementProcess.png differ diff --git a/art/UBL-2.5-WasteNotificationProcess.png b/art/UBL-2.5-WasteNotificationProcess.png new file mode 100644 index 0000000..841a8ce Binary files /dev/null and b/art/UBL-2.5-WasteNotificationProcess.png differ diff --git a/config-UBL-Signature.xml b/config-UBL-Signature.xml index cb3d21a..ea7c362 100644 --- a/config-UBL-Signature.xml +++ b/config-UBL-Signature.xml @@ -10,7 +10,7 @@ --> - + diff --git a/config-UBL.xml b/config-UBL.xml index 7520444..2d2876a 100644 --- a/config-UBL.xml +++ b/config-UBL.xml @@ -6,11 +6,11 @@ Library: OASIS Universal Business Language (UBL) 2.5 CSD02 http://docs.oasis-open.org/ubl/csd02-UBL-2.5/ - Release Date: 19 November 2025 + Release Date: 03 December 2025 --> - + diff --git a/htmlart/UBL-2.5-WasteMovementProcess.png b/htmlart/UBL-2.5-WasteMovementProcess.png new file mode 100644 index 0000000..6db8c7c Binary files /dev/null and b/htmlart/UBL-2.5-WasteMovementProcess.png differ diff --git a/htmlart/UBL-2.5-WasteNotificationProcess.png b/htmlart/UBL-2.5-WasteNotificationProcess.png new file mode 100644 index 0000000..eb912fd Binary files /dev/null and b/htmlart/UBL-2.5-WasteNotificationProcess.png differ diff --git a/images/UBL-2.5-WasteMovementProcess.drawio b/images/UBL-2.5-WasteMovementProcess.drawio new file mode 100644 index 0000000..f404864 --- /dev/null +++ b/images/UBL-2.5-WasteMovementProcess.drawio @@ -0,0 +1,59 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/images/UBL-2.5-WasteNotificationProcess.drawio b/images/UBL-2.5-WasteNotificationProcess.drawio new file mode 100644 index 0000000..571928b --- /dev/null +++ b/images/UBL-2.5-WasteNotificationProcess.drawio @@ -0,0 +1,75 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/raw/xsd/common/UBL-CommonExtensionComponents-2.5.xsd b/raw/xsd/common/UBL-CommonExtensionComponents-2.5.xsd index de6820c..78a03fc 100644 --- a/raw/xsd/common/UBL-CommonExtensionComponents-2.5.xsd +++ b/raw/xsd/common/UBL-CommonExtensionComponents-2.5.xsd @@ -2,10 +2,10 @@