]>
&name; &version; Standards Track Work Product &this-loc;/&name;-&version;.html &this-loc;/&name;-&version;.pdf &this-loc;/&name;-&version;.xml &previous-loc;/UBL-2.1.html &previous-loc;/UBL-2.1.pdf &previous-loc;/UBL-2.1.xml &latest-loc;/&name;-2.1.html &latest-loc;/&name;-2.1.pdf Universal Business Language Version 2.1 OASIS Universal Business Language TC Jon Bosak Individual bosak@pinax.com Tim McGrath Document Engineering Services tim.mcgrath@documentengineeringservices.com G. Ken Holman Crane Softwrights Ltd. gkholman@CraneSoftwrights.com Jon Bosak Individual bosak@pinax.com Tim McGrath Document Engineering Services tim.mcgrath@documentengineeringservices.com &pubdate; 2013 Additional artefacts The ZIP containing the complete files of this release is found in the directory: &this-loc;/ Related work This specification supersedes UBL 2.0. This specification has alternative representations in the following directories: UBL 2.1 Abstract Syntax Notation 1 (ASN.1) Alternative Representation Version 1.0. Latest version. http://docs.oasis-open.org/ubl/UBL-2.1-ASN.1/v1.0/UBL-2.1-ASN.1-v1.0.html. UBL 2.1 Unified Modeling Language (UML) Alternative Representation Version 1.0. Latest version. http://docs.oasis-open.org/ubl/UBL-2.1-UML/v1.0/UBL-2.1-UML-v1.0.html. Declared XML Namespaces urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2 urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2 urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2 urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2 urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2 urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2 urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2 urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2 urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2 urn:oasis:names:specification:ubl:schema:xsd:AttachedDocument-2 urn:oasis:names:specification:ubl:schema:xsd:AwardedNotification-2 urn:oasis:names:specification:ubl:schema:xsd:BillOfLading-2 urn:oasis:names:specification:ubl:schema:xsd:CallForTenders-2 urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2 urn:oasis:names:specification:ubl:schema:xsd:CatalogueDeletion-2 urn:oasis:names:specification:ubl:schema:xsd:CatalogueItemSpecificationUpdate-2 urn:oasis:names:specification:ubl:schema:xsd:CataloguePricingUpdate-2 urn:oasis:names:specification:ubl:schema:xsd:CatalogueRequest-2 urn:oasis:names:specification:ubl:schema:xsd:CertificateOfOrigin-2 urn:oasis:names:specification:ubl:schema:xsd:ContractAwardNotice-2 urn:oasis:names:specification:ubl:schema:xsd:ContractNotice-2 urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2 urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2 urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2 urn:oasis:names:specification:ubl:schema:xsd:DocumentStatus-2 urn:oasis:names:specification:ubl:schema:xsd:DocumentStatusRequest-2 urn:oasis:names:specification:ubl:schema:xsd:ExceptionCriteria-2 urn:oasis:names:specification:ubl:schema:xsd:ExceptionNotification-2 urn:oasis:names:specification:ubl:schema:xsd:Forecast-2 urn:oasis:names:specification:ubl:schema:xsd:ForecastRevision-2 urn:oasis:names:specification:ubl:schema:xsd:ForwardingInstructions-2 urn:oasis:names:specification:ubl:schema:xsd:FreightInvoice-2 urn:oasis:names:specification:ubl:schema:xsd:FulfilmentCancellation-2 urn:oasis:names:specification:ubl:schema:xsd:GoodsItemItinerary-2 urn:oasis:names:specification:ubl:schema:xsd:GuaranteeCertificate-2 urn:oasis:names:specification:ubl:schema:xsd:InstructionForReturns-2 urn:oasis:names:specification:ubl:schema:xsd:InventoryReport-2 urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 urn:oasis:names:specification:ubl:schema:xsd:ItemInformationRequest-2 urn:oasis:names:specification:ubl:schema:xsd:Order-2 urn:oasis:names:specification:ubl:schema:xsd:OrderCancellation-2 urn:oasis:names:specification:ubl:schema:xsd:OrderChange-2 urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2 urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2 urn:oasis:names:specification:ubl:schema:xsd:PackingList-2 urn:oasis:names:specification:ubl:schema:xsd:PriorInformationNotice-2 urn:oasis:names:specification:ubl:schema:xsd:ProductActivity-2 urn:oasis:names:specification:ubl:schema:xsd:Quotation-2 urn:oasis:names:specification:ubl:schema:xsd:ReceiptAdvice-2 urn:oasis:names:specification:ubl:schema:xsd:Reminder-2 urn:oasis:names:specification:ubl:schema:xsd:RemittanceAdvice-2 urn:oasis:names:specification:ubl:schema:xsd:RequestForQuotation-2 urn:oasis:names:specification:ubl:schema:xsd:RetailEvent-2 urn:oasis:names:specification:ubl:schema:xsd:SelfBilledCreditNote-2 urn:oasis:names:specification:ubl:schema:xsd:SelfBilledInvoice-2 urn:oasis:names:specification:ubl:schema:xsd:Statement-2 urn:oasis:names:specification:ubl:schema:xsd:StockAvailabilityReport-2 urn:oasis:names:specification:ubl:schema:xsd:Tender-2 urn:oasis:names:specification:ubl:schema:xsd:TendererQualification-2 urn:oasis:names:specification:ubl:schema:xsd:TendererQualificationResponse-2 urn:oasis:names:specification:ubl:schema:xsd:TenderReceipt-2 urn:oasis:names:specification:ubl:schema:xsd:TradeItemLocationProfile-2 urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2 urn:oasis:names:specification:ubl:schema:xsd:TransportationStatusRequest-2 urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlan-2 urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlanRequest-2 urn:oasis:names:specification:ubl:schema:xsd:TransportProgressStatus-2 urn:oasis:names:specification:ubl:schema:xsd:TransportProgressStatusRequest-2 urn:oasis:names:specification:ubl:schema:xsd:TransportServiceDescription-2 urn:oasis:names:specification:ubl:schema:xsd:TransportServiceDescriptionRequest-2 urn:oasis:names:specification:ubl:schema:xsd:UnawardedNotification-2 urn:oasis:names:specification:ubl:schema:xsd:UtilityStatement-2 urn:oasis:names:specification:ubl:schema:xsd:Waybill-2 This specification defines the Universal Business Language, version 2.1. Status This document was last revised or approved by the UBL TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ubl/. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at http://www.oasis-open.org/committees/ubl/ipr.php. See for more information regarding this release package. Citation format When referencing this specification the following citation format should be used: UBL-2.1 Universal Business Language Version 2.1. &pubdate;. OASIS &standard;. http://docs.oasis-open.org/ubl/&stage;-UBL-2.1/UBL-2.1.html. Notices Copyright © OASIS Open 2001-2013. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name “OASIS” is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark.php for guidance. CPFR is a registered trademark of the Voluntary Interindustry Commerce Solutions (VICS) association. The term “CPFR” is not to be used in any format without written permission from VICS. For more information on VICS and CPFR, visit www.vics.org.
Introduction Since its approval as a W3C recommendation in 1998, XML has been adopted in a number of industries as a framework for the definition of the messages exchanged in electronic commerce. The widespread use of XML has led to the development of multiple industry-specific XML versions of such basic documents as purchase orders, shipping notices, and invoices. While industry-specific data formats have the advantage of maximal optimization for their business context, the existence of different formats to accomplish the same purpose in different business domains is attended by a number of significant disadvantages as well. Developing and maintaining multiple versions of common business documents like purchase orders and invoices is a major duplication of effort. Creating and maintaining multiple adapters to enable trading relationships across domain boundaries is an even greater effort. The existence of multiple XML formats makes it much harder to integrate XML business messages with back-office systems. The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find. The OASIS Universal Business Language (UBL) is intended to help solve these problems by defining a generic XML interchange format for business documents that can be restricted or extended to meet the requirements of particular industries. Specifically, UBL provides the following: A suite of structured business objects and their associated semantics expressed as reusable data components and common business documents. A library of XML schemas for reusable data components such as “Address”, “Item”, and “Payment”—the common data elements of everyday business documents. A set of XML schemas for common business documents such as “Order”, “Despatch Advice”, and “Invoice” that are constructed from the UBL library components and can be used in generic procurement and transportation contexts. A standard basis for XML business schemas provides the following advantages: Lower cost of integration, both among and within enterprises, through the reuse of common data structures. Lower cost of commercial software, because software written to process a given XML tag set is much easier to develop than software that can handle an unlimited number of tag sets. An easier learning curve, because users need master just a single library. Lower cost of entry and therefore quicker adoption by small and medium-size enterprises (SMEs). Standardized training, resulting in many skilled workers. A universally available pool of system integrators. Standardized, inexpensive data input and output tools. A standard target for inexpensive off-the-shelf business software. UBL is designed to provide a universally understood and recognized syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees. UBL schemas are modular, reusable, and extensible in XML-aware ways. As the first standard implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a conceptual model of information components known as Business Information Entities (BIEs). These components are assembled into specific document models such as Order and Invoice. These document models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in this release. UBL can also be regarded as a generic Open-edi Configuration in the perspective of the Open-edi Reference Model (ISO/IEC 14662:2010). This is described in more detail in .
Terminology
Terms and Definitions ASiC-S Associated Signature Container (simple form). A standard container that associates a single data object with one or more detached signature(s) that apply to it. See . Digital Signature A value generated from the application of a private key to a message via a cryptographic algorithm such that it has the properties of integrity and message authentication and/or signer authentication. A signature may be (non-exclusively) described as detached, enveloping, or enveloped (, with modifications). Document A set of information components that are exchanged as part of a business transaction; for example, in placing an order. Transform The processing of data from its source to its derived form. Typical transforms include XML Canonicalization and XSLT . XSD schema An XML document definition conforming to the W3C XML Schema language . The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with the meanings given in . The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specification with the meanings given in . The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in .
Symbols and Abbreviations ABIE Aggregate Business Information Entity AdES Advanced Electronic Signature ASBIE Association Business Information Entity BBIE Basic Business Information Entity BIE Business Information Entity C14N Canonicalization CC Core Component CPFR Collaborative Planning, Forecasting, and Replenishment CV2 Credit Card Verification Numbering System DSig Digital Signature EDI Electronic Data Interchange ISO International Organization for Standardization NDR UBL Naming and Design Rules QC Qualified Certificate QS Qualified Signature UML Unified Modeling Language UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business UNDG United Nations Dangerous Goods URI Uniform Resource Identifier UUID Universally Unique Identifier XAdES XML Advanced Electronic Signatures XML Extensible Markup Language XMLDSig XML Digital Signature XPath The XML Path Language XSD W3C XML Schema Language XSLT Extensible Stylesheet Language Transformations (a transformation language)
Normative References ASN.1 ITU-T X.680-X.683: Abstract Syntax Notation One (ASN.1), ITU-T X.690-X.693: ASN.1 encoding rules CCTSISO/TS 15000-5:2005 Electronic Business Extensible Markup Language (ebXML)— Part 5: ebXML Core Components Technical Specification, Version 2.01 (identical to Part 8 of the ebXML Framework) CPFRVoluntary Interindustry Commerce Standards, Collaborative Planning, Forecasting, and Replenishment Version 2.0, Global Commerce Initiative Recommended Guidelines, June 2002 Customization OASIS Committee Specification 01, UBL 2 Guidelines for Customization, First Edition, 25 December 2009 CVA OASIS Context/value association using Genericode 1.0. 15 April 2010. Committee Specification 01 http://docs.oasis-open.org/codelist/cs01-ContextValueAssociation-1.0/doc/context-value-association.html. genericode OASIS Code List Representation (Genericode) Version 1.0. 28 December 2007. Committee Specification 01. http://docs.oasis-open.org/codelist/cs-genericode-1.0/doc/oasis-code-list-representation-genericode.html. ISO11179 ISO/IEC 11179-1:1999 Information technology — Specification and standardization of data elements — Part 1: Framework for the specification and standardization of data elements RELAX NG ISO/IEC 19757-2, Information technology — Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG , Information technology — Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG AMENDMENT 1: Compact Syntax RFC2119 Key words for use in RFCs to Indicate Requirement Levels SCH Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation (Schematron) UMLUnified Modeling Language Version 1.5 (formal/03-03-01) XAdES XML Advanced Electronic Signatures. ETSI TS 101 903 V1.4.1, June 2009. XMLExtensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000 xmldsig XML-Signature Syntax and Processing. W3C Recommendation 12 February 2002 XSD1XML Schema Part 1: Structures. Second Edition. W3C Recommendation 28 October 2004 XSD2XML Schema Part 2: Datatypes. Second Edition. W3C Recommendation 28 October 2004 XSLTXSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999
Non-Normative References 1999/93/ECDirective 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures. 2011/130/UECommission Decision 2011/130/UE of the European Commission of 25 February 2011 on establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market. ASiC Electronic Signatures and Infrastructures (ESI); Associated Signature Containers (ASiC). ETSI TS 102 918 V1.1.1, April 2011. BOV-FSV ISO/IEC 15944-20 Information technology - Business operational view - Linking business operational view to functional service view CPFRoverviewCPFR: An Overview, 18 May 2004 CWA15579CEN Workshop Agreement: E-invoices and digital signatures (CWA 15579), July 2006. CWA15580CEN Workshop Agreement: Storage of Electronic Documents (CWA 15580), July 2006. eBiz-TCF Reference Architecture of eBusiness in Textile Clothing and Footwear Sector Open-edi ISO/IEC 14662:2010 Information technology - Open-edi reference model ODFP OASIS Standard, Open Document Format for Office Applications (OpenDocument) Version 1.2 - Part 3 Packages, December 2006. RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), August 2001. UBL-2.1-ASN.1 UBL 2.1 Abstract Syntax Notation 1 (ASN.1) Alternative Representation Version 1.0. Latest version. http://docs.oasis-open.org/ubl/UBL-2.1-ASN.1/v1.0/UBL-2.1-ASN.1-v1.0.html. UBL-2.1-UML UBL 2.1 Unified Modeling Language (UML) Alternative Representation Version 1.0. Latest version. http://docs.oasis-open.org/ubl/UBL-2.1-UML/v1.0/UBL-2.1-UML-v1.0.html. UN/CEFACT Rec. 37Signed Digital Evidence Interoperability Recommendation, 27 September 2010. XAdES (ISO) ISO 14533-2:2012 Processes, data elements and documents in commerce, industry and administration -- Long term signature profiles -- Part 2: Long term signature profiles for XML Advanced Electronic Signatures (XAdES) XML C14NJohn Boyer, Canonical XML Version 1.0, 15 March 2001. XPath 2.0Anders Berglund, et al., XML Path Language (XPath) Version 2.0, 23 January 2007. XPointerSteven DeRose, et al., XML Pointer Language (XPointer) Version 1.0 Working Draft, 16 August 2002. XSLT 2.0Michael Kay, XSL Transformations (XSLT) Version 2.0, 2007-01-23.
UBL 2.1 Business Objects The processes described in this section, and the business rules associated with them, define a context for the use of UBL 2.1 business documents. They are normative insofar as they provide semantics for the UBL document schemas, but they should not be construed as limiting the application of those schemas. UBL 2.1 extends the generalized supply chain processes of UBL 2.0 (including the commercial collaborations of international trade) to include support for collaborative planning, forecasting, and replenishment; vendor managed inventory; utility billing; tendering; and intermodal freight management. The following diagram illustrates the business context use case covered by UBL 2.1.
UBL 2.1 Use Case [Use Case Diagram]
The document types included in UBL 2.1 are listed in . It is important to note that, as with previous UBL releases, the UBL 2.1 library is designed to support the construction of a wide variety of document types beyond those provided in the 2.1 package. It is expected that implementers will develop their own customized document types and components and that more UBL document types will be added as the library evolves. For guidance in customizing UBL document types, see the UBL Guidelines for Customization .
General Business Rules This section describes some of the requirements and general business rules that are assumed for collaborations and document exchanges using UBL 2.1.
Items An item may be a product (goods) or a service Items may have multiple classifications A contract may influence prices of items An item may be part of another item An item may have a price per unit and an order unit An item may reference pictures and documents An item may have a validity period An item may refer to other relevant or necessary items For a discussion of the difference between item and line item see .
Item Identification One of the following identifiers may be used to identify each Item (for example, a product): Buyer’s Item Identification, or Seller’s Item Identification, or Manufacturer’s Item Identification, or Catalogue Item Identification, or Item Identification according to a system promulgated by a standards body, industry group, or community of use. The Item may be further distinguished by the specification of Measurement(s) or Physical Attribute(s). This enables specification of the following kinds of item: Item Requiring Description This is an item that is not identified by an unambiguous machine-processable identifier and requires additional descriptive information to precisely identify it. Customer Defined Item This is an item that the customer describes according to his need, and in the specification of which the customer may make some reference to comparable “standard” items. Item Requiring Measurements This is an item for which it is necessary to specify one or more measurements as part of the descriptive specification of the item.
Item Instances Certain Items may be identified and ordered as individual, unique objects—for example, a specific car rather than a make and model of a car. This form of identification may also be needed for product tracing (e.g., perishable goods) or because of the nature of the commodity (e.g., used, collectible, specialized, or rare). In data modeling terms, an Item Instance is an extension of an Item.
Item Pricing For any given Item, price ranges by amount, quantity, location, etc., are specified by the Seller during the sourcing stage. They are not repeated back to the Seller during Ordering; only the active price is specified. In some cases, the Buyer may not know the Item Price, in which case it is not specified. This makes a detailed response from the Seller necessary; see .
Hazardous Items Although ordered items may include Hazardous items, it is not necessary to specify information related to Hazardous status at the order stage. The Buyer may not be aware of the nature of the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice and Transportation documents.
Parties In UBL, a party is defined as an individual, a group, or a body having a role in a business function. Dependent on the business process, a Party may play various roles in the document exchange. For a list of UBL parties and their roles, see .
Multilingual Text Some textual components, such as Notes and Description, may be specified in several languages. Each should be a separate occurrence of the component, using the language attribute to define its presentation. However, multiple occurrences of the same textual components should not be in the same language.
Taxation Rules UBL does not provide documents for tax reporting purposes. Instead, it provides structures to support the information on which taxes are based. These aim to be generic and not based on any specific tax regime.
Item vs. Line Item Many of the UBL document types employ the concept of a “line” inherited from traditional paper documents such as purchase orders and invoices. As in these older realizations, a “line” is a substantial data object with a number of subfields, typically including a short description, quantity, unit name, unit price, extension, and so on. Often in UBL these data structures include an element named Item that describes more fully the item of sale being ordered, invoiced, shipped, etc. Item in the line context always refers to the generic item of sale, not a unique, trackable, individual instance of such an item. In the case of line structures such as InvoiceLine and TenderLine, the relationship between the line and the Item it contains is unproblematic, but a person unfamiliar with traditional usage may easily be confused by the line element called LineItem. In traditional business processes, “line item” is a common name for the entire line structure in a purchase order or invoice, not just the item of sale contained in the line. Thus, despite the name, a LineItem is not an Item but rather a complex data structure that contains an Item along with quantity, price, and so on.
Shipment vs. Consignment References to “shipment” and “consignment” appear in a number of places in the UBL data model relating to the transport of goods. For IT specialists unfamiliar with the way these terms are used in international trade, the structural relationships between the two can be puzzling. For example, a close look at the data model shows that shipments can comprise multiple consignments and consignments can comprise multiple shipments. This is not a design flaw but rather a reflection of the possible real-world relationships between the two concepts. Shipment and consignment actually refer to two different ways of looking at the same (possibly very complex) situation. From the physical or logistical point of view, a consignment is the transportation of an identifiable collection of goods items from one party (the consignor) to another (the consignee) via one or more modes of transport. From the contractual or logical point of view, a shipment is the contractual arrangement whereby an identifiable collection of goods items is to be transported from one party (the shipper) to another party (the recipient). In UBL, the party originating the shipment is usually a supplier, and the party receiving the shipment is usually a buyer. In the simplest fulfilment scenario, these distinctions are almost invisible; see below (used, like the subsequent three, by permission of Document Engineering Services). In this case, the supplier of the contracted shipment is the consignor of the physical goods, and the buyer is the consignee.
Simple Fulfilment [Simple Fulfilment Diagram]
Often, however, a single contractual shipment is split up into separate physical consignments that may be received on separate schedules, as shown in . The shipper may use multiple carriers, or the shipment may be so large that it must be transported in multiple vessels, becoming in effect multiple consignments. It is therefore often necessary for the UBL description of a shipment to contain descriptions of the consignments into which the goods have been divided.
Split Fulfilment [Split Fulfilment Diagram]
So far, the shipper (here a supplier) remains the only consignor and the recipient (here the buyer) the only consignee. But sometimes the division of a shipment into consigments takes place “behind the scenes” through the involvement of a freight forwarder, who becomes both a second consignee and a second consignor (). The “shipment” in this case is the entire end-to-end organization of the transport of goods on behalf of the shipper.
Intermediary Fulfilment [Intermediary Fulfilment Diagram]
Another layer of complexity is introduced when pieces of different, possibly unrelated shipments are consolidated into a single consignment to make the physical process more efficient (to share space in the same shipping container, for example, which optimizes transport by ensuring that the container is fully loaded and also provides a more competitive tariff). In , goods from two completely unrelated business transactions between two buyers and their suppliers — two different shipments — are consolidated by a freight forwarder into a single consignment for part of their journey and then separated again by another freight forwarder farther on. This requires the UBL description of the consignment to contain descriptions of the shipments participating in the consolidation. Note that the transaction between the two freight forwarders is itself a shipment (a consolidated shipment), and its data structure must be able to describe the two shipments it is covering (Supplier A to Buyer A and Supplier B to Buyer B) so that the receiving forwarder knows how to deconsolidate the consignment.
Consolidated Fulfilment [Consolidated Fulfilment Diagram]
Note that the word “consignment” in the context of transportation has a meaning different from that of “consignment” in sales and vendor-managed inventory ().
Transport vs. Transportation The terms “transport” and “transportation” both appear many times in the UBL data model. There is no semantic difference between these terms as used in UBL; in the context of freight management, they mean exactly the same thing: the conveyance of goods or persons. “Transportation” is the oldest of the two forms, the noun “transportation” first appearing in written English about 70 years earlier than the noun “transport”. UBL 2.0 adopted “transportation” as the preferred form in terms such as “transportation service” and “transportation status”, but in the process of developing UBL 2.1, which features greatly expanded data representation capabilities for multimodal freight management, it became clear that “transport” is the form to be preferred, both because it is shorter and because it is the more commonly used of the two in international contexts. The decision to adopt “transport” for new usages while preserving backward compatibility with UBL 2.0 by retaining “transportation” in data items from the earlier release has resulted in the mixed terminology seen here.
Financial Information UBL 2.1 has been enhanced to support the financial information required for downstream processing of Invoices within financial services. By aligning information models, business vocabularies such as UBL for eBusiness and ISO 20022 for eFinance enable Straight Through Processing (STP) and paperless trading along the entire Financial Supply Chain. For example, the UBL Invoice and Remittance Advice can be used together with financial messages to ensure end-to-end transport of reconciliation identifiers (invoicing party references). In particular, UBL provides a solution for advanced external remittance, where the UBL Remittance Advice is used to transmit the details of complex remittance information associated with the payment initiation process (see ISO 20022 guides for details). UBL 2.1 is also designed to support basic trade financing practices (invoice financing, factoring, pre-shipment/order financing, Letter of Credit, etc.).
Indirect Taxes The structure and semantics of UBL 2.1 with respect to taxation information have been aligned with the OASIS Indirect Tax Reference Model Version 2.0 produced by the OASIS Tax XML TC supported by the OECD. The purpose of this reference model is to present a model of the tax related information contained within the messages exchanged between the participants involved in a business transaction, the primary purpose of which is not tax-related, but which may be subject to the imposition of an indirect tax. This model is intended to serve as a reference for any effort to analyze the related messages (documents) of an implementation to verify that the indirect tax implications are adequately addressed, and as input to any effort to define message-oriented specifications involving indirect taxation. It is based on a three party scenario, where parties in a commercial business process can conduct their transactions and provide taxation, customs or independently auditable information when required.
Overview of Business Processes Following from UBL 2.0, the UBL 2.1 documents and library support an increased range of different business processes. These processes (with the additions in 2.1 shown in underlined boldface) can be categorized as follows: Procurement Sourcing Pre-Award Tendering Catalogue Post-Award Catalogue Quotation Ordering Fulfilment Billing Freight Billing Utility Billing Payment Replenishment Collaborative Planning, Forecasting, and Replenishment Vendor Managed Inventory Cyclic Replenishment Program Transportation International Freight Management Intermodal Freight Management Freight Status Reporting International Trade Certification of Origin of Goods The following sections contain the formal business process descriptions:
Tendering Tendering is the case where a contracting authority (the Originator) initiates a procurement project to buy goods, services, or works during a specified period, as shown in the following diagram.
The Tendering Process [Tendering Process Diagram]
A similar but less formally defined process than tendering is quotation (see ).
Contract Information Preparation The Tendering process optionally begins with publication of a Prior Information Notice prepared by a Contracting Authority to declare the intention to buy goods, services, or works during a specified period. The purpose of this step (if implemented) is to reduce preparation time when an actual Contract Notice is published (see ).
Contract Information Preparation [Tendering Process Diagram]
Contract Information Notification The process of Notification includes the publication by the Contracting Authority of a Contract Notice to announce the project to buy goods, services, or works. The details shown here are specific to the EU, which requires contracts over a certain amount (Harmonized contracts) to be published in the Official Journal of the EU. Other tendering contexts will differ in their publication requirements.
Contract Information Notification [Contract Information Notification Diagram]
Invitation to Tender In some procedures, the Contracting Authority invites economic operators to participate in a contest by sending them an invitation to tender using a Call for Tenders to define the procurement project to buy goods, services, or works during a specified period. The Call for Tenders may be sent jointly with an unstructured letter of invitation to tender.
Invitation to Tender [Invitation to Tender Diagram]
Submission of Qualification Information The economic operator sends a Tenderer Qualification to the Contracting Authority to define its own situation or status relating to the requirements of the Contracting Authority for a specific tendering process. The Contracting Authority uses the Tenderer Qualification Response to notify the Tenderer of its admission to or exclusion from the tendering process.
Submission of Qualification Information [Submission of Qualification Information Diagram]
Submission of Tenders A Tenderer submits one or more Tender documents that offer a tender to the Contracting Authority for bid. The Contracting Authority responds with a Tender Receipt to notify the reception of the tender for a tendering process. The date and time of the Tender Receipt are significant, because tendering procedures usually have strict deadlines for tender presentation.
Submission of Tenders [Submission of Tenders Diagram]
Awarding of Tenders The awarding of tenders takes place in three phases. First, the Contracting Authority notifies each tenderer of its success or failure in winning the contract, using the Awarded Notification document to communicate the contract award to the winning tenderer or the Unawarded Notification document to communicate that the contract has been awarded to another tenderer.
Award Notification [Award Notification Diagram]
Second, the Contracting Authority creates a Contract Award Notice to announce the awarding of a procurement project.
Award Publication [Award Publication Diagram]
Finally, the Tenderer sends a Guarantee Certificate to notify the deposit of a guarantee.
Guarantee Deposit [Guarantee Deposit Diagram]
Catalogue A Catalogue is a document with structured item information that is used for commercial purposes over a period of time. It can be established, updated and deleted with different types of catalogue transactions. Different meanings are given to the concept of catalogue depending on the user’s perspective. Thus, it can also be understood as: a tender: an electronic document which contains all references of items, services and prices available, proposed by the Catalogue Provider. a set of needs: list of needs of products or services that the Customer Party may purchase or contract. a requirement: list of selected items and corresponding prices supplied to a Catalogue Provider to be bought. Document types associated with Catalogue processes are Catalogue Request, Application Response, Catalogue Item Specification Update, Catalogue Pricing Update, and Catalogue Deletion.
Catalogue Business Rules Any conditions specified in the contract shall overrule those stated in the common Catalogue. A Catalogue exchange shall be between one Provider and one Receiver Party. A classification system may have its own set of properties. A classification scheme shall have metadata. A Catalogue may have a validity period. A Catalogue should include item classifications. Classification schemes should include standard and specific properties. A Catalogue may refer to the lot (sub-section) of a contract. A Catalogue may explicitly specify the framework contract reference. A Catalogue may refer to a DPS contract number. When a Catalogue item is updated, the item shall be replaced in the Catalogue. When a Catalogue item is updated, historical information about replaced or updated items must be available to reconcile with outstanding transactions. Prices may be updated independently of other Catalogue information. Catalogue distribution may be Provider or Receiver Party initiated. If a Receiver initiates a request for a Catalogue, they may request an entire Catalogue or only updates to either pricing or item specification details. Whether Receiver Party initiated or not, the decision to issue a new Catalogue or update an existing one shall be at the discretion of the Provider Party. If an updated Catalogue is issued, then an action code shall define the status of the items in the Catalogue.
Catalogue Provision Catalogue provision is the case where a Provider sends information regarding items available for purchase to a Receiver. This may be on request or unsolicited. Because they are only potential purchasers, a Receiver may never become a Customer Party.
Create Catalogue The process of creating a Catalogue is shown in the following diagram. The UBL document types involved are Catalogue, Catalogue Request, and Application Response.
Create Catalogue Process [Create Catalogue Diagram]
Update Catalogue Item Specification The process of updating a Catalogue Item specification using Catalogue Item Specification Update is shown in the following diagram. The Catalogue Request and Application Response documents also participate.
Update Item Specification Process [Update Item Specification Diagram]
Update Catalogue Pricing The process of updating Catalogue pricing is shown in the following diagram. The UBL document types involved are Catalogue, Catalogue Request, Catalogue Pricing Update, and Application Response.
Update Catalogue Pricing Process [Update Catalogue Pricing Diagram]
Delete Catalogue Deletion of a Catalogue using Catalogue Deletion and Application Response is shown in the following diagram.
Delete Catalogue Process [Delete Catalogue Diagram]
Punchout Punchout is a technological innovation whereby an Originator is able to directly access a Seller’s catalogue application from within the Seller’s own procurement application.
Punchout Sourcing Process [Punchout Sourcing Diagram]
The Originators leave (“punch out” from) their system and interact with the Seller’s catalogue to locate and order products, while the Seller’s procurement application transparently gathers pertinent information. While conceptually the punchout request is a form of Request for Quotation (see ), the exchange transaction is tightly coupled to the specific catalogue application and is considered outside the scope of UBL; thus, the only UBL document type involved in this process is Quotation.
Quotation Less formally defined than a tender (see ), a quotation process is the case where the Originator asks for a Quotation via a Request for Quotation, as shown in the following diagram.
Quotation Process [Quotation Diagram]
Ordering Ordering is the collaboration that creates a contractual obligation between the Seller Supplier Party and the Buyer Customer Party. Document types in these processes are Order, Order Response, Order Response Simple, Order Change, and Order Cancellation.
Ordering Process [Ordering Diagram]
Ordering Business Rules The Order may specify allowance and charge instructions (e.g., freight, documentation, etc.) that identify the type of charge and who pays which charges. The Order may be placed “on account” against a trading credit account held by the Seller, or against a credit/debit card account, or against a direct debit agreement. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an Order, additional currencies may be specified both for individual item pricing and for any allowances or charges. Trade discount may be specified at the Order level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed response from the Seller necessary; see . The Order provides for multiple Order Lines. The Order may specify delivery terms, while the Order Line may provide instructions for delivery. The Buyer may indicate potential acceptable alternatives.
Order Response Simple The Order Response Simple is the means by which the Seller confirms receipt of the Order from the Buyer, indicating either commitment to fulfil without change or that the Order has been rejected.
Order Response Proposed changes to an Order by the Seller are accomplished through the full Order Response document. The Order Response proposes to replace the original Order. It reflects the entire new state of an order transaction. It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering. These may include: Delivery date, offered by the Seller if not specifically requested by the Buyer Prices Discounts Charges Item Classification codes The Seller may advise on replacements, substitutes, or other necessary changes using the Order Response.
Order Change The Buyer may change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see ) followed by a new, complete replacement Order. An Order Change reflects the entire current state of an order transaction. Buyers may initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers may accept or reject the Order Change using either Order Response or Order Response Simple.
Order Cancellation At any point in the process, a Buyer may cancel an established order transaction using the Order Cancellation document. Legal contracts, trading partner agreements, and business rules will determine the point at which an Order Cancellation will be ignored (e.g., at the point of manufacture or the initiation of the delivery process). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of contract formation for business commitments will dictate which, if any, of these restrictions or guidelines will apply.
Fulfilment Fulfilment is the collaboration in which the goods or services are transferred from the Despatch Party to the Delivery Party. Document types in these processes are Despatch Advice, Receipt Advice, Order Cancellation, Order Change, and Fulfilment Cancellation. In common practice, fulfilment is either supported by a proactive Despatch Advice from the Despatch Party or by a reactive Receipt Advice from the Delivery Party. If the Customer is not satisfied with the goods or services, they may then cancel or change the order (see ). The Seller may have a fulfilment (or customer) service dealing with anomalies. Cancellation of a Despatch Advice or Receipt Advice is accomplished using the Fulfilment Cancellation document (see ).
Despatch Advice Business Rules The Despatch Advice is sent by the Despatch Party to the Delivery Party to confirm shipment of items.
Fulfilment with Despatch Advice Process [Fulfilment with Despatch Advice Diagram]
The Despatch Advice provides for two situations: Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver can check the Transport Handling Unit and then the contained items. Quantities of the same item on the same Order Line may be separated into different Transport Handling Units and hence appear on separate Despatch Lines within a Transport Handling Unit. Organization of the delivery set of items by Despatch Line, annotated by the Transport Handling Unit in which they are placed, to facilitate checking against the Order. For convenience, any Order Line split over multiple Transport Handling Units will result in a Despatch Line for each Transport Handling Unit they are contained in. Additionally, in either case, the Despatch Advice may advise: Full Despatch—advising the Recipient and/or Buyer that all the items on the order will be, or are being, delivered in one complete consignment on a given date. Partial Despatch—advising the Recipient and/or Buyer that the items on the order will be, or are being, partially delivered in a consignment on a given date. Despatch Lines of the Despatch Advice need not correspond one-to-one with Order Lines, and are linked by a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines from one Order Line. Equally, partial despatch may result in some Order Lines not being matched by any Line in a Despatch Advice. Within a Despatch Advice, an Item may also indicate the Country of Origin and the Hazardous nature of the Item.
Receipt Advice Business Rules The Receipt Advice is sent by the Delivery Party to the Despatch Party to confirm receipt of items. It also is capable of reporting shortages or damaged items.
Fulfilment with Receipt Advice Process [Fulfilment with Receipt Advice Diagram]
The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding Despatch Advice: Indication of receipt by Transport Handling Unit(s) and contained Receipt Lines one-to-one with the Despatch Advice as detailed by the Seller party, or Indication of receipt by Receipt Lines annotated by Transport Handling Unit, one-to-one with the Despatch Advice as detailed by the Seller party. The Receipt Advice allows the Delivery Party to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason.
Fulfilment Cancellation Business Rules In real life, the sender of a Despatch Advice or Receipt Advice sometimes needs to cancel the document after it has been sent. The Fulfilment Cancellation document is provided for this purpose. For example, a Despatch Advice may later be cancelled by the Supplier when a problem with shipment prevents the delivery of goods, or the goods to be shipped are not available, or the order is cancelled; in these cases, the customer cancels receipt and adjusts the order accordingly (see ). Similarly, a Receipt Advice may later be cancelled by the customer (see ) if the customer discovers an error in ordering (failure to follow formal contractual obligations, incorrect product identification, etc.) or a problem with a delivered item (malfunction, missing part, etc.). In this case, the billing and payment process may be put on hold.
Billing In the Billing process, a request is made for payment for goods or services that have been ordered, received, or consumed. In practice, there are several ways in which goods or services may be billed. Document types in these processes are Invoice, Credit Note, Debit Note, and Application Response. For UBL 2.1, we assume the following billing methods: Traditional Billing Using Credit Note Using Debit Note Self Billing (also known as billing on receipt) Using Credit Note Using Self Billed Credit Note
Billing Business Rules An Invoice defines the financial consequences of a business transaction. The Invoice is normally issued on the basis of one despatch event triggering one Invoice. An Invoice may also be issued for pre-payment on a whole or partial basis. The possibilities are: Prepayment invoice (payment expected) Pro-forma invoice (pre Despatch Advice, payment not expected) Normal Invoice, on despatch for despatched items Invoice after return of Receipt Advice The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice, or Receipt Advice by a Reference for those documents. The Invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT—Value Added Tax—superimposed). Charges may be specified either as a lump sum or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover: Packaging Delivery/postage Freight Documentation Each Invoice Line refers to any related Order Line(s) and may also refer to the Despatch Line and/or Receipt Line.
Traditional Billing Traditional billing is where the supplier invoices the customer when the goods are delivered or the services are provided. In this case, the invoice may be created at the time of despatch or when the Delivery Party acknowledges that the goods have been received (using a Receipt Advice). When there are discrepancies between the Despatch Advice, Receipt Advice, or Invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an Application Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or another Invoice as required. A Credit Note or Debit Note may also be issued in the case of retrospective price change. Credit Notes or Debit Notes may be also issued after the Billing collaboration (as part of the Payment collaboration).
Billing Using Credit Notes Billing using Credit Note is shown in the following diagram.
Billing with Credit Note Process [Billing with Credit Note Diagram]
When using Credit Notes, the Supplier (in their Accounting role) is responsible for specifying the tax requirements.
Billing Using Debit Notes Billing using Debit Note is shown in the following diagram.
Billing with Debit Note Process [Billing with Debit Note Diagram]
When using Debit Notes, both the Supplier (in their Accounting role) and the Customer (in their Accounting role) are responsible for providing taxation information.
Self Billing A self billing process is where a Customer “invoices” itself, in the name and on behalf of the Supplier, and provides the Supplier with a copy of the self billed invoice.
Self Billing Using Credit Notes Self Billing using Credit Note is shown in the following diagram.
Self Billing with Credit Note Process [Self Billing with Credit Note Diagram]
If the Supplier finds that the Self Billed Invoice is incorrect, e.g., wrong quantities or wrong prices, or if the goods have not been invoiced at all, it may send an Application Response or a Credit Note to the Customer. The customer may then verify whether the adjustment is acceptable or not and consequently issue another Self Billed Invoice or a Self Billed Credit Note.
Self Billing Using Self Billed Credit Notes Self Billing using Self Billed Credit Note is shown in the following diagram.
Self Billing with Self Billed Credit Note Process [Self Billing with Self Billed Credit Note Diagram]
When using Self Billed Credit Notes, the Customer is raising the Self Billed Credit Note in the name and on behalf of the Supplier. Therefore the Supplier and the Customer are still both responsible for providing taxation information.
Reminder for Payment A Reminder may be used to notify the Customer of accounts due to be paid.
Reminder for Payment Process [Reminder for Payment Diagram]
Freight Billing An extension of the Billing process is that of Freight Billing. This represents the billing process between the Transport Service Buyer (e.g., the Consignor) and Transport Service Provider (e.g., a Freight Forwarder) through the use of an invoice for freight charges. The Transport Service Provider initiates the process of billing the Transport Service Buyer for logistic services. The Freight Invoice lists the charges incurred in order to fulfil the agreed service.
Freight Billing Process [Freight Billing Diagram]
Utility Billing This process defines the billing process for invoicing between suppliers of utilities (including electricity, gas, water, and telephony services) and private and public customers. The Utility Statement supplements an Invoice with information about consumption of the utility’s services. An invoice may refer to one or more utility statements, and a utility statement may refer to one or more invoices.
Utility Billing Process [Utility Billing Diagram]
Payment Notification In the payment notification process, the Payee (who is most often the Accounting Customer) is notified of any funds transferred, against the account of the Accounting Supplier, using a Remittance Advice document.
Payment Notification Process [Payment Diagram]
Report State of Accounts A Statement of account may be used to notify the Accounting Customer of the status of the billing.
Statement Process [Statement Diagram]
Collaborative Planning, Forecasting, and Replenishment The VICS Collaborative Planning, Forecasting, and Replenishment (CPFR®) guidelines formalize the processes by which two trading partners agree upon a joint plan to forecast and monitor sales through replenishment and to recognize and respond to any exceptions. In the UBL 2.1 context of use, these CPFR processes between the retailer and the manufacturer have been extended to cover the planning process between other parties such as the manufacturer and the supplier. These binary collaboration definitions are the template guidelines for implementers to build their own collaboration process based on their supply chain topology and requirements. As shown in Figure 2-2 of , the seller and the buyer engage in three main activities in order to improve the overall performance of the supply chain: Planning establishes the ground rules for the collaborative relationship. Trading partners exchange information about their corporate strategies and business plans in order to collaborate in the development of a Joint Business Plan. The Joint Business Plan identifies the significant events that affect supply and demand in the planning period, such as promotions, inventory policy changes, store openings/closings, and product introductions. The Forecasting phase involves the development of a shared plan based on consumer demand. Estimation of consumer demand at the point of sale is called sales forecasting, and future product ordering based on the sales forecast is referred to as order forecast. The Replenishment phase involves order generation, which transitions forecasts to firm demand, and order fulfilment, the process of producing, shipping, delivering, and stocking products for consumer purchase. Note: This phase may be implemented using other UBL processes. A fourth collaborative activity, Analysis, involves monitoring the execution of activities for exceptions that are identified during the strategy and planning phase. Calculation of key performance metrics and plan adjustments for improving results also take place in Analysis. This activity is represented in the CPFR diagram by the arrows labeled “Exception Triggers” and the process called “Resolve/Collaborate on Exception Items” in the Forecasting phase. While these collaboration activities are presented in logical order, most companies are involved in all of them at any moment in time. There is no predefined sequence of steps. Execution issues can impact strategy, and analysis can lead to adjustments in forecasts.
Collaboration Agreement and Joint Business Planning The Collaboration Arrangement is the preparatory step that defines the scope of the project, assigns roles, establishes procedures for data interchange, and issues identification and resolution. The following actions are performed through meetings and agreements: Receive and review background information from the sales organization or buyers Identify the product categories that should be included in the initial scope Define Collaboration Objectives Define specific metrics that reflect the objectives Determine the Event collaboration cycle Determine the times of the review meetings to discuss the results Document the data sources that are essential for a successful event collaboration process, and Document additional information that can be used in the event analysis.
CPFR Steps 1 and 2 [CPFR Steps 1 & 2 Diagram]
The first step of the CPFR Process continues with the exchange of messages containing purchase conditions. (UBL 2.1 does not standardize the format of such messages.) Afterwards, for determining the exception criteria that should be monitored and handled during the execution, Exception Criteria messages are exchanged. Exchange of revised Exception Criteria messages continues until the criteria are accepted by both sides.
Establish Collaborative Relationships [Establish Collaborative Relationships Diagram]
In CPFR Step 2 (the Joint Business Planning phase) there are two messages that should be exchanged and agreed upon: Retail Event and Trade Item Location Profile. Revisions are exchanged until an agreement is achieved.
Create Joint Business Plan [Create Joint Business Plan Diagram]
Sales Forecast Generation and Exception Handling CPFR Step 2 helps the buyer and seller agree to the event details and calendar that meet their joint business and collaboration objectives. The objective of the event calendar is to ensure that events are planned to achieve the optimal results and to enable both parties to plan the execution of the event more accurately, from the preparation of advertising and displays to the production and delivery of the promotional stock. In CPFR Step 3, the Sales Forecast is generated. Following Option A, Conventional Order Management, from the CPFR implementation scenarios (see , Table 3), the responsible partner for the generation of Sales Forecast is the Seller. Having Event Calendar information and the Delivery Plan already in their system, there are two more kinds of information that the Seller needs for an effective Sales Forecast: POS Data and DC Data. As shown in and , both of these pieces of information are sent within a Product Activity message. This time there is no revision of the messages because these messages contain statistical and historical information collected previously by the Buyer.
CPFR Steps 3, 4, and 5 [CPFR Steps 3, 4, and 5 Diagram]
Based on the event details (dates, products, tactics, etc.) and using the available data source(s), a volume estimate/forecast is created for each product/store combination included in the scope of the event by the Seller. During the calculation, sales forecasting algorithms make use of the coefficients for causal factors based on the event history. Once the Sales Forecast suggestion is generated and sent to the Buyer, the Buyer revises it and might recommend some changes on the Forecast. The Forecast Revision message exchange continues until the forecast is agreed by both sides.
Create Sales Forecast [Create Sales Forecast Diagram]
In many cases some time may elapse between Sales Forecast Generation and Order Generation. During this period, both sides observe changes to the conditions. If one of the partners detects an exception invalidating the exception criteria defined in CPFR Step 1, it sends an Exception Notification message to the other party. Exceptional circumstances that may be communicated between trading partners include deviations between planned impacts (either between buyer and seller, or between subsequent generations of planned impacts from the same trading partner), as well as deviations between planned and actual impacts. It should be noted that both sides might detect an exception, and therefore both sides should be capable of sending and receiving exceptions. Of course, for specific implementations if the collaborating parties want to change this behaviour, they can customize the process so that one partner will be responsible for the generation of the Exception Notifications. CPFR Step 4 is solely composed of the exception generation and receiving activity. CPFR Step 5, on the other hand, is the resolution of the Exceptions.
Exception Handling [Exception Handling Diagram]
If there is no Exception Notification Message within the defined period, the process continues with Order Forecast Generation (CPFR Step 6).
Order Forecast Generation and Exception Handling In the supply chain process, it is important for sales forecasts that are created to be converted into the shipment (order) forecasts that can then be used in the production planning processes at the manufacturing locations and be incorporated into the ordering processes at the retailer. As shown in , the responsibility for creating Order Forecast belongs to the Seller per Option A of the CPFR implementation scenarios (see , Table 3). Sales forecasts can be transformed into order forecasts by incorporating inventory status information, possible retail event plans, and current point of sale data. Therefore, Buyer sends the updated versions of the Retail Event, Inventory Status, and POS Data to the Seller.
CPFR Steps 6, 7, 8 and 9 [CPFR Steps 6, 7, 8 and 9 Diagram]
After the Seller creates the Order Forecast using the obtained data, it sends the forecast to the Buyer. The Buyer checks the order forecast and sends back a revision document which includes update requests if necessary. The exchange of Order Forecast Revisions continues until there are no further update requests and the Order Forecast is agreed by both sides. Document types used in this process are Retail Event, Product Activity, Forecast, and Forecast Revision.
Create Order Forecast [Create Order Forecast Diagram]
After the Order Forecast is frozen, the process continues with the exception detection activity (CPFR Step 7). The exception detection process that follows Order Forecast is similar to process described earlier for exception detection following Sales Forecast (see ). The only difference between the Order Forecast and Sales Forecast exceptions is the content of the exceptions. CPFR Step 8, Order Forecast Exception Resolution activity, is handled similarly to Sales Forecast Exception Resolution.
Identifying and Resolving Exceptions for Order Forecast [Identifying and Resolving Exceptions for Order Forecast Diagram]
Exception Monitor During Execution [Exception Monitor During Execution Diagram]
If there is no exception during a period of time, the process continues with the Order Generation Step. From the technical point of view, the exception monitoring and its resolution are exactly same as in the case of Order Forecast Exception Handling and Sales Forecast Exception Handling. The difference is in the content of the exceptions. The actual events and orders are compared to the Forecasted Sales and Forecasted Orders. When there is a situation violating the normal exception criteria, one of the sides might generate an exception notification. Besides comparison of forecasts, other information gathered during the execution is observed (e.g., event dates, POS data, etc.). The resolution of the exceptions is the same as the process carried out for Sales Forecast Exception resolution.
Vendor Managed Inventory Vendor Managed Inventory (VMI) is a family of business processes in which the Retailer Customer Party for an item provides certain information to the Seller Supplier Party, and the Seller Supplier Party takes full responsibility for maintaining an agreed-upon inventory of the item, usually at the Retailer Customer Party’s point of sale. A third party logistics provider can also be involved to make sure that the Retailer Customer Party has the required level of inventory by adjusting the demand and supply gaps. UBL supports three common models of VMI: Basic VMI Cyclic Replenishment Program (CRP) Replenishment on Customer Demand These processes are described in more detail below. It should be noted that the particular semantics used here come from a large-scale UBL application developed for the Italian textile and clothing industry by ENEA, the Italian National Agency for New Technologies, Energy, and Sustainable Economic Development (see ). These models are applicable to the implementation of vendor-managed relationships in a broad range of retail sectors, but for the sake of simplicity, and in keeping with the model application, the two principal parties in the VMI relationship (the Seller Supplier Party and the Retailer Customer Party) are referred to as “producer” and “retailer” in the descriptions that follow; more generically, they are vendor and customer.
Basic Vendor Managed Inventory In the classic VMI scenario, a shop-within-a-shop area or an entire store is managed completely by the producer. The logistic concept of VMI can be combined with consignment/concession as well as with charge-on-delivery as the financial model. Mostly it is combined with consignment.
Initial Stocking of the Area by Producer At the beginning of the cooperation, the area is stocked by the producer. The retailer receives item and delivery information and reports back the goods actually received. UBL document types used here are Catalogue, Despatch Advice, and Receipt Advice.
Initial Stocking of the Area by Producer [Initial Stocking of the Area by Producer Diagram]
Report of Sales and Inventory Movement The sales and inventory movement information is transferred from the retailer to the producer using Product Activity.
Report of Sales and Inventory Movement [Report of Sales and Inventory Movement Diagram]
Permanent Replenishment Based on sales and inventory movement, the producer periodically makes a new delivery of goods accompanied by a Despatch Advice. If the delivery contains an item not previously stocked, an updated Catalogue is also sent so that the retailer can add the item to its product database. Upon delivery of the goods, the retailer reports back the items received using a Receipt Advice.
Permanent Replenishment [Permanent Replenishment Diagram]
Invoicing for Vendor Managed Inventory A UBL Invoice is sent either on a delivery or a sales basis. In a charge-on-delivery model, the data for the invoice is prepared from the delivery, and in a consignment/concession model from the sales reports.
Invoicing for Vendor Managed Inventory [Invoicing for Vendor Managed Inventory Diagram]
Returns Initiated by the Producer If sales do not meet expectations, items are reallocated by the producer. Because the producer cannot request a retailer to send the products to a competitor, the producer requests a return and handles the goods afterwards by itself. Document types used here are Instruction for Returns, Despatch Advice, and Receipt Advice.
Returns Initiated by the Producer [Returns Initiated by the Producer Diagram]
Price Adjustments In the event of a price change, an updated price list (in the form of a new Catalogue containing the change) is sent from producer to retailer.
Price Adjustments [Price Adjustments Diagram]
Cyclic Replenishment Program (CRP) A variant of VMI is the Cyclic Replenishment Program (CRP). In this process, the producer establishes a catalogue of NOS (Never Out of Stock) or seasonal NOS items, and the retailer chooses items for cyclic (weekly) replenishment. The logistic scenario can be combined with the charge-on-delivery as well as with a consignment/concession model. At the end of every sales period, a report of sales and inventory movement at all retail locations is sent to the producer. CRP differs from the third VMI variant, Replenishment on Customer Demand (below), in that the producer cannot change the terms of the order.
Transfer of Base Item Catalogue The producer publishes the Catalogue of its NOS and seasonal NOS items to the retailer.
Transfer of Base Item Catalogue [Transfer of Base Item Catalogue Diagram]
Initial Stocking of the Area by Retailer At the beginning of the cooperative relationship—or the beginning of a season, if seasonal NOS products are the focus—the retailer orders its base stock, and the products are delivered. Order, Despatch Advice, and Receipt Advice are used in this process.
Initial Stocking of the Area by Retailer [Initial Stocking of the Area by Retailer Diagram]
Periodic (Weekly) Replenishment Each period (every week), the retailer’s system calculates the quantities needed for replenishment of the product area. From the result, an order is sent, and the producer responds with a direct delivery within 48 hours. The replenishment process uses the same documents in the same order as the Initial Stocking process, so the duplicate diagram is omitted here; see . It must be remembered, however, that the two processes are taking place at different points in time, so their pre and post conditions will be different.
Report of Sales and Inventory Movements At the end of each sales day, a report of all sales and inventory movement at all retail locations is sent from the retailer to the producer using Product Activity.
Report of Sales and Inventory Movements [Report of Sales and Inventory Movements Diagram]
Cyclic Replenishment Program Invoicing A UBL Invoice is sent either on a delivery or a sales basis.
Invoicing for Cyclic Replenishment Program [Invoicing for Cyclic Replenishment Program Diagram]
Synchronizing of Stock Information Information about the actual stock is synchronised periodically (for example, every one to three months) using Inventory Report. This is combined at least once a year with a physical inventory. The retailer sends an inventory report containing the information about the quantities currently in stock.
Synchronizing Stock Information [Synchronizing of Stock Information Diagram]
Changes to the Item Catalogue In the event of a change, either inside an item belonging to the CRP Catalogue or the relationship of an item to the CRP Catalogue, information about the change is sent to the retailer by sending an updated Catalogue document. Item change is indicated by an optional ActionCode field in each changed CatalogueLine.
Changes to the Item Catalogue [Changes to the Item Catalogue Diagram]
Replenishment On Customer Demand Another variant of VMI is Replenishment On Customer Demand. In this process, the producer selects a subset of its products for a specific retailer and sends out the related article catalogue. Then the producer periodically sends information about the availability of items so that the retailer can form the best ordering plan. The replenishment periodically happens on retailer (customer) demand, and unlike the case with CRP (above), the producer is allowed to propose changes to the orders. Also, because of the requirement to update item availability information, an additional document type (Stock Availability Report) is added to the process. The processes of sales and inventory reporting, invoicing, stock synchronization, and changing the catalogue are identical to the same processes in CRP. As with CRP, a report of sales and inventory movement at all retail locations is sent to the producer at the end of every sales period. Invoicing and logistics are normally charge-on-delivery but can also be based on a consignment/concession model.
Transfer of Base Article Catalogue The producer publishes a Catalogue of its products to the retailer. The catalogue can include basic articles, never-out-of-stock (NOS) articles, seasonal articles, short-season-collection articles, or seasonal NOS articles.
Transfer of Base Article Catalogue [Transfer of Base Article Catalogue Diagram]
Periodic Transfer of Article Availability Information The producer sends out information about availability of goods (quantities on hand, quantities incoming, articles out of stock) using a Stock Availability Report.
Periodic Transfer of Article Availability Information [Transfer of Article Availability Diagram]
Initial Stocking of the Area by Producer and Retailer At the beginning of the business cooperation—or perhaps at the beginning of a season, if seasonal NOS (never out of stock) products are the focus—the retailer orders its base stock and the products are delivered. Note that the producer is allowed to propose changes to the order (compare this figure with ). Document types used in this process include Order, Order Change, Despatch Advice, and Receipt Advice.
Initial Stocking of the Area by Producer and Retailer [Initial Stocking of the Area Diagram]
Periodic Replenishment Periodically, the retailer’s system calculates the quantities needed for replenishment of the area. From the result, an order is sent, and the producer responds with a direct delivery within 48 hours. The replenishment process uses the same documents in the same order as the Initial Stocking process, so the duplicate diagram is omitted here; see . It must be remembered, however, that the two processes are taking place at different points in time, so their pre and post conditions will be different.
Report of Sales and Inventory Movement Sales and inventory movement information is transferred daily from the retailer to the producer. The process for sales and inventory reporting is the same as in CRP (see ).
Invoicing for Replenishment On Customer Demand An invoice is sent either on a delivery or a sales basis. The invoice process for Replenishment On Customer Demand is the same as for CRP (see ).
Synchronizing Stock Information Information about the actual stock is synchronised periodically (for example, every one to three months). Synchronization occurs at least once a year together with a physical inventory. The stock synchronization process for Replenishment On Customer Demand is the same as in CRP (see ).
Changes to the Article Catalogue In the event of a change, either inside an item belonging to the Catalogue or the relationship of an item to the Catalogue, information about the change is sent to the retailer by sending an updated Catalogue document. Item change is indicated by an optional ActionCode field in each changed CatalogueLine. The process for changing the catalogue in Replenishment On Customer Demand is the same as in CRP (see ).
International Freight Management Freight management for domestic trade is typically accomplished using Despatch Advice and Receipt Advice (see ). The additional processes shown in are engineered to support the ordering and management of logistical services for international trade. With receipt of an order and acknowledgement by the Supplier Party that the goods are available and ready to be shipped, the Consignor or Consignee initiates the transportation arrangements. This includes booking the consignment with a Transport Service Provider such as the Freight Forwarder or Carrier and advising the Delivery Party of the arrangements as needed. Document types in these processes are Forwarding Instructions, Packing List, Bill of Lading, and Waybill. (Regarding the Transportation Status document type, see ). It should be noted that these processes involve the Consignee and Consignor and do not cover all the logistical processes required to physically move the goods or regulatory notifications such as Customs declarations. For a discussion of the difference between consignment (consignor to consignee) and shipment (shipper to recipient), see . For a discussion of the difference between transport and transportation, see .
Initiate Freight Management Process [Initiate Freight Management Process Diagram]
Forwarding Instructions Forwarding Instructions are normally used by any party who gives instructions for the transportation services required for a consignment of goods (the Transport Service Buyer) to any party who is contracted to provide the transportation services (called the Transport Service Provider). Forwarding Instructions may also be used by any party who requests a booking of shipment space to be made for the transportation services required for a consignment of goods to any party who will provide the underlying transportation services. The parties who issue this document are commonly referred to as the shipper, consignee, or consignor, while the parties who receive this document are forwarders, carriers, shipping agents, etc. Forwarding Instructions may also be issued by a freight forwarder or shipping agent in their capacity as a Transport Service Buyer. This document may be used to arrange for the transportation: Of different types of goods or cargoes Whether containerized or non-containerized Through different modes of transport, and From any origin to any destination.
Packing List A Packing List is normally issued by the Consignor. It states the distribution of goods in individual packages.
Bill of Lading A Bill of Lading is a transport document that is the evidence of a contractual agreement between the parties for the transportation service. The document evidences a contract of carriage by sea and the acceptance of responsibility for the goods by the carrier, by which the carrier undertakes to deliver the goods against surrender of the document. It is in common use for ocean or inland waterways modes of transport. The Bill of Lading (B/L) may serve as a document of title. A provision in the document that the goods are to be delivered to the order of a named person, or to order, or to bearer, constitutes such an undertaking. A Bill of Lading is normally issued by the party who provides the physical transportation services (e.g., the maritime carrier) to the party who gives instructions for the transportation services (shipper, consignor, etc.) as a receipt for the cargo and sometimes of instructions, stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided. A Bill of Lading may also be issued by the party who acts as an agent for the carrier or other agents to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided, but who does not provide the physical transportation service. In such case a Bill of Lading is signed “as agent”. Much of the information contained in the Bill of Lading corresponds to the information on the Forwarding Instructions. A freight forwarder, who can be either a Transport Service Provider or a Transport Service User according to different circumstances and depending on the contractual interlocutor, can assume responsibility for the shipment with regards to the shipper and issue Bills of Lading as a common carrier, a contractual carrier, or as a Non Vessel Operating Common Carrier (NVOCC). In such case, when the transportation is multimodal, it can provide a multimodal Bill of Lading.
Waybill A Waybill is a transport document issued by the party who undertakes to provide transportation services, or undertakes to arrange for their provision, to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the instructions for the beneficiary and may contain the details of the transportation, charges, and terms and conditions under which the transportation service is provided. Unlike a Bill of Lading, a Waybill is not negotiable and cannot be assigned to a third party (endorsement). It may be issued as a cargo receipt and is not required to be surrendered at the destination in order to pick up the cargo. This may simplify the documentation procedures between a Transport Service Buyer and a Transport Service Provider, but using this document in combination with international payments (e.g., documentary credits) is not advisable. A freight forwarder may decide to issue a waybill to communicate consignment, transport, and conveyance information to third parties, be they shippers, subcontractors, transport operators, or authorities.
Freight Status Reporting Freight Status Reporting is the process by which a Transport Service Provider (such as a Carrier or Freight Forwarder) communicates the status of shipments currently under their management to the Transport Users (such as a Freight Forwarder, Consignee, or Consignor). A Transportation Status document is provided either through a Transportation Status Request document or through an agreed status reporting procedure.
Freight Status Reporting Process [Freight Status Reporting Diagram]
Certification of Origin of Goods When a Consignor exports certain goods they may be required to attest to the origin of the goods. A Certificate of Origin is a document required by regulatory bodies declaring that goods in a particular international shipment are of a certain origin. It is the responsibility of the Exporter to sign the Certificate of Origin Application document and submit it for authentication to a recognized authority (such as a local chamber of commerce or designated government agency or board). This party becomes the Endorser and will issue the Certificate of Origin document. To do this the Endorser must have access to other documents, such as the commercial Invoice and Bill of Lading, in order to verify the Exporter’s claims that the goods originated in that country. In effect, the Certificate of Origin document is a dossier describing a set of related documents. After it is issued, the Certificate of Origin is sent to the Importer.
Certification of Origin of Goods Process [Certification of Origin of Goods Diagram]
Intermodal Freight Management Intermodal transport implies the use of a combination of transport modes. Any support for the management of such chains has to support the modal change of cargo flows from one mode to another in order to create seamless sequences of transportation legs. Quite often the end legs are carried by road, but there are instances of short sea shipping, inland waterways, and rail being used as end legs. The Intermodal Freight Management process differs from conventional international freight management in that it may involve multiple different transport modes. The focus is the multimodal transport chain as seen from the Transport User’s point of view. The Transport User needs information about all the possible transport services that can be used to build a complete transport chain. If the choices to be made by the Transport User or his agent are based upon the qualities of the transport services themselves, and not by which transport mode is used, the description of the transport services and the exchanges of information about the transport roles and services must be simple and common. Taking an intermodal approach requires a generalized view of the business processes, parties, and roles involved in the process. The roles of the various Parties are defined as follows: The Transport User is the role representing anyone who needs to have cargo transported. The Transport User provides the Transport Service Provider with instructions and detailed information about the cargo to be transported. The Transport Service Provider is the role that ensures the transport of the cargo from the origin to the destination. This includes the management of the transport services and the operation of the transport means and handling equipment. A Transport Service Provider may also provide administrative services required for moving the cargo, such as cargo inspection. The Transportation Network Manager is the role that extracts all information available regarding the infrastructure related to planning and executing transport and makes this information available to the Transport Service Provider. The Transport Regulator is the role that receives all mandatory reporting (and checks if reporting has been carried out) in order to ensure that all transport services are completed according to existing rules and regulations. It should be noted that one Party (person or organization) may take on different roles. For example, a freight forwarder is, on the one hand, a Transport Service Provider when its client is a Transport User. On the other hand, the freight forwarder is a Transport User when it acquires services from subcontractors to ensure that a transport service is carried out between origin and destination. In so doing, the freight forwarder can operate as agent, thus arranging a contractual relationship between the carrier and the shipper, or as principal, thus organizing the transportation chain by concluding contracts in its own name on behalf of the shipper(s). The Intermodal Freight Management process takes place in three stages: Planning: In this stage, the Transport Users express their transport demand in a standard format, the Transport Service Description Request. Transport Service Providers plan their transport services and announce them to Transport Users using the Transport Service Description. This stage also covers the arrangement of transport services between Transport Users and Transport Service Providers, establishing Transport Execution Plans. Once a Transport Execution Plan has been established, a Goods Item Itinerary is sent from the Transport Service Provider to the Transport User. The Goods Item Itinerary provides additional information related to the complete transport service. Execution: In this stage, Transport Service Providers perform the physical transport of the cargo, and they exchange information related to the status of the transported cargo with the Transport Users using the Transportation Status document. Furthermore, in this stage Transport Service Providers exchange regulatory information with Transport Regulators as well as receive status regarding the transport infrastructure from Transportation Network Managers using the Transport Progress Status document. Completion: This stage facilitates the issuing of proofs of delivery, claims, and invoices between Transport Service Providers and Transport Users.
The Generic Freight Management Process [The Generic Freight Management Process Diagram]
These three stages are detailed in the following diagram, which shows the part played in the Intermodal Freight Management process by the UBL document types Transport Service Description, Transport Service Description Request, Transport Execution Plan, Transport Execution Plan Request, Transportation Status, Transportation Status Request, Transport Progress Status, Transport Progress Status Request, Goods Item Itinerary, and Freight Invoice.
The Intermodal Freight Management Process [The Intermodal Freight Management Process Diagram]
Announcing Intermodal Transport Services The Transport Service Description is used to publish information about a transport service. A Transport Service Description Request is used to request such information. A transport service can be the physical transport of cargo between an origin and a destination, and it can also refer to other transport-related services such as terminal services, warehousing services, handling services, or document handling services.
Transport Service Description [Transport Service Description Diagram]
Establishing a Transport Execution Plan The Transport Execution Plan is a plan established between a Transport User and a Transport Service Provider in order to collaborate and document the details surrounding the provision of a required transport service. Depending on the nature of the transport service and the business relationship between the Transport User and the Transport Service Provider, the process of establishing a Transport Execution Plan may be carried out by means of multiple interactions between the two roles, from the initial request from the Transport User up to the final agreement of the Transport Execution Plan among the parties involved. The following diagram () shows the message exchange involved in a basic scenario. A Transport Execution Plan Request is sent from the Transport User in order to request a transport service. If the Transport Service Provider accepts the transport service request, he responds with a confirmed Transport Execution Plan. If the Transport Service Provider does not accept the transport service request, he responds with a rejected Transport Execution Plan. The handling of a Transport Service Request will in many cases depend upon whether or not there is a pre-established agreement between the Transport User and the Transport Service Provider. If there is a pre-established agreement, the Transport Service Request can typically be considered a call-off from the agreement between the two parties. (An established framework agreement or contract usually defines terms and conditions and a total capacity limit, e.g., 100 container spaces on a vessel per year. A call-off occurs when the Transport User places an order against this agreement, for example a booking of 10 of the 100 container spaces.) The Transport User can confirm the Transport Execution Plan Request without the need to make a careful examination of the Transport Execution Plan submitted by the Transport Service Provider. The Transport User then sends a Transport Execution Plan with a status code indicating confirmation. Assuming acceptance by the Transport Service Provider, this scenario is considered a two-step choreography. If a pre-established agreement does not exist (e.g., spot market services), the Transport User issues a Transport Execution Plan Request with a status code indicating that the Transport Execution Plan is not yet confirmed. The Transport User only confirms the Transport Execution Plan after a careful analysis of what has been submitted by the Transport Service Provider. This scenario is a three-step choreography where the Transport User confirms the Transport Execution Plan content in his second or subsequent response to the Transport Service Provider. Updates to the Transport Execution Plan may be issued by either the Transport User or the Transport Service Provider. If the Transport User wants to update an existing Transport Execution Plan, a new instance of a Transport Execution Plan must be issued with reference to the original Transport Execution Plan. Similarly, if the Transport Service Provider wants to update an existing Transport Execution Plan, a new Transport Execution Plan replaces the original Transport Execution Plan with a reference to the original one. In either case, the Transport Execution Plan must include a document status code indicating that this is an update of the original content. The cancellation of a Transport Execution Plan may be requested by either the Transport Service Provider or the Transport User. In either case, the Transport Execution Plan is sent with a document status code indicating that the Transport Execution Plan should be cancelled. For the cancellation to be effective, it must be accepted by the party receiving the cancellation request. Acceptance is signified by sending back a Transport Execution Plan with a status code indicating confirmation; rejection of the cancellation is signified by issuing a Transport Execution Plan with a status code indicating rejection. Upon completion of the transport service covered by the Transport Execution Plan, a final Transport Execution Plan document is sent from the Transport Service Provider to the Transport User that includes a document status code indicating that the transport service is completed.
Transport Execution Plan [TEP Diagram]
Providing an Itinerary for a Transport Service The Goods Item Itinerary specifies the route and time schedule for one or more transported items and is issued from the Transport Service Provider to the Transport User. The Goods Item Itinerary is initially issued from the Transport Service Provider to the Transport User after a Transport Execution Plan is confirmed by both parties. It may contain one or more transport segments with different Transport Execution Plans employing different Transport Service Providers. One transport service (one Transport Execution Plan) may cover more than one segment (leg). In addition to providing an overview of the initial route and time schedule, the Goods Item Itinerary is used to document progress by recording new estimated times for departure or arrival and actual departure and arrival times. So when updates to the initial transport execution schedule occur, a new version of the Goods Item Itinerary is issued to the Transport User. A Goods Item Itinerary document thus contains information that may be used for analyzing the performance (in time) of transport services and for tracing the progress of cargo in transit if such analysis is required.
Goods Item Itinerary [GII Diagram]
Reporting Transport Means Progress Status The Transport Progress Status collects and reports information about the status of the transport means. The Transport Service Provider issues a Transport Progress Status Request to ask the Transportation Network Manager for status information related to a specific transport vehicle, using the vehicle identification number. The Transportation Network Manager then provides information about the location and time schedule status to the Transport Service Provider. During a transport service, there might be a number of information providers taking on the Transportation Network Manager role, offering Transport Progress Statuses to the Transport Service Provider. The most typical use of Transport Progress Status is to ask assistance from the Transportation Network Manager when estimated times of arrival are established. Reporting on the status of the goods themselves is covered by the Freight Status Reporting process (see ).
Transport Progress Status [TPS Diagram]
Party Roles In the UBL supply chain processes, two main actors, Customer and Supplier, represent the key organizations or people involved in the processes. Each of these actors may play various roles. Some processes may also involve supplementary roles that may be provided by different parties. The actual role undertaken is dependent on the context of use. For example, the Despatch Party and Delivery Party as applied to the Procurement process may differ in the Transportation process. In the Transportation Process, two of the main roles are the Transport User and the Transport Service Provider. The Transport User is the role responsible for purchasing a transport service, while the Transport Service Provider is the role responsible for selling and executing a transport service. Both the Customer and the Supplier may be responsible for purchasing and following up the transport of goods, hence both these actors may undertake the Transport User role. In other words, the role of a specific actor depends on the specific circumstances. The following table contains a description of the typical roles for the actor known as Party. Note that some roles require an extension of the information entities required. In UBL 2.1, the following are roles that extend the Party structure: Customer Party, Supplier Party, Contracting Party, Endorser Party, and Qualifying Party. Party Roles Actor Role Description Example Synonyms Sends Receives Customer Party Originator The party that had the original demand for the goods and/or services and therefore initiated the procurement transaction. The Originator participates in pre-ordering activity either through Request for Quotation and Quotation or by receiving a Quotation as a response to a punchout transaction on a marketplace or Seller’s website. If the Originator subsequently places an Order, the Originator adopts the role of Buyer. The Originator is typically the contact point for queries regarding the original requirement and may be referred to in an Order Change, Order Cancellation, or Order Response. If an employee requests a computer, the employing company may become the Buyer, but the employee is the Originator. They need to receive information about the order. Request for Quotation Quotation Customer Party Buyer The party that purchases the goods or services on behalf of the Originator. The Buyer may be referred to in Order Response, Despatch Advice, Fulfilment Cancellation, Invoice, Self Billed Invoice, Credit Note, and Statement. A company may delegate the task of purchasing to a specialized group to consolidate orders and gain greater discounts. Order Point Order, Order Change, Order Cancellation, Fulfilment Cancellation Order Response, Fulfilment Cancellation Customer Party Delivery The party to whom goods should be delivered. The Delivery Party may be the same as the Originator. The Delivery Party must be referred to at line item level in Request for Quotation, Quotation, Order, Order Change, Order Cancellation, and Order Response. The Delivery Party may be referred to at line level in Invoice, Self Billed Invoice, Credit Note, and Debit Note. The Delivery Party may be stipulated in a transport contract. If a municipality buys a wheelchair for a citizen, the wheelchair must be delivered to the citizen (the Delivery Party). In such cases the citizen may be notified before delivery of the wheelchair. Delivery Point, Destination Party, Receiver, Recipient Receipt Advice Despatch Advice Customer Party Accounting Customer The party responsible for making settlement relating to a purchase and resolving billing issues using a Debit Note. The Accounting Customer must be referred to in an Order and may be referred to in an Order Response. In a Self Billing scenario, the Accounting Customer is responsible for calculating and issuing tax invoices. If a kindergarten buys some toys they may be the Originator, Buyer, and Delivery Party, but the municipality may play the role of Accounting Customer—they are going to pay for it. Invoice, Accounts Payable, Debtor In a traditional Billing scenario: Debit Note, Application Response, and Remittance Advice In a Self Billing scenario: Self Billed Invoice, Self Billed Credit Note, and Remittance Advice In a traditional Billing scenario: Invoice, Credit Note, and Statement; in a Self Billing scenario: Credit Note, Application Response, and Statement Supplier Party Seller The party responsible for handling Originator and Buyer services. The Seller party is legally responsible for providing the goods to the Buyer. The Seller party receives and quotes against Requests for Quotation and may provide information to the Buyer’s requisitioning process through Catalogues and Quotations. The organization that sells wheelchairs to municipalities. Sales Point, Provider, Customer Manager Quotation, Order Response, Order Response Simple, Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update, Fulfilment Cancellation Request for Quotation, Order, Order Change, Order Cancellation, Catalogue Request, Fulfilment Cancellation Supplier Party Despatch The party where goods are to be collected from. The Despatch Party may be stipulated in a transport contract. The wheelchair Supplier may store chairs at a local warehouse. The warehouse will actually despatch the chair to the Delivery Party. The local warehouse is then the Despatch Party. Despatch Point, Shipper, Sender Despatch Advice Receipt Advice Supplier Party Accounting Supplier The party who claims the payment and is responsible for resolving billing issues and arranging settlement. There are cases where the Accounting Supplier is not the Seller party. For example, factoring, where the invoicing is outsourced to another company. Accounts Receivable, Invoice Issuer, Creditor In a traditional Billing scenario: Invoice, Credit Note, and Statement; in a Self Billing scenario: Credit Note, Application Response, and Statement In a traditional Billing scenario: Debit Note, Account Response, and Remittance Advice In a Self Billing scenario: Self Billed Invoice, Self Billed Credit Note, and Remittance Advice Supplier Party Payee The party to whom the Invoice is paid. The Accounting Supplier may not be the party to be paid due to changes in the organization, e.g., a company merger. Accounts Receivable, Creditor Remittance Advice Customer Party Contractor The party responsible for the contract to which the Catalogue relates. An organization has a central office for maintaining catalogues of approved items for purchase. Central Catalogue Party, Purchasing Manager Catalogue Request Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update Party Provider The party responsible for the integrity of the information provided about an item. The manufacturer may publish and maintain the data sheets about a product. Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update Party Receiver A general role, describing the receiver of a document. For a catalogue, this can be the customer, a potential customer, or a third party exposing the document, for instance, an interim broker. A marketplace may receive an Application Response. Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update, Application Response Party Sender The party sending a document. A marketplace may send an Application Response. Application Response Party Consignor The party consigning the goods as stipulated in the transport contract. A Buyer, Delivery, Seller, or Despatcher Party may also play the role of Consignor. Also known as the Transport User. The Consignor may be stipulated in a transport contract. The wheelchair Supplier may source from a local warehouse. The Freight Forwarder will collect the chair from the local warehouse, which is thus the Consignor. In this case, the warehouse also plays the role of Despatch Party to the Freight Forwarder. Despatch Point, Shipper, Sender, Transport User Forwarding Instructions, Packing List Bill of Lading, Waybill, Freight Invoice, Transportation Status Party Consignee The party receiving a consignment of goods as stipulated in the transport contract. The party taking responsibility for the receipt of the consignment covering the wheelchair. Delivery Point, Transport Service Buyer Forwarding Instructions, Freight Invoice Bill of Lading, Waybill, Freight Invoice, Transportation Status Party Freight Forwarder The party arranging the carriage of goods, including connected services and/or associated formalities, on behalf of a Consignor or Consignee. Also known as the Transport Service Provider. The Freight Forwarder may also be the Carrier. The Freight Forwarder may create an Invoice and bill to the Transport Service Buyer for the transportation service provided. The Consignor may have a contract with this Freight Forwarder, which is a Transport Services Provider, to arrange all their transport needs. Shipping Agent, Broker, Courier, Transport Service Provider Forwarding Instructions, Freight Invoice, Transportation Status Bill of Lading, Waybill, Packing List Party Carrier The party providing physical transport services. The Freight Forwarder may engage an airline company to deliver the wheelchair. The airline is then the Carrier and delivers the chair to the Delivery Party. Freight Haulier, Shipper, Ships Agent, Shipping Company, Airline, Rail Operator, Road Haulier Bill of Lading, Waybill Forwarding Instructions Party Exporter The party who makes regulatory export declarations, or on whose behalf regulatory export declarations are made, and who is the owner of the goods or has similar right of disposal over them at the time when the declaration is accepted. The wheelchair Supplier has to apply for a Certificate of Origin in order to sell the chairs overseas. Seller, Consignor Certificate of Origin Application Response Party Endorser The party appointed by the Government of a country who has the right to certify a Certificate of Origin. This endorsement restricts goods imported from certain countries for political or other reasons. The Government agency validates all the information provided by Exporter for Certificate of Origin approval. Authorized Organization, Embassy Certificate of Origin, Application Response Certificate of Origin Party Importer The party who makes, or on whose behalf an agent or other authorized person makes, an import declaration. This may include a person who has possession of the goods or to whom the goods are consigned. A specialized group in a company consolidates the purchase request and handles the receiving of goods. Order Point, Delivery Party, Buyer, Customer, Consignee Certificate of Origin Party Transport User The Transport User is the role representing anyone who has a demand for transport services, books transport services, and follows up the execution of such services. The manufacturer has to order transport of products from a carrier or freight forwarder (Transport Service Provider). Transport Buyer, Logistics Service Client Transport Execution Plan Request, Transportation Status Request, Transport Service Description Request Transport Execution Plan, Transportation Status, Transport Service Description, Goods Item Itinerary Party Transport Service Provider The Transport Service Provider is the role that plans, markets and performs transport services. The carrier or freight forwarder who arranges for transport services on behalf of a manufacturer (Transport User) Transport Provider, Transport Seller, Logistics Service Provider Transport Execution Plan, Transportation Status, Transport Service Description, Transport Progress Status Request, Goods Item Itinerary Transport Execution Plan Request, Transportation Status Request, Transport Service Description Request, Transport Progress Status Party Transportation Network Manager The Transportation Network Manager is the role that extracts all information available regarding the infrastructure (static/dynamic) related to planning and executing transport and makes this information available to the Transport Service Provider. During a transport service, or even during a single leg, the Transport Service Provider may rely on information from several Transportation Network Managers. The Traffic Information Centre (TIC) issuing information related to road work and/or traffic conditions as a service to a Transport Service Provider Road Administration, Traffic Information Centre, Coastal Administration, Harbor Master, Railway Administration, Infrastructure Manager Transport Progress Status Transport Progress Status Request
UBL 2.1 Schemas The UBL 2.1 XSD schemas are the only normative representations of the UBL 2.1 document types and library components for the purposes of document validation and conformance. All of the UBL 2.1 XSD schemas are contained in the xsd subdirectory of the UBL 2.1 release package (see for more information regarding the structure of the 2.1 release package and for information regarding dependencies among the schema modules). The xsd directory is further subdivided into an xsd/maindoc subdirectory containing the schemas for individual 2.1 document types and an xsd/common subdirectory containing schemas in the UBL common library. For convenience in implementing the schemas, parallel (and technically non-normative) “runtime” sets with the annotation elements stripped out are provided in the xsdrt directory.
UBL 2.1 Document Schemas The tables that follow describe each of the UBL 2.1 document types. Along with a link to the normative schema for each document type, each table provides links to the corresponding “runtime” schema, model spreadsheets (see ), summary report (see ), RELAX NG schema (see ), and example instance, if any (see ).
Application Response Description: A document to indicate the application’s response to a transaction. This may be a business response and/or a technical response, sent automatically by an application or initiated by a user. Processes involved Any collaboration Submitter role Sender Receiver role Receiver Normative schema xsd/maindoc/UBL-ApplicationResponse-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ApplicationResponse-2.1.xsd RELAX NG schema rnc/versions/UBL-ApplicationResponse-2.1.rnc Document model (ODF) mod/maindoc/UBL-ApplicationResponse-2.1.ods Document model (Excel) mod/maindoc/UBL-ApplicationResponse-2.1.xls Document model (UML) uml/UBL-ApplicationResponse-2.1.html Summary report mod/summary/reports/UBL-ApplicationResponse-2.1.html
Attached Document Description: A UBL  wrapper  that allows a document of any kind to be packaged with the UBL document that references it. Processes involved Any collaboration Submitter role Sender Receiver role Receiver Normative schema xsd/maindoc/UBL-AttachedDocument-2.1.xsd Runtime schema xsdrt/maindoc/UBL-AttachedDocument-2.1.xsd RELAX NG schema rnc/versions/UBL-AttachedDocument-2.1.rnc Document model (ODF) mod/maindoc/UBL-AttachedDocument-2.1.ods Document model (Excel) mod/maindoc/UBL-AttachedDocument-2.1.xls Document model (UML) uml/UBL-AttachedDocument-2.1.html Summary report mod/summary/reports/UBL-AttachedDocument-2.1.html
Awarded Notification Description: The document used to communicate a contract award to the winner. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-AwardedNotification-2.1.xsd Runtime schema xsdrt/maindoc/UBL-AwardedNotification-2.1.xsd RELAX NG schema rnc/versions/UBL-AwardedNotification-2.1.rnc Document model (ODF) mod/maindoc/UBL-AwardedNotification-2.1.ods Document model (Excel) mod/maindoc/UBL-AwardedNotification-2.1.xls Document model (UML) uml/UBL-AwardedNotification-2.1.html Summary report mod/summary/reports/UBL-AwardedNotification-2.1.html
Bill of Lading Description: A document that conveys information about an instance of a transportation service and may under some circumstances serve as a contractual document for the service. See and compare with . Processes involved Freight Management Submitter role Freight Forwarder, Carrier Receiver role Consignor (or Consignee), Freight Forwarder Normative schema xsd/maindoc/UBL-BillOfLading-2.1.xsd Runtime schema xsdrt/maindoc/UBL-BillOfLading-2.1.xsd RELAX NG schema rnc/versions/UBL-BillOfLading-2.1.rnc Document model (ODF) mod/maindoc/UBL-BillOfLading-2.1.ods Document model (Excel) mod/maindoc/UBL-BillOfLading-2.1.xls Document model (UML) uml/UBL-BillOfLading-2.1.html Summary report mod/summary/reports/UBL-BillOfLading-2.1.html
Call for Tenders Description: A document used by a Contracting Party to define a procurement project to buy goods, services, or works during a specified period. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-CallForTenders-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CallForTenders-2.1.xsd RELAX NG schema rnc/versions/UBL-CallForTenders-2.1.rnc Document model (ODF) mod/maindoc/UBL-CallForTenders-2.1.ods Document model (Excel) mod/maindoc/UBL-CallForTenders-2.1.xls Document model (UML) uml/UBL-CallForTenders-2.1.html Summary report mod/summary/reports/UBL-CallForTenders-2.1.html
Catalogue Description: A document that describes items, prices, and price validity. See . Processes involved Catalogue, Create Catalogue, Delete Catalogue, Update Catalogue Item Specification, Update Catalogue Pricing; Initial Stocking of the Area by Producer, Permanent Replenishment, Price Adjustments, Transfer of Base Item Catalogue, Changes to the Item Catalogue, Changes to the Article Catalogue Submitter role Seller Receiver role Contracting Party Normative schema xsd/maindoc/UBL-Catalogue-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Catalogue-2.1.xsd RELAX NG schema rnc/versions/UBL-Catalogue-2.1.rnc Document model (ODF) mod/maindoc/UBL-Catalogue-2.1.ods Document model (Excel) mod/maindoc/UBL-Catalogue-2.1.xls Document model (UML) uml/UBL-Catalogue-2.1.html Summary report mod/summary/reports/UBL-Catalogue-2.1.html
Catalogue Deletion Description: A document used to cancel an entire Catalogue. Processes involved Catalogue Submitter role Seller Receiver role Contracting Party Normative schema xsd/maindoc/UBL-CatalogueDeletion-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CatalogueDeletion-2.1.xsd RELAX NG schema rnc/versions/UBL-CatalogueDeletion-2.1.rnc Document model (ODF) mod/maindoc/UBL-CatalogueDeletion-2.1.ods Document model (Excel) mod/maindoc/UBL-CatalogueDeletion-2.1.xls Document model (UML) uml/UBL-CatalogueDeletion-2.1.html Summary report mod/summary/reports/UBL-CatalogueDeletion-2.1.html
Catalogue Item Specification Update Description: A document used to update information (e.g., technical descriptions and properties) about Items in an existing Catalogue. Processes involved Catalogue Submitter role Seller Receiver role Contracting Party Normative schema xsd/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xsd RELAX NG schema rnc/versions/UBL-CatalogueItemSpecificationUpdate-2.1.rnc Document model (ODF) mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.ods Document model (Excel) mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xls Document model (UML) uml/UBL-CatalogueItemSpecificationUpdate-2.1.html Summary report mod/summary/reports/UBL-CatalogueItemSpecificationUpdate-2.1.html
Catalogue Pricing Update Description: A document used to update information about prices in an existing Catalogue. Processes involved Catalogue Submitter role Seller Receiver role Contracting Party Normative schema xsd/maindoc/UBL-CataloguePricingUpdate-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CataloguePricingUpdate-2.1.xsd RELAX NG schema rnc/versions/UBL-CataloguePricingUpdate-2.1.rnc Document model (ODF) mod/maindoc/UBL-CataloguePricingUpdate-2.1.ods Document model (Excel) mod/maindoc/UBL-CataloguePricingUpdate-2.1.xls Document model (UML) uml/UBL-CataloguePricingUpdate-2.1.html Summary report mod/summary/reports/UBL-CataloguePricingUpdate-2.1.html
Catalogue Request Description: A document used to request a Catalogue. Processes involved Catalogue Submitter role Contracting Party Receiver role Seller Normative schema xsd/maindoc/UBL-CatalogueRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CatalogueRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-CatalogueRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-CatalogueRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-CatalogueRequest-2.1.xls Document model (UML) uml/UBL-CatalogueRequest-2.1.html Summary report mod/summary/reports/UBL-CatalogueRequest-2.1.html
Certificate of Origin Description: A document that describes the Certificate of Origin. Processes involved Certification of Origin of Goods Submitter role Exporter, Issuer Receiver role Issuer, Importer Normative schema xsd/maindoc/UBL-CertificateOfOrigin-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CertificateOfOrigin-2.1.xsd RELAX NG schema rnc/versions/UBL-CertificateOfOrigin-2.1.rnc Document model (ODF) mod/maindoc/UBL-CertificateOfOrigin-2.1.ods Document model (Excel) mod/maindoc/UBL-CertificateOfOrigin-2.1.xls Document model (UML) uml/UBL-CertificateOfOrigin-2.1.html Summary report mod/summary/reports/UBL-CertificateOfOrigin-2.1.html
Contract Award Notice Description: A document published by a Contracting Party to announce the awarding of a procurement project. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-ContractAwardNotice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ContractAwardNotice-2.1.xsd RELAX NG schema rnc/versions/UBL-ContractAwardNotice-2.1.rnc Document model (ODF) mod/maindoc/UBL-ContractAwardNotice-2.1.ods Document model (Excel) mod/maindoc/UBL-ContractAwardNotice-2.1.xls Document model (UML) uml/UBL-ContractAwardNotice-2.1.html Summary report mod/summary/reports/UBL-ContractAwardNotice-2.1.html
Contract Notice Description: A document used by a Contracting Party to announce a project to buy goods, services or works. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-ContractNotice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ContractNotice-2.1.xsd RELAX NG schema rnc/versions/UBL-ContractNotice-2.1.rnc Document model (ODF) mod/maindoc/UBL-ContractNotice-2.1.ods Document model (Excel) mod/maindoc/UBL-ContractNotice-2.1.xls Document model (UML) uml/UBL-ContractNotice-2.1.html Summary report mod/summary/reports/UBL-ContractNotice-2.1.html
Credit Note Description: A document used to specify credits due to the Debtor from the Creditor. Processes involved Billing Submitter role Supplier Accounting Party Receiver role Customer Accounting Party Normative schema xsd/maindoc/UBL-CreditNote-2.1.xsd Runtime schema xsdrt/maindoc/UBL-CreditNote-2.1.xsd RELAX NG schema rnc/versions/UBL-CreditNote-2.1.rnc Document model (ODF) mod/maindoc/UBL-CreditNote-2.1.ods Document model (Excel) mod/maindoc/UBL-CreditNote-2.1.xls Document model (UML) uml/UBL-CreditNote-2.1.html Summary report mod/summary/reports/UBL-CreditNote-2.1.html UBL 2.0 example instance xml/UBL-CreditNote-2.0-Example.xml UBL 2.1 example instance xml/UBL-CreditNote-2.1-Example.xml
Debit Note Description: A document used to specify debts incurred by the Debtor. Processes involved Billing Submitter role Customer Accounting Party Receiver role Supplier Accounting Party Normative schema xsd/maindoc/UBL-DebitNote-2.1.xsd Runtime schema xsdrt/maindoc/UBL-DebitNote-2.1.xsd RELAX NG schema rnc/versions/UBL-DebitNote-2.1.rnc Document model (ODF) mod/maindoc/UBL-DebitNote-2.1.ods Document model (Excel) mod/maindoc/UBL-DebitNote-2.1.xls Document model (UML) uml/UBL-DebitNote-2.1.html Summary report mod/summary/reports/UBL-DebitNote-2.1.html UBL 2.1 example instance xml/UBL-DebitNote-2.1-Example.xml
Despatch Advice Description: A document used to describe the despatch or delivery of goods and services. Processes involved Fulfilment Submitter role Despatch Receiver role Delivery Normative schema xsd/maindoc/UBL-DespatchAdvice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-DespatchAdvice-2.1.xsd RELAX NG schema rnc/versions/UBL-DespatchAdvice-2.1.rnc Document model (ODF) mod/maindoc/UBL-DespatchAdvice-2.1.ods Document model (Excel) mod/maindoc/UBL-DespatchAdvice-2.1.xls Document model (UML) uml/UBL-DespatchAdvice-2.1.html Summary report mod/summary/reports/UBL-DespatchAdvice-2.1.html UBL 2.0 example instance xml/UBL-DespatchAdvice-2.0-Example.xml
Document Status Description: A document used to provide information about document status. Processes involved Any collaboration Submitter role Party currently controlling Status of the collaboration Receiver role Party requesting Status on collaboration Normative schema xsd/maindoc/UBL-DocumentStatus-2.1.xsd Runtime schema xsdrt/maindoc/UBL-DocumentStatus-2.1.xsd RELAX NG schema rnc/versions/UBL-DocumentStatus-2.1.rnc Document model (ODF) mod/maindoc/UBL-DocumentStatus-2.1.ods Document model (Excel) mod/maindoc/UBL-DocumentStatus-2.1.xls Document model (UML) uml/UBL-DocumentStatus-2.1.html Summary report mod/summary/reports/UBL-DocumentStatus-2.1.html
Document Status Request Description: A document used to request the status of another document. Processes involved Any collaboration Submitter role Party requesting Status on collaboration Receiver role Party currently controlling Status of the collaboration Normative schema xsd/maindoc/UBL-DocumentStatusRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-DocumentStatusRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-DocumentStatusRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-DocumentStatusRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-DocumentStatusRequest-2.1.xls Document model (UML) uml/UBL-DocumentStatusRequest-2.1.html Summary report mod/summary/reports/UBL-DocumentStatusRequest-2.1.html
Exception Criteria Description: A document used to specify the thresholds for forecast variance, product activity, and performance history beyond which exceptions should be triggered. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-ExceptionCriteria-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ExceptionCriteria-2.1.xsd RELAX NG schema rnc/versions/UBL-ExceptionCriteria-2.1.rnc Document model (ODF) mod/maindoc/UBL-ExceptionCriteria-2.1.ods Document model (Excel) mod/maindoc/UBL-ExceptionCriteria-2.1.xls Document model (UML) uml/UBL-ExceptionCriteria-2.1.html Summary report mod/summary/reports/UBL-ExceptionCriteria-2.1.html UBL 2.1 example instance xml/UBL-ExceptionCriteria-2.1-Example.xml
Exception Notification Description: A document used to notify an exception in forecast variance, product activity, or performance history. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-ExceptionNotification-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ExceptionNotification-2.1.xsd RELAX NG schema rnc/versions/UBL-ExceptionNotification-2.1.rnc Document model (ODF) mod/maindoc/UBL-ExceptionNotification-2.1.ods Document model (Excel) mod/maindoc/UBL-ExceptionNotification-2.1.xls Document model (UML) uml/UBL-ExceptionNotification-2.1.html Summary report mod/summary/reports/UBL-ExceptionNotification-2.1.html UBL 2.1 example instance xml/UBL-ExceptionNotification-2.1-Example.xml
Forecast Description: A document used to forecast sales or orders. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-Forecast-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Forecast-2.1.xsd RELAX NG schema rnc/versions/UBL-Forecast-2.1.rnc Document model (ODF) mod/maindoc/UBL-Forecast-2.1.ods Document model (Excel) mod/maindoc/UBL-Forecast-2.1.xls Document model (UML) uml/UBL-Forecast-2.1.html Summary report mod/summary/reports/UBL-Forecast-2.1.html UBL 2.1 example instance xml/UBL-Forecast-2.1-Example.xml
Forecast Revision Description: A document used to revise a Forecast. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-ForecastRevision-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ForecastRevision-2.1.xsd RELAX NG schema rnc/versions/UBL-ForecastRevision-2.1.rnc Document model (ODF) mod/maindoc/UBL-ForecastRevision-2.1.ods Document model (Excel) mod/maindoc/UBL-ForecastRevision-2.1.xls Document model (UML) uml/UBL-ForecastRevision-2.1.html Summary report mod/summary/reports/UBL-ForecastRevision-2.1.html UBL 2.1 example instance xml/UBL-ForecastRevision-2.1-Example.xml
Forwarding Instructions Description: A document issued to a forwarder, giving instructions regarding the action to be taken for the forwarding of goods described therein. See . Processes involved Freight Management Submitter role Consignor (or Consignee), Freight Forwarder Receiver role Freight Forwarder, Carrier Normative schema xsd/maindoc/UBL-ForwardingInstructions-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ForwardingInstructions-2.1.xsd RELAX NG schema rnc/versions/UBL-ForwardingInstructions-2.1.rnc Document model (ODF) mod/maindoc/UBL-ForwardingInstructions-2.1.ods Document model (Excel) mod/maindoc/UBL-ForwardingInstructions-2.1.xls Document model (UML) uml/UBL-ForwardingInstructions-2.1.html Summary report mod/summary/reports/UBL-ForwardingInstructions-2.1.html UBL 2.0 example instance xml/UBL-ForwardingInstructions-2.0-Example-International.xml
Freight Invoice Description: A document stating the charges incurred for a logistics service. Processes involved Freight Billing Submitter role Freight Forwarder Receiver role Consignor or Consignee Normative schema xsd/maindoc/UBL-FreightInvoice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-FreightInvoice-2.1.xsd RELAX NG schema rnc/versions/UBL-FreightInvoice-2.1.rnc Document model (ODF) mod/maindoc/UBL-FreightInvoice-2.1.ods Document model (Excel) mod/maindoc/UBL-FreightInvoice-2.1.xls Document model (UML) uml/UBL-FreightInvoice-2.1.html Summary report mod/summary/reports/UBL-FreightInvoice-2.1.html UBL 2.1 example instance xml/UBL-FreightInvoice-2.1-Example.xml
Fulfilment Cancellation Description: A document used to cancel an entire Despatch Advice or Receipt Advice. Processes involved Fulfilment with Despatch Advice, Fulfilment with Receipt Advice Submitter role Buyer or Seller Receiver role Seller or Buyer Normative schema xsd/maindoc/UBL-FulfilmentCancellation-2.1.xsd Runtime schema xsdrt/maindoc/UBL-FulfilmentCancellation-2.1.xsd RELAX NG schema rnc/versions/UBL-FulfilmentCancellation-2.1.rnc Document model (ODF) mod/maindoc/UBL-FulfilmentCancellation-2.1.ods Document model (Excel) mod/maindoc/UBL-FulfilmentCancellation-2.1.xls Document model (UML) uml/UBL-FulfilmentCancellation-2.1.html Summary report mod/summary/reports/UBL-FulfilmentCancellation-2.1.html UBL 2.1 example instance xml/UBL-FulfilmentCancellation-2.1-Example.xml
Goods Item Itinerary Description: A document providing details relating to a transport service, such as transport movement, identification of equipment and goods, subcontracted service providers, etc. Processes involved Intermodal Freight Management Submitter role Transport Service Provider Receiver role Transport User Normative schema xsd/maindoc/UBL-GoodsItemItinerary-2.1.xsd Runtime schema xsdrt/maindoc/UBL-GoodsItemItinerary-2.1.xsd RELAX NG schema rnc/versions/UBL-GoodsItemItinerary-2.1.rnc Document model (ODF) mod/maindoc/UBL-GoodsItemItinerary-2.1.ods Document model (Excel) mod/maindoc/UBL-GoodsItemItinerary-2.1.xls Document model (UML) uml/UBL-GoodsItemItinerary-2.1.html Summary report mod/summary/reports/UBL-GoodsItemItinerary-2.1.html UBL 2.1 example instance xml/UBL-GoodsItemItinerary-2.1-Example.xml
Guarantee Certificate Description: A document to notify the deposit of a bid bond guarantee. Processes involved Tendering Submitter role Tenderer Receiver role Contracting Authority Normative schema xsd/maindoc/UBL-GuaranteeCertificate-2.1.xsd Runtime schema xsdrt/maindoc/UBL-GuaranteeCertificate-2.1.xsd RELAX NG schema rnc/versions/UBL-GuaranteeCertificate-2.1.rnc Document model (ODF) mod/maindoc/UBL-GuaranteeCertificate-2.1.ods Document model (Excel) mod/maindoc/UBL-GuaranteeCertificate-2.1.xls Document model (UML) uml/UBL-GuaranteeCertificate-2.1.html Summary report mod/summary/reports/UBL-GuaranteeCertificate-2.1.html
Instruction for Returns Description: A document used to initiate a return of goods. The producer is requesting the return of products that are not selling well, either to use in other places or to free up rack or shelf space. Processes involved Cyclic Replenishment Program Submitter role Seller Receiver role Buyer Normative schema xsd/maindoc/UBL-InstructionForReturns-2.1.xsd Runtime schema xsdrt/maindoc/UBL-InstructionForReturns-2.1.xsd RELAX NG schema rnc/versions/UBL-InstructionForReturns-2.1.rnc Document model (ODF) mod/maindoc/UBL-InstructionForReturns-2.1.ods Document model (Excel) mod/maindoc/UBL-InstructionForReturns-2.1.xls Document model (UML) uml/UBL-InstructionForReturns-2.1.html Summary report mod/summary/reports/UBL-InstructionForReturns-2.1.html UBL 2.1 example instance xml/UBL-InstructionForReturns-2.1-Example.xml
Inventory Report Description: A report on the quantities of each item that are, or will be, in stock. This document is sent by a Buyer (for example a retailer) to a Seller (for example a producer). Processes involved Cyclic Replenishment Program Submitter role Buyer Receiver role Seller Normative schema xsd/maindoc/UBL-InventoryReport-2.1.xsd Runtime schema xsdrt/maindoc/UBL-InventoryReport-2.1.xsd RELAX NG schema rnc/versions/UBL-InventoryReport-2.1.rnc Document model (ODF) mod/maindoc/UBL-InventoryReport-2.1.ods Document model (Excel) mod/maindoc/UBL-InventoryReport-2.1.xls Document model (UML) uml/UBL-InventoryReport-2.1.html Summary report mod/summary/reports/UBL-InventoryReport-2.1.html UBL 2.1 example instance xml/UBL-InventoryReport-2.1-Example.xml
Invoice Description: A document used to request payment. Processes involved Billing Submitter role Supplier Accounting Party Receiver role Customer Accounting Party Normative schema xsd/maindoc/UBL-Invoice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Invoice-2.1.xsd RELAX NG schema rnc/versions/UBL-Invoice-2.1.rnc Document model (ODF) mod/maindoc/UBL-Invoice-2.1.ods Document model (Excel) mod/maindoc/UBL-Invoice-2.1.xls Document model (UML) uml/UBL-Invoice-2.1.html Summary report mod/summary/reports/UBL-Invoice-2.1.html UBL 2.0 example instance xml/UBL-Invoice-2.0-Example.xml UBL 2.1 example instance xml/UBL-Invoice-2.1-Example.xml
Item Information Request Description: A document used to request product activity, forecast, or performance data. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-ItemInformationRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ItemInformationRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-ItemInformationRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-ItemInformationRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-ItemInformationRequest-2.1.xls Document model (UML) uml/UBL-ItemInformationRequest-2.1.html Summary report mod/summary/reports/UBL-ItemInformationRequest-2.1.html
Order Description: A document used to order goods and services. Processes involved Ordering Submitter role Buyer Receiver role Seller Normative schema xsd/maindoc/UBL-Order-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Order-2.1.xsd RELAX NG schema rnc/versions/UBL-Order-2.1.rnc Document model (ODF) mod/maindoc/UBL-Order-2.1.ods Document model (Excel) mod/maindoc/UBL-Order-2.1.xls Document model (UML) uml/UBL-Order-2.1.html Summary report mod/summary/reports/UBL-Order-2.1.html UBL 2.0 example instance xml/UBL-Order-2.0-Example.xml UBL 2.1 example instance xml/UBL-Order-2.1-Example.xml
Order Cancellation Description: A document used to cancel an entire Order. Processes involved Ordering, Fulfilment Submitter role Buyer Receiver role Seller Normative schema xsd/maindoc/UBL-OrderCancellation-2.1.xsd Runtime schema xsdrt/maindoc/UBL-OrderCancellation-2.1.xsd RELAX NG schema rnc/versions/UBL-OrderCancellation-2.1.rnc Document model (ODF) mod/maindoc/UBL-OrderCancellation-2.1.ods Document model (Excel) mod/maindoc/UBL-OrderCancellation-2.1.xls Document model (UML) uml/UBL-OrderCancellation-2.1.html Summary report mod/summary/reports/UBL-OrderCancellation-2.1.html UBL 2.1 example instance xml/UBL-OrderCancellation-2.1-Example.xml
Order Change Description: A document used to specify changes to an existing Order. Processes involved Ordering, Fulfilment Submitter role Buyer Receiver role Seller Normative schema xsd/maindoc/UBL-OrderChange-2.1.xsd Runtime schema xsdrt/maindoc/UBL-OrderChange-2.1.xsd RELAX NG schema rnc/versions/UBL-OrderChange-2.1.rnc Document model (ODF) mod/maindoc/UBL-OrderChange-2.1.ods Document model (Excel) mod/maindoc/UBL-OrderChange-2.1.xls Document model (UML) uml/UBL-OrderChange-2.1.html Summary report mod/summary/reports/UBL-OrderChange-2.1.html UBL 2.1 example instance xml/UBL-OrderChange-2.1-Example.xml
Order Response Description: A document used to indicate detailed acceptance or rejection of an Order or to make a counter-offer. Processes involved Ordering Submitter role Seller Receiver role Buyer Normative schema xsd/maindoc/UBL-OrderResponse-2.1.xsd Runtime schema xsdrt/maindoc/UBL-OrderResponse-2.1.xsd RELAX NG schema rnc/versions/UBL-OrderResponse-2.1.rnc Document model (ODF) mod/maindoc/UBL-OrderResponse-2.1.ods Document model (Excel) mod/maindoc/UBL-OrderResponse-2.1.xls Document model (UML) uml/UBL-OrderResponse-2.1.html Summary report mod/summary/reports/UBL-OrderResponse-2.1.html UBL 2.1 example instance xml/UBL-OrderResponse-2.1-Example.xml
Order Response Simple Description: A document used to indicate simple acceptance or rejection of an entire Order. Processes involved Ordering Submitter role Seller Receiver role Buyer Normative schema xsd/maindoc/UBL-OrderResponseSimple-2.1.xsd Runtime schema xsdrt/maindoc/UBL-OrderResponseSimple-2.1.xsd RELAX NG schema rnc/versions/UBL-OrderResponseSimple-2.1.rnc Document model (ODF) mod/maindoc/UBL-OrderResponseSimple-2.1.ods Document model (Excel) mod/maindoc/UBL-OrderResponseSimple-2.1.xls Document model (UML) uml/UBL-OrderResponseSimple-2.1.html Summary report mod/summary/reports/UBL-OrderResponseSimple-2.1.html UBL 2.0 example instance xml/UBL-OrderResponseSimple-2.0-Example.xml UBL 2.1 example instance xml/UBL-OrderResponseSimple-2.1-Example.xml
Packing List Description: A document describing how goods are packed. Processes involved Freight Management Submitter role Consignor Receiver role Freight Forwarder Normative schema xsd/maindoc/UBL-PackingList-2.1.xsd Runtime schema xsdrt/maindoc/UBL-PackingList-2.1.xsd RELAX NG schema rnc/versions/UBL-PackingList-2.1.rnc Document model (ODF) mod/maindoc/UBL-PackingList-2.1.ods Document model (Excel) mod/maindoc/UBL-PackingList-2.1.xls Document model (UML) uml/UBL-PackingList-2.1.html Summary report mod/summary/reports/UBL-PackingList-2.1.html
Prior Information Notice Description: A document used by a contracting party to declare the intention to buy goods, services, or works during a specified period. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-PriorInformationNotice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-PriorInformationNotice-2.1.xsd RELAX NG schema rnc/versions/UBL-PriorInformationNotice-2.1.rnc Document model (ODF) mod/maindoc/UBL-PriorInformationNotice-2.1.ods Document model (Excel) mod/maindoc/UBL-PriorInformationNotice-2.1.xls Document model (UML) uml/UBL-PriorInformationNotice-2.1.html Summary report mod/summary/reports/UBL-PriorInformationNotice-2.1.html
Product Activity Description: A document reporting the movement of goods at specified retail locations for inventory tracking purposes. Processes involved Collaborative Planning, Forecasting, and Replenishment, Vendor Managed Inventory Submitter role Buyer Receiver role Seller Normative schema xsd/maindoc/UBL-ProductActivity-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ProductActivity-2.1.xsd RELAX NG schema rnc/versions/UBL-ProductActivity-2.1.rnc Document model (ODF) mod/maindoc/UBL-ProductActivity-2.1.ods Document model (Excel) mod/maindoc/UBL-ProductActivity-2.1.xls Document model (UML) uml/UBL-ProductActivity-2.1.html Summary report mod/summary/reports/UBL-ProductActivity-2.1.html UBL 2.1 example instance 1 xml/UBL-ProductActivity-2.1-Example-1.xml UBL 2.1 example instance 2 xml/UBL-ProductActivity-2.1-Example-2.xml UBL 2.1 example instance 3 xml/UBL-ProductActivity-2.1-Example-3.xml
Quotation Description: A document used to quote for the provision of goods and services. Processes involved Quotation Submitter role Seller Receiver role Originator Normative schema xsd/maindoc/UBL-Quotation-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Quotation-2.1.xsd RELAX NG schema rnc/versions/UBL-Quotation-2.1.rnc Document model (ODF) mod/maindoc/UBL-Quotation-2.1.ods Document model (Excel) mod/maindoc/UBL-Quotation-2.1.xls Document model (UML) uml/UBL-Quotation-2.1.html Summary report mod/summary/reports/UBL-Quotation-2.1.html UBL 2.0 example instance xml/UBL-Quotation-2.0-Example.xml UBL 2.1 example instance xml/UBL-Quotation-2.1-Example.xml
Receipt Advice Description: A document used to describe the receipt of goods and services. Processes involved Fulfilment Submitter role Delivery Receiver role Despatch Normative schema xsd/maindoc/UBL-ReceiptAdvice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-ReceiptAdvice-2.1.xsd RELAX NG schema rnc/versions/UBL-ReceiptAdvice-2.1.rnc Document model (ODF) mod/maindoc/UBL-ReceiptAdvice-2.1.ods Document model (Excel) mod/maindoc/UBL-ReceiptAdvice-2.1.xls Document model (UML) uml/UBL-ReceiptAdvice-2.1.html Summary report mod/summary/reports/UBL-ReceiptAdvice-2.1.html UBL 2.0 example instance xml/UBL-ReceiptAdvice-2.0-Example.xml
Reminder Description: A document used to remind a customer of payments overdue. Processes involved Billing Submitter role Supplier Accounting Party and/or Payee Receiver role Customer Accounting Party and/or Payee Normative schema xsd/maindoc/UBL-Reminder-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Reminder-2.1.xsd RELAX NG schema rnc/versions/UBL-Reminder-2.1.rnc Document model (ODF) mod/maindoc/UBL-Reminder-2.1.ods Document model (Excel) mod/maindoc/UBL-Reminder-2.1.xls Document model (UML) uml/UBL-Reminder-2.1.html Summary report mod/summary/reports/UBL-Reminder-2.1.html UBL 2.1 example instance xml/UBL-Reminder-2.1-Example.xml
Remittance Advice Description: A document that specifies details of an actual payment. Processes involved Payment Notification Submitter role Supplier Accounting Party and/or Payee Receiver role Customer Accounting Party and/or Payee Normative schema xsd/maindoc/UBL-RemittanceAdvice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-RemittanceAdvice-2.1.xsd RELAX NG schema rnc/versions/UBL-RemittanceAdvice-2.1.rnc Document model (ODF) mod/maindoc/UBL-RemittanceAdvice-2.1.ods Document model (Excel) mod/maindoc/UBL-RemittanceAdvice-2.1.xls Document model (UML) uml/UBL-RemittanceAdvice-2.1.html Summary report mod/summary/reports/UBL-RemittanceAdvice-2.1.html UBL 2.0 example instance xml/UBL-RemittanceAdvice-2.0-Example.xml
Request for Quotation Description: A document used to request a Quotation for goods and services from a seller. Processes involved Quotation Submitter role Originator Receiver role Seller Normative schema xsd/maindoc/UBL-RequestForQuotation-2.1.xsd Runtime schema xsdrt/maindoc/UBL-RequestForQuotation-2.1.xsd RELAX NG schema rnc/versions/UBL-RequestForQuotation-2.1.rnc Document model (ODF) mod/maindoc/UBL-RequestForQuotation-2.1.ods Document model (Excel) mod/maindoc/UBL-RequestForQuotation-2.1.xls Document model (UML) uml/UBL-RequestForQuotation-2.1.html Summary report mod/summary/reports/UBL-RequestForQuotation-2.1.html UBL 2.0 example instance xml/UBL-RequestForQuotation-2.0-Example.xml UBL 2.1 example instance xml/UBL-RequestForQuotation-2.1-Example.xml
Retail Event Description: A document used to specify basic information about retail events (such as promotions, product introductions, and community or environmental events) that affect supply or demand. Processes involved Cyclic Replenishment Program Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-RetailEvent-2.1.xsd Runtime schema xsdrt/maindoc/UBL-RetailEvent-2.1.xsd RELAX NG schema rnc/versions/UBL-RetailEvent-2.1.rnc Document model (ODF) mod/maindoc/UBL-RetailEvent-2.1.ods Document model (Excel) mod/maindoc/UBL-RetailEvent-2.1.xls Document model (UML) uml/UBL-RetailEvent-2.1.html Summary report mod/summary/reports/UBL-RetailEvent-2.1.html UBL 2.1 example instance xml/UBL-RetailEvent-2.1-Example.xml
Self Billed Credit Note Description: A credit note created by the debtor in a self billing arrangement with a creditor; Self Billed Credit Note replaces Debit Note in such arrangements. Processes involved Billing Submitter role Customer Accounting Party Receiver role Supplier Accounting Party Normative schema xsd/maindoc/UBL-SelfBilledCreditNote-2.1.xsd Runtime schema xsdrt/maindoc/UBL-SelfBilledCreditNote-2.1.xsd RELAX NG schema rnc/versions/UBL-SelfBilledCreditNote-2.1.rnc Document model (ODF) mod/maindoc/UBL-SelfBilledCreditNote-2.1.ods Document model (Excel) mod/maindoc/UBL-SelfBilledCreditNote-2.1.xls Document model (UML) uml/UBL-SelfBilledCreditNote-2.1.html Summary report mod/summary/reports/UBL-SelfBilledCreditNote-2.1.html UBL 2.1 example instance xml/UBL-SelfBilledCreditNote-2.1-Example.xml
Self Billed Invoice Description: An invoice document created by the customer (rather than the supplier) in a Self Billing relationship. Processes involved Billing Submitter role Customer Accounting Party Receiver role Supplier Accounting Party Normative schema xsd/maindoc/UBL-SelfBilledInvoice-2.1.xsd Runtime schema xsdrt/maindoc/UBL-SelfBilledInvoice-2.1.xsd RELAX NG schema rnc/versions/UBL-SelfBilledInvoice-2.1.rnc Document model (ODF) mod/maindoc/UBL-SelfBilledInvoice-2.1.ods Document model (Excel) mod/maindoc/UBL-SelfBilledInvoice-2.1.xls Document model (UML) uml/UBL-SelfBilledInvoice-2.1.html Summary report mod/summary/reports/UBL-SelfBilledInvoice-2.1.html
Statement Description: A document used to report the status of orders, billing, and payment. This document is a statement of account, not a summary invoice. Processes involved Billing Submitter role Supplier Accounting Party Receiver role Customer Accounting Party Normative schema xsd/maindoc/UBL-Statement-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Statement-2.1.xsd RELAX NG schema rnc/versions/UBL-Statement-2.1.rnc Document model (ODF) mod/maindoc/UBL-Statement-2.1.ods Document model (Excel) mod/maindoc/UBL-Statement-2.1.xls Document model (UML) uml/UBL-Statement-2.1.html Summary report mod/summary/reports/UBL-Statement-2.1.html UBL 2.0 example instance xml/UBL-Statement-2.0-Example.xml
Stock Availability Report Description: A report on the quantities of each item that are, or will be, in stock. This document is sent by a Seller (for example a producer) to a Buyer (for example a retailer). Processes involved Cyclic Replenishment Program Submitter role Seller (Producer) Receiver role Buyer (Retailer) Normative schema xsd/maindoc/UBL-StockAvailabilityReport-2.1.xsd Runtime schema xsdrt/maindoc/UBL-StockAvailabilityReport-2.1.xsd RELAX NG schema rnc/versions/UBL-StockAvailabilityReport-2.1.rnc Document model (ODF) mod/maindoc/UBL-StockAvailabilityReport-2.1.ods Document model (Excel) mod/maindoc/UBL-StockAvailabilityReport-2.1.xls Document model (UML) uml/UBL-StockAvailabilityReport-2.1.html Summary report mod/summary/reports/UBL-StockAvailabilityReport-2.1.html UBL 2.1 example instance xml/UBL-StockAvailabilityReport-2.1-Example.xml
Tender Description: A document whereby an economic operator (the tenderer) makes a formal offer (the tender) to a contracting authority to execute an order for the supply or purchase of goods, or for the execution of work, according to the terms of a proposed contract. Processes involved Tendering Submitter role Tenderer Receiver role Contracting Authority Normative schema xsd/maindoc/UBL-Tender-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Tender-2.1.xsd RELAX NG schema rnc/versions/UBL-Tender-2.1.rnc Document model (ODF) mod/maindoc/UBL-Tender-2.1.ods Document model (Excel) mod/maindoc/UBL-Tender-2.1.xls Document model (UML) uml/UBL-Tender-2.1.html Summary report mod/summary/reports/UBL-Tender-2.1.html
Tender Receipt Description: A document sent by a contracting party to an economic operator acknowledging receipt of a Tender. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-TenderReceipt-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TenderReceipt-2.1.xsd RELAX NG schema rnc/versions/UBL-TenderReceipt-2.1.rnc Document model (ODF) mod/maindoc/UBL-TenderReceipt-2.1.ods Document model (Excel) mod/maindoc/UBL-TenderReceipt-2.1.xls Document model (UML) uml/UBL-TenderReceipt-2.1.html Summary report mod/summary/reports/UBL-TenderReceipt-2.1.html
Tenderer Qualification Description: A document declaring the qualifications of a tenderer. Processes involved Tendering Submitter role Tenderer Receiver role Contracting Authority Normative schema xsd/maindoc/UBL-TendererQualification-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TendererQualification-2.1.xsd RELAX NG schema rnc/versions/UBL-TendererQualification-2.1.rnc Document model (ODF) mod/maindoc/UBL-TendererQualification-2.1.ods Document model (Excel) mod/maindoc/UBL-TendererQualification-2.1.xls Document model (UML) uml/UBL-TendererQualification-2.1.html Summary report mod/summary/reports/UBL-TendererQualification-2.1.html
Tenderer Qualification Response Description: A document issued by a procurement organization to notify an economic operator whether it has been admitted to or excluded from the tendering process. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-TendererQualificationResponse-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TendererQualificationResponse-2.1.xsd RELAX NG schema rnc/versions/UBL-TendererQualificationResponse-2.1.rnc Document model (ODF) mod/maindoc/UBL-TendererQualificationResponse-2.1.ods Document model (Excel) mod/maindoc/UBL-TendererQualificationResponse-2.1.xls Document model (UML) uml/UBL-TendererQualificationResponse-2.1.html Summary report mod/summary/reports/UBL-TendererQualificationResponse-2.1.html
Trade Item Location Profile Description: A document specifying trade item attributes relating to replenishment policies. Processes involved Collaborative Planning, Forecasting, and Replenishment Submitter role Buyer, Seller Receiver role Buyer, Seller Normative schema xsd/maindoc/UBL-TradeItemLocationProfile-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TradeItemLocationProfile-2.1.xsd RELAX NG schema rnc/versions/UBL-TradeItemLocationProfile-2.1.rnc Document model (ODF) mod/maindoc/UBL-TradeItemLocationProfile-2.1.ods Document model (Excel) mod/maindoc/UBL-TradeItemLocationProfile-2.1.xls Document model (UML) uml/UBL-TradeItemLocationProfile-2.1.html Summary report mod/summary/reports/UBL-TradeItemLocationProfile-2.1.html UBL 2.1 example instance xml/UBL-TradeItemLocationProfile-2.1-Example.xml
Transport Execution Plan Description: A document used in the negotiation of a transport service between a transport user and a transport service provider. Processes involved Intermodal Freight Management Submitter role Transport Service Provider, Transport User Receiver role Transport User, Transport Service Provider Normative schema xsd/maindoc/UBL-TransportExecutionPlan-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportExecutionPlan-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportExecutionPlan-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportExecutionPlan-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportExecutionPlan-2.1.xls Document model (UML) uml/UBL-TransportExecutionPlan-2.1.html Summary report mod/summary/reports/UBL-TransportExecutionPlan-2.1.html UBL 2.1 example instance xml/UBL-TransportExecutionPlan-2.1-Example.xml
Transport Execution Plan Request Description: A document sent by a transport user to request a transport service from a transport service provider. Processes involved Intermodal Freight Management Submitter role Transport User Receiver role Transport Service Provider Normative schema xsd/maindoc/UBL-TransportExecutionPlanRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportExecutionPlanRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportExecutionPlanRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportExecutionPlanRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportExecutionPlanRequest-2.1.xls Document model (UML) uml/UBL-TransportExecutionPlanRequest-2.1.html Summary report mod/summary/reports/UBL-TransportExecutionPlanRequest-2.1.html UBL 2.1 example instance xml/UBL-TransportExecutionPlanRequest-2.1-Example.xml
Transport Progress Status Description: A document sent from a transportation network manager to a transport service provider giving the status of the whereabouts and schedule of the transport means involved in a transport service. Processes involved Intermodal Freight Management Submitter role Transportation Network Manager Receiver role Transport Service Provider Normative schema xsd/maindoc/UBL-TransportProgressStatus-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportProgressStatus-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportProgressStatus-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportProgressStatus-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportProgressStatus-2.1.xls Document model (UML) uml/UBL-TransportProgressStatus-2.1.html Summary report mod/summary/reports/UBL-TransportProgressStatus-2.1.html UBL 2.1 example instance xml/UBL-TransportProgressStatus-2.1-Example.xml
Transport Progress Status Request Description: A document sent from a transport service provider to a transportation network manager requesting a Transport Progress Status. Processes involved Intermodal Freight Management Submitter role Transport Service Provider Receiver role Transportation Network Manager Normative schema xsd/maindoc/UBL-TransportProgressStatusRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportProgressStatusRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportProgressStatusRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportProgressStatusRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportProgressStatusRequest-2.1.xls Document model (UML) uml/UBL-TransportProgressStatusRequest-2.1.html Summary report mod/summary/reports/UBL-TransportProgressStatusRequest-2.1.html UBL 2.1 example instance xml/UBL-TransportProgressStatusRequest-2.1-Example.xml
Transport Service Description Description: A document sent by a transport service provider to announce the availability of a transport service. Processes involved Intermodal Freight Management Submitter role Transport Service Provider Receiver role Transport User Normative schema xsd/maindoc/UBL-TransportServiceDescription-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportServiceDescription-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportServiceDescription-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportServiceDescription-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportServiceDescription-2.1.xls Document model (UML) uml/UBL-TransportServiceDescription-2.1.html Summary report mod/summary/reports/UBL-TransportServiceDescription-2.1.html UBL 2.1 example instance xml/UBL-TransportServiceDescription-2.1-Example.xml
Transport Service Description Request Description: A document requesting a Transport Service Description, sent from a party with a transport demand (transport user) to a party providing transport services (transport service provider). Processes involved Intermodal Freight Management Submitter role Transport User Receiver role Transport Service Provider Normative schema xsd/maindoc/UBL-TransportServiceDescriptionRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportServiceDescriptionRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportServiceDescriptionRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportServiceDescriptionRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportServiceDescriptionRequest-2.1.xls Document model (UML) uml/UBL-TransportServiceDescriptionRequest-2.1.html Summary report mod/summary/reports/UBL-TransportServiceDescriptionRequest-2.1.html UBL 2.1 example instance xml/UBL-TransportServiceDescriptionRequest-2.1-Example.xml
Transportation Status Description: A document to circulate reports of transportation status or changes in status (events) among a group of participants. Processes involved Freight Status Reporting Submitter role Transport Service Provider Receiver role Transport User Normative schema xsd/maindoc/UBL-TransportationStatus-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportationStatus-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportationStatus-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportationStatus-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportationStatus-2.1.xls Document model (UML) uml/UBL-TransportationStatus-2.1.html Summary report mod/summary/reports/UBL-TransportationStatus-2.1.html UBL 2.1 example instance xml/UBL-TransportationStatus-2.1-Example.xml
Transportation Status Request Description: A document requesting a Transportation Status report. Processes involved Freight Status Reporting Submitter role Transport User Receiver role Transport Service Provider Normative schema xsd/maindoc/UBL-TransportationStatusRequest-2.1.xsd Runtime schema xsdrt/maindoc/UBL-TransportationStatusRequest-2.1.xsd RELAX NG schema rnc/versions/UBL-TransportationStatusRequest-2.1.rnc Document model (ODF) mod/maindoc/UBL-TransportationStatusRequest-2.1.ods Document model (Excel) mod/maindoc/UBL-TransportationStatusRequest-2.1.xls Document model (UML) uml/UBL-TransportationStatusRequest-2.1.html Summary report mod/summary/reports/UBL-TransportationStatusRequest-2.1.html UBL 2.1 example instance xml/UBL-TransportationStatusRequest-2.1-Example.xml
Unawarded Notification Description: A document communicating to a tenderer that the contract has been awarded to different tenderer. Processes involved Tendering Submitter role Contracting Authority Receiver role Tenderer Normative schema xsd/maindoc/UBL-UnawardedNotification-2.1.xsd Runtime schema xsdrt/maindoc/UBL-UnawardedNotification-2.1.xsd RELAX NG schema rnc/versions/UBL-UnawardedNotification-2.1.rnc Document model (ODF) mod/maindoc/UBL-UnawardedNotification-2.1.ods Document model (Excel) mod/maindoc/UBL-UnawardedNotification-2.1.xls Document model (UML) uml/UBL-UnawardedNotification-2.1.html Summary report mod/summary/reports/UBL-UnawardedNotification-2.1.html
Utility Statement Description: A supplement to an Invoice or Credit Note, containing information on the consumption of services provided by utility suppliers to private and public customers, including electricity, gas, water, and telephone services. Processes involved Utility Billing Submitter role Supplier Accounting Party Receiver role Customer Accounting Party Normative schema xsd/maindoc/UBL-UtilityStatement-2.1.xsd Runtime schema xsdrt/maindoc/UBL-UtilityStatement-2.1.xsd RELAX NG schema rnc/versions/UBL-UtilityStatement-2.1.rnc Document model (ODF) mod/maindoc/UBL-UtilityStatement-2.1.ods Document model (Excel) mod/maindoc/UBL-UtilityStatement-2.1.xls Document model (UML) uml/UBL-UtilityStatement-2.1.html Summary report mod/summary/reports/UBL-UtilityStatement-2.1.html
Waybill Description: A transport document describing a shipment. It is issued by the party who undertakes to provide transportation services, or undertakes to arrange for their provision, to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the instructions for the beneficiary and may contain the details of the transportation, charges, and terms and conditions under which the transportation service is provided. See and compare with . Processes involved Freight Management Submitter role Freight Forwarder, Carrier Receiver role Consignor (or Consignee), Freight Forwarder Normative schema xsd/maindoc/UBL-Waybill-2.1.xsd Runtime schema xsdrt/maindoc/UBL-Waybill-2.1.xsd RELAX NG schema rnc/versions/UBL-Waybill-2.1.rnc Document model (ODF) mod/maindoc/UBL-Waybill-2.1.ods Document model (Excel) mod/maindoc/UBL-Waybill-2.1.xls Document model (UML) uml/UBL-Waybill-2.1.html Summary report mod/summary/reports/UBL-Waybill-2.1.html UBL 2.0 example instance xml/UBL-Waybill-2.0-Example-International.xml
UBL 2.1 Common Schemas The xsd/common directory contains schemas referenced by the document schemas in xsd/maindoc. Elements defined in the common schemas constitute a library of reusable business data components from which the UBL document schemas are (and customized document types may be) assembled. For a discussion of the way schemas are assembled, see . The name of each schema file together with a brief description of its contents is given below.
Reusable BIE Schemas
CommonBasicComponents xsd/common/UBL-CommonBasicComponents-2.1.xsd The CommonBasicComponents schema defines the global Basic Business Information Entities (BBIEs) that are used throughout UBL, serving, in effect, as a “global BBIE type database” for constructing documents. BBIEs are the “leaf nodes” of UBL documents, corresponding to individual data fields in traditional printed business forms. CommonAggregateComponents xsd/common/UBL-CommonAggregateComponents-2.1.xsd The CommonAggregateComponents schema defines the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an “ABIE type database” for constructing the main documents. For a discussion of the terms Basic Business Information Entity and Aggregate Business Information Entity, see .
Reusable Data Type Schemas
CCTS_CCT_SchemaModule xsd/common/CCTS_CCT_SchemaModule-2.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 should 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. UnqualifiedDataTypes xsd/common/UBL-UnqualifiedDataTypes-2.1.xsd This schema defines Unqualified Data Types for BBIE definition. These types are derived from the Core Component Types in CCTS_CCT_SchemaModule. Where an unqualified type is not based solely on an XSD data type, all CCTS supplementary components are made available in the UBL UDT from the CCTS CCT. QualifiedDataTypes xsd/common/UBL-QualifiedDataTypes-2.1.xsd permits the definition of Qualified Datatypes as derivations from CCTS-specified Unqualified Datatypes. In UBL 2.1, all data type qualifications are expressed in the file cva/UBL-DefaultDTQ-2.1.cva. The UBL-QualifiedDataTypes-2.1.xsd file in the UBL 2.1 release is included among the schema modules imported by the Common Library and all document-level schema fragments in order to be consistent with the relationship of types in a CCTS framework, though the schema module itself has no declarations. See for information regarding UBL 2.1 data type derivation.
Documentation Metadata Schema
CoreComponentParameters xsd/common/UBL-CoreComponentParameters-2.1.xsd The CoreComponentParameters schema defines the structure of the annotation/documentation sections that appear in all the other schemas, providing a consistent format for metadata such as object class, representation terms, semantic descriptions, and other supplementary information. While not required by UBL schemas, this module is provided to encourage consistency in the documentation of customized extensions.
Extension Content Schemas UBL extensions enable the validation of user-defined additions to the standard schemas, which are sometimes needed to satisfy legal requirements and can perform other useful functions as well. For further information regarding the UBL extension mechanism, see .
CommonExtensionComponents xsd/common/UBL-CommonExtensionComponents-2.1.xsd The CommonExtensionComponents schema defines the extension structures that are used in all UBL document types, providing metadata regarding the use of an extension embedded in a UBL document instance. ExtensionContentDatatype xsd/common/UBL-ExtensionContentDataType-2.1.xsd The ExtensionContentDataType schema specifies the actual structural constraints of the extension element containing the foreign non-UBL content. By default, the version of this schema provided in the UBL 2.1 distribution imports the UBL Signature Extension module and namespace (see ). This both enables support by default for advanced digital signatures and serves as an illustration of the way extensions are defined in UBL. This is the only schema intended to be modified by a user when it is necessary to support the constraints of additional user-defined extension structures. This is accomplished by adding other schema import directives, as is already done for the signature extension. Without adding the directives, the user’s constructs found under the extension point will not be validated. No changes are required to the complex type declaration ExtensionContentType.
Signature Extension Schemas UBL 2.1 schemas are supplied with a predefined standard extension that supports advanced digital signatures; see and for further information regarding the UBL extension supporting digital signatures such as XAdES.
CommonSignatureComponents xsd/common/UBL-CommonSignatureComponents-2.1.xsd The CommonSignatureComponents schema defines the scaffolding structures containing the IETF/W3C Digital Signature information XML elements related to either the entire document or particular signature business objects found within the document. SignatureAggregateComponents xsd/common/UBL-SignatureAggregateComponents-2.1.xsd The SignatureAggregateComponents schema defines those Aggregate Business Information Entities (ABIEs) that are used for signature constructs not defined in the common library. SignatureBasicComponents xsd/common/UBL-SignatureBasicComponents-2.1.xsd The SignatureBasicComponents schema defines those Basic Business Information Entities (BBIEs) that are used for signature constructs not defined in the common library. For a discussion of the terms Basic Business Information Entity and Aggregate Business Information Entity, see . xmldsig-core-schema xsd/common/UBL-xmldsig-core-schema-2.1.xsd This is a copy of the IETF/W3C Digital Signature core schema file, modified only to remove the unnecessary PUBLIC and SYSTEM identifiers from the DOCTYPE. XAdESv132 xsd/common/UBL-XAdESv132-2.1.xsd This is a copy of the XAdES v1.3.2 schema file, modified only to change the importing URI for the XML digital signature core schema file. The presence of this schema file does not oblige the use of XAdES. It is provided only as a convenience for those users who choose to include an XAdES extension inside of a digital signature. XAdESv141 xsd/common/UBL-XAdESv141-2.1.xsd This is a copy of the XAdES v1.4.1 schema file, modified only to change the importing URI for the XAdES v1.3.2 schema file. The presence of this schema file does not oblige the use of XAdES. It is provided only as a convenience for those users who choose to include an XAdES extension inside of a digital signature.
Schema Dependencies The following diagram shows the dependencies among the schema modules making up a UBL 2.1 document schema.
UBL Schema Dependencies [schema dependency diagram]
The UBL schemas are delivered supporting the UBL standardized extension for digital signatures, defining the content of the extension to be a single element either in or out of the UBL signature extension namespace. As shown on the bottom right in this diagram, a set of UBL schemas supporting a different user-customized extension can be created by replacing the delivered ExtensionContentDataType schema fragment with one also importing the required custom schema fragments that define the custom content. For more regarding the signature extension, see . The relationship of the UBL schemas to the UBL data model is illustrated in .
Extension Validation Methodology The UBL extension mechanism allows the addition of other extensions in the same instance. The UBL Digital Signature extension described in is built into the UBL 2.1 distribution and validates transparently. Users wishing to validate other extensions found in the instance simply revise the UBL-ExtensionContentDataType-2.1.xsd schema fragment. An <xsd:import> directive is added to incorporate the schema constraints of the apex of another extension to be validated in the single pass of XSD validation. shows the replacement of the schema fragment with one in which user-defined extension modules with namespaces ext:, zzz:, zac:, and zbc: augment the digital signature extension modules with namespaces ext:, sig:, sac:, sbc: and ds:. Due to limitations of W3C Schema validation semantics (this is not the case in RELAX NG, for example), the apex element of the extension in the instance being validated cannot be constrained solely to the apex element declared. W3C Schema’s lax validation permits any element declared in any schema fragment to be the apex of an extension. Thus, an instance will pass when a known extension element not permitted by the user to be an apex element is in the place of an apex element. This is simply regarded by downstream processes as an unknown extension and will likely be ignored.
Notes for Extension Creators The following points should be noted: Extension designers should follow the example by providing separate namespaces for apex element, aggregate constructs, and basic constructs if they wish the new items to be considered for inclusion in future UBL releases. This structures the new items for inclusion in the UBL common library. See xml/MyTransportationStatus.xml for a document instance exemplifying the recommended treatment of namespaces. Whenever possible, one should use existing UBL common library aggregate and basic constructs in extensions rather than inventing new items with the same semantics. However, a common library aggregate construct should only be used when the entire aggregate and all of its descendants are applicable in the extension context without any changes. If any items must be removed, then a new extension aggregate with a new local name should be used. If all the constructs in the common library aggregate are applicable but some items need to be added, then a new extension aggregate with the same name should be created by adding the new constructs to a copy of the common library aggregate. The UBL Digital Signature extension described in has been modeled as an example to follow when designing and writing other custom extensions.
Additional Document Constraints In addition to the UBL 2.1 document constraints formally expressed by the schemas in , UBL mandates several other rules governing conformant UBL 2.1 instances that cannot be expressed using W3C Schema. These additional UBL document rules, addressing instance validation, character encoding, and empty elements, are specified below. These rules first appeared in the OASIS UBL 1.0 and UBL 1.0 NDR Standards. They are listed here because logically they belong with the great majority of UBL instance constraints specified in the schemas. To aid in coordinating references between these various publications, the rules below retain their original “IND” labels. The former IND4 was removed in the revision process leading to UBL 2.0.
Validation The UBL library and document schemas are targeted at supporting business information exchanges. Business information exchanges require a high degree of precision to ensure that application processing and corresponding business actions are reflective of the purpose, intent, and information content agreed to by both trading partners. Schemas provide the base mechanism for ensuring that instance documents do in fact support these requirements.
[IND1] All UBL instance documents MUST validate to a corresponding schema.
UBL recommends a two-phase approach for validation of rules related to specific data content (such as to check of code list values). See for a description of this approach.
Character Encoding XML supports a wide variety of character encodings. Processors must understand which character encoding is employed in each XML document. XML 1.0 supports a default value of UTF-8 for character encoding, but best practice is always to identify the character encoding being employed.
[IND2] All UBL instance documents MUST identify their character encoding within the XML declaration.
Example:
<?xml version="1.0" encoding="UTF-8"?>
UBL, as an OASIS TC, is obligated to conform to agreements OASIS has entered into. OASIS is a liaison member of the ISO IEC ITU UN/CEFACT eBusiness Memorandum of Understanding Management Group (MOUMG). Resolution 01/08 (MOU/MG01n83) requires the use of UTF-8.
[IND3] In conformance with ISO IEC ITU UN/CEFACT eBusiness Memorandum of Understanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) as agreed to by OASIS, all UBL XML SHOULD be expressed using UTF-8.
Example:
<?xml version="1.0" encoding="UTF-8"?>
Empty Elements Use of empty elements within XML instance documents is a source of controversy for a variety of reasons. An empty element does not simply represent data that is missing. It may express data that is not applicable for some reason, trigger the expression of an attribute, denote all possible values instead of just one, mark the end of a series of data, or appear as a result of an error in XML file generation. Conversely, missing data elements can also have meaning—that the trading partner does not provide that data. In information exchange environments, different trading partners may allow, require, or ban empty elements. UBL takes the position that empty elements do not provide the level of assurance necessary for business information exchanges and therefore must not be used.
[IND5] UBL conformant instance documents MUST NOT contain an element devoid of content or containing null values, except in the case of extension, where the UBL ExtensionContent element is used.
An important implication of this rule is that every container element must contain at least one of its possible constituents even if all of its possible constituents are declared to be optional. To ensure that no attempt is made to circumvent rule IND5, UBL also prohibits attempting to convey meaning by omitting an element (i.e., an optional element may be omitted, but that omission cannot carry a specific meaning upon which an action is conditioned).
[IND6] The absence of a construct or data in a UBL instance document MUST NOT carry meaning.
Natural language text elements Natural language text elements such as Note and Description appear throughout the UBL document model. They are of the same unstructured Text type as character data fields that are not intended for natural language prose, such as AddressLine. All natural language text elements in UBL are repeatable within some container; for example, all Note elements are repeatable as adjacent siblings under a common parent. Despite appearances, these multiple text elements are not intended for the representation of separate paragraphs or divisions within a single parent text; rather, each Note element (for example) contains the entire text of the note in one of the languages in which the note is provided. In other words, UBL allows 0..n Note or Description elements in order to present the same note or description in 0..n languages, not to reflect structures such as paragraphs internal to a text in a single language. Since UBL text elements are intended for unstructured sequences of character data, more complex texts should be located in external documents and associated with the UBL message using document references. UBL enforces this restriction with the following two rules:
[IND7] Where two or more sibling “Text. Type” elements of the same name exist in a document, no two can have the same “languageID” attribute value. [IND8] Where two or more sibling “Text. Type” elements of the same name exist in a document, no two can omit the “languageID” attribute.
UBL Digital Signatures This section provides the context for the use of UBL digital signatures and then defines profiles for advanced digital signatures in UBL and a specific UBL extension that implements one specific kind of advanced digital signature.
Introduction There are certain circumstances in which it becomes necessary to electronically sign UBL documents. This can be the case when creating tenders or invoices. For example, in some countries digitally signing electronic invoices is required by law. UBL (without extension) has a data structure (known as Signature) for defining electronic signatures and a number of elements for using such signatures in a document. To integrate UBL into the larger standards environment, this section associates the IETF/W3C XML Digital Signature specification (a general framework for digitally signing XML documents) with the signature elements provided by UBL. These include specific provisions to use extensions supporting , XML Advanced Electronic Signatures (ETSI TS 101 903), when the electronic signing of UBL documents is necessary to satisfy legal and technical requirements. XAdES extends XMLDSig for use with advanced and qualified electronic signatures as specified in European Directive . Use of XAdES and the concept of Advanced Electronic Signature is not limited to Europe, as it is being adopted by many countries outside the EU, and, at the time of publication of this specification, it is undergoing international standardization in ISO as ISO 14533-2:2012 . One important benefit of XAdES is that it allows the addition of information and timestamps that extend the validity of a signature beyond the expiration or revocation of the electronic certificates involved in signature verification or the obsolescence of the underlying cryptographic keys and algorithms. By extending XMLDSig with additional embedded syntax and processing, XAdES satisfies the European Directive on a Community Framework for Electronic Signatures as well as other use cases requiring long-term preservation of signed documents. XAdES contains several modules that permit various levels of security, such as content commitment and non-repudiation enforcement with timestamps and long-term signature verification. The two digital signature profiles provided in UBL 2.1 represent two approaches to signing UBL documents: enveloped and detached. Each of these approaches uses XMLDSig in a way that may or may not include XAdES features. In other words, the mechanisms implemented here can be used not only to implement XAdES in these two ways but also to implement other signature technologies based on XMLDSig as well.
XML Digital Signatures
Overview Digital signatures, when appropriate rules and functions are used, can support the following properties for a document: Integrity: the document has not been modified since it was signed. Authenticity: the identity of the party creating the signature that applies to the document is certified. Non-repudiation (content commitment): the document signer cannot deny its involvement in creating and/or approving the document (depending on the context and signer role). Anteriority: associating a time-stamp to the signature, a proof that the signature (and therefore the signed document) existed before a certain point in time. defines XML Signature processing rules and syntax to provide integrity and message authentication and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. specifies a standard format for time-stamping that can be used with XMLDSig and XAdES. The directive defines the following technology-neutral requirements that an electronic signature must meet to be considered an Advanced Electronic Signature (AdES) and have legal validity: it is uniquely linked to the signatory; it is capable of identifying the signatory; it is created using means that the signatory can maintain under his sole control; and it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable. The Qualified Signature (QS) is also defined as an AdES based on Qualified Certificates (QC) and Secure Signature Creation Devices for signing operations. In Europe, QS is equivalent to handwritten signature provided it is based on a QC issued by an accredited Certificate Service Provider. These references are provided only for informational use and refer to the framework defined in . XAdES extends XMLDSig to support AdES, but its adoption is not limited to an EU context, as similar requirements are in place in other countries. The introduction to reads, in part,
The XML advanced electronic signatures defined in the present document will be built by incorporating to the XML signatures as defined in XMLDSIG one new ds:Object XML element containing the additional qualifying information.
That XAdES is completely embedded in XMLDSig ensures that the UBL profiles for XMLDSig are sufficient to support XAdES. These profiles also support other existing or future extensions of XMLDSig that are completely embedded in XMLDSig syntax. These other possible UBL digital signature profiles may or may not use the XAdES extensions to XMLDSig. It is important to note that XAdES and XMLDSig define digital signature processing rules and syntax but do not cover the implementation of security measures required for an AdES, which are out of scope for UBL. Implementation may depend on local regulations in place and specific provisions set by the authority issuing the certificates supporting the signature. The implementer has to determine the set of requirements that apply to the specific context of use and determine accordingly the suitability of the standards and the specific profiles to be used. XAdES can help in fulfilling legal requirements, but this is not just a matter of correctly applying a technical standard. Users are advised to examine the regulations applicable to their specific context of use.
XML Signature Types An XML signature may be (non-exclusively) described (per XMLDSig and XAdES) as detached, enveloping, or enveloped. Detached. The signature applies to content that is external to the <ds:Signature> element and can be identified via a URI or transform. Consequently, the signature is “detached" from the content it signs. This definition typically applies to separate data objects, but it also includes the case where the <ds:Signature> and signed data object are sibling elements residing within the same XML document. Enveloping. The signature applies to content found within a <ds:Object> element of the signature itself. The <ds:Object> (or its content) is identified via a <ds:Reference> (using a URI fragment identifier or transform). Enveloped. The signature applies to the XML content that contains <ds:Signature> as an element. Implementations of enveloped signature(s) must take care not to include the signature in the calculation of the signature value. UBL defines two profiles for signing a UBL document: enveloped and detached.
XAdES A compliant implementation of XAdES guarantees wide acceptance in implementing legal regulations, such as European Commission Directive and European Commission Decision , and it supports best practices in eInvoicing, eProcurement, and eBusiness in general as set forth by relevant standard bodies such as CEN ( and ). The UBL implementation of XAdES provides the following additional properties: A signed UBL document will be processed correctly by any compliant UBL software (including UBL software that is not XMLDSig/XAdES aware) and by any compliant XMLDSig/XAdES verification software (including software that is not UBL aware). No change is required for currently defined UBL or XMLDSig/XAdES syntaxes. The extension mechanism specified here supports any XMLDSig/XAdES form, leaving to the implementer the choice of the most appropriate one according to the specific legal framework or application context. XAdES defines a set of forms that extends XMLDSig and allows adding some validation data to the signature. The two basic forms are: XAdES-BES, which satisfies the minimum requirements for AdES; and XAdES-EPES, which builds on XAdES-BES to include a security policy identifier that specifies the rules followed to validate the signature. A conformant XAdES signature generation and verification implementation supports at least XAdES-BES or XAdES-EPES. The other forms can be built by the signature generator or the signature verifier by extending one of the two basic forms. They are: XAdES-T, where a timestamp is added to enforce content commitment (non-repudiation) and as a proof of anteriority. This envelope allows ascertaining the validity of a signature in case the signer certificate is later revoked. XAdES-C, which adds to the signed document a complete reference to verification data (certificates and revocation lists) to support long-term signature verification. XAdES-X, which adds timestamps to XAdES-C references to protect against future compromise of certificates. XAdES-X-L, which is similar to XADES-X but adds real certificates and revocation lists instead of just references. XAdES-A, which adds timestamps (periodically, as required) to extend the validity period for long-term storage, taking into account a possible weakening of the algorithms used to sign the document and related certificates during the storage period. No specific XAdES form is recommended for a UBL document, as this choice depends on the specific context of use, agreements between the parties, and local regulations.
Requirements for Digital Signatures in UBL The main requirements to be addressed when choosing a specific signature profile can be divided into the following categories: Legal requirements. In some countries a digital signature is required on electronic invoices. It can also be compulsory in electronic procurement, especially in a cross-border context, to have a digital signature on the key document exchanged, e.g., a response to a request for tender. Another important legal requirement is long-term document preservation, for a storage period that in general is specific to each country and can span many years. The requirement to guarantee the integrity and authenticity of all fiscally relevant archived documents, as specified, for example, by for electronic invoices, can be met with digital signatures when proper XAdES forms are used. Business requirements. A digital signature can reduce the risks associated with a business transaction (e.g., content commitment of a commercial order, proof-of-origin and integrity of an invoice), and its use can be provided for in the interchange agreement between parties. The choice of the signature format and its application is a key factor in achieving interoperability. Process requirements.The presence of the digital signature should not add any specific constraints on UBL document content processing. If the signed document remains a valid UBL document, the signature can be verified at any stage of the process: it should be possible to validate a signed document at any time “as is" by UBL and XAdES verifiers. Archiving of UBL documents also can be an important issue to consider, as document preservation has specific requirements.
Profiles for UBL Digital Signatures UBL specifies two profiles for use in digitally signing UBL documents: Enveloped Signature Profile: One or more signatures are added to the UBL document inside a single identifiable and dedicated UBL extension. Other UBL extensions MAY be present provided they have different identifiers so that they can be distinguished from the one that contains the document signature(s). This profile is defined such that UBL content processing can be separated from electronic signature processing, both on the issuing side and on the receiving side, and specialized applications can be devoted to each function. The UBL application does not need to be electronic signature aware, and the electronic signature application does not need to be involved in the management of the UBL syntax. A signature business object in the UBL document may reference a particular electronic signature in the extension. Detached Signature Profile: The signature is outside the UBL document content in another information resource. Some mechanism has to be defined by the implementer to send or make available the signature to the recipient. This method of signing may be identified in the UBL document. This approach can be useful to avoid or minimize any kind of modification to the UBL document and is compatible with other signature methods not explicitly referenced by this profile. The two profiles for adding one or more digital signatures to a UBL document are based on . These profiles and their associated methods decouple the UBL document to be signed from any specificity in the digital signature standard adopted within XMLDSig. The XAdES standard is an example of a standard use of XMLDSig. UBL users may use any standard built on XMLDSig or simply use XMLDSig as it stands without any extensions. Managing XML signatures inside of a UBL document is described in . Managing XML signatures outside of a UBL document is described in . Both profiles support co-signatures, i.e., a UBL document can be independently cosigned by multiple signers in any order and at any time. Both profiles support countersignatures, i.e., a UBL document can have its signatures signed by another signature. The enveloped signature profile supports a final signature, i.e., a UBL document once signed with a final signature cannot have any other signature added without invalidating the final signature. The choice of the most suitable profile should take into account the specific document processing and delivery infrastructure. The main advantage of the enveloped profile is that the signature(s) are embedded in the UBL document (which syntactically remains a valid UBL document). This means that the transport of the signatures is guaranteed by the UBL document delivery infrastructure. The detached signature profile has a simpler preparation phase and signature procedure, but specific means to send or make available the signature(s) to the recipient have to be implemented. A standard container like can be used to associate the UBL document with detached advanced electronic signature(s) that apply to it. The simple container (ASiC-S) can be created later than signature generation in such a way that it contains a UBL document and one or more detached signatures that apply to it.
Enveloped XML Signatures in UBL Documents The enveloped signature profile supports one or more signatures to be applied to a UBL document and embedded in the UBL document itself inside a dedicated extension. This profile can be used with all UBL documents under their respective <ext:UBLExtensions> extension points. UBL syntax implementing the enveloped profile, together with examples of its use, are provided in . The user MAY choose to indicate in a <cac:Signature> element that the signature details are found in the signature extension. The URI urn:oasis:names:specification:ubl:dsig:enveloped is reserved as a value for <cbc:SignatureMethod> to signal this. The URI urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped:​xades MAY be used as a value for <cbc:SignatureMethod> to signal when XAdES is in use. Additionally, the user MAY include a <cbc:ID> child of <cac:Signature> for referencing purposes from the enveloped signature. The identifier used can be any value, but for convenience the URI of a URN beginning with urn:​oasis:​names:​specification:​ubl:​signature:, ending with the local name of the parent of the signature business object, and optionally followed with a colon and number, as in the urn:​oasis:​names:​specification:​ubl:​signature:​IssuerEndorsement example, is reserved for this purpose for UBL users. As with all identifiers, the identifier SHOULD exist and SHOULD be unique across all identifier values. An example is as follows: urn:oasis:names:specification:ubl:signature:Invoice urn:oasis:names:specification:ubl:dsig:enveloped MyParty ]]> See for a sample UBL Invoice that references an enveloped digital signature.
Enveloped Signature Syntax and Transformation Two different syntaxes are used in UBL enveloped signatures: UBL-specified scaffolding under the extension point used to contain the signature information and IETF/W3C-specified information for each digital signature. A transformation element is also present to prevent a signature from being invalidated by the subsequent addition of another signature. These features are described in detail in and .
Detached XML Signatures for UBL Documents This profile supports the application to a UBL document of one or more signatures located outside of the document itself in some other resource. It is important to note that externally signing a UBL document with a detached signature imposes no requirements on the UBL document itself. Such a signature, in any kind of signature container, can digitally sign the content of a UBL document regardless of whether this is reflected in the document. If a user knows the document will have a detached conformant IETF/W3C XML digital signature, the user MAY choose to signal in their UBL document that it is so signed. The URI value urn:​oasis:​names:​specification:​ubl:​dsig:​detached is reserved to indicate that the detached signature is an IETF/W3C XML digital signature. The URI urn:​oasis:​names:​specification:​ubl:​dsig:​detached:​xades MAY be used as a value to signal when XAdES is in use. The value is used in the <cbc:SignatureMethod> child of <cac:Signature>. If the location of the digital signature is known, the user MAY choose to indicate the location in a <cbc:URI> child element of a <cac:ExternalReference> child element of a <cac:DigitalSignatureAttachment> element. Following is a complete example of a <cac:Signature> business object that might be found in a UBL instance: urn:oasis:names:specification:ubl:signature:Invoice urn:oasis:names:specification:ubl:dsig:detached MyParty sigFile.xml ]]> A document with multiple detached signatures is simply a document that is co-signed. By the appropriate use of the <ds:Reference> element pointing to the UBL document from a detached signature file, all such signatures are signing the content of the document but not each other. A countersigning document signature, on the other hand, signs signatures already created for and external to or present in the document at the time it is countersigned. A digital countersignature <ds:Signature>, which may be located internal to the UBL document or in an external file, includes additional <ds:Reference> elements, each pointing either to the <ds:Signature> element or <ds:SignatureValue> element child of the signature being signed. In the first case, where the signature is detached, the <ds:Reference> element points to the external file for that signature; in the second case, where the signature is enveloped, the <ds:Reference> element points to the Id= value of either the <ds:Signature> or <ds:SignatureValue> element for that signature. The XAdES specification supports an alternative countersignature approach where a <ds:Signature> element pointing to the countersigned signature’s <ds:SignatureValue> is embedded in the <ds:Object> of the countersigning signature. The inclusion of an alternative method in this specification does not prohibit this approach. See for a sample UBL Invoice that references a detached digital signature.
Digital Signature Transformation (Detached Signatures) The content to be signed is addressed in the URI= attribute of <ds:Reference>: ]]> An option when using detached digital signatures is to express in XPath that address that qualifies all nodes in the referenced content to be included in the calculation of the digital signature hash. For a signature calculated for a document to remain valid, none of the signed information can change, nor can any information be added or removed from that portion of the document included in the hash calculation. Consider the need to create a detached signature for a UBL file in which there already exists an enveloped signature. The following transformation element in a digital signature flexibly prevents the signature being invalidated by the subsequent addition of any signatures using the enveloped profile within the extension of the document being signed: count(ancestor-or-self::sig:UBLDocumentSignatures)=0 ]]> A non-final transformation algorithm used in the detached signature signs all content outside of any enveloped signatures in the UBL document. When the UBL document does not already have an enveloped signature, one cannot be added without invalidating the detached signature. In effect, the entire document has been signed and cannot change, but the addition of the scaffolding for a signature constitutes a change. However, when the UBL document already has an enveloped signature, other signatures can be added without invalidating the detached signature, because the scaffolding doesn’t change when other signatures are added within the existing scaffolding; the non-final transformation algorithm does not include the signatures found in the existing scaffolding. When there is no preexisting enveloped signature, the entire document must be signed in the detached signature. To sign only a portion of a UBL document, an appropriate address SHOULD be used because UBL business object elements do not have attributes of type ID. This requires XPointer awareness on the part of the digital signature tools being used.
UBL Extension for Enveloped XML Digital Signatures UBL extensions enable user-defined additions to the standard schemas. The UBL 2.1 schemas in this distribution are provided with a predefined standard extension for enveloped signatures that supports IETF/W3C Digital Signature profiles. These include advanced IETF/W3C XML digital signatures conforming to the ETSI XAdES specification , thus satisfying EU legal requirements for electronically signed business documents. This extension also serves as a case study for the creation of user-defined UBL extensions; see . Further information on the UBL extension mechanism can be found in . UBL’s implementation of XML digital signatures puts all the signatures relating to a document in a single extension, which is engaged in validation by the UBL-ExtensionContentDataType-2.1.xsd schema module.
Namespaces As is true for the UBL document schemas and common library, the UBL digital signature extension is modeled with three namespaces: one for the apex element (a parallel to the document schema), one for new aggregate constructs (a parallel to the common aggregate schema), and one for new basic constructs (a parallel to the common basic schema). See . The urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​CommonSignatureComponents-2 namespace is used for the apex element, the urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​SignatureAggregateComponents-2 namespace is used for new aggregate elements, and the urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​SignatureBasicComponents-2 namespace is used for new basic elements. The IETF/W3C digital signature standard namespace http://www.w3.org/2000/09/xmldsig# is also used in this extension. These namespaces are bound to the sig:, sac:, sbc: and ds: prefixes respectively, but any prefix or even the default namespace can be used for any of these in an XML instance. Schema fragments for the two XAdES namespaces http://uri.etsi.org/01903/v1.3.2# and http://uri.etsi.org/01903/v1.4.1# are included and engaged in UBL 2.1 for the convenience of users of the XAdES specification. There is no obligation to use the XAdES extension in the IETF/W3C digital signature. The table below lists the namespaces used for UBL digital signatures. The prefixes on the left are only documentary conventions; their choice is not constrained by XML. Namespaces for UBL Digital Signatures Prefix Namespace Reference ds http://www.w3.org/2000/09/xmldsig# xades http://uri.etsi.org/01903/v1.3.2# ext urn:oasis:names:specification:ubl:schema: xsd:CommonExtensionComponents-2 UBL extension namespace sig urn:oasis:names:specification:ubl:schema: xsd:CommonSignatureComponents-2 UBL signature extension apex namespace sac urn:oasis:names:specification:ubl:schema: xsd:SignatureAggregateComponents-2 UBL signature extension aggregate namespace sbc urn:oasis:names:specification:ubl:schema: xsd:SignatureBasicComponents-2 UBL signature extension basic namespace
Identification This UBL extension is distinguished from other extensions and identified using the URI urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped in the <ext:ExtensionURI> element. In addition to Enveloped signatures, also provides methods to be used with Detached signatures (i.e., digital signatures that stand outside the document being signed). Detached signatures constitute an independent technique without associated UBL artefacts, but an example instance showing detached signatures is included in this package; see .
Validation The UBL-ExtensionContentDataType-2.1.xsd module links UBL validation to all needed extensions by importing the apex schema fragment of each extension vocabulary. The distribution version of this module supports IETF/W3C XML digital signatures by declaring that the <ext:ExtensionContent> element can contain elements from the UBL Digital Signature extension namespace. Accordingly, a single <sig:UBLDocumentSignatures> element is used as the apex of all the document’s electronic signatures. The <ext:ExtensionContent> element alternatively allows any other namespace apex element in order to allow other foreign extensions in the same document.
Structure The signature extension structure exists to contain one or more IETF/W3C standard digital signature constructs. The UBL scaffolding for this extension starts with a <ext:UBLExtension> element with two children: <ext:ExtensionURI> (for extension distinction and identification) and <ext:ExtensionContent> (for containing the extension information, in this case the actual signatures and supporting information). The signature extension Business Information Entities for UBL 2.1 are contained in a single spreadsheet, provided here in two different formats.
mod/common/UBL-CommonSignatureComponents-2.1.ods mod/common/UBL-CommonSignatureComponents-2.1.xls
One or more signature extensions in a given document may each contain one or more sets of signature information. The following instructions guide the proper use of this particular extension.
The Extension Metadata The standard scaffolding for a given signature extension begins with the <ext:UBLExtension> element. The extension’s role as a UBL signature extension is indicated with a child <ext:ExtensionURI> element with the urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped value. The urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped:​xades value MAY be used to indicate the use of XAdES in the extension. Other extension metadata elements defined in UBL are allowed to be included for the convenience of users without changing the meaning or use of the extension. urn:oasis:names:specification:ubl:dsig:enveloped ]]>
The Extension Identifier All uses of the optional <cbc:ID> metadata SHOULD be unique so that each extension can be uniquely identified. The identifier used can be any value. URNs beginning with urn:​oasis:​names:​specification:​ubl:​extension: and ending with a number value are reserved for this purpose for the convenience of UBL users. The value urn:​oasis:​names:​specification:​ubl:​extension:3 is an example of such a URN. As with all identifiers, each SHOULD be unique across all identifier values in a given UBL instance.
The Signature Apex The mandatory <ext:ExtensionContent> element contains the UBL signature scaffolding. The apex element of the UBL signature information is <sig:UBLDocumentSignatures>.
The Signature Information Each <sac:SignatureInformation> aggregate is used to contain the information related to a single IETF/W3C digital signature. Every signature added to the extension is isolated under a separate <sac:SignatureInformation> aggregate element containing the signature and its supporting information. As many of these aggregates can be in the extension as is needed, each one containing the information for a single digital extension. ]]> Note that three namespaces are used for signature information, in parallel with UBL’s use of a document namespace, an aggregate namespace, and a basic namespace. The apex element is in the urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​CommonSignatureComponents-2 namespace, a parallel to a UBL document namespace. Signature-related aggregate entities are in the urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​SignatureAggregateComponents-2 namespace. Signature-related basic entities are in the urn:​oasis:​names:​specification:​ubl:​schema:​xsd:​SignatureBasicComponents-2 namespace. Accordingly, there are three W3C Schema fragments in the distribution accommodating these three namespaces.
The Signature Identifier An aggregate MAY be identified for referencing purposes using the common library <cbc:ID> element. Such an identifier may be useful in workflow scenarios where a particular signature needs to be identified external to the document, but its use is not obligatory. The identifier used can be any value. URNs beginning with urn:​oasis:​names:​specification:​ubl:​signature: and ending with a number value are reserved for this purpose for the convenience of UBL users. The value urn:​oasis:​names:​specification:​ubl:​signature:3 is an example of such a URN. As with all identifiers, each SHOULD be unique across all identifier values in a given UBL instance.
The Signature Reference An aggregate MAY make reference to an existing <cac:Signature> business object in the same UBL document, but this is not obligatory. When needed, the <sbc:ReferencedSignatureID> basic element is used to point to the <cbc:ID> identifier value of the referenced <cac:Signature>. The identifier used can be any value. URNs beginning with urn:​oasis:​names:​specification:​ubl:​signature:​ and ending with the local name of the parent of the signature business object, optionally followed with a colon and number, are reserved for this purpose for the convenience of UBL users. An example of such a URN is urn:​oasis:​names:​specification:​ubl:​signature:​IssuerEndorsement. As with all identifier references, the referenced identifier SHOULD exist and SHOULD be unique across all such identifier values in a given UBL instance. See for rules regarding common library UBL signature elements in the unextended portion of UBL documents that are being referenced by this element, together with an example of their use.
The Signature Content A single <ds:Signature> element is a child of the aggregate. It MAY be absent from the document, thus supporting workflow scenarios where the element is added by a subsequent process after the UBL scaffolding is added by an earlier process. However, the signature information is semantically incomplete without the IETF/W3C-defined element. To support signatures countersigning this signature, this element must use the Id= attribute with a value unique among other attributes of schema type ID in the instance.
A Signature Skeleton The following is a skeleton example of a single signature: urn:oasis:names:specification:ubl:signature:1 urn:oasis:names:specification:ubl:signature:Invoice ... ... ... ... ... ... ... ]]> The XAdES specification contains all qualifying XAdES information in a single <ds:Object> element located as shown above. The UBL 2.1 distribution includes and engages XAdES schema fragments versioned 1.3.2 and 1.4.1 for the convenience of users who choose to use these versions of XAdES. Users of the UBL signature extension are not obliged to use any XAdES extensions.
Transformation The content to be signed is indicated in the URI= attribute of <ds:Reference>. Using the empty string indicates that the entire document (i.e. the enveloping UBL instance) is what is being signed: ]]> A requirement when using digital signatures is to express in XPath that address that qualifies all nodes in the referenced content to be included in the calculation of the digital signature hash. For a signature added to a document to remain valid, none of the information can change, nor can any information be added or removed from that portion of the document included in the hash calculation. One of two such transformation expressions SHOULD be used in the UBL signature extension; users should choose the appropriate one to meet the objectives of adding the signature to the document. Adding non-signature information to the UBL document will invalidate all signatures already in the extension. The choice to make is whether to support additional signatures after adding the signature with the transformation expression. The following transformation element in a digital signature flexibly prevents the signature from being invalidated by the subsequent addition of other signatures within the extension: count(ancestor-or-self::sig:UBLDocumentSignatures | here()/ancestor::sig:UBLDocumentSignatures[1]) > count(ancestor-or-self::sig:UBLDocumentSignatures) ]]> The following transformation element in a digital signature is inflexible and thus would be considered a “final” signature to be added to the document. Such a signature will be invalidated by the subsequent addition of other signatures to the document: count(ancestor-or-self::ds:Signature | here()/ancestor::ds:Signature[1]) > count(ancestor-or-self::ds:Signature) ]]> Multiple separate items of extra-document content (e.g., attachments) or embedded W3C signature content can be included in the same signature by using sibling <ds:Reference> elements with other URI= attribute values. For example, to countersign another signature in the same UBL document, make a local reference to that signature’s unique identifier, as in: <ds:Reference URI="#{Id attribute of ds:Signature}"> To digitally sign only a portion of standard UBL content and not the entire document of UBL content, one uses an appropriate XPointer address for URI=. This requires XPointer awareness on the part of the digital signature tools being used.
Digital Signature Examples The xml/UBL-Invoice-2.0-Enveloped.xml sample document illustrates the embedding of three extensions in a single document, one of which is a bona fide verifiable enveloped signature extension. A <cac:Signature> element makes reference to the embedded signature. The xml/UBL-Invoice-2.0-Detached.xml sample document illustrates the placement of a detached digital signature outside of the UBL file. A <cac:Signature> element makes reference to the external signature. The xml/UBL-Invoice-2.0-Detached-Signature.xml instance is an example of a bona fide verifiable digital signature of the xml/UBL-Invoice-2.0-Detached.xml instance.
Conformance
Document and Schema Conformance The UBL 2.1 XSD schemas are the only normative representations of the UBL 2.1 document types and library components for the purposes of document validation and conformance. Conformance as applied to UBL documents and schemas, and the distinction between UBL conformance and UBL compatibility, are described in detail in the UBL 2 Guidelines for Customization .
Digital Signature Conformance Claiming syntax conformance to the enveloped signature profile of UBL 2.1 requires the following: a schema-valid UBL extension in which the UBL Signature apex element is the apex of the extension; the <ext:Extension> element is present in the UBL extension and has either urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped or urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped:​xades as its value; the value in all uses of <sbc:ReferencedSignatureID>, when present, correlates to a corresponding <cbc:ID> element of a <cac:Signature> element in the same instance; and the <cbc:SignatureMethod> element, when present, of signature business objects whose signatures are in the UBL extension has either urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped or urn:​oasis:​names:​specification:​ubl:​dsig:​enveloped:​xades as its value. Claiming processing conformance to the enveloped profile of UBL 2.1 requires the conformant processing of all contained <ds:Signature> elements per . Claiming syntax conformance to the detached profile of this specification requires that the <cbc:SignatureMethod> element, when present, of signature business objects whose signatures are outside of the UBL document has either urn:​oasis:​names:​specification:​ubl:​dsig:​detached or urn:​oasis:​names:​specification:​ubl:​dsig:​detached:​xades as its value.
XAdES Conformance When conformance to XAdES in a UBL document is chosen, UBL 2.1 requires the valid expression and processing of the XAdES syntax found in an XMLDSig per .
Release Notes
Availability Online and downloadable versions of this release are available from the locations specified at the top of this document.
Status of this Release Release of this package to the public marks the beginning of its fourth public review. The UBL Technical Committee actively solicits input from the user community regarding this release. See at the beginning of this document for procedures to be used in submitting comments to the Committee. Note that in accordance with OASIS policies regarding intellectual property, the UBL TC cannot accept input from persons outside the UBL TC (including OASIS members) unless it is submitted via the comment list. THIS RELEASE IS SUBJECT TO CHANGE. IT IS PROVIDED FOR TESTING PURPOSES ONLY AND SHOULD NOT BE USED FOR PRODUCTION SYSTEMS.
Package Structure The fourth public review draft of the UBL 2.1 specification is published as a zip archive in the &this-loc;/ directory. Unzipping this archive creates a directory named &stage;-UBL-2.1 containing a master DocBook XML file (UBL-2.1.xml), a generated hypertext version of this file (UBL-2.1.html), a generated PDF version of this file (UBL-2.1.pdf), and a number of subdirectories. The files in these subdirectories, linked to from UBL-2.1.xml, UBL-2.1.html, and UBL-2.1.pdf, contain the various normative and informational pieces of the 2.1 release. A description of each subdirectory is given below. Note that while the UBL-2.1.xml file is the “original” of this specification, it may not be viewable in all currently available web browsers.
art Diagrams and illustrations used in this specification cl Code list specification files; see cva Artefacts expressing data type qualifications; see in and in db DocBook stylesheets for viewing UBL-2.1.xml mod Spreadsheet data models; see rnc Alternative versions of the UBL 2.1 schemas in RELAX NG (compact syntax); see uml Unified Modeling Language (UML) graphical view of the UBL 2.1 schemas; see val Test harness for demonstrating UBL 2.1 two-phase validation; see xml Sample UBL 2.1 instances; see xsd XSD schemas; see xsdrt “Runtime” XSD schemas; see
Support UBL is a volunteer project of the international business community. Inquiries regarding UBL may be posted to the public ubl-dev list, archives for which are located at
http://lists.oasis-open.org/archives/ubl-dev/
Subscriptions to ubl-dev can be made through the OASIS list manager at
http://www.oasis-open.org/mlmanage/index.php
OASIS provides an official community gathering place and information resource for UBL at
http://ubl.xml.org/
UBL Customization UBL provides a vocabulary that, for many user communities, can be used “as is”. However, it is recognized that some user communities must 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 should be based on real-world needs balanced against perceived economic benefits.
Upgrading from UBL 2.0 to UBL 2.1 For current UBL implementers, the most important thing to know about UBL 2.1 is that it is completely backward-compatible with UBL 2.0. In other words, any document that validates against a UBL 2.0 schema will validate against the UBL 2.1 version of that schema. The remaining differences relate mainly to the extended functionality that has been added to the 2.0 business processes in the areas of eTendering, sales reporting, utility statements, transport handling, and collaborative planning, forecasting, and replenishment (CPFR®). Nonetheless, it would be unwise to simply overlay this UBL 2.1 release onto an existing 2.0 installation, and the possible differences among existing 1.0 and 2.0 installations are too large to allow a specific set of instructions to be provided for making the transition. The brief history of UBL document types in the next section puts the new capabilities into context and may help users of existing UBL 1.0 and 2.0 implementations decide whether to upgrade to 2.1. New 2.1 users, on the other hand, can simply install 2.1 and rest assured that their software will interoperate with UBL documents generated by existing conformant UBL 2.0 installations. For more on the concept of conformance, see and .
Dictionary Entry Name Corrections in UBL 2.1 Dictionary Entry Names (DENs) uniquely identify every BIE in the UBL library using the methodology described in . Several typographical errors in dictionary entry naming were discovered and corrected in the course of preparing UBL 2.1. These corrections have no effect on processing, validation, or instance generation, but they are listed in for completeness in documentation.
Revision History Since its first release as an OASIS Standard in 2004, UBL has experienced one major and now one minor version upgrade. This appendix provides a description of the evolution of UBL.
UBL 1.0 Though apparently limited in scope, the eight document types provided in UBL 1.0 (2004) are applicable to a very large number of real-world use cases and have been widely deployed. These original 1.0 document types, later updated in UBL 2.0 and continued here in 2.1, are Order, Order Response, Order Response Simple, Order Change, Order Cancellation, Despatch Advice, Receipt Advice, and Invoice. The figure below shows the original assumed process context for this most basic set of UBL document types. The scope of the process corresponds roughly to that of the UBL 2 Order, Fulfillment, and Traditional Billing processes described in the text (see , , and ).
UBL 1.0 Order-to-Invoice Business Process [ubl 1.0 order-to-invoice diagram]
Because versions of UBL beginning with 2.0 do not maintain backward compatibility with UBL 1.0 document instances (that is, UBL 1.0 document instances will not validate against schemas from UBL 2.0 and later), use of UBL 1.0 in new installations is deprecated. Suitably revised versions of the original eight document types continue all the business functionality of UBL 1.0 in later versions.
Major Revision: UBL 2.0 Adoption of UBL 1.0 following ratification as an OASIS standard in November 2004 resulted in major inputs of new business content beyond the eight basic order-to-invoice business documents specified in the original release. In particular, contributions from representatives of government procurement, taxation, and transportation agencies in Europe, Asia, and North America resulted in greatly expanded pre-order and post-invoice capabilities together with the addition of several transport-related document types, bringing the total number of document types in UBL 2.0 to 31. The new release also featured changes in UBL’s use of XML schema methodology—most importantly, the adoption of global scoping for all element types—breaking backward compatibility with UBL 1.0 instances and therefore necessitating designation as a major revision, signified by incrementing the version number from 1.0 to 2.0 rather than 1.1. The original eight UBL 1.0 document types were revised to reflect these changes. UBL 2.0 achieved OASIS Standardization in December 2006, and the package was updated and corrected in May 2008. The 23 document types added in UBL 2.0 can be summarized as follows:
Added UBL 2.0 document types for sourcing: Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update, Catalogue Request, Quotation, Request for Quotation
Added UBL 2.0 document types for fulfilment: Bill of Lading, Certificate of Origin, Forwarding Instructions, Packing List, Transportation Status, Waybill
Added UBL 2.0 document types for billing: Credit Note, Debit Note, Freight Invoice, Reminder, Self Billed Credit Note, Self Billed Invoice
Added UBL 2.0 document types for payment: Remittance Advice, Statement
Added UBL 2.0 supplementary document types: Application Response, Attached Document
Minor Revision: UBL 2.1
New Document Types in UBL 2.1 Because it preserves backward compatibility with UBL 2.0, UBL 2.1 is technically a minor release, not a major one. However, it does add 34 new document types, bringing the total number of UBL business documents to 65.
Added UBL 2.1 document types for eTendering: Awarded Notification, Call for Tenders, Contract Award Notice, Contract Notice, Guarantee Certificate, Tender, Tender Receipt, Tenderer Qualification, Tenderer Qualification Response, Unawarded Notification
Added UBL 2.1 document types for Collaborative planning, forecasting, and replenishment: Exception Criteria, Exception Notification, Forecast, Forecast Revision, Item Information Request, Prior Information Notice, Trade Item Location Profile
Added UBL 2.1 document types for Vendor Managed Inventory: Instruction for Returns, Inventory Report, Product Activity, Retail Event, Stock Availability Report
Added UBL 2.1 document types for Intermodal Freight Management: Goods Item Itinerary, Transport Execution Plan, Transport Execution Plan Request, Transport Progress Status, Transport Progress Status Request, Transport Service Description, Transport Service Description Request, Transportation Status, Transportation Status Request
Added UBL 2.1 document type for Utility billing: Utility Statement
Added UBL 2.1 supplementary document types: Document Status, Document Status Request
Financial Information Enhancements in UBL 2.1 UBL 2.1 has been enhanced to support the financial information required for downstream processing of Invoices within financial services. Through standardization, business vocabularies such as UBL for eBusiness and ISO 20022 for eFinance enable Straight Through Processing (STP) and paperless trading along the entire financial supply chain. Based on analysis conducted during the current development cycle by the UBL Financial Information Requirements Task Group (FIRTG), the following enhancements have been included in UBL 2.1:
Financial account: Aligned with today’s needs and designed for global usage (AliasName, AccountTypeCode, ...). A financial account can now be associated to the Person information aggregate, not only to a Party. Payment mandate information can optionally be sent as part of the Order; this can be considered a simplification for small businesses. Trade financing: UBL 2.1 is designed to support basic trade financing practices (invoice financing, factoring, pre-shipment/order financing, Letter of Credit, ...) Payments reconciliation: UBL Invoice and Remittance Advice can be used together with financial messages to ensure end-to-end transport of reconciliation identifiers (invoicing party references). In particular, UBL provides a solution for advanced external remittance, where the UBL Remittance Advice is used to transmit the details of complex remittance information associated with the payment initiation process (see ISO 20022 guides for details). Person is now enriched with a person identification, which is often required by the banking sector for legal reasons. Currency Amounts: UBL 2.1 features improved handling of alternative currency amounts.
UBL 2.1 also includes enhancements to legal information.
Party Legal Entity: The Party’s legal information has been considerably enriched with information required by advanced procurement and global usage. Service Provider Party: The exchange of electronic business information is increasingly supported and executed through service providers using business models such as outsourcing, application service provision, or virtual service via cloud computing. UBL Party is now improved to keep track of services handled by one or more service providers. Power of Attorney can now be associated with a Party.
Revised Approach to Data Definitions in UBL 2.1 Since the definitions of the several thousand uniquely named data items in UBL 2.1 are normative in themselves, it is important that each be specified with the greatest care possible. However, there are two very different approaches that can be taken in accomplishing this objective. One approach, used more or less by default in UBL 2.0, is to give a definition for each item that correctly describes that item as a node in a data model. This is the approach that resulted in (for example) the UBL 2.0 definition of TaxTotal in CreditNoteLine as “An association to Tax Total”. While perfectly correct from the standpoint of data model construction (the ASBIE for TaxTotal is, in fact, an association to the class or ABIE named Tax Total; see ), such a definition is less than ideally useful for the business analyst attempting to determine the meaning of TaxTotal as an element name in an actual Credit Note. Of course, the definition of the ABIE itself could be tracked back through this reference to its place in the model, where in UBL 2.0 one would find the class “Tax Total” defined as “Information about a total amount of a particular tax”, but even here an attempt to be absolutely correct can lead to a pathological expansion of the definition, as “Information about a total amount of a particular tax” becomes “A description of information about a total amount of a particular tax” and then “Structured data constituting a description of information about a total amount of a particular tax” and so on. A second approach to wording the definitions, adopted in UBL 2.1, is to write each definition as an answer to the question “What does this mean?” in the context of an actual document instance containing the item. Thus, in UBL 2.1, the definition of TaxTotal in CreditNoteLine has changed from “An association to Tax Total” to “A total amount of taxes of a particular kind applicable to this credit note line”, which the designers of UBL 2.1 believe to be more directly usable to someone analyzing an instance of a Credit Note. This compression of levels of abstraction has been carried through so far as to eliminate phrases such as “A description of” in the great majority of cases, leaving it to the reader’s common sense to understand that a definition such as “The delivery requested by the party requesting a transportation service” refers to a description of the act of delivery and not the physical delivery itself, which of course could never literally be part of a document. The only widespread exceptions to this policy are the definitions of ABIEs in the Common Library, which begin “A class to describe...” or sometimes “A class to define...” in order to emphasize their more abstract role. The designers of UBL 2.1 believe that anything lost in technical correctness through this approach will be more than compensated for in improved practical usability.
Schema changes from UBL 2.0 XML to UBL 2.1 XML The following three tables show the differences between the XML elements and attributes in UBL 2.0 (as updated in 2008) and those in UBL 2.1. All changes in 2.1 schemas are backward-compatible with valid UBL 2.0 instances. Changes include the addition of new elements and attributes; changes in cardinality from 1 to 0..1 (i.e., making a formerly required element optional); changes in cardinality from 0..1 to 0..n (i.e., allowing an unlimited number of occurrences instead of just one); and corrections to Dictionary Entry Names (DENs).
Changes to Library Elements, UBL 2.0 to UBL 2.1 The following table sums up the differences between the XML elements in the UBL 2.0 Common Library (as updated in 2008) and those in the UBL 2.1 Common Library. Changes to Library Elements, UBL 2.0 to UBL 2.1 Aggregate BIE Basic or Association BIE Changes for UBL 2.1 ActivityDataLine   Added ActivityProperty   Added Address       LocationCoordinate Changed cardinality from 0..1 to 0..n AllowanceCharge       AllowanceChargeReason Changed cardinality from 0..1 to 0..n   PerUnitAmount Added AppealTerms   Added AuctionTerms   Added AwardingCriterion   Added AwardingCriterionResponse   Added AwardingTerms   Added BudgetAccount   Added BudgetAccountLine   Added Capability   Added CatalogueLine       ReplacedRelatedItem Added   KeywordItemProperty Added   CallForTendersLineReference Added   CallForTendersDocumentReference Added Certificate   Added CertificateOfOriginApplication       Remarks Changed cardinality from 0..1 to 0..n   ExporterParty Added   ImporterParty Added ClassificationScheme       Note Changed cardinality from 0..1 to 0..n Clause   Added CompletedTask   Added Condition   Added Consignment       CarrierAssignedID Added   ConsigneeAssignedID Added   ConsignorAssignedID Added   FreightForwarderAssignedID Added   BrokerAssignedID Added   ContractedCarrierAssignedID Added   PerformingCarrierAssignedID Added   AnimalFoodIndicator Added   HumanFoodIndicator Added   LivestockIndicator Added   BulkCargoIndicator Added   ContainerizedIndicator Added   GeneralCargoIndicator Added   SpecialSecurityIndicator Added   ThirdPartyPayerIndicator Added   CarrierServiceInstructions Added   CustomsClearanceServiceInstructions Added   ForwarderServiceInstructions Added   SpecialServiceInstructions Added   SequenceID Added   ShippingPriorityLevelCode Added   HandlingCode Added   HandlingInstructions Added   Information Added   TotalGoodsItemQuantity Added   TotalTransportHandlingUnitQuantity Added   InsuranceValueAmount Added   DeclaredForCarriageValueAmount Added   DeclaredStatisticsValueAmount Added   FreeOnBoardValueAmount Added   SpecialInstructions Added   SplitConsignmentIndicator Added   DeliveryInstructions Added   ConsignmentQuantity Added   ConsolidatableIndicator Added   HaulageInstructions Added   LoadingSequenceID Added   ChildConsignmentQuantity Added   TotalPackagesQuantity Added   ConsolidatedShipment Added   CustomsDeclaration Added   RequestedPickupTransportEvent Added   RequestedDeliveryTransportEvent Added   PlannedPickupTransportEvent Added   PlannedDeliveryTransportEvent Added   Status Added   ChildConsignment Added   PerformingCarrierParty Added   SubstituteCarrierParty Added   LogisticsOperatorParty Added   TransportAdvisorParty Added   HazardousItemNotificationParty Added   InsuranceParty Added   MortgageHolderParty Added   BillOfLadingHolderParty Added   TransportEvent Added   CollectPaymentTerms Added   DisbursementPaymentTerms Added   PrepaidPaymentTerms Added   ExtraAllowanceCharge Added   MainCarriageShipmentStage Added   PreCarriageShipmentStage Added   OnCarriageShipmentStage Added   TransportHandlingUnit Added   FirstArrivalPortLocation Added   LastExitPortLocation Added Consumption   Added ConsumptionAverage   Added ConsumptionCorrection   Added ConsumptionHistory   Added ConsumptionLine   Added ConsumptionPoint   Added ConsumptionReport   Added ConsumptionReportReference   Added Contact       Note Changed cardinality from 0..1 to 0..n Contract       NominationDate Added   NominationTime Added   Note Added   VersionID Added   Description Added   NominationPeriod Added   ContractualDelivery Added ContractExecutionRequirement   Added ContractExtension   Added ContractingActivity   Added ContractingParty   Added ContractingPartyType   Added CreditNoteLine       Note Changed cardinality from 0..1 to 0..n   PaymentPurposeCode Added   FreeOfChargeIndicator Added   InvoicePeriod Added   OrderLineReference Added   OriginatorParty Added   PaymentTerms Added   AllowanceCharge Added   DeliveryTerms Added   SubCreditNoteLine Added   ItemPriceExtension Added CustomsDeclaration   Added DebitNoteLine       Note Changed cardinality from 0..1 to 0..n   PaymentPurposeCode Added   AllowanceCharge Added   SubDebitNoteLine Added Declaration   Added Delivery       ReleaseID Added   AlternativeDeliveryLocation Added   CarrierParty Added   NotifyParty Added   DeliveryTerms Added   MinimumDeliveryUnit Added   MaximumDeliveryUnit Added   Shipment Added DeliveryTerms       SpecialTerms Changed cardinality from 0..1 to 0..n   LossRisk Changed cardinality from 0..1 to 0..n   Amount Added DependentPriceReference   Added Despatch       GuaranteedDespatchDate Added   GuaranteedDespatchTime Added   ReleaseID Added   Instructions Added   DespatchLocation Added   CarrierParty Added   NotifyParty Added   EstimatedDespatchPeriod Added   RequestedDespatchPeriod Added DespatchLine       Note Changed cardinality from 0..1 to 0..n   BackorderReason Changed cardinality from 0..1 to 0..n   OutstandingReason Changed cardinality from 0..1 to 0..n DocumentReference       IssueTime Added   LanguageID Added   LocaleCode Added   VersionID Added   DocumentStatusCode Added   DocumentDescription Added   ValidityPeriod Added   IssuerParty Added   ResultOfVerification Added DocumentResponse       DocumentReference Changed cardinality from 1 to 1..n Duty   Added EconomicOperatorRole   Added EconomicOperatorShortList   Added EmissionCalculationMethod   Added EnergyTaxReport   Added EnergyWaterSupply   Added EnvironmentalEmission   Added EvaluationCriterion   Added Event   Added EventComment   Added EventLineItem   Added EventTactic   Added EventTacticEnumeration   Added Evidence   Added EvidenceSupplied   Added ExceptionCriteriaLine   Added ExceptionNotificationLine   Added ExternalReference       HashAlgorithmMethod Added   MimeCode Added   FormatCode Added   EncodingCode Added   CharacterSetCode Added   FileName Added   Description Added FinancialAccount       AliasName Added   AccountFormatCode Added FinancialGuarantee   Added ForecastException   Added ForecastExceptionCriterionLine   Added ForecastLine   Added ForecastRevisionLine   Added FrameworkAgreement   Added GoodsItem       ID Changed cardinality from 1 to 0..1   ChargeableQuantity Added   ReturnableQuantity Added   TraceID Added   Delivery Added   Pickup Added   Despatch Added   MeasurementDimension Added   ContainingPackage Added   ShipmentDocumentReference Added   MinimumTemperature Added   MaximumTemperature Added HazardousItem       AdditionalInformation Changed cardinality from 0..1 to 0..n ImmobilizedSecurity   Added InstructionForReturnsLine   Added InventoryReportLine   Added InvoiceLine       Note Changed cardinality from 0..1 to 0..n   PaymentPurposeCode Added   InvoicePeriod Added   WithholdingTaxTotal Added   SubInvoiceLine Added   ItemPriceExtension Added Item       AdditionalInformation Changed cardinality from 0..1 to 0..n   Certificate Added   Dimension Added ItemComparison       PriceAmount Changed dictionary entry name from “Item Comparison. Price. Amount” to “Item Comparison. Price Amount. Amount” ItemIdentification       BarcodeSymbologyID Added ItemInformationRequestLine   Added ItemInstance       BestBeforeDate Added ItemLocationQuantity       Package Added   AllowanceCharge Added   DependentPriceReference Added ItemManagementProfile   Added ItemProperty       ID Added   NameCode Added   TestMethod Added   Value Changed cardinality from 1 to 0..1   ValueQuantity Added   ValueQualifier Added   ImportanceCode Added   ListValue Added   RangeDimension Added   ItemPropertyRange Added ItemPropertyGroup       ImportanceCode Added ItemPropertyRange   Added LineItem       Note Changed cardinality from 0..1 to 0..n   WarrantyInformation Added   SubLineItem Added   WarrantyValidityPeriod Added   WarrantyParty Added   TaxTotal Added   ItemPriceExtension Added   LineReference Added Location       Description Changed cardinality from 0..1 to 0..n   Conditions Changed cardinality from 0..1 to 0..n   LocationTypeCode Added   InformationURI Added   Name Added   SubsidiaryLocation Added   LocationCoordinate Added LocationCoordinate       AltitudeMeasure Added MaritimeTransport       RadioCallSignID Added   ShipsRequirements Added   GrossTonnageMeasure Added   NetTonnageMeasure Added   RegistryCertificateDocumentReference Added   RegistryPortLocation Added Meter   Added MeterProperty   Added MeterReading   Added MiscellaneousEvent   Added MonetaryTotal       AllowanceTotalAmount Changed dictionary entry name from “Monetary Total. Allowance Total Amount. Amount” to “Monetary Total. Allowance_ Total Amount. Amount”   ChargeTotalAmount Changed dictionary entry name from “Monetary Total. Charge Total Amount. Amount” to “Monetary Total. Charge_ Total Amount. Amount”   PayableAlternativeAmount Added NotificationRequirement   Added OnAccountPayment   Added OrderLine       Note Changed cardinality from 0..1 to 0..n   OrderLineReference Added OrderReference       SalesOrderID Changed dictionary entry name from “Order Reference. Sales Order Identifier. Identifier” to “Order Reference. Sales_ Order Identifier. Identifier”   OrderTypeCode Added Package       TraceID Added   ContainingTransportEquipment Added   Delivery Added   Pickup Added   Despatch Added Party       IndustryClassificationCode Added   Person Changed cardinality from 0..1 to 0..n   ServiceProviderParty Added   PowerOfAttorney Added   FinancialAccount Added PartyLegalEntity       RegistrationDate Added   RegistrationExpirationDate Added   CompanyLegalFormCode Added   CompanyLegalForm Added   SoleProprietorshipIndicator Added   CompanyLiquidationStatusCode Added   CorporateStockAmount Added   FullyPaidSharesIndicator Added   HeadOfficeParty Added   ShareholderParty Added PartyTaxScheme       ExemptionReason Changed cardinality from 0..1 to 0..n PaymentMandate   Added PaymentMeans       PaymentMandate Added   TradeFinancing Added PaymentTerms       PaymentMeansID Changed cardinality from 0..1 to 0..n   PaymentPercent Added   SettlementDiscountAmount Added   PenaltyAmount Added   PaymentTermsDetailsURI Added   PaymentDueDate Added   InstallmentDueDate Added   InvoicingPartyReference Added   ExchangeRate Added   ValidityPeriod Added PerformanceDataLine   Added Person       ID Added   OtherName Added   NationalityID Added   GenderCode Added   BirthDate Added   BirthplaceName Added   Contact Added   FinancialAccount Added   IdentityDocumentReference Added   ResidenceAddress Added Pickup   Added PowerOfAttorney   Added Price       PricingExchangeRate Added PriceExtension   Added ProcessJustification   Added ProcurementProject   Added ProcurementProjectLot   Added ProjectReference   Added PromotionalEvent   Added PromotionalEventLineItem   Added PromotionalSpecification   Added QualificationResolution   Added QualifyingParty   Added QuotationLine       Note Changed cardinality from 0..1 to 0..n   RequestForQuotationLineID Added   AlternativeLineItem Added   RequestLineReference Added ReceiptLine       Note Changed cardinality from 0..1 to 0..n   RejectReason Changed cardinality from 0..1 to 0..n   QuantityDiscrepancyCode Added   OversupplyQuantity Changed dictionary entry name from “Receipt Line. Oversupply Quantity. Quantity” to “Receipt Line. Oversupply_ Quantity. Quantity” Regulation   Added ReminderLine       Note Changed cardinality from 0..1 to 0..n   PenaltySurchargePercent Added   Amount Added   PaymentPurposeCode Added RemittanceAdviceLine       Note Changed cardinality from 0..1 to 0..n   PaymentPurposeCode Added   InvoicingPartyReference Added Renewal   Added RequestForQuotationLine       Note Changed cardinality from 0..1 to 0..n   OptionalLineItemIndicator Added   PrivacyCode Added   SecurityClassificationCode Added RequestForTenderLine   Added RequestedTenderTotal   Added Response       ReferenceID Changed cardinality from 1 to 0..1   EffectiveDate Added   EffectiveTime Added   Status Added ResultOfVerification   Added RetailPlannedImpact   Added SalesItem   Added SecondaryHazard       Extension Changed cardinality from 0..1 to 0..n ServiceFrequency   Added ServiceProviderParty   Added ShareholderParty   Added Shipment       HandlingInstructions Changed cardinality from 0..1 to 0..n   Information Changed cardinality from 0..1 to 0..n   ConsignmentQuantity Added   Consignment Changed cardinality from 1 to 0..n   ReturnAddress Added ShipmentStage       PreCarriageIndicator Changed cardinality from 1 to 0..1   OnCarriageIndicator Changed cardinality from 1 to 0..1   EstimatedDeliveryDate Added   EstimatedDeliveryTime Added   RequiredDeliveryDate Added   RequiredDeliveryTime Added   LoadingSequenceID Added   SuccessiveSequenceID Added   Instructions Added   DemurrageInstructions Added   CrewQuantity Added   PassengerQuantity Added   LoadingTransportEvent Added   ExaminationTransportEvent Added   AvailabilityTransportEvent Added   ExportationTransportEvent Added   DischargeTransportEvent Added   WarehousingTransportEvent Added   TakeoverTransportEvent Added   OptionalTakeoverTransportEvent Added   DropoffTransportEvent Added   ActualPickupTransportEvent Added   DeliveryTransportEvent Added   ReceiptTransportEvent Added   StorageTransportEvent Added   AcceptanceTransportEvent Added   TerminalOperatorParty Added   CustomsAgentParty Added   EstimatedTransitPeriod Added   FreightAllowanceCharge Added   FreightChargeLocation Added   DetentionTransportEvent Added   RequestedDepartureTransportEvent Added   RequestedArrivalTransportEvent Added   RequestedWaypointTransportEvent Added   PlannedDepartureTransportEvent Added   PlannedArrivalTransportEvent Added   PlannedWaypointTransportEvent Added   ActualDepartureTransportEvent Added   ActualWaypointTransportEvent Added   ActualArrivalTransportEvent Added   TransportEvent Added   EstimatedDepartureTransportEvent Added   EstimatedArrivalTransportEvent Added   PassengerPerson Added   DriverPerson Added   ReportingPerson Added   CrewMemberPerson Added   SecurityOfficerPerson Added   MasterPerson Added   ShipsSurgeonPerson Added Signature       Note Changed cardinality from 0..1 to 0..n   ValidatorID Changed dictionary entry name from “Signature. Validator Identifier. Identifier” to “Signature. Validator. Identifier”   SignatoryParty Changed cardinality from 1 to 0..1 StatementLine       Note Changed cardinality from 0..1 to 0..n   PaymentPurposeCode Added   AllowanceCharge Added   CollectedPayment Added Status       ReferenceDate Changed dictionary entry name from “Status. Reference_ Date. Date” to “Status. Reference Date. Date”   ReferenceTime Changed dictionary entry name from “Status. Reference_ Time. Time” to “Status. Reference Time. Time”   Description Changed cardinality from 0..1 to 0..n   StatusReason Changed cardinality from 0..1 to 0..n   SequenceID Changed dictionary entry name from “Status. Sequence. Identifier” to “Status. Sequence Identifier. Identifier”   Text Changed cardinality from 0..1 to 0..n   ReliabilityPercent Added   Condition Added StockAvailabilityReportLine   Added SubcontractTerms   Added SubscriberConsumption   Added SupplierConsumption   Added TaxCategory       TaxExemptionReason Changed cardinality from 0..1 to 0..n TaxTotal       TaxIncludedIndicator Added TelecommunicationsService   Added TelecommunicationsSupply   Added TelecommunicationsSupplyLine   Added TenderLine   Added TenderPreparation   Added TenderRequirement   Added TenderResult   Added TenderedProject   Added TendererPartyQualification   Added TendererQualificationRequest   Added TendererRequirement   Added TenderingProcess   Added TenderingTerms   Added TradeFinancing   Added TransportEquipment       ReferencedConsignmentID Added   Information Changed cardinality from 0..1 to 0..n   AirFlowPercent Added   HumidityPercent Added   AnimalFoodApprovedIndicator Added   HumanFoodApprovedIndicator Added   DangerousGoodsApprovedIndicator Added   RefrigeratedIndicator Added   Characteristics Added   DamageRemarks Added   Description Added   SpecialTransportRequirements Added   GrossWeightMeasure Added   GrossVolumeMeasure Added   TareWeightMeasure Added   TrackingDeviceCode Added   PowerIndicator Added   TraceID Added   SupplierParty Added   OwnerParty Added   OperatingParty Added   UnloadingLocation Added   StorageLocation Added   PositioningTransportEvent Added   QuarantineTransportEvent Added   DeliveryTransportEvent Added   PickupTransportEvent Added   HandlingTransportEvent Added   LoadingTransportEvent Added   TransportEvent Added   ApplicableTransportMeans Added   HaulageTradingTerms Added   HazardousGoodsTransit Added   PackagedTransportHandlingUnit Added   ServiceAllowanceCharge Added   FreightAllowanceCharge Added   AttachedTransportEquipment Added   Delivery Added   Pickup Added   Despatch Added   ShipmentDocumentReference Added   ContainedInTransportEquipment Added   Package Added   GoodsItem Added TransportEvent       Description Changed cardinality from 0..1 to 0..n   CurrentStatus Changed cardinality from 1..n to 0..n   Location Added   Signature Added   Period Added TransportExecutionTerms   Added TransportHandlingUnit       HandlingInstructions Changed cardinality from 0..1 to 0..n   TraceID Added   TransportMeans Added   GoodsItem Added   FloorSpaceMeasurementDimension Added   PalletSpaceMeasurementDimension Added   ShipmentDocumentReference Added   Status Added   CustomsDeclaration Added   ReferencedShipment Added   Package Added TransportMeans       TransportMeansTypeCode Added   TradeServiceCode Added   MeasurementDimension Added TransportSchedule   Added TransportationSegment   Added TransportationService       TransportationServiceDescription Added   TransportationServiceDetailsURI Added   NominationDate Added   NominationTime Added   Name Added   SequenceNumeric Added   TransportEquipment Added   SupportedTransportEquipment Added   UnsupportedTransportEquipment Added   CommodityClassification Added   SupportedCommodityClassification Added   UnsupportedCommodityClassification Added   TotalCapacityDimension Added   ShipmentStage Added   TransportEvent Added   ResponsibleTransportServiceProviderParty Added   EnvironmentalEmission Added   EstimatedDurationPeriod Added   ScheduledServiceFrequency Added UnstructuredPrice   Added UtilityItem   Added WebSiteAccess   Added WinningParty   Added WorkPhaseReference   Added
Changes to Document Elements, UBL 2.0 to UBL 2.1 The following table sums up the differences between the XML elements in the UBL 2.0 document schemas (as updated in 2008) and those in the UBL 2.1 document schemas. Changes to Document Elements, UBL 2.0 to UBL 2.1 Aggregate BIE Basic or Association BIE Changes for UBL 2.1 ApplicationResponse       ProfileExecutionID Added   VersionID Changed dictionary entry name from “Application Response. Version Identifier. Identifier” to “Application Response. Version. Identifier”   DocumentResponse Changed cardinality from 1..n to 0..n AttachedDocument       ProfileExecutionID Added   ParentDocumentVersionID Added   ParentDocumentLineReference Added AwardedNotification   Added BillOfLading       ProfileExecutionID Added CallForTenders   Added Catalogue       ProfileExecutionID Added   ActionCode Added   SourceCatalogueReference Added   DocumentReference Added CatalogueDeletion       ProfileExecutionID Added   EffectiveDate Added   EffectiveTime Added CatalogueItemSpecificationUpdate       ProfileExecutionID Added CataloguePricingUpdate       ProfileExecutionID Added CatalogueRequest       ProfileExecutionID Added   Signature Added CertificateOfOrigin       ProfileExecutionID Added   VersionID Changed dictionary entry name from “Certificate Of Origin. Version Identifier. Identifier” to “Certificate Of Origin. Version. Identifier”   Signature Added ContractAwardNotice   Added ContractNotice   Added CreditNote       ProfileExecutionID Added   CreditNoteTypeCode Added   BuyerReference Added   StatementDocumentReference Added   OriginatorDocumentReference Added   BuyerCustomerParty Added   SellerSupplierParty Added   Delivery Added   DeliveryTerms Added   PaymentMeans Added   PaymentTerms Added DebitNote       ProfileExecutionID Added   StatementDocumentReference Added   BuyerCustomerParty Added   SellerSupplierParty Added   AllowanceCharge Added   Delivery Added   DeliveryTerms Added   PaymentMeans Added   PaymentTerms Added DespatchAdvice       ProfileExecutionID Added DocumentStatus   Added DocumentStatusRequest   Added ExceptionCriteria   Added ExceptionNotification   Added Forecast   Added ForecastRevision   Added ForwardingInstructions       ProfileExecutionID Added FreightInvoice       ProfileExecutionID Added   Shipment Changed cardinality from 1 to 1..n FulfilmentCancellation   Added GoodsItemItinerary   Added GuaranteeCertificate   Added InstructionForReturns   Added InventoryReport   Added Invoice       ProfileExecutionID Added   DueDate Added   BuyerReference Added   StatementDocumentReference Added   ProjectReference Added   WithholdingTaxTotal Added ItemInformationRequest   Added Order       ProfileExecutionID Added   SalesOrderID Changed dictionary entry name from “Order. Sales Order Identifier. Identifier” to “Order. Sales_ Order Identifier. Identifier”   OrderTypeCode Added   CustomerReference Changed dictionary entry name from “Order. Customer Reference. Text” to “Order. Customer_ Reference. Text”   CatalogueReference Added   ProjectReference Added   DeliveryTerms Changed cardinality from 0..1 to 0..n   PaymentMeans Changed cardinality from 0..1 to 0..n   PaymentTerms Added   TaxExchangeRate Added   PricingExchangeRate Added   PaymentExchangeRate Added OrderCancellation       ProfileExecutionID Added   CancellationNote Changed cardinality from 1 to 1..n OrderChange       ProfileExecutionID Added   SalesOrderID Changed dictionary entry name from “Order Change. Sales Order Identifier. Identifier” to “Order Change. Sales_ Order Identifier. Identifier”   SequenceNumberID Changed dictionary entry name from “Order Change. Sequence_ Number. Identifier” to “Order Change. Sequence Number. Identifier”   CustomerReference Changed dictionary entry name from “Order Change. Customer Reference. Text” to “Order Change. Customer_ Reference. Text”   PaymentMeans Changed cardinality from 0..1 to 0..n   PaymentTerms Added   TaxExchangeRate Added   PricingExchangeRate Added   PaymentExchangeRate Added OrderResponse       ProfileExecutionID Added   SalesOrderID Changed dictionary entry name from “Order Response. Sales Order Identifier. Identifier” to “Order Response. Sales_ Order Identifier. Identifier”   OrderResponseCode Added   CustomerReference Changed dictionary entry name from “Order Response. Customer Reference. Text” to “Order Response. Customer_ Reference. Text”   PaymentMeans Changed cardinality from 0..1 to 0..n   PaymentTerms Added   TaxExchangeRate Added   PricingExchangeRate Added   PaymentExchangeRate Added   OrderLine Changed cardinality from 1..n to 0..n OrderResponseSimple       ProfileExecutionID Added   RejectionNote Changed cardinality from 0..1 to 0..n PackingList       ProfileExecutionID Added   Description Changed cardinality from 0..1 to 0..n   VersionID Changed dictionary entry name from “Packing List. Version Identifier. Identifier” to “Packing List. Version. Identifier” PriorInformationNotice   Added ProductActivity   Added Quotation       ProfileExecutionID Added   BuyerCustomerParty Added ReceiptAdvice       ProfileExecutionID Added   ReceiptAdviceTypeCode Added Reminder       ProfileExecutionID Added RemittanceAdvice       ProfileExecutionID Added RequestForQuotation       ProfileExecutionID Added   SubmissionDueDate Added   RequestedValidityPeriod Added   BuyerCustomerParty Added RetailEvent   Added SelfBilledCreditNote       ProfileExecutionID Added   PaymentCurrencyCode Added   PaymentAlternativeCurrencyCode Added   StatementDocumentReference Added   OriginatorDocumentReference Added   BuyerCustomerParty Added   SellerSupplierParty Added   Delivery Added   DeliveryTerms Added   PaymentMeans Added   PaymentTerms Added   PaymentExchangeRate Added   PaymentAlternativeExchangeRate Added SelfBilledInvoice       ProfileExecutionID Added Statement       ProfileExecutionID Added   StatementTypeCode Added   PaymentMeans Changed cardinality from 0..1 to 0..n StockAvailabilityReport   Added Tender   Added TenderReceipt   Added TendererQualification   Added TendererQualificationResponse   Added TradeItemLocationProfile   Added TransportExecutionPlan   Added TransportExecutionPlanRequest   Added TransportProgressStatus   Added TransportProgressStatusRequest   Added TransportServiceDescription   Added TransportServiceDescriptionRequest   Added TransportationStatus       ProfileExecutionID Added   TransportationStatusTypeCode Added   TransportExecutionStatusCode Added   Consignment Changed cardinality from 1 to 0..n   TransportEvent Changed cardinality from 1..n to 0..n   SenderParty Added   ReceiverParty Added   TransportationStatusRequestDocumentReference Added   TransportExecutionPlanDocumentReference Added   UpdatedPickupTransportEvent Added   UpdatedDeliveryTransportEvent Added   StatusLocation Added   StatusPeriod Added TransportationStatusRequest   Added UnawardedNotification   Added UtilityStatement   Added Waybill       ProfileExecutionID Added
Changes to Attributes, UBL 2.0 to UBL 2.1 The following table lists all the attributes added since the release of UBL 2.0 (as updated in 2008). Changes to Attributes, UBL 2.0 to UBL 2.1 Type Attribute Changes for UBL 2.1 Amount       CurrencyCodeListVersionID Added Measure       UnitCodeListVersionID Added Numeric       format Added Percent       format Added Rate       format Added Quantity       UnitCodeListID Added   UnitCodeListAgencyID Added   UnitCodeListAgencyName Added Text       languageLocalID Added Name       languageLocalID Added
The UBL 2.1 Data Model Following the principles of the ebXML Core Components Technical Specification , the UBL data model is based on a library of reusable information items known as Business Information Entities (BIEs). Each business document defined by UBL is created by assembling items appropriate to that document type from the UBL BIE library. Further detail regarding BIEs is provided in .
UBL 2.1 Schema Generation Historically, both the UBL common library of reusable components and the assembly models for the individual UBL documents have been published as spreadsheets using a format specifically developed for UBL business information modeling (this format is discussed further below). Each spreadsheet is provided in both Open Document and Microsoft Excel formats; in the UBL 2.1 release, the spreadsheets for the common library will be found in mod/common, and spreadsheets for the individual documents will be found in mod/maindoc. In UBL 2.1, the data model is instantiated and maintained in iSurf eDoCreator, a project of the European Commission, and spreadsheets using the format that has become standard for UBL development are generated from the eDoCreator database. UBL 2.1 schemas are, in turn, generated from these spreadsheets using a set of XSLT scripts created and maintained by the UBL Schema Generation Task Group. Quality assurance for these schemas is aided by a comparison with schemas independently generated by eDoCreator from the same database used to generate the spreadsheets. This approach continues the role of the UBL spreadsheets in providing human-readable documentation of the UBL data model as well as publishing the supplementary metadata required by . By preserving a vendor-neutral representation from which schemas can be generated directly, the spreadsheets guarantee that the UBL model semantics are not bound to a single production system. The following diagram shows the conceptual relationships between data models and schemas in UBL 2.1, with data models on the left and schemas on the right. Compare .
UBL Data Model Realization [spreadsheet realization diagram]
The UBL Common Library As noted above, UBL is based on a reusable library of Business Information Entities. In the current release, the Common Library contains more than two thousand of these individually defined data items. The entire UBL 2.1 library of Business Information Entities is contained in a single spreadsheet, provided here like all the spreadsheets in two different formats.
mod/common/UBL-CommonLibrary-2.1.ods mod/common/UBL-CommonLibrary-2.1.xls
Business Information Entities In the language of , UBL Business Information Items (BIEs) include BBIEs (“basic” individual pieces of information), ABIEs (aggregations of other BIEs), and ASBIEs (“associations” to ABIEs). Fuller explanations of these terms in the context of the CCTS framework will be found in the CCTS specification. For purposes of understanding UBL as a set of XML schemas, however, it may be useful to describe these terms employing concepts more familiar to XML users. With the understanding that every XML document describes a logical tree of elements, the different kinds of Business Information Entities from which UBL documents are constructed may be described as follows: UBL BBIEs (Basic Business Information Entities) are the leaf nodes of every UBL document structure. These are ordinary data fields such as one would expect to find in any business form, and they are realized in the schemas as individual XML elements at the bottom level of the document tree with simple content representing amounts, codes, quantities, and so on. All UBL BBIE elements (and only UBL BBIE elements) are members of the UBL common basic components namespace, conventionally denoted in UBL schemas by the cbc: prefix. (Since all namespace prefixes in XML are assigned on a per-instance basis according to namespace declarations in the individual instance, prefixes such as cbc: may be replaced with arbitrarily different namespace prefixes in actual UBL documents.) UBL ASBIEs (Association Business Information Entities) are substructures of a UBL document. Children of ASBIEs may be BBIEs or other ASBIEs, never ABIEs. All UBL ASBIEs (and only UBL ASBIEs) are members as elements of the UBL common aggregate components namespace, denoted in UBL schemas by the cac: prefix. UBL document ABIEs (Aggregate Business Information Entities) are the root nodes and top-level structures of UBL documents. Children of document ABIEs may be BBIEs or ASBIEs, never ABIEs. All UBL document ABIEs (and only UBL document ABIEs) are defined within individual namespaces specific to each document as both elements and types. UBL library ABIEs (that is, all ABIEs except document ABIEs) have a structural shape but are not concrete document structures; rather, they are abstract structures or templates for ASBIEs, thus allowing the same structure to be reused in multiple roles. Children of library ABIEs in the data structure can be BBIEs or ASBIEs, never ABIEs. All library ABIEs must be realized as ASBIEs in order to actually exist as elements in the UBL document tree. All UBL library ABIEs (and only UBL library ABIEs) are realized as types in the UBL cac: namespace. This naming scheme inherited from CCTS may prove problematic for some UBL users. In particular, the CCTS terms “Association Business Information Entity” and “Aggregate Business Information Entity” do not well describe these two concepts as they are realized in XML. The problem word here is “association”, which correctly describes this relationship within a UML (Unified Modeling Language) framework but is perhaps better thought of in the UBL context as meaning that a particular ASBIE is “associated with” an abstract ABIE structure. For our purposes, it would have been better if ASBIEs had instead been called “Aggregate Business Information Entities” and ABIEs had instead been called “Structural Templates”. It may prove easiest for the UBL user to regard the terms ASBIE and ABIE as opaque labels and to ignore the historical expansions of these acronyms. It can be seen from the above that the XML implementations of ASBIEs and library ABIEs share the same cac: namespace. In the schemas, library ABIEs are all implemented as XML types, and ASBIEs are all implemented as XML elements. This is simply a reflection of their different roles—library ABIEs as abstract classes or structural templates (realized as XML types) and ASBIEs as concrete instantiations (realized as XML elements derived from those types). While the distinction between ABIEs/classes/types on the one hand and ASBIEs/instantiations/elements on the other is clear enough, it should be noted that in some cases an ASBIE does not qualify the name of the ABIE from which it is derived. In effect, they have the same name. Some library ABIEs are used only in the form of an ASBIE having the same name; for example, AddressLine is a library ABIE that is only used in the form of an ASBIE named AddressLine. Some library ABIEs are realized in some places as ASBIEs with the same name (where it is felt that the unqualified name is sufficient) and elsewhere as ASBIEs with a name that is further qualified; for example, the library ABIE Address has numerous ASBIE realizations with qualified names like LocationAddress, ApplicableAddress, DespatchAddress, and so on, but it’s also seen as an ASBIE simply named Address that’s included in the library ABIEs FinancialInstitution, Branch, Location, and ConsumptionPoint. Some library ABIEs are never actually implemented as ASBIEs with the same name; for example, only one ASBIE is associated with the library ABIE ActivityDataLine, and it has the qualified name SupplyChainActivityDataLine. The UBL Common Aggregate Component schema declares an identically named element or potential ASBIE for every library ABIE regardless of whether that element is used in a UBL document schema to represent an ASBIE (these are among the long list of global element declarations at the beginning of the CAC module). ABIEs are implemented as one or more ASBIEs via XSD references to these elements farther down in the CAC schema module or in individual document schema modules, which all import the CAC module. For example, the global element AddressLine declared in the CAC with the line ]]> is implemented as an ASBIE with the same name in the declaration of the Address ABIE as follows: [...] ]]> One consequence of this approach is that the list of global elements that begins the CAC module contains elements that are in fact never used under those names in UBL 2.1. For example, the element ActivityDataLine mentioned above is used by reference in creating the ASBIE SupplyChainActivityDataLine, but it never appears in the form of an ASBIE named ActivityDataLine. Such unused ABIE names remain available in the global element declarations for customizers and designers of future additions to UBL.
Navigating the UBL 2.1 Data Model Spreadsheets The concepts described above can be illustrated by navigating the UBL data models to construct a trivial UBL Invoice instance. We will start with a wrapper copied from an example in the xml directory of the UBL 2.1 distribution (xml/UBL-Invoice-2.1-Example.xml): [...] ]]> Now we will fill out this shell of an instance, completing the part in the brackets by traversing the data model. Like all the document models defined by UBL, the Invoice model is expressed as a spreadsheet. UBL provides both .ods and .xls versions:
mod/maindoc/UBL-Invoice-2.1.ods mod/maindoc/UBL-Invoice-2.1.xls
An HTML rendition of the spreadsheet contents also is provided:
mod/summary/reports/UBL-Invoice-2.1.html
Note that the spreadsheets corresponding to each UBL 2.1 document type are linked from the description of that type in . Line 2 of the spreadsheet (either version) defines the document ABIE named Invoice. Column P confirms that Invoice is an ABIE, as also indicated by the pink background in that row of the spreadsheet. Everything after Invoice in the spreadsheet ends up as part of the schema, and the order seen here is the order in which these components will appear in both the schema and any conforming instances of Invoice. The BBIE children of Invoice are given first (white background), and then all the ASBIE children of Invoice (green background). As shown in Column O, most of these components are optional. The first required field is ID (line 7) and the second is IssueDate (line 10), so we can write, for example, 123 2011-09-22 ]]> Next let’s add an optional InvoicePeriod (line 25). This is an ASBIE, implying that it has some kind of substructure, and it derives from the generic ABIE called Period (this is the “Associated Object Class” referred to in Column M). To find this structure, we look for the Period library ABIE in one of the Common Library model spreadsheets
mod/common/UBL-CommonLibrary-2.1.ods or mod/common/UBL-CommonLibrary-2.1.xls
Period will be found at line 1418 and seen to contain seven 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 2.1) need not contain any of the seven optional BBIE elements specified at lines 1419–1425, and indeed the corresponding declaration of the complex type PeriodType in the CAC schema (xsd/common/UBL-CommonAggregateComponents-2.1.xsd) shows that an empty InvoicePeriod element will pass XML validation; but UBL explicitly prohibits such structures (see ). In UBL, as a normative rule independent of schema constraints, every ASBIE must have at least one child (BBIE or ASBIE) instantiated. In this case, therefore, one or more of the seven possible BBIE children of InvoicePeriod will need to appear in a UBL Invoice document for it to be conformant UBL in addition to the requirement that the document validate against the Invoice schema. If StartDate and EndDate (for example) are chosen for the content of InvoicePeriod, the corresponding section of the sample instance might then look like this: 2011-08-01 2011-08-31 ]]> Next in order in the Invoice come two required pieces, the ASBIEs AccountingSupplierParty and AccountingCustomerParty. As shown in Column M of the Invoice spreadsheet, AccountingSupplierParty (line 36) derives from the SupplierParty ABIE and AccountingCustomerParty (line 37) derives from the CustomerParty ABIE. Checking in the Common Library, it is seen that both SupplierParty (line 1899 of the Common Library spreadsheet) and CustomerParty (line 552 of the Common Library spreadsheet) can contain an ASBIE named Party (as shown in lines 1903 and 556, respectively) and that each Party ASBIE is an instantiation of the Party ABIE (line 1312). Therefore both parties have the same structure (lines 1313 through 1331). 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 1320) that derives (Column M) from the ABIE PartyName (line 1349), which is a wrapper for the BBIE Name (line 1350). A conforming piece of the document instance might therefore look like this: Custom Cotter Pins North American Veeblefetzer ]]> Returning to the Invoice model, it is seen that the Invoice must close with a LegalMonetaryTotal (line 54) and at least one InvoiceLine (line 55). Taking LegalMonetaryTotal first, it is found in the Common Library to be derived from MonetaryTotal (line 1245), which has a mandatory PayableAmount BBIE. A corresponding example instance fragment might be therefore be constructed as follows: 100.00 ]]> If the preceding explanation of Party is understood, there should be nothing problematic about the process of forming the example LegalMonetaryTotal element shown above except the currencyID attribute on PayableAmount, which does not appear explicitly in the model line for that BBIE (line 1253). 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 (Column K) 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 supplementary “CCT Components” called “Amount. Currency. Identifier” and “Currency. Code List Version. Identifier”. In the XML realization of CCTS, supplementary components are expressed as attributes, and the CCTS names “Amount. Currency. Identifier”and “Currency. Code List Version. Identifier” are transformed into the XML attribute names currencyID and currencyCodeListVersionID, respectively. All of these CCTS-based types and attributes are declared in the CCTS Core Component Type schema module:
xsd/common/CCTS_CCT_SchemaModule-2.1.xsd
Note that this schema module comes from UN/CEFACT, not UBL; that it does not implement all of the supplementary components of core component types defined by ; and that all of the attributes it does declare are defined as optional. In UBL, however, the attributes currencyID and mimeCode are required, not optional. In order to impose its own restrictions, therefore, and also to supply a full set of supplementary component attributes, UBL provides an Unqualified Data Types module that imports the CCTS module and then overrides those definitions as needed:
xsd/common/UBL-UnqualifiedDataTypes-2.1.xsd
Further information about UBL data types can be found in . Note in particular , which includes a list of all the attributes associated with UBL unqualified data types. A reverse lookup of the implied occurrence of each attribute in the data models is provided in this summary report:
mod/summary/reports/UBL-AllDocuments-2.1.html#UDT
In the example fragment above, currencyID has been used to label the amount in Canadian dollars (CAD). As explained in , the value CAD for this attribute is not specified in schemas to be checked using XSD validation but will instead be found in separate OASIS genericode code list files in the gc directory of the UBL 2.1 distribution, which are engaged through a separate XSLT-based process. Using the same methodology, a sample InvoiceLine can be constructed to complete the example as follows: 1 100.00 Cotter pin, MIL-SPEC ]]> The finished example can be found in
xml/UBL-Invoice-2.1-Example-Trivial.xml
Summary Reports While the document model spreadsheets described above function as a basic form of documentation, an alternative form of documentation that will be found useful in many contexts is provided by HTML reports contributed by Crane Softwrights Ltd. and included here by permission in the mod/summary/reports directory. The summary report for each UBL 2.1 document type is linked from the description of that type in . Each document report summarizes business object definitions and selected columns of the corresponding spreadsheet in a hyperlinked form that omits unused elements to facilitate rapid review of each document model. There is also a single master report incorporating every document type and the entire common library:
mod/summary/reports/UBL-AllDocuments-2.1.html
For notes on the use of these reports, and links to abbreviated reports for each of the individual UBL document types, see
mod/summary/readme-Reports.html
Business Information Entity Documentation The mod directory also contains a complete list of all the UBL 2.1 business information entities (BBIEs, ABIEs, and ASBIEs) in genericode format and an HTML file displaying information about the re-use of ABIEs and ASBIEs in table form.
mod/UBL-Entities-2.1.gc mod/UBL-Signature-Entities-2.1.gc mod/UBL-ABIE-Reuse-Table-2.1.html
UML-Based View of the UBL Data Model For users familiar with the Unified Modeling Language, a graphical view of the data model of the UBL 2.1 document ABIEs as a set of UML classes is provided in this package.
uml/index.htm
See for information regarding UML diagrams for other UBL 2.1 BIEs.
Data Type Qualifications in UBL All UBL data types ultimately derive either from the UN/CEFACT Core Components Technical Specification Core Component Types (CCT) or from the W3C Schema specification itself; this derivation takes place in the UBL UDT module. The following table lists the CCTS 2.01 Core Component Types. CCTS Unqualified Data Types CCTS Data Type Definition Amount. Type A number of monetary units specified in a currency where the unit of currency is explicit or implied. Binary Object. Type A set of finite-length sequences of binary octets. Code. Type A character string (letters, figures or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an Attribute together with relevant supplementary information. Date Time. Type A particular point in the progression of time together with relevant supplementary information. Identifier. Type A character string to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects in the same scheme together with relevant supplementary information. Indicator. Type A list of two mutually exclusive Boolean values that express the only possible states of a Property. Measure. Type A numeric value determined by measuring an object along with the specified unit of measure. Numeric. Type Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure. Quantity. Type A counted number of non-monetary units possibly including fractions. Text. Type A character string (i.e. a finite set of characters) generally in the form of words of a language.
The UBL unqualified data types include the CCTS unqualified data types (named according to the UBL Naming and Design Rules) and a few others, as listed in the following table. Some of these (GraphicType, PictureType, SoundType, VideoType, and ValueType) are defined for completeness but not actually used in UBL 2.1. The rightmost column of this table lists the UBL XML attributes that implement the CCTS supplementary components associated with each CCTS data type. It is important to be aware of these attributes, because they do not appear directly in the UBL data models but are logically implied by data type inheritance and do appear in the UBL XML schemas in accordance with the UBL Naming and Design Rules. As indicated here, a few of the most significant of these supplementary CCTS components become required XML attributes in UBL and will be required in any instance of an element derived from the corresponding type. See for an example of UBL attributes and a further discussion of this point. A reverse lookup of the implied occurrence of each attribute in the data models is provided in this summary report:
mod/summary/reports/UBL-AllDocuments-2.1.html#UDT
UBL Unqualified Data Types UBL Unqualified Data Type Definition Attributes AmountType A number of monetary units specified using a given unit of currency. currencyID (required) currencyCodeListVersionID BinaryObjectType A set of finite-length sequences of binary octets. format mimeCode (required) encodingCode characterSetCode uri filename GraphicType A diagram, graph, mathematical curve, or similar representation. not used in UBL 2.1 PictureType A diagram, graph, mathematical curve, or similar representation. not used in UBL 2.1 SoundType An audio representation. not used in UBL 2.1 VideoType A video representation. not used in UBL 2.1 CodeType A character string (letters, figures, or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute, together with relevant supplementary information. listID listAgencyID listAgencyName listName listVersionID name languageID listURI listSchemeURI DateTimeType A particular point in the progression of time, together with relevant supplementary information. format (not used in UBL 2.1) DateType One calendar day according the Gregorian calendar. TimeType An instance of time that occurs every day. IdentifierType A character string to identify and uniquely distinguish one instance of an object in an identification scheme from all other objects in the same scheme, together with relevant supplementary information. schemeID schemeName schemeAgencyID schemeAgencyName schemeVersionID schemeDataURI schemeURI IndicatorType A list of two mutually exclusive Boolean values that express the only possible states of a property. format MeasureType A numeric value determined by measuring an object using a specified unit of measure. unitCode (required) unitCodeListVersionID NumericType Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure. format ValueType Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure. not used in UBL 2.1 PercentType Numeric information that is assigned or is determined by calculation, counting, or sequencing and is expressed as a percentage. It does not require a unit of quantity or unit of measure. format RateType A numeric expression of a rate that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure. format QuantityType A counted number of non-monetary units, possibly including a fractional part. unitCode unitCodeListID unitCodeListAgencyID unitCodeListAgencyName TextType A character string (i.e. a finite set of characters), generally in the form of words of a language. languageID languageLocaleID NameType A character string that constitutes the distinctive designation of a person, place, thing, or concept. languageID languageLocaleID
Some UBL BBIEs have data type qualifications based on the unqualified UBL types. These qualified types are all code types, and their definitions are the mechanism whereby a specific set of values is associated with each code. UBL data type qualifications are expressed formally in an OASIS (Context/Value Association) file contained in the cva directory of the 2.1 distribution.
cva/UBL-DefaultDTQ-2.1.cva
The specification of the CVA mechanism and format is maintained by the OASIS Code List Representation Technical Committee. A human-readable version is provided in an accompanying HTML file, which also serves as primary documentation on the UBL codes defined as qualified data types.
cva/UBL-DefaultDTQ-2.1.html
The val directory contains the predefined CVA associations compiled into an XSLT file, UBL-DefaultDTQ-2.1.xsl, which is used in the recommended two-phase validation process to perform a check of code list values. See for a description of this process.
val/UBL-DefaultDTQ-2.1.xsl
The UBL 2.1 approach to data type qualification is illustrated in the following diagram.
Data Type Qualification in UBL 2.1 [Data type qualification]
In UBL 2.1, the schema library of common basic components (basic information entities or BBIEs, (A) in the diagram) is based on a combination of the data types defined in the file of UBL 2.1 qualified data types (B) and the data types defined in a file of UBL 2.1 unqualified data types (C). The latter inherits the data type definitions in the UN/CEFACT CCTS CCT schema module Ver. 1.1 050114 (D). The UBL 2.1 CVA file (E) controls the creation of the UBL 2.1 XSLT stylesheet (F) used in validation. While this XSLT file, UBL-2.1-DefaultDTQ.xsl, can, in theory, apply to qualified data type qualifications in general (such as field length restrictions and value range restrictions), the version of this file included in the UBL 2.1 release contains only code list values. The two remaining boxes on the right in the diagram illustrate that users can add further data type qualifications if desired by preparing a custom CVA (G) and creating a custom XSLT file (H) to replace the default CVA and XSLT stylesheet provided in the UBL 2.1 distribution. Users intending to prepare a custom CVA should note that cva/UBL-DefaultDTQ-2.1.cva contains relative URIs that expect the UBL 2.0 code lists from the UBL 2.0 Update Package in a sibling directory named os-UBL-2.0. This is irrelevant to users of the precompiled val/UBL-DefaultDTQ-2.1.xsl file contained in the UBL 2.1 package, but users wishing to create their own CVA file must first install the UBL 2.0 release and then the UBL 2.0 update. To properly install the update, first download and install the original UBL 2.0 release:
http://docs.oasis-open.org/ubl/os-UBL-2.0.zip
Then download and install the UBL 2.0 update:
http://docs.oasis-open.org/ubl/os-UBL-2.0-update-delta.zip
Complete installation instructions can be found in the update package. As indicated above, the os-UBL-2.0 directory thus created must be a sibling to the directory created by installing the UBL 2.1 package. UBL 2.1 Code Lists and Two-phase Validation
Introduction Code lists—the sets of codes such as “FR” and “USD” that are used to specify countries, currencies, and so on—play an important role in UBL, just as they do in all electronic business messaging schemes. By default, UBL uses several lists of standard codes published by agencies such as ISO and UN/CEFACT, as well as various codes that are specific to UBL. In UBL 1.0 (2004), standard and default code list values were enumerated directly in the UBL schemas. This allowed all UBL 1.0 instances to be validated in a single pass using generic XML XSD (W3C Schema) processors. However, the specification of the default values directly in the schemas also made it difficult to modify the code lists to suit individual trading partner relationships and impossible to extend the list of allowable code list values while still using the standard UBL schemas as published by OASIS. To give users maximum flexibility in configuring and updating UBL code lists without changing the standard UBL schemas, UBL 2.0 introduced a two-phase validation model that has now been fully implemented in UBL 2.1. In the first phase, the UBL instance is checked for structure and vocabulary against a standard UBL schema using a generic schema validator (or custom-built software performing the same function). This is exactly the same procedure used for validation in UBL 1.0, except that the schemas do not contain hardwired code list values. Then in an added second validation (or verification) phase, code list values in the instance are checked against values obtained from external code list configuration files using an XSLT 1.0 processor driven by an XSLT 1.0 stylesheet. The default code list values assumed by the UBL 2.1 specification are expressed as data type qualifications in a file named UBL-2.1-DefaultDTQ.xsl located in the val directory, as described in more detail below. Publicly available tools were used to create the XSL file using the methodology described in the “Validation” section of , the UBL Guidelines for Customization. Separating the checking of structure and vocabulary from the checking of code values allows trading partners to easily and precisely specify code list subsets and extensions and to apply them not just to individual UBL document types but also to particular elements and subtrees within UBL document instances. Another way to say this is that the the UBL code list methodology allows different versions of the same code list to be used in different document contexts. Thus, for example, a business in Canada might agree with a business in the United States to use a set of code list configuration files that allow the Buyer to be associated with either a U.S. state or a Canadian province but restrict the Seller to just U.S. states—that is, to apply a code list subset containing state and province codes in one place in a document instance and a different code list subset containing just state codes in another place in the instance.
Default Validation Setup To facilitate the processing of UBL 2.1 instances using the two-phase method, an “out-of-the-box” collection of open-source software that can be used to demonstrate default validation of UBL 2.1 documents is included in the val directory of this release package. The validation harness assumes a Linux or Windows system with no currently installed XML or XSLT processing software. The Java Runtime Environment (JRE) 1.5 or later is required to use the programs in the val directory; JRE versions below 1.5 will throw an error from the xjparse.jar module used to invoke the xerces schema parser. If necessary, download and install the latest JRE from the following location before continuing:
http://www.java.com/en/download/manual.jsp
To demonstrate UBL 2.1 default validation: Change to the val directory. From within that directory, enter the test command test.bat (Windows) or sh test.sh (Linux) The output, which is explained in the next section, should resemble the output shown in the following figure (the spacing has been manually adjusted to make the output easier to read).
Validation test output [Output of validation test]
From within the val directory, you can now validate any UBL document against the UBL 2.1 schemas by executing commands of the form validate<ubl-schema> <ubl-document> where <ubl-document> is the path of a document to be validated and <ubl-schema> is the path of the UBL 2.1 schema for that document type (Order, Invoice, etc.). For example, the scripts val/testsamples.bat and val/testsamples.sh show this process being used to validate the sample XML instances in the xml directory.
Discussion of the Default Validation Test The test output displayed above demonstrates the default validation process with three test files: a valid UBL Order (val/order-test-good.xml); a UBL Order containing a bad (misspelled) element (val/order-test-bad1.xml); and a UBL Order that is schema-valid but contains an illegal code list value (val/order-test-bad2.xml). The file val/test.bat (Windows) or val/test.sh (Linux) is used to run the script val/validate.bat or val/validate.sh against each of the test files. The first run using order-test-good.xml demonstrates both phases of the default validation process running normally. In the first phase, a standard W3C Schema (XSD) validator, xerces, is invoked from val/w3cschema.bat (or val/w3cschema.sh) to validate the specified UBL document (.xml) against the specified UBL 2.1 runtime schema (.xsd). Since the input is a valid UBL Order, the output of the first phase simply indicates that the file is valid against the given Order schema. The second phase of validation uses a standard XSLT 1.0 engine, saxon, to verify that the values of various codes used in the UBL document to be tested (currency codes, packaging types, etc.) are valid in terms of the default UBL 2.1 code list values specified in val/UBL-DefaultDTQ-2.1.xsl. Here the output line “No code list validation errors” from the validate script indicates that the saxon run (invoked from val/xslt.bat or val/xslt.sh) finds no illegal code values in the document. The second run shows what happens when the input document (order-test-bad1.xml) contains an actual structure or vocabulary error, in this case due to omission of the trailing “e” from the element named cbc:ChannelCode. When the xerces parser encounters the malformed element name, it emits the error message shown in the example, and the validate script reacts to a non-zero status code from w3cschema.bat (or w3cschema.sh) by terminating the validation process. In the third run, the input document order-test-bad2.xml is structurally valid according to the Order schema, but it contains an illegal code list value (the ChannelCode “AL” for cell phone has been mistyped as “LA”). Thus it passes the first phase when tested against the schema but fails the second phase when tested against val/UBL-DefaultDTQ-2.1.xsl. To summarize, input documents are checked in the first validation phase for correctness of structure and vocabulary, using the constraints expressed in the appropriate UBL schema, and then they are checked in the second phase for correctness of default code list values, using the default constraints expressed in the XSLT file UBL-DefaultDTQ-2.1.xsl. This process is illustrated in the following diagram.
Two-phase Default UBL 2.1 Validation [two-phase validation]
It should be clear from the foregoing that the second phase of the default validation process can safely be omitted if it is considered unnecessary to check code list values. However, the reverse is not true; the second phase depends for correct operation on a prior check for structural validity, and therefore it will not give reliable results if run in the absence of the first (schema) validation phase.
Customizing the Default XSLT File The validation framework provided in the val directory can be used to implement code list changes, define variant code lists to fit specific trading partner agreements, or associate different versions of the same code list with different parts of the same UBL document by substituting a custom process (be it XSLT or some other language or process) for the default UBL-DefaultDTQ-2.1.xsl provided in the UBL 2.1 distribution. This allows extensive code list management without the need to change the standard UBL 2.1 schemas. Schematron-based techniques for generating a custom XSLT file to take the place of UBL-DefaultDTQ-2.1.xsl are explained in and . See also for more about UBL data type qualifications. Since XSLT is a very powerful general-purpose XML transformation tool, the same framework can be extended to perform fairly sophisticated business rule checking by manually coding additional logic into the XSLT file that drives the second validation phase. Such modification is beyond the scope of the customization methodologies associated specifically with UBL, but a business analyst willing to perform XSLT programming can use this mechanism to offload a large proportion of input filtering from the backend business application to a simpler input processing area. Additional XSLT scripts can be added to extract logical subtrees of incoming UBL documents for allocation to different downstream processes and to perform even more extensive front-end processing.
Sources for the Default Validation Framework Components of several freely available software distributions were used to create the val directory. Sources are given below so that these components can be updated as later releases become available. The file val/xjparse.jar (renamed from xjparse-2.0.1.jar) and the files in the “val/lib” directory are from the xjparse 2.0.1 distribution at
http://xjparse.org
The file val/saxon.jar is from the saxon 6.5.5 distribution at
http://prdownloads.sourceforge.net/saxon/saxon6-5-5.zip
The file val/UBL-DefaultDTQ-2.1.xsl was created using the Schematron implementation of CVA files for validation at
http://www.CraneSoftwrights.com/resources/ubl/#cva2sch
Code Lists Included in UBL 2.1 The code lists included in the UBL 2.1 distribution use an OASIS Standard XML format for code lists called . Each code list in the distribution occupies its own genericode file. Documentation on the UBL code lists is contained in a generated report file:
cva/UBL-DefaultDTQ-2.1.html
The code list files in UBL 2.1 are divided into two subdirectories, cl/gc/default and cl/gc/special-purpose.
cl/gc/default The code lists in the cl/gc/default directory contain the default code values represented in UBL-DefaultDTQ-2.1.xsl. A second-phase code list check using an unmodified version of the test setup from this distribution as described above will verify all occurrences of code values from these lists against the values specified in the cl/gc/default directory. These are the code lists expected to be used in most application contexts.
cl/gc/default/AllowanceChargeReasonCode-2.1.gc cl/gc/default/BinaryObjectMimeCode-2.1.gc cl/gc/default/ChannelCode-2.1.gc cl/gc/default/CountryIdentificationCode-2.1.gc cl/gc/default/CurrencyCode-2.1.gc cl/gc/default/DocumentStatusCode-2.1.gc cl/gc/default/PackagingTypeCode-2.1.gc cl/gc/default/PaymentMeansCode-2.1.gc cl/gc/default/ReceiptAdviceTypeCode-2.1.gc cl/gc/default/TransportEquipmentTypeCode-2.1.gc cl/gc/default/TransportModeCode-2.1.gc cl/gc/default/UnitOfMeasureCode-2.1.gc cl/gc/default/WeekDayCode-2.1.gc The line status code list bound into UBL-DefaultDTQ-2.1.xsl is unchanged from UBL 2.0.
cl/gc/special-purpose This directory contains genericode versions of code lists that are used only in certain application contexts. They are not bound into the UBL-DefaultDTQ-2.1.xsl file included in this distribution, but are provided here in the cl/gc/special-purpose directory to make them available for incorporation into custom validation scripts. The files in this directory are as follows:
cl/gc/special-purpose/AdjustmentReasonCode-2.1.gc cl/gc/special-purpose/CollaborationPriorityCode-2.1.gc cl/gc/special-purpose/DataSourceCode-2.1.gc cl/gc/special-purpose/DisplayTacticTypeCode-2.1.gc cl/gc/special-purpose/ExceptionStatusCode-2.1.gc cl/gc/special-purpose/ForecastPurposeCode-2.1.gc cl/gc/special-purpose/ForecastTypeCode-2.1.gc cl/gc/special-purpose/LanguageCode-2.1.gc cl/gc/special-purpose/MiscellaneousEventTypeCode-2.1.gc cl/gc/special-purpose/PerformanceMetricCriterionCode-2.1.gc cl/gc/special-purpose/PortCode-2.1-air.gc cl/gc/special-purpose/PortCode-2.1-border.gc cl/gc/special-purpose/PortCode-2.1-fixed.gc cl/gc/special-purpose/PortCode-2.1-multi.gc cl/gc/special-purpose/PortCode-2.1-port.gc cl/gc/special-purpose/PortCode-2.1-post.gc cl/gc/special-purpose/PortCode-2.1-rail.gc cl/gc/special-purpose/PortCode-2.1-road.gc cl/gc/special-purpose/PortCode-2.1-unknown.gc cl/gc/special-purpose/PortCode-2.1.gc cl/gc/special-purpose/PromotionalEventTypeCode-2.1.gc cl/gc/special-purpose/ResolutionCode-2.1.gc cl/gc/special-purpose/RetailEventStatusCode-2.1.gc cl/gc/special-purpose/RevisionStatusCode-2.1.gc cl/gc/special-purpose/StatusCode-2.1.gc cl/gc/special-purpose/SupplyChainActivityTypeCode-2.1.gc cl/gc/special-purpose/ThresholdValueComparisonCode-2.1.gc cl/gc/special-purpose/TimeFrequencyCode-2.1.gc cl/gc/special-purpose/TransportationStatusCode-2.1.gc cl/gc/special-purpose/CoordinateSystemCode-2.1.gc cl/gc/special-purpose/EnvironmentalEmissionCode-2.1.gc cl/gc/special-purpose/NotificationTypeCode-2.1.gc cl/gc/special-purpose/TransportationStatusTypeCode-2.1.gc cl/gc/special-purpose/TransportServiceCode-2.1.gc cl/gc/special-purpose/DocumentStatusReasonCode-2.1.gc cl/gc/special-purpose/AccountTypeCode-2.1.gc cl/gc/special-purpose/AddressTypeCode-2.1.gc cl/gc/special-purpose/CargoTypeCode-2.1.gc cl/gc/special-purpose/CommodityIdentificationCode-2.1.gc cl/gc/special-purpose/DocumentTypeCode-2.1.gc cl/gc/special-purpose/FullnessIndicationCode-2.1.gc cl/gc/special-purpose/HumanSexesCode-2.1.gc cl/gc/special-purpose/HandlingCode-2.1.gc cl/gc/special-purpose/HazardousCategoryCode-2.1.gc cl/gc/special-purpose/PartyRoleCode-2.1.gc cl/gc/special-purpose/ItemClassificationCode-2.1.gc cl/gc/special-purpose/LocationTypeCode-2.1.gc cl/gc/special-purpose/PackageLevelCode-2.1.gc cl/gc/special-purpose/SealStatusCode-2.1.gc cl/gc/special-purpose/SizeTypeCode-2.1.gc cl/gc/special-purpose/TransportMeansTypeCode-2.1.gc The commodity identification code list included from UN/CEFACT is a placebo list consisting of just a single generic value. It is typical that users would have their own choice of values, or in fact perhaps many lists of values, for commodity identification codes. The United Nations Standard Products and Services Code (UNSPSC), maintained by GS1 US, is a commonly used source of values for this list. The UN/LOCODE Recommendation 16 (port code) list is included in its complete form and in nine subset lists. Each subset list includes only those ports identified as belonging to a certain type. A genericode file for the United Nations Dangerous Goods code list to apply to the BBIE UNDGCode is not included in UBL due to the dynamic nature of the information in that list and the myriad of subsets that may be needed by different communities of users.
Code List Agency Identifiers The code list information provided in the form of genericode files in this distribution (see ) comes from three sources: the OASIS UBL Technical Committee, the International Organization for Standardization (ISO), and UN/CEFACT, the Centre for Trade Facilitation and Electronic Business of the UN Economic Commission for Europe (UNECE). Some of the source files obtained from UNECE are internally marked as having ISO as the code list agency, as is indicated in the genericode file. The custodial agency responsible for each code list is identified in the corresponding genericode file as shown in the following examples. <Agency> <LongName xml:lang="en">OASIS Universal Business Language</LongName> <Identifier>UBL</Identifier> </Agency> <Agency> <LongName xml:lang="en">International Organization for Standardization</LongName> <Identifier Identifier="http://www.unece.org/trade/untdid/d11a/tred/tred3055.htm" >5</Identifier> </Agency> <Agency> <LongName xml:lang="en">United Nations Economic Commission for Europe</LongName> <Identifier Identifier="http://www.unece.org/trade/untdid/d11a/tred/tred3055.htm" >6</Identifier> </Agency> The numeric “5” and “6” agency identifiers are from the code list “Responsible Agency Code” most recently published at
http://www.unece.org/trade/untdid/d11a/tred/tred3055.htm
UBL 2.1 Example Document Instances The xml directory of this distribution contains a number of sample UBL documents that can be used for testing purposes. The testsamples.bat batch file and the testsamples.sh script in the val directory of this distribution can be used to demonstrate the validity of these examples in Windows and Linux operating environments. See for a general discussion of UBL validation methodology. For convenience, those examples that relate specifically to a particular document type are linked from the description of that type in .
Example instances containing extensions xml/MyTransportationStatus.xml xml/UBL-Invoice-2.0-Enveloped.xml
Example instances related to signatures (see ) xml/UBL-Invoice-2.0-Detached-Signature.xml xml/UBL-Invoice-2.0-Detached.xml xml/UBL-Invoice-2.0-Enveloped.xml
Example instances with unconventional use of namespace bindings xml/UBL-Invoice-2.0-Example-NS1.xml xml/UBL-Invoice-2.0-Example-NS2.xml xml/UBL-Invoice-2.0-Example-NS3.xml xml/UBL-Invoice-2.0-Example-NS4.xml
Example instances of different versions of certain document types xml/UBL-CreditNote-2.0-Example.xml xml/UBL-CreditNote-2.1-Example.xml xml/UBL-DebitNote-2.1-Example.xml xml/UBL-DespatchAdvice-2.0-Example.xml xml/UBL-ExceptionCriteria-2.1-Example.xml xml/UBL-ExceptionNotification-2.1-Example.xml xml/UBL-Forecast-2.1-Example.xml xml/UBL-ForecastRevision-2.1-Example.xml xml/UBL-ForwardingInstructions-2.0-Example-International.xml xml/UBL-FreightInvoice-2.1-Example.xml xml/UBL-FulfilmentCancellation-2.1-Example.xml xml/UBL-GoodsItemItinerary-2.1-Example.xml xml/UBL-InstructionForReturns-2.1-Example.xml xml/UBL-InventoryReport-2.1-Example.xml xml/UBL-Invoice-2.0-Example.xml xml/UBL-Invoice-2.1-Example.xml xml/UBL-Invoice-2.1-Example-Trivial.xml xml/UBL-Order-2.0-Example-International.xml xml/UBL-Order-2.0-Example.xml xml/UBL-Order-2.1-Example.xml xml/UBL-OrderCancellation-2.1-Example.xml xml/UBL-OrderChange-2.1-Example.xml xml/UBL-OrderResponse-2.1-Example.xml xml/UBL-OrderResponseSimple-2.0-Example.xml xml/UBL-OrderResponseSimple-2.1-Example.xml xml/UBL-ProductActivity-2.1-Example-1.xml xml/UBL-ProductActivity-2.1-Example-2.xml xml/UBL-ProductActivity-2.1-Example-3.xml xml/UBL-Quotation-2.0-Example.xml xml/UBL-Quotation-2.1-Example.xml xml/UBL-ReceiptAdvice-2.0-Example.xml xml/UBL-Reminder-2.1-Example.xml xml/UBL-RemittanceAdvice-2.0-Example.xml xml/UBL-RequestForQuotation-2.0-Example.xml xml/UBL-RequestForQuotation-2.1-Example.xml xml/UBL-RetailEvent-2.1-Example.xml xml/UBL-SelfBilledCreditNote-2.1-Example.xml xml/UBL-Statement-2.0-Example.xml xml/UBL-StockAvailabilityReport-2.1-Example.xml xml/UBL-TradeItemLocationProfile-2.1-Example.xml xml/UBL-TransportationStatus-2.1-Example.xml xml/UBL-TransportationStatusRequest-2.1-Example.xml xml/UBL-TransportExecutionPlan-2.1-Example.xml xml/UBL-TransportExecutionPlanRequest-2.1-Example.xml xml/UBL-TransportProgressStatus-2.1-Example.xml xml/UBL-TransportProgressStatusRequest-2.1-Example.xml xml/UBL-TransportServiceDescription-2.1-Example.xml xml/UBL-TransportServiceDescriptionRequest-2.1-Example.xml xml/UBL-Waybill-2.0-Example-International.xml
Alternative Representations of the UBL 2.1 Schemas UBL 2.1 continues the practice, adopted at the beginning of the UBL effort, of creating its normative XML specifications using W3C Schema (XSD) syntax. Alternative representations of the same content are technically non-normative, but are generated directly from the XSD and, with the exception of the UBL 2.1 digital signature extension (see ), are intended to implement the same document instance constraints.
ASN.1 UBL 2.1 Specification The UBL ASN.1 specification provides an alternative schema definition for UBL documents in accordance with ITU-T X.680-X.693 . The UBL ASN.1 specification defines the same UBL documents as the UBL XSD schemas that constitute the normative definitions of valid UBL documents. The UBL ASN.1 XML specification enables ASN.1 tools to be used for UBL transfers, and in conjunction with the ASN.1 Packed Encoding Rules, it provides a specification for an efficient binary encoding of UBL messages. The ASN.1 modules were created using a tool from OSS Nokalva that conforms to ITU-T Recommendation X.694 | ISO/IEC 8825-5 for converting XSD Schema to ASN.1.
UBL 2.1 UML Diagrams The UBL 2.1 UML diagrams provide a graphical view of the UBL document models using . The UML diagrams were created using a tool from Sparx Systems.
UBL 2.1 RELAX NG Schemas (compact syntax) versions of the UBL schemas contributed by Crane Softwrights Ltd. and used here by permission are located in the rnc directory. The Crane package includes RELAX NG schemas for both UBL 2.0 and 2.1, as detailed in the related documentation.
rnc/readme-rnc.html
The UBL 2.1 RELAX NG schema for each UBL 2.1 document type is linked from the description of that document type in .
The Open-edi reference model perspective of UBL ISO/IEC 14662:2010 Information technology - Open-edi reference model has been developed primarily in order to provide standards required for the inter-working of organizations through interconnected information technology systems. Open-edi lowers barriers to electronic data interchange by introducing standard business scenarios and the necessary services to support them. The Open-edi Reference Model identifies the required standards for Open-edi and provides a reference for those standards by defining the basic concepts used to develop them. depicts two views to describe the relevant aspects of business transactions: the Business Operational View (BOV); the Functional Service View (FSV).
Open-edi Overview [Open-edi Overview]
The BOV addresses the aspects of the semantics of business data in business transactions and associated data interchanges which apply to the business needs of Open-edi. The BOV-related standards are tools and rules by which users who understand the operating aspects of a business domain may create scenarios. The FSV addresses the supporting services meeting the mechanistic needs of Open-edi, focusing on information technology aspects of functional capabilities, service interfaces, and protocols. Using the concepts of Open-edi, UBL 2.1 provides a generic Open-edi Configuration that an Open-edi Community may customize with their own requirements to implement their own Open-edi Configuration. ISO/IEC 15944-20 Information technology - Business operational view - Linking business operational view to functional service view presents the relationships linking the BOV with the FSV. illustrates how the two normative deliverables of UBL, the semantic components and the XML schemas, align respectively with the BOV and FSV views of the Open-edi Reference Model.
Open-edi Application [Open-edi Application]
provides the configuration’s BOV with a suite of normative business objects and associated semantics from which the community selects the semantic components needed in an information bundle. An information bundle describes the semantics of the recorded information to be exchanged between Open-edi Support Infrastructures servicing Decision Making Applications. The community’s configuration combines these information bundles with their identified scenarios and roles. and provides the configuration’s FSV with a set of corresponding normative XML schemas and document instance rules constraining the expression of the business objects in user data. One translates the semantic component values into a transfer syntax from the information bundle specification as a set of recorded information. It is the UBL XML syntax for the sets of recorded information defined by the information bundles that is exchanged between Parties. provides the configuration’s FSV with a normative schema fragment suitable for including profiles of advanced digital signatures in user data. The other aspects of the implemented BOV and implemented FSV of the community’s Open-edi Configuration are governed by influences outside of the scope of UBL. Those aspects guide the community in customizing UBL to suit their requirements, as outlined in . Acknowledgements The OASIS UBL Technical Committee thanks Altova for its contribution of XML Spy licenses for use in UBL schema design; Sparx Systems for its contribution of Enterprise Architect licenses for use in developing UML content models; Syncro Soft for its contribution of oXygen licenses used in DocBook authoring of UBL documentation; RenderX for its contribution of XEP licenses used in generating PDF documents from DocBook originals; SRDC for developing iSurf eDoCreator (supported by European Commission FP7 ICT-213031 iSurf Project) and providing technical assistance in its use as an online repository and editing environment for UBL 2.1 document models and the generation of UBL schemas; OSS Nokalva for its contribution of ASN.1 UBL 2.1 specifications; and Crane Softwrights for permission to include a copy of their publicly-available HTML reports and UBL 2.1 RELAX NG schema resources. The following persons and companies participated as members of the OASIS UBL Technical Committee during the four years of its development (2008–2012). Inigo Barreira, iZenpe S.A. Roger Bass, Individual Oriol Bausa Peris, Individual Kenneth Bengtsson, Alfa1lab Georg Birgisson, Document Engineering Services Limited Peter Borresen, Document Engineering Services Limited Jon Bosak, Individual Mikkel Brun, Tradeshift Network Ltd. Arianna Brutti, ENEA UTT PMI Andrea Caccia, AITI-Associazione Italiana Tesorieri de Impresa Manuel Cano, Nexus IT Sally Chan, The Boeing Company William Chan, Individual Roberto Cisternino, Individual Anthony Coates, Document Engineering Services Limited Gary Cornelius, CSW Group Ltd. Mavis Cournane, Cognitran Robin Cover, OASIS Eduardo Criado Albuixech, Eurobits Technologies Juan Cruellas, Departamento de Arquitectura de Computadores, Univ Politecnica de Cataluna Piero De Sabbata, ENEA UTT PMI Michael Dill, Individual Asuman Dogac, Individual Kees Duvekot, RFS Holland Holding B.V. Pim van der Eijk, Sonnenglanz Consulting David Fitzpatrick, Booz Allen Hamilton Martin Forsberg, Swedish Association of Local Authorities & Regions Bob Glushko, Document Engineering Services Limited Arturo Gonzalez Mac Dowell, Eurobits Technologies Stephen Green, Document Engineering Services Limited Michael Grimley, US Department of Defense (DoD) Eduardo Gutentag, Oracle Betty Harvey, Individual Anne Hendry, Individual Hideki Hiura, Justsystems Corporation G. Ken Holman, Crane Softwrights Ltd. Naomasa Hosoda, NEC Corporation Julian Inza, Eurobits Technologies Akihiro Kawauchi, Individual Kyung-In Kim, Korea Institute for Electronic Commerce (KIEC) Sung Hyuk Kim, Individual Stig Korsgaard, Danish Bankers Association Ram Kumar, Individual John Larmouth, Individual Thomas Lee, University of Hong Kong Thomas Love, efoil, Inc. Luis Martin-Santos, Gaia Net Exchange S.L. Tim McGrath, Document Engineering Services Limited Brais Mendez Ferreiro, Sociedad de Explotacion de Redes Electronicas y Servicios, SA (SERES) Garret Minakawa, Oracle Tuncay Namli, Individual Yasuyuki Nishioka, PSLX consortium Dave Nurse, CSW Group Ltd. Cagdas Ocalan, Middle East Technical University Mark Palmer, NIST Klaus Pedersen, Difi-Agency for Public Management and eGovernment Sue Probert, Individual Sven Rasmussen, Danish Agency for Digitisation, Ministry of Finance Zarella Rendon, PTC Yukinori Saito, ERP Research Corporation Sacha Schlegel, Individual Andrew Schoka, Individual Mark Seaborne, PicoForms Jose Silva, Individual Ali Sinaci, Middle East Technical University Kumar Sivaraman, Oracle Enric Staromiejski, SOM Team Paul Thorpe, OSS Nokalva Karsten Tolle, Document Engineering Services Limited Juerg Tschumperlin, New Zealand Ministry of Education Fulya Tuncer, Middle East Technical University Kenneth Vaughn, Individual Vito Vavalli, AITI-Associazione Italiana Tesorieri de Impresa Audun Vennesland, SINTEF Catherine Williams, PISCES Ltd Nigel Wooden, ACORD Corporation Marcelo Yarzabal, Eurobits Technologies Patrick Yee, University of Hong Kong Arif Yildirim, Revenue Administration of Turkey Peter Yim, Individual Pine Zhang, UOML Alliance