Universal Business Language Version 2 - OASIS · urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2 urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2

Universal Business Language Version2.1Committee Specification Draft 02 / Public Review Draft02

30 May 2011

Specification URIs:

This Version:http://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.htmlhttp://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.pdfhttp://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.xml (Authoritative)

Previous Version:http://docs.oasis-open.org/ubl/prd1-UBL-2.1/UBL-2.1.htmlhttp://docs.oasis-open.org/ubl/prd1-UBL-2.1/UBL-2.1.pdfhttp://docs.oasis-open.org/ubl/prd1-UBL-2.1/UBL-2.1.xml

Latest Version:http://docs.oasis-open.org/ubl/UBL-2.1.htmlhttp://docs.oasis-open.org/ubl/UBL-2.1.pdfhttp://docs.oasis-open.org/ubl/UBL-2.1.xml (Authoritative)

Technical Committee:OASIS Universal Business Language TC

Chairs:Jon Bosak, Pinax <[email protected]>Tim McGrath <[email protected]>

Editors:Jon Bosak, Pinax <[email protected]>Tim McGrath <[email protected]>G. Ken Holman, Crane Softwrights Ltd. <[email protected]>

Related Work:This specification supersedes UBL 2.0.

Declared XML Namespaces:

urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2

30 May 2011Page 1 of 156

UBLCopyright © OASIS® . All Rights Reserved.

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.html

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.pdf

http://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.xml


http://docs.oasis-open.org/ubl/prd1-UBL-2.1/UBL-2.1.pdf

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/UBL-2.1.xml

http://docs.oasis-open.org/ubl/UBL-2.1.html

http://docs.oasis-open.org/ubl/UBL-2.1.pdf

http://docs.oasis-open.org/ubl/UBL-2.1.xml

http://www.oasis-open.org/committees/ubl

mailto:[email protected]





http://docs.oasis-open.org/ubl/os-UBL-2.0-update/UBL-2.0.html

urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2

urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2urn:oasis:names:specification:ubl:schema:xsd:AttachedDocument-2urn:oasis:names:specification:ubl:schema:xsd:AwardedNotification-2urn:oasis:names:specification:ubl:schema:xsd:BillOfLading-2urn:oasis:names:specification:ubl:schema:xsd:CallForTenders-2urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2urn:oasis:names:specification:ubl:schema:xsd:CatalogueDeletion-2urn:oasis:names:specification:ubl:schema:xsd:CatalogueItemSpecificationUpdate-2urn:oasis:names:specification:ubl:schema:xsd:CataloguePricingUpdate-2urn:oasis:names:specification:ubl:schema:xsd:CatalogueRequest-2urn:oasis:names:specification:ubl:schema:xsd:CertificateOfOrigin-2urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2urn:oasis:names:specification:ubl:schema:xsd:ContractAwardNotice-2urn:oasis:names:specification:ubl:schema:xsd:ContractNotice-2urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2urn:oasis:names:specification:ubl:schema:xsd:DocumentStatus-2urn:oasis:names:specification:ubl:schema:xsd:DocumentStatusRequest-2urn:oasis:names:specification:ubl:schema:xsd:ExceptionCriteria-2urn:oasis:names:specification:ubl:schema:xsd:ExceptionNotification-2urn:oasis:names:specification:ubl:schema:xsd:Forecast-2urn:oasis:names:specification:ubl:schema:xsd:ForecastRevision-2urn:oasis:names:specification:ubl:schema:xsd:ForwardingInstructions-2urn:oasis:names:specification:ubl:schema:xsd:FreightInvoice-2urn:oasis:names:specification:ubl:schema:xsd:GuaranteeCertificate-2urn:oasis:names:specification:ubl:schema:xsd:InstructionForReturns-2urn:oasis:names:specification:ubl:schema:xsd:InventoryReport-2urn:oasis:names:specification:ubl:schema:xsd:Invoice-2urn:oasis:names:specification:ubl:schema:xsd:ItemInformationRequest-2urn:oasis:names:specification:ubl:schema:xsd:Order-2urn:oasis:names:specification:ubl:schema:xsd:OrderCancellation-2urn:oasis:names:specification:ubl:schema:xsd:OrderChange-2urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-2urn:oasis:names:specification:ubl:schema:xsd:PackingList-2urn:oasis:names:specification:ubl:schema:xsd:PerformanceHistory-2urn:oasis:names:specification:ubl:schema:xsd:PriorInformationNotice-2urn:oasis:names:specification:ubl:schema:xsd:ProductActivity-2urn:oasis:names:specification:ubl:schema:xsd:Quotation-2urn:oasis:names:specification:ubl:schema:xsd:ReceiptAdvice-2urn:oasis:names:specification:ubl:schema:xsd:Reminder-2urn:oasis:names:specification:ubl:schema:xsd:RemittanceAdvice-2urn:oasis:names:specification:ubl:schema:xsd:RequestForQuotation-2urn:oasis:names:specification:ubl:schema:xsd:RetailEvent-2urn:oasis:names:specification:ubl:schema:xsd:SelfBilledCreditNote-2urn:oasis:names:specification:ubl:schema:xsd:SelfBilledInvoice-2urn:oasis:names:specification:ubl:schema:xsd:Statement-2urn:oasis:names:specification:ubl:schema:xsd:StockAvailabilityReport-2urn:oasis:names:specification:ubl:schema:xsd:Tender-2urn:oasis:names:specification:ubl:schema:xsd:TendererQualification-2

30 May 2011Page 2 of 156


urn:oasis:names:specification:ubl:schema:xsd:TendererQualificationResponse-2urn:oasis:names:specification:ubl:schema:xsd:TenderReceipt-2urn:oasis:names:specification:ubl:schema:xsd:TradeItemLocationProfile-2urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlan-2urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionStatus-2urn:oasis:names:specification:ubl:schema:xsd:TransportProgressStatus-2urn:oasis:names:specification:ubl:schema:xsd:UnawardedNotification-2urn:oasis:names:specification:ubl:schema:xsd:UtilityStatement-2urn:oasis:names:specification:ubl:schema:xsd:Waybill-2

Citation format::When referencing this specification the following citation format should be used:

[UBL-2.1] Universal Business Language Version 2.1 30 May 2011. Committee Specification Draft 02 /Public Review Draft 02. http://docs.oasis-open.org/ubl/prd2-UBL-2.1/UBL-2.1.html

Abstract: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 approvalis also listed above. Check the current location noted above for possible later revisions of this doc-ument. This document is updated periodically on no particular schedule.

Technical Committee members should send comments on this specification to the Technical Com-mittee's email list. Others should send comments to the Technical Committee by using the "SendA Comment" button on the Technical Committee's web page at http://www.oasis-open.org/commit-tees/ubl/.

For information on whether any patents have been disclosed that may be essential to implementingthis specification, and any offers of patent licensing terms, please refer to the Intellectual PropertyRights section of the Technical Committee web page at http://www.oasis-open.org/commit-tees/ubl/ipr.php.

See Appendix A, Release Notes (Non-Normative) for more information regarding this releasepackage.

30 May 2011Page 3 of 156



http://www.oasis-open.org/committees/ubl/

http://www.oasis-open.org/committees/ubl/

http://www.oasis-open.org/committees/ubl/ipr.php

http://www.oasis-open.org/committees/ubl/ipr.php

NoticesCopyright © OASIS® Open 2011. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS IntellectualProperty 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 thatcomment 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 copyrightnotice and this section are included on all such copies and derivative works. However, this documentitself may not be modified in any way, including by removing the copyright notice or references toOASIS, except as needed for the purpose of developing any document or deliverable produced by anOASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASISIPR 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 successorsor assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DIS-CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIPRIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULARPURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that wouldnecessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard,to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses tosuch patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee thatproduced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership ofany patent claims that would necessarily be infringed by implementations of this specification by a patentholder that is not willing to provide a license to such patent claims in a manner consistent with the IPRMode of the OASIS Technical Committee that produced this specification. OASIS may include suchclaims 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 thatmight be claimed to pertain to the implementation or use of the technology described in this documentor the extent to which any license under such rights might or might not be available; neither does itrepresent that it has made any effort to identify any such rights. Information on OASIS' procedures withrespect to rights in any document or deliverable produced by an OASIS Technical Committee can befound on the OASIS website. Copies of claims of rights made available for publication and any assurancesof licenses to be made available, or the result of an attempt made to obtain a general license or permissionfor the use of such proprietary rights by implementers or users of this OASIS Committee Specificationor OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representationthat any information or list of intellectual property rights will at any time be complete, or that any claimsin such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and shouldbe used only to refer to the organization and its official outputs. OASIS welcomes reference to, and im-plementation and use of, specifications, while reserving the right to enforce its marks against misleadinguses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

30 May 2011Page 4 of 156


http://www.oasis-open.org

http://www.oasis-open.org/who/trademark.php

Table of Contents1. Introduction (Non-Normative) .................................................................................................... 8

1.1. Terminology .................................................................................................................. 91.1.1. Terms and Definitions ......................................................................................... 91.1.2. Symbols and Abbreviations ................................................................................. 9

1.2. Normative References ................................................................................................. 101.3. Non-Normative References .......................................................................................... 11

2. UBL 2.1 Context of Use .......................................................................................................... 122.1. General Business Requirements .................................................................................. 13

2.1.1. Items ............................................................................................................... 132.1.2. Item Identification ............................................................................................. 132.1.3. Item Instances .................................................................................................. 142.1.4. Item Pricing ...................................................................................................... 142.1.5. Hazardous Items .............................................................................................. 142.1.6. Parties ............................................................................................................. 142.1.7. Multilingual Text ................................................................................................ 14

2.2. Overview of Business Processes .................................................................................. 142.3. Tendering .................................................................................................................... 15

2.3.1. Contract Information Preparation ....................................................................... 162.3.2. Contract Information Notification ........................................................................ 172.3.3. Invitation to Tender ........................................................................................... 182.3.4. Submission of Qualification Information .............................................................. 182.3.5. Submission of Tenders ...................................................................................... 192.3.6. Awarding of Tenders ......................................................................................... 20

2.4. Catalogue ................................................................................................................... 212.4.1. Catalogue Business Rules ................................................................................ 212.4.2. Catalogue Provision .......................................................................................... 22

2.5. Quotation .................................................................................................................... 272.6. Ordering ..................................................................................................................... 28

2.6.1. Ordering Business Rules .................................................................................. 282.6.2. Order Response Simple .................................................................................... 292.6.3. Order Response ............................................................................................... 292.6.4. Order Change .................................................................................................. 292.6.5. Order Cancellation ............................................................................................ 29

2.7. Fulfilment .................................................................................................................... 292.7.1. Despatch Advice Business Rules ...................................................................... 302.7.2. Receipt Advice Business Rules ......................................................................... 31

2.8. Billing ......................................................................................................................... 312.8.1. Billing Business Rules ....................................................................................... 322.8.2. Traditional Billing ............................................................................................... 322.8.3. Self Billing ........................................................................................................ 352.8.4. Reminder for Payment ...................................................................................... 37

2.9. Freight Billing .............................................................................................................. 382.10. Utility Billing .............................................................................................................. 382.11. Payment ................................................................................................................... 39

2.11.1. Report State of Accounts ................................................................................ 402.12. Collaborative Planning, Forecasting, and Replenishment ............................................. 41

2.12.1. Collaboration Agreement and Joint Business Planning ...................................... 422.12.2. Sales Forecast Generation and Exception Handling .......................................... 452.12.3. Order Forecast Generation and Exception Handling .......................................... 48

2.13. Vendor Managed Inventory ......................................................................................... 532.13.1. Basic Vendor Managed Inventory ..................................................................... 532.13.2. Cyclic Replenishment Program (CRP) .............................................................. 582.13.3. Replenishment On Customer Demand ............................................................. 61

2.14. International Freight Management .............................................................................. 642.14.1. Forwarding Instructions ................................................................................... 65

30 May 2011Page 5 of 156


2.14.2. Packing List .................................................................................................... 652.14.3. Bill of Lading .................................................................................................. 662.14.4. Waybill ........................................................................................................... 66

2.15. Intermodal Freight Management ................................................................................. 662.15.1. Transport Service Description .......................................................................... 682.15.2. Transport Execution Plan ................................................................................. 692.15.3. Goods Item Itinerary ....................................................................................... 712.15.4. Transport Execution Status .............................................................................. 712.15.5. Transport Progress Status ............................................................................... 72

2.16. Freight Status Reporting ............................................................................................ 732.17. Certification of Origin of Goods .................................................................................. 742.18. Document Types ........................................................................................................ 752.19. Party Roles ............................................................................................................... 80

3. UBL 2.1 Schemas .................................................................................................................. 853.1. UBL Document Schemas ............................................................................................. 853.2. UBL Common Schemas .............................................................................................. 88

3.2.1. Reusable BIE Schemas .................................................................................... 883.2.2. Reusable Data Type Schemas ........................................................................... 883.2.3. Documentation Metadata Schema ..................................................................... 893.2.4. Extension Content Schemas ............................................................................. 893.2.5. Signature Extension Schemas ........................................................................... 903.2.6. Signature Components ..................................................................................... 90

3.3. Schema Dependencies ................................................................................................ 914. Additional Document Constraints ............................................................................................ 92

4.1. Validation .................................................................................................................... 924.2. Character Encoding ..................................................................................................... 924.3. Empty Elements .......................................................................................................... 92

5. UBL Extension for XML Digital Signatures ............................................................................... 945.1. Namespaces ............................................................................................................... 945.2. Identification ............................................................................................................... 945.3. Validation .................................................................................................................... 955.4. Structure ..................................................................................................................... 955.5. Transformation ............................................................................................................ 975.6. Digital Signature Examples .......................................................................................... 985.7. Extension Validation Methodology (Non-Normative) ....................................................... 985.8. Notes for Extension Creators (Non-Normative) .............................................................. 99

6. Conformance ....................................................................................................................... 100

Appendixes

A. Release Notes (Non-Normative) ........................................................................................... 101A.1. Availability ................................................................................................................ 101A.2. Status of This Release .............................................................................................. 101A.3. Package Structure ..................................................................................................... 101A.4. Support .................................................................................................................... 102A.5. Expected Additions in PRD3 ...................................................................................... 102A.6. Taxation Rules .......................................................................................................... 102A.7. UBL Customization ................................................................................................... 102A.8. Upgrading from UBL 2.0 to UBL 2.1 ........................................................................... 103A.9. Dictionary Entry Name Corrections in UBL 2.1 ............................................................ 103

B. Revision History (Non-Normative) ......................................................................................... 104B.1. UBL 1.0 .................................................................................................................... 104B.2. Major Revision: UBL 2.0 ............................................................................................ 104B.3. Minor Revision: UBL 2.1 ............................................................................................ 105

B.3.1. New Document Types in UBL 2.1 .................................................................... 105B.3.2. Financial Information Enhancements in UBL 2.1 ............................................... 105B.3.3. Changes from UBL 2.0 (As Updated) to UBL 2.1 PRD2 .................................... 106

B.3.3.1. Changes to Library Elements (UBL 2.0 to UBL 2.1 PRD2) ...................... 106

30 May 2011Page 6 of 156


B.3.3.2. Changes to Document Elements (UBL 2.0 to UBL 2.1 PRD2) ................. 119B.3.3.3. Changes to Attributes (UBL 2.0 to UBL 2.1 PRD2) ................................. 124

B.3.4. Changes from UBL 2.1 PRD1 to UBL 2.1 PRD2 ............................................... 125B.3.4.1. Changes to Library Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2) ............ 125B.3.4.2. Changes to Document Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2) ....... 130

C. The UBL 2.1 Data Model (Non-Normative) ............................................................................ 133C.1. The UBL Common Library ......................................................................................... 134C.2. UBL Document Models .............................................................................................. 134C.3. Business Information Entity Documentation ................................................................ 140

D. UBL 2.1 Code Lists and Two-phase Validation (Non-Normative) .............................................. 141D.1. Introduction .............................................................................................................. 141D.2. Default Validation Setup ............................................................................................. 141D.3. Discussion of the Default Validation Test ..................................................................... 142D.4. Customizing the Default XSLT File ............................................................................. 144D.5. Sources for the Default Validation Framework ............................................................. 144D.6. Code Lists Included in UBL 2.1 .................................................................................. 144

D.6.1. cl/gc/default ................................................................................................... 144D.6.2. cl/gc/special-purpose ...................................................................................... 145

E. UBL 2.1 Example Document Instances (Non-Normative) ........................................................ 146F. Data Type Qualifications in UBL (Non-Normative) ................................................................... 148G. Alternative Representations of the UBL 2.1 Schemas (Non-Normative) ................................... 152

G.1. ASN.1 UBL 2.1 Specification ..................................................................................... 152G.2. UBL 2.1 RELAX NG Schemas ................................................................................... 152

H. Acknowledgements .............................................................................................................. 156

30 May 2011Page 7 of 156


1. Introduction (Non-Normative)Since its approval as a W3C recommendation in 1998, XML has been adopted in a number of industriesas a framework for the definition of the messages exchanged in electronic commerce. The widespreaduse of XML has led to the development of multiple industry-specific XML versions of such basic documentsas purchase orders, shipping notices, and invoices.

While industry-specific data formats have the advantage of maximal optimization for their businesscontext, the existence of different formats to accomplish the same purpose in different business domainsis attended by a number of significant disadvantages as well.

• Developing and maintaining multiple versions of common business documents like purchase ordersand invoices is a major duplication of effort.

• Creating and maintaining multiple adapters to enable trading relationships across domain boundariesis an even greater effort.

• The existence of multiple XML formats makes it much harder to integrate XML business messageswith back-office systems.

• The need to support an arbitrary number of XML formats makes tools more expensive and trainedworkers harder to find.

The OASIS Universal Business Language (UBL) is intended to help solve these problems by defininga generic XML interchange format for business documents that can be extended to meet the requirementsof particular industries. Specifically, UBL provides the following:

• A library of XML schemas for reusable data components such as “Address,” “Item,” and “Pay-ment”—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 procure-ment 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 datastructures.

• Lower cost of commercial software, because software written to process a given XML tag set is mucheasier 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 commercial syntax for legallybinding 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 existingEDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbranceor licensing fees.

30 May 2011Page 8 of 156


UBL schemas are modular, reusable, and extensible in XML-aware ways. As the first standard imple-mentation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on aconceptual model of information components known as Business Information Entities (BIEs). Thesecomponents are assembled into specific document models such as Order and Invoice.These documentassembly models are then transformed in accordance with UBL Naming and Design Rules into W3CXSD schema syntax.This approach facilitates the creation of UBL-based document types beyond thosespecified in this release.

1.1.Terminology

1.1.1.Terms and Definitions

Assembly modelA tree-structured model of ABIEs that can be implemented as a document schema. In this release,assembly models are provided in tabular form as spreadsheets.

DocumentA set of information components that are interchanged as part of a business transaction; for example,in placing an order.

XSD schemaAn XML document definition conforming to the W3C XML Schema language [XSD1] [XSD2].

The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC),Association Core Component (ASCC), Business Information Entity (BIE), Basic Business InformationEntity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with themeanings given in [CCTS].

The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specificationwith the meanings given in [ISO11179].

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RE-COMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as de-scribed in [RFC2119].

1.1.2. Symbols and Abbreviations

ABIEAggregate Business Information Entity

ASBIEAssociation Business Information Entity

BBIEBasic Business Information Entity

BIEBusiness Information Entity

CCCore Component

CPFRCollaborative Planning, Forecasting, and Replenishment [CPFR]

CV2Credit Card Verification Numbering System

30 May 2011Page 9 of 156


EDIElectronic Data Interchange

ISOInternational Organization for Standardization

NDRUBL Naming and Design Rules

UMLUnified Modeling Language [UML]

UN/CEFACTUnited Nations Centre for Trade Facilitation and Electronic Business

UNDGUnited Nations Dangerous Goods

URIUniform Resource Identifier

UUIDUniversally Unique Identifier

XMLExtensible Markup Language [XML]

XPathThe XML Path Language

XSDW3C XML Schema Language [XSD1] [XSD2]

1.2. Normative References[ASN.1] ITU-T X.680-X.683: Abstract Syntax Notation One (ASN.1) [http://www.itu.int/ITU-T/studygroups/

com17/languages/X.680-X.693-0207w.zip] , ITU-T X.690-X.693: ASN.1 encoding rules [http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip]

[CCTS] ISO/TS 15000-5:2005 Electronic Business Extensible Markup Language (ebXML)—Part 5:ebXML Core Components Technical Specification, Version 2.01 [http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip] (identical to Part 8 of theebXML Framework)

[CPFR] Voluntary Interindustry Commerce Standards, Collaborative Planning, Forecasting and Replen-ishment Version 2.0, Global Commerce Initiative Recommended Guidelines, June 2002 [http://www.vics.org/docs/committees/cpfr/CPFR_Tabs_061802.pdf]

[Customization] OASIS Committee Specification 01, UBL 2 Guidelines for Customization, First Edition,25 December 2009 [http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf]

[CVA] OASIS Committee Specification 01, Context/value association using genericode 1.0, 15 April2010 [http://docs.oasis-open.org/codelist/cs01-ContextValueAssociation-1.0/doc/context-value-association.html]

[genericode] OASIS Committee Specification 01, Code List Representation (Genericode) Version 1.0,28 December 2007 [http://docs.oasis-open.org/codelist/cs-genericode-1.0/doc/oasis-code-list-representation-genericode.pdf]

30 May 2011Page 10 of 156


http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-X.693-0207w.zip

http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip

http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip

http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip

http://www.vics.org/docs/committees/cpfr/CPFR_Tabs_061802.pdf

http://www.vics.org/docs/committees/cpfr/CPFR_Tabs_061802.pdf

http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf

http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf

http://docs.oasis-open.org/codelist/cs01-ContextValueAssociation-1.0/doc/context-value-association.html

http://docs.oasis-open.org/codelist/cs01-ContextValueAssociation-1.0/doc/context-value-association.html

http://docs.oasis-open.org/codelist/cs-genericode-1.0/doc/oasis-code-list-representation-genericode.pdf

http://docs.oasis-open.org/codelist/cs-genericode-1.0/doc/oasis-code-list-representation-genericode.pdf

[ISO11179] ISO/IEC 11179-1:1999 Information technology — Specification and standardization of dataelements — Part 1: Framework for the specification and standardization of data elements [http:// w w w . o a s i s - o p e n . o r g / c o m m i t t e e s / d o w n l o a d . p h p / 6 2 3 3 /c002349_ISO_IEC_11179-1_1999%28E%29.pdf]

[RELAX NG] ISO/IEC 19757-2, Information technology — Document Schema Definition Language(DSDL) — Part 2: Regular-grammar-based validation — RELAX NG [http://standards.iso.org/ittf/PubliclyAvailableStandards/c037605_ISO_IEC_19757-2_2003(E).zip] , Information technology— Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation— RELAX NG AMENDMENT 1: Compact Syntax [http://standards.iso.org/ittf/PubliclyAvailableStandards/c040774_ISO_IEC_19757-2_2003_Amd_1_2006(E).zip]

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels [http://www.faqs.org/rfcs/rfc2119.html]

[SCH] Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation (Schematron)[http://standards.iso.org/ittf/PubliclyAvailableStandards/c040833_ISO_IEC_19757-3_2006(E).zip]

[UML] Unified Modeling Language Version 1.5 (formal/03-03-01) [http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip]

[XAdES] XML Advanced Electronic Signatures. ETSI TS 101 903 V1.2.2 (2004-04) [http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf]

[XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October2000 [http://www.w3.org/TR/2000/REC-xml-20001006]

[xmldsig] XML-Signature Syntax and Processing. W3C Recommendation 12 February 2002 [http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/]

[XSD1] XML Schema Part 1: Structures. Second Edition. W3C Recommendation 28 October 2004[http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/]

[XSD2] XML Schema Part 2: Datatypes. Second Edition. W3C Recommendation 28 October 2004[http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/]

[XSLT] XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999 [http://www.w3.org/TR/1999/REC-xslt-19991116]

1.3. Non-Normative References[CPFRoverview] CPFR: An Overview, 18 May 2004 [http://www.vics.org/docs/standards/

CPFR_Overview_US-A4.pdf]

[eBiz-TCF] Reference Architecture of eBusiness in Textile Clothing and Footwear Sector [http://spring.bologna.enea.it/ebiz/defaultebiz.asp?versione=DOWNSTREAM]

30 May 2011Page 11 of 156


http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.pdf

http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.pdf

http://standards.iso.org/ittf/PubliclyAvailableStandards/c037605_ISO_IEC_19757-2_2003(E).zip


http://standards.iso.org/ittf/PubliclyAvailableStandards/c040774_ISO_IEC_19757-2_2003_Amd_1_2006(E).zip



http://www.faqs.org/rfcs/rfc2119.html


http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip

http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf

http://www.w3.org/TR/2000/REC-xml-20001006

http://www.w3.org/TR/2000/REC-xml-20001006

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

http://www.w3.org/TR/1999/REC-xslt-19991116

http://www.vics.org/docs/standards/CPFR_Overview_US-A4.pdf

http://spring.bologna.enea.it/ebiz/defaultebiz.asp?versione=DOWNSTREAM

2. UBL 2.1 Context of UseThe processes described in this section, and the business rules associated with them, define a contextfor the use of UBL 2.1 business documents. They are normative insofar as they provide semantics forthe UBL document schemas, but they should not be construed as limiting the application of thoseschemas.

UBL 2.1 extends the supply chain (including the commercial collaborations of international trade) to includedocuments for collaborative forecasting, planning and scheduling; vendor managed inventory; utilitybilling; tendering; and intermodal freight management. The following diagram illustrates the processcontext assumed by UBL 2.1 documents.

Figure 1. UBL 2.1 Use Case

The document types included in UBL 2.1 are listed in Section 2.18, “Document Types”. It is importantto note that, as with previous UBL releases, the UBL 2.1 library is designed to support the constructionof a wide variety of document types beyond those provided in the 2.1 package. It is expected that imple-menters will develop their own customized document types and components and that more UBL document

30 May 2011Page 12 of 156


types will be added as the library evolves. For guidance in customizing UBL document types, see theUBL Guidelines for Customization [Customization].

2.1. General Business RequirementsThis section describes some of the requirements and general business rules that are assumed for col-laborations and document exchanges in UBL 2.1.

2.1.1. Items

• An item may be a product or a service

• Items may have multiple classifications

• A contract may influence prices

• 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

2.1.2. 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.

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 product code and re-quires 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 whichthe 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 descriptivespecification of the item.

30 May 2011Page 13 of 156


2.1.3. Item Instances

Certain Items may be identified and ordered as individual, unique objects—for example, a specific carrather 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.

2.1.4. Item Pricing

For any given Item, price ranges by amount, quantity, location, etc., are specified by the Seller duringthe sourcing stage. They are not repeated back to the Seller during Ordering; only the active price isspecified.

In some cases, the Buyer may not know the Item Price, in which case it is not specified. This makes adetailed response from the Seller necessary; see Order Response.

2.1.5. Hazardous Items

Although ordered items may include Hazardous items, it is not necessary to specify information relatedto Hazardous status at the order stage.The Buyer may not be aware of the nature of the Item. Indicationof the Hazardous nature of the Item, and any relevant information, would be indicated in the DespatchAdvice and Transportation documents.

2.1.6. Parties

In UBL, a party is defined as an individual, a group, or a body having a role in a business function. De-pendent on the business process, a Party may play various roles in the document exchange. For a listof UBL parties and their roles, see Section 2.19, “Party Roles”.

2.1.7. Multilingual Text

Some textual components, such as Notes and Description, may be specified in several languages. Eachshould 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.

2.2. Overview of Business ProcessesFollowing from UBL 2.0, the UBL 2.1 documents and library support an increased range of differentbusiness processes. These processes (with the additions in 2.1 shown in underlined boldface) can becategorized as follows:

ProcurementSourcing

Pre-AwardTenderingCatalogue

Post-AwardCatalogueQuotation

OrderingFulfilmentBilling

Freight BillingUtility Billing

Payment

30 May 2011Page 14 of 156


ReplenishmentCollaborative Planning, Forecasting and ReplenishmentVendor Managed Inventory

Cyclic Replenishment ProgramTransportation

International Freight ManagementIntermodal Freight ManagementFreight Status Reporting

International TradeCertification of Origin of Goods

The following sections contain the formal business process descriptions:

Section 2.3, “Tendering”Section 2.4, “Catalogue”Section 2.5, “Quotation”Section 2.6, “Ordering”Section 2.7, “Fulfilment”Section 2.8, “Billing”Section 2.9, “Freight Billing”Section 2.10, “Utility Billing”Section 2.11, “Payment”Section 2.12, “Collaborative Planning, Forecasting, and Replenishment”Section 2.13, “Vendor Managed Inventory”Section 2.14, “International Freight Management”Section 2.15, “Intermodal Freight Management”Section 2.16, “Freight Status Reporting”Section 2.17, “Certification of Origin of Goods”

2.3.TenderingTendering is the case where a contracting authority (the Originator) initiates a procurement project tobuy goods, services, or works during a specified period, as shown in the following diagram.

Figure 2. The Tendering Process

30 May 2011Page 15 of 156


2.3.1. Contract Information Preparation

The Tendering process optionally begins with publication of a Prior Information Notice prepared by aContracting 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 Noticeis published (see Section 2.3.2, “Contract Information Notification”).

Figure 3. Contract Information Preparation

30 May 2011Page 16 of 156


2.3.2. Contract Information Notification

The process of Notification includes the publication by the Contracting Authority of a Contract Notice toannounce 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 OfficialJournal of the EU. Other tendering contexts will differ in their publication requirements.

Figure 4. Contract Information Notification

30 May 2011Page 17 of 156


2.3.3. Invitation to Tender

In some procedures, the Contracting Authority invites economic operators to participate in a contest bysending them an invitation to tender using a Call for Tenders to define the procurement project to buygoods, services, or works during a specified period. The Call For Tenders may be sent jointly with anunstructured letter of invitation to tender.

Figure 5. Invitation to Tender

2.3.4. Submission of Qualification Information

The economic operator sends a Tenderer Qualification to the Contracting Authority to define its ownsituation 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 admissionto or exclusion from the tendering process.

30 May 2011Page 18 of 156


Figure 6. Submission of Qualification Information

2.3.5. Submission of Tenders

A Tenderer submits one or more Tender documents that offer a tender to the Contracting Authority forbid. The Contracting Authority responds with a Tender Receipt to notify the reception of the tender fora tendering process.The date and time of the Tender Receipt are significant, because tendering proced-ures usually have tight deadlines for tender presentation.

Figure 7. Submission of Tenders

30 May 2011Page 19 of 156


2.3.6. 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 tendereror the Unawarded Notification document to communicate that the contract has been awarded to anothertenderer.

Figure 8. Award Notification

Second, the Contracting Authority causes a Contract Award Notice to be published to announce theawarding of a procurement project.

30 May 2011Page 20 of 156


Figure 9. Award Publication

Finally, the Tenderer sends a Guarantee Certificate to notify the deposit of a guarantee.

Figure 10. Guarantee Deposit

2.4. CatalogueA Catalogue is a document produced by a party in the procurement chain that describes items andprices. Document types associated with Catalogue processes are Catalogue Request, Application Re-sponse, Catalogue Item Specification Update, Catalogue Pricing Update, and Catalogue Deletion.

2.4.1. Catalogue Business Rules

• Any conditions specified in the contract shall overrule those stated in the common Catalogue.

30 May 2011Page 21 of 156


• 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 beavailable 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 updatesto either pricing or item specification details.

• Whether Receiver Party initiated or not, the decision to issue a new Catalogue or update an existingone 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 theCatalogue.

2.4.2. Catalogue Provision

Catalogue provision is the case where a Provider sends information regarding items available for purchaseto a Receiver. This may be on request or unsolicited. Because they are only potential purchasers, aReceiver may never become a Customer Party.

2.4.2.1. Create Catalogue

The process of creating a Catalogue is shown in the following diagram.

30 May 2011Page 22 of 156


Figure 11. Create Catalogue Process

30 May 2011Page 23 of 156


2.4.2.2. Update Catalogue Item Specification

The process of updating a Catalogue Item Specification is shown in the following diagram.

Figure 12. Update Item Specification Process

30 May 2011Page 24 of 156


2.4.2.3. Update Catalogue Pricing

The process of updating Catalogue pricing is shown in the following diagram.

Figure 13. Update Catalogue Pricing Process

30 May 2011Page 25 of 156


2.4.2.4. Delete Catalogue

Deletion of a Catalogue is shown in the following diagram.

Figure 14. Delete Catalogue Process

2.4.2.5. Punchout

Punchout is a technological innovation whereby an Originator is able to directly access a Seller’s applic-ation from within their own procurement application.

30 May 2011Page 26 of 156


Figure 15. Punchout Sourcing Process

The Originators leave (“punch out” from) their system and interact with the Seller’s catalogue to locateand order products, while their application transparently gathers pertinent information.

While conceptually the punchout request is a form of Request for Quote, the exchange transaction istightly coupled to the specific catalogue application and is considered outside the scope of UBL.

2.5. QuotationLess formally defined than a tender, a quotation process is the case where the Originator asks for aquotation, as shown in the following diagram.

Figure 16. Quotation Process

30 May 2011Page 27 of 156


2.6. OrderingOrdering is the collaboration that creates a contractual obligation between the Seller Supplier Party andthe Buyer Customer Party. Document types in these processes are Order, Order Response, Order Re-sponse Simple, Order Change, and Order Cancellation.

Figure 17. Ordering Process

2.6.1. Ordering Business Rules

• The Order may specify allowance and charge instructions (e.g., freight, documentation, etc.) thatidentify 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 againsta direct debit agreement. The Order allows for an overall currency defining a default for all pricingand also a specific currency to be used for Invoicing. Within an Order, additional currencies may bespecified 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, inwhich case it is not specified. This makes a detailed response from the Seller necessary; see OrderResponse (Section 2.6.3).

• 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.

30 May 2011Page 28 of 156


2.6.2. Order Response Simple

The Order Response Simple is the means by which the Seller confirms receipt of the Order from theBuyer, indicating either commitment to fulfil without change or that the Order has been rejected.

2.6.3. 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 ordertransaction.

It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that werenot 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 Re-sponse.

2.6.4. Order Change

The Buyer may change an established Order in two ways, subject to the legal contract or trading partneragreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see Sec-tion 2.6.5, “Order Cancellation”) 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 changingordered items, quantity, delivery date, ship-to address, etc. Suppliers may accept or reject the OrderChange using either Order Response or Order Response Simple.

2.6.5. Order Cancellation

At any point of the process, a Buyer may cancel an established order transaction using the Order Can-cellation document. Legal contracts, trading partner agreements, and business rules will determine thepoint at which an Order Cancellation will be ignored (e.g., at the point of manufacture or the initiation ofthe delivery process). Given the agreements and rules, an Order Cancellation may or may not be anautomated business transaction.The terms and conditions of contract formation for business commitmentswill dictate which, if any, of these restrictions or guidelines will apply.

2.7. FulfilmentFulfilment is the collaboration in which the goods or services are transferred from the Despatch Partyto the Delivery Party.

Document types in these processes are Despatch Advice, Receipt Advice, Order Cancellation, and OrderChange.

In common practice, fulfilment is either supported by a proactive Despatch Advice from the DespatchParty or by a reactive Receipt Advice from the Delivery Party.

30 May 2011Page 29 of 156


If the Customer is not satisfied with the goods or services, they may then cancel or change the order(see Section 2.6, “Ordering”).

The Seller may have a fulfilment (or customer) service dealing with anomalies.

Figure 18. Fulfilment with Despatch Advice Process

2.7.1. Despatch Advice Business Rules

The Despatch Advice is sent by the Despatch Party to the Delivery Party to confirm shipment of items.

The Despatch Advice provides for two situations:

1. Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver cancheck the Transport Handling Unit and then the contained items. Quantities of the same item onthe same Order Line may be separated into different Transport Handling Units and hence appearon separate Despatch Lines within a Transport Handling Unit.

2. Organization of the delivery set of items by Despatch Line, annotated by the Transport HandlingUnit in which they are placed, to facilitate checking against the Order. For convenience, any OrderLine split over multiple Transport Handling Units will result in a Despatch Line for each TransportHandling 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 arebeing, 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 arebeing, 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 linkedby a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines

30 May 2011Page 30 of 156


from one Order Line. Equally, partial despatch may result in some Order Lines not being matched byany Line in a Despatch Advice.

Within a Despatch Advice, an Item may also indicate the Country of Origin and the Hazardous natureof the Item.

2.7.2. Receipt Advice Business Rules

The Receipt Advice is sent by the Delivery Party to the Despatch Party to confirm receipt of items andis capable of reporting shortages or damaged items.

Figure 19. Fulfilment with Receipt Advice Process

The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimeddelivery, it must be organised in the same way as the corresponding Despatch Advice:

1. Indication of receipt by Transport Handling Unit(s) and contained Receipt Lines one-to-one with theDespatch Advice as detailed by the Seller party, or

2. Indication of receipt by Receipt Lines annotated by Transport Handling Unit, one-to-one with theDespatch Advice as detailed by the Seller party.

The Receipt Advice allows the Delivery Party to state any shortages from the claimed despatch quantityand to state any quantities rejected for a given reason.

2.8. BillingIn the Billing process, a request is made for payment for goods or services that have been ordered, re-ceived, 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:

1. Traditional Billing

30 May 2011Page 31 of 156


a. Using Credit Note

b. Using Debit Note

2. Self Billing (also known as billing on receipt)

a. Using Credit Note

b. Using Self Billed Credit Note

2.8.1. Billing Business Rules

The Invoice is normally issued on the basis of one despatch event triggering one invoice. An Invoicemay also be issued for pre-payment on a whole or partial basis. The possibilities are:

• Prepayment invoice (payment expected)

• Pro-forma invoice (pre 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 reiterateany 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.

Taxation on the Invoice allows for compound taxes, the sequence of calculation being implied by thesequence of information repeated in the data stream (e.g., Energy tax, with VAT—Value AddedTax—superimposed).

Charges may be specified either as a lump sum or by percentage applied to the whole Invoice valueprior 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/orReceipt Line.

2.8.2.Traditional Billing

Traditional billing is where the supplier invoices the customer when the goods are delivered or the servicesprovided. In this case, the invoice may be created at the time of despatch or when the Delivery Partyacknowledges that the goods have been received (using a Receipt Advice).

When there are discrepancies between the Despatch Advice, Receipt Advice, and/or the Invoice andthe goods actually received, or the goods are rejected for quality reasons, the customer may send anApplication Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or an-other 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 Paymentcollaboration).

30 May 2011Page 32 of 156


2.8.2.1. Billing Using Credit Notes

Billing using Credit Notes is shown in the following diagram.

Figure 20. Billing with Credit Note Process

When using Credit Notes, the Supplier (in their Accounting role) is responsible for specifying the tax re-quirements.

2.8.2.2. Billing Using Debit Notes

Billing using Debit Notes is shown in the following diagram.

30 May 2011Page 33 of 156


Figure 21. Billing with Debit Note Process

When using Debit Notes, both the Supplier (in their Accounting role) and the Customer (in their Accountingrole) are responsible for providing taxation information.

30 May 2011Page 34 of 156


2.8.3. 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.

2.8.3.1. Self Billing Using Credit Notes

Self Billing using Credit Notes is shown in the following diagram.

Figure 22. Self Billing with Credit Note Process

If the Supplier finds that the Self Billed Invoice is incorrect, e.g., wrong quantities or wrong prices, or ifthe goods have not been invoiced at all, it may send an Application Response or a Credit Note to theCustomer.The customer may then verify whether the adjustment is acceptable or not and consequentlyissue another Self Billed Invoice or a Self Billed Credit Note.

30 May 2011Page 35 of 156


2.8.3.2. Self Billing Using Self Billed Credit Notes

Self Billing using Self Billed Credit Notes is shown in the following diagram.

Figure 23. Self Billing with Self Billed Credit Note Process

When using Self Billed Credit Notes, the Customer is raising the Self Billed Credit Note in the name andon behalf of the Supplier.Therefore the Supplier and the Customer are still both responsible for providingtaxation information.

30 May 2011Page 36 of 156


2.8.4. Reminder for Payment

A Reminder may be used to notify the Customer of accounts due to be paid.

Figure 24. Reminder for Payment Process

30 May 2011Page 37 of 156


2.9. Freight BillingAn extension of the Billing process is that of Freight Billing. This represents the billing process betweenthe Transport Service Buyer and Transport Service Provider through the use of an Invoice for freightcharges.

The Transport Service Provider initiates the process of billing the Transport Service Buyer for logisticservices.

The Freight Invoice lists the charges incurred in order to fulfil the agreed service.

Figure 25. Freight Billing Process

2.10. Utility BillingThis 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.

30 May 2011Page 38 of 156


Figure 26. Utility Billing Process

2.11. PaymentIn the payment process, the Payee (who is most often the Accounting Customer) is notified of any fundstransferred, against the account of the Accounting Supplier, using a Remittance Advice.

The document type in this process is the Remittance Advice.

Figure 27. Payment Process

30 May 2011Page 39 of 156


2.11.1. Report State of Accounts

A Statement of Account may be used to notify the Accounting Customer of the status of the billing.

Figure 28. Statement Process

30 May 2011Page 40 of 156


2.12. Collaborative Planning, Forecasting, and Replen-ishmentThe VICS Collaborative Planning, Forecasting, and Replenishment (CPFR®) guidelines [CPFR] formalizethe processes by which two trading partners agree upon a joint plan to forecast and monitor sales throughreplenishment 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 havebeen extended to cover the planning process between other parties such as the manufacturer and thesupplier. These binary collaboration definitions are the template guidelines for implementers to buildtheir own collaboration process based on their supply chain topology and requirements.

Figure 29. CPFR

30 May 2011Page 41 of 156


As shown above, the seller and the buyer employ four main activities in order to improve the overallperformance of the supply chain:

1. Strategy and Planning establish the ground rules for the collaborative relationship.Trading partnersexchange information about their corporate strategies and business plans in order to collaborateon developing a joint business plan. The Joint Business Plan identifies the significant events thataffect supply and demand in the planning period, such as promotions, inventory policy changes,store openings/closings, and product introductions.

2. The Demand and Supply Management phase involves the development of a shared plan on theconsumer demand. The consumer demand at the point of sale is categorized as sales forecastingand the future product ordering based on the sales forecast is referred as order forecast.

3. Execution 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.

4. The Analysis phase involves monitoring the execution of activities for exceptions that are identifiedduring the strategy and planning phase. Calculation of key performance metrics and plan adjustmentsfor improving results also take place in this phase.

While these collaboration activities are presented in logical order, most companies are involved in all ofthem at any moment in time. There is no predefined sequence of steps. Execution issues can impactstrategy, and analysis can lead to adjustments in forecasts.

2.12.1. Collaboration Agreement and Joint Business Planning

The Collaboration Arrangement is the preparatory step that defines the scope of the project, assignsroles, establishes procedures for data interchange, and issues identification and resolution.The followingactions 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.

30 May 2011Page 42 of 156


Figure 30. CPFR Steps 1 and 2

The first step of the CPFR Process continues with the exchange of messages containing purchaseconditions. (In this initial OASIS public review build, these are assumed to be generic purchase conditionmessages. A UBL document type for Purchase Conditions is planned for addition in the second publicreview cycle.) Afterwards, for determining the exception criteria that should be monitored and handled

30 May 2011Page 43 of 156


during the execution, Exception Criteria messages are exchanged. Exchange of Exception Criteria Re-vision messages continues until the criteria are accepted by both sides.

Figure 31. Establish Collaborative Relationships

In CPFR Step 2 (the Joint Business Planning phase) there are two messages that should be exchangedand agreed upon: Retail Event and Trade Item Location Profile. The revisions are exchanged until anagreement is achieved.

30 May 2011Page 44 of 156


Figure 32. Create Joint Business Plan

2.12.2. Sales Forecast Generation and Exception Handling

CPFR Step 2 helps the buyer and seller agree to the event details and calendar that meet their jointbusiness and collaboration objectives. The objective of the event calendar is to ensure that events are

30 May 2011Page 45 of 156


planned to achieve the optimal results and to enable both parties to plan the execution of the event moreaccurately, from the preparation of advertising and displays to the production and delivery of the promo-tional stock.

In CPFR Step 3, the Sales Forecast is generated. Following Option A, Conventional Order Management,from the CPFR implementation scenarios (see [CPFRoverview], Table 3), the responsible partner forthe generation of Sales Forecast is the Seller. Having Event Calendar information and the Delivery Planalready in their system, there are two more kinds of information that the Seller needs for an effectiveSales Forecast: POS Data and DC Data. As shown in Figure 25, both of these pieces of information aresent within a Product Activity Message. This time there is no revision of the messages because thesemessages contain statistical and historical information collected previously by the Buyer.

Figure 33. CPFR Steps 3, 4, and 5

30 May 2011Page 46 of 156


Based on the event details (dates, products, tactics, etc.) and using the available data source(s), avolume estimate/forecast is created for each product/store combination included in the scope of theevent by the Seller. During the calculation, sales forecasting algorithms make use of the coefficients forcausal factors based on the event history. Once the Sales Forecast suggestion is generated and sentto the Buyer, the Buyer revises it and might recommend some changes on the Forecast. The ForecastRevision message exchange continues until the forecast is agreed by both sides.

Figure 34. Create Sales Forecast

On average, six weeks elapse between Sales Forecast Generation and Order Generation. During thisperiod, both sides observe changes to the conditions. If one of the partners detects an exception inval-

30 May 2011Page 47 of 156


idating the exception criteria defined in CPFR Step 1, it sends an Exception Notification message to theother party. Exceptional circumstances that may be communicated between trading partners includedeviations between planned impacts (either between buyer and seller, or between subsequent generationsof planned impacts from the same trading partner), as well as deviations between planned and actualimpacts. It should be noted that both sides might detect an exception, and therefore both sides shouldbe capable of sending and receiving exceptions. Of course, for specific implementations if the collabor-ating parties want to change this behaviour, they can customize the process so that one partner will beresponsible for the generation of the exception notifications.

CPFR Step 4 is solely composed of the exception generation and receiving activity. CPFR Step 5, onthe other hand, is the resolution of the Exceptions.

Figure 35. Exception Handling

If there is no Exception Notification Message within the defined period, the process continues with OrderForecast Generation (CPFR Step 6).

2.12.3. Order Forecast Generation and Exception Handling

In the supply chain process, it is important for sales forecasts that are created to be converted into theshipment (order) forecasts that can then be used in the production planning processes at the manufac-turing locations and be incorporated into the ordering processes at the retailer. As shown in Figure 28,the responsibility for creating Order Forecast belongs to the Seller per Option A of the CPFR implement-ation scenarios (see [CPFRoverview], Table 3). Sales forecasts can be transformed into order forecastsby 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 tothe Seller.

30 May 2011Page 48 of 156


Figure 36. CPFR Steps 6, 7, 8 and 9

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 requestsif necessary. The exchange of Order Forecast Revisions continues until there are no further update re-quests and the Order Forecast is agreed by both sides.

30 May 2011Page 49 of 156


Figure 37. Create Order Forecast

After the Order Forecast is frozen, the process continues with the exception detection activity (CPFRStep 7). The exception detection process that follows Order Forecast is similar to process describedearlier for exeption detection following Sales Forecast (see Section 2.12.2, “Sales Forecast Generationand Exception Handling”).The only difference between the Order Forecast and Sales Forecast exceptionsis the content of the exceptions.

30 May 2011Page 50 of 156


CPFR Step 8, Order Forecast Exception Resolution activity, is handled similarly to Sales Forecast Ex-ception Resolution.

Figure 38. Identifying and Resolving Exceptions for Order Forecast

30 May 2011Page 51 of 156


Figure 39. Exception Monitor During Execution

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 thecase of Order Forecast Exception Handling and Sales Forecast Exception Handling. The difference isin the content of the exceptions. The actual events and orders are compared to the Forecasted Salesand Forecasted Orders.When there is a situation violating the normal exception criteria, one of the sidesmight generate an exception notification. Besides comparison of forecasts, other information gatheredduring the execution is observed (e.g., event dates, POS data, etc.). The resolution of the exceptionsis the same as the process carried out for Sales Forecast Exception resolution.

During this exception monitoring time, Buyer also waits for a possible Termination message indicatingthe end of the collaboration. The Termination message is not mentioned by the CPFR guidelines but isincluded in UBL to indicate the successful termination of the CPFR collaboration. Since the CPFRPlanning Process is supposed to be an iterative process, most of the time there will not be a terminationmessage and the process will continue from CPFR Step 2 with a new cycle of forecast generation andorder execution.

30 May 2011Page 52 of 156


2.13. Vendor Managed InventoryVendor Managed Inventory (VMI) is a family of business processes in which the Retailer Customer Partyfor an item provides certain information to the Seller Supplier Party, and the Seller Supplier Party takesfull responsibility for maintaining an agreed-upon inventory of the item, usually at the Retailer CustomerParty's point of sale. A third party logistics provider can also be involved to make sure that the RetailerCustomer 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 semanticsused here come from a large-scale UBL application developed for the Italian textile and clothing industryby ENEA, the Italian National Agency for New Technologies, Energy, and Sustainable Economic Devel-opment (see [eBiz-TCF]). These models are applicable to the implementation of vendor-managed rela-tionships in a broad range of retail sectors, but for the sake of simplicity, and in keeping with the modelapplication, the two principal parties in the VMI relationship (the Seller Supplier Party and the RetailerCustomer Party) are referred to as "producer" and "retailer" in the descriptions that follow; more gener-ically, they are vendor and customer.

2.13.1. Basic Vendor Managed Inventory

In the classic VMI scenario, a shop-within-a-shop area or an entire store is managed completely by theproducer. The logistic concept of VMI can be combined with consignment/concession as well as withcharge-on-delivery as the financial model. Mostly it is combined with consignment.

2.13.1.1. Initial Stocking of the Area by Producer

At the beginning of the cooperation, the area is stocked by the producer. The retailer receives item anddelivery information and reports back the goods actually received.

30 May 2011Page 53 of 156


Figure 40. Initial Stocking of the Area by Producer

2.13.1.2. Report of Sales and Inventory Movement

The sales and inventory movement information is transferred from the retailer to the producer.

30 May 2011Page 54 of 156


Figure 41. Report of Sales and Inventory Movement

2.13.1.3. Permanent Replenishment

Based on sales and inventory movement, the producer periodically makes a new delivery of goods ac-companied by a Despatch Advice. If the delivery contains an item not previously stocked, an updatedcatalogue is also sent so that the retailer can add the item to its product database. Upon delivery of thegoods, the retailer reports back the items received using a Receipt Advice.

Figure 42. Permanent Replenishment

30 May 2011Page 55 of 156


2.13.1.4. Invoicing for Vendor Managed Inventory

An invoice is sent either on a delivery or a sales basis. In a charge-on-delivery model, the data for theinvoice is prepared from the delivery, and in a consignment/concession model from the sales reports.

Figure 43. Invoicing for Vendor Managed Inventory

2.13.1.5. Returns Initiated by the Producer

If sales do not meet expectations, items are reallocated by the producer. Because the producer cannotrequest a retailer to send the products to a competitor, the producer requests a return and handles thegoods afterwards by itself.

30 May 2011Page 56 of 156


Figure 44. Returns Initiated by the Producer

2.13.1.6. Price Adjustments

In the event of a price change, an updated price list (in the form of a new catalogue containing thechange) is sent from producer to retailer.

Figure 45. Price Adjustments

30 May 2011Page 57 of 156


2.13.2. Cyclic Replenishment Program (CRP)

A variant of VMI is the Cyclic Replenishment Program (CRP). In this process, the producer establishesa catalogue of NOS (Never Out of Stock) or seasonal NOS items, and the retailer chooses items forcyclic (weekly) replenishment. The logistic scenario can be combined with the charge-on-delivery aswell as with a consignment/concession model. At the end of every sales period, a report of sales andinventory 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 producercannot change the terms of the order.

2.13.2.1.Transfer of Base Item Catalogue

The producer publishes the catalogue of its NOS and seasonal NOS items to the retailer.

Figure 46. Transfer of Base Item Catalogue

2.13.2.2. Initial Stocking of the Area by Retailer

At the beginning of the cooperative relationship—or the beginning of a season, if seasonal NOS productsare the focus—the retailer orders its base stock, and the products are delivered.

30 May 2011Page 58 of 156


Figure 47. Initial Stocking of the Area by Retailer

2.13.2.3. Periodic (Weekly) Replenishment

Each period (every week), the retailer's system calculates the quantities needed for replenishment ofthe product area. From the result, an order is sent, and the producer responds with a direct deliverywithin 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 Figure 47, “Initial Stocking of the Area by Retailer”. It mustbe remembered, however, that the two processes are taking place at different points in time, so theirpre and post conditions will be different.

30 May 2011Page 59 of 156


2.13.2.4. 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 sentfrom the retailer to the producer.

Figure 48. Report of Sales and Inventory Movements

2.13.2.5. Cyclic Replenishment Program Invoicing

An invoice is sent either on a delivery or a sales basis.

Figure 49. Invoicing for Cyclic Replenishment Program

2.13.2.6. Synchronizing of Stock Information

Information about the actual stock is synchronised periodically (for example, every one to three months).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.

30 May 2011Page 60 of 156


Figure 50. Synchronizing Stock Information

2.13.2.7. Changes to the Item Catalogue

In the event of a change, either inside an item belonging to the CRP catalogue or the relationship of anitem to the CRP catalogue, information about the change is sent to the retailer.

Figure 51. Changes to the Item Catalogue

2.13.3. Replenishment On Customer Demand

Another variant of VMI is Replenishment On Customer Demand. In this process, the producer selectsa subset of its products for a specific retailer and sends out the related article catalogue. Then the pro-ducer periodically sends information about the availability of items so that the retailer can form the bestordering plan. The replenishment periodically happens on retailer (customer) demand, and unlike thecase with CRP (above), the producer is allowed to propose changes to the orders. Also, because of therequirement 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 thecatalogue are identical to the same processes in CRP. As with CRP, a report of sales and inventorymovement at all retail locations is sent to the producer at the end of every sales period. Invoicing andlogistics are normally charge-on-delivery but can also be based on a consignment/concession model.

30 May 2011Page 61 of 156


2.13.3.1.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 NOSarticles.

Figure 52. Transfer of Base Article Catalogue

2.13.3.2. Periodic Transfer of Article Availability Information

The producer sends out information about availability of goods (quantities on hand, quantities incoming,articles out of stock).

Figure 53. Periodic Transfer of Article Availability Information

2.13.3.3. 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 seasonalNOS (never out of stock) products are the focus—the retailer orders its base stock and the products aredelivered. Note that the producer is allowed to propose changes to the order (compare this figure withFigure 47, “Initial Stocking of the Area by Retailer”).

30 May 2011Page 62 of 156


Figure 54. Initial Stocking of the Area by Producer and Retailer

2.13.3.4. Periodic Replenishment

Periodically, the retailer's system calculates the quantities needed for replenishment of the area. Fromthe 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 Figure 54, “Initial Stocking of the Area by Producer andRetailer”. It must be remembered, however, that the two processes are taking place at different pointsin time, so their pre and post conditions will be different.

2.13.3.5. 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 Figure 48, “Report of Salesand Inventory Movements”).

30 May 2011Page 63 of 156


2.13.3.6. 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 Figure 49,“Invoicing for Cyclic Replenishment Program”).

2.13.3.7. 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 Figure 50, “Synchronizing Stock Information”).

2.13.3.8. Changes to the Article Catalogue

In the event of a change, either inside an item belonging to the catalogue or the relationship of an itemto the catalogue, information about the change is sent to the retailer.

The process for changing the catalogue in Replenishment On Customer Demand is the same as in CRP(see Figure 51, “Changes to the Item Catalogue”).

2.14. International Freight ManagementFreight management for domestic trade is typically accomplished using DespatchAdvice and ReceiptAd-vice (see Section 2.7, “Fulfilment”). The additional processes shown in Figure 55, “Initiate Freight Man-agement Process”, are engineered to support the ordering and management of logistical services forinternational trade.

With receipt of an order and acknowledgement by the Supplier Party that the goods are available andready to be shipped, the Consignor or Consignee initiates the transportation arrangements.This includesbooking the consignment with a Transport Service Provider such as the Freight Forwarder or Carrierand 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 Section 2.16, “Freight Status Reporting”).

It should be noted that these processes involve the Consignee and Consignor and do not cover all thelogistical processes required to physically move the goods or regulatory notifications such as Customsdeclarations.

30 May 2011Page 64 of 156


Figure 55. Initiate Freight Management Process

2.14.1. Forwarding Instructions

Forwarding Instructions are normally used by any party who gives instructions for the transportationservices required for a consignment of goods (the Transport Service Buyer) to any party who is contractedto provide the transportation services (called the Transport Service Provider). Forwarding Instructionsmay also be used by any party who requests a booking of shipment space to be made for the transport-ation services required for a consignment of goods to any party who will provide the underlying trans-portation services. The parties who issue this document are commonly referred to as the shipper, con-signee, or consignor, while the parties who receive this document are forwarders, carriers, shippingagents, etc.

Forwarding Instructions may also be issued by a freight forwarder or shipping agent in their capacity asa 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.

2.14.2. Packing List

A Packing List is normally issued by the Consignor. It states the distribution of goods in individualpackages.

30 May 2011Page 65 of 156


Based on this detail, the party who provides the logistic services will make arrangement for the transport-ation of the goods.

2.14.3. Bill of Lading

A Bill of Lading is issued by the party who provides the physical transportation services (e.g., carrier) tothe party who gives instructions for the transportation services (shipper, consignor, etc.) stating the detailsof the transportation, charges, and terms and conditions under which the transportation service isprovided.

A Bill of Lading may also be issued by the party who acts as an agent for the carrier or other agents tothe party who gives instructions for the transportation services (shipper, consignor, etc.) stating the detailsof the transportation, charges, and terms and conditions under which the transportation service isprovided, but who does not provide the physical transportation service.

A Bill of Lading corresponds to the information on the Forwarding Instructions. It is used for ocean orriver modes of transport.

A Bill of Lading may serve as a contractual document between the parties for the transportation service.The document evidences a contract of carriage by sea and the acceptance of responsibility for the goodsby the carrier, by which the carrier undertakes to deliver the goods against surrender of the document.A provision in the document that the goods are to be delivered to the order of a named person, or toorder, or to bearer, constitutes such an undertaking.

2.14.4. Waybill

A Waybill is issued by the party who provides the physical transportation services to the party who givesinstructions for the transportation services (shipper, consignor, etc.). It states the details of the transport-ation, 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. It is issuedas a cargo receipt and is not required to be surrendered at the destination in order to pick up the cargo.This simplifies the documentation procedures between a Transport Service Buyer and a TransportService Provider.

2.15. Intermodal Freight ManagementIntermodal transport implies the use of a combination of transport modes. Any support for the managementof such chains has to support the modal shift of cargo flows from road to intermodal transport using roadin combination with short sea shipping, inland waterways, and rail.

The Intermodal Freight Management process differs from conventional freight management in that it isgeneric and independent of transport mode. The focus is the multimodal transport chain as seen fromthe Transport User’s point of view.The Transport User needs information about all the possible transportservices that can be used to build a complete transport chain. If the choices to be made by the TransportUser are based upon the qualities of the transport services themselves, and not by which transport modeis used, the description of the transport services, and the exchanges of information about the roles andservices must be simple and common.

The roles of the various Parties are defined as follows:

• The Transport User is the role representing anyone that needs to have cargo transported. TheTransport User also provides the Transport Service Provider with instructions and detailed informationabout the transport items to be transported.

• The Transport Service Provider is the role that ensures the transport of the cargo from the origin tothe destination. This includes the management of the transport services and the operation of the

30 May 2011Page 66 of 156


transport means and handling equipment. A Transport Service Provider may also provide adminis-trative services required for moving the cargo, such as cargo inspection.

• The Transportation Network Manager is the role that extracts all information available regarding theinfrastructure (static or dynamic) related to planning and executing transport and makes this inform-ation available to the Transport User and the Transport Service Provider.

• The Transport Regulator is the role that receives all mandatory reporting (and checks if reportinghas been carried out) in order to ensure that all transport services are completed according to existingrules and regulations.

It should be noted that a person or organization may take on different roles. For example, a freight for-warder is, on the one hand, a Transport Service Provider when communicating with clients (TransportUsers). On the other hand, the freight forwarder is a Transport User when acquiring services from sub-contractors to ensure that a transport service is carried out between an origin and a destination.

The Intermodal Freight Management process takes place in three stages:

• Planning: Allows Transport Service Providers to advertise their services to Transport Users in acommon format, in terms of a schedule and a freight rate published in a standard format. It allowsTransport Users to provide a short list of potential services from which they can make a final choiceby negotiating with potential Transport Service Providers.This is the "Plan" generic business process.

• Execution: Enables Transport Service Providers to manage the physical transport of the goods, ex-changing information on the status of the shipment with the Transport Users and the status of thetransport infrastructure with Transportation Network Managers; it also allows Transport Users andTransport Service Providers to exchange regulatory information with Transport Regulators (the "Ex-ecute" generic business process).

• Completion: Facilitates the issuing of proof of delivery and invoices between the Transport ServiceProvider and the Transport User (the "Complete" generic business process).

Figure 56. The Generic Freight Management Process

These three stages are detailed in the following diagram.

30 May 2011Page 67 of 156


Figure 57. The Intermodal Freight Management Process

2.15.1.Transport Service Description

The Transport Service Description (TSD) document is used to publish information about a transportservice. 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.

30 May 2011Page 68 of 156


Figure 58. Transport Service Description

2.15.2.Transport Execution Plan

The Transport Execution Plan (TEP) is a plan established between a Transport User and a TransportService Provider.The process of establishing a TEP can be carried out after many interactions betweenthe two roles, from the quotation stage up to the final agreement of the TEP.

The following diagram shows the transactions involved in a basic scenario where the TEP is used tobook and confirm a transport service and to send notification of a completed transport service. The GII(see Section 2.15.3, “Goods Item Itinerary”) is sent from the Transport Service Provider to the TransportUser after the TEP is confirmed by both parties.This document contains route and schedule informationfor all segments involved in a transport service (including segments where parts of the transport servicehave been outsourced to other Transport Service Providers). If there are changes to the execution ofthe transport service, the GII is updated and re-sent to the Transport User.

30 May 2011Page 69 of 156


Figure 59. Transport Execution Plan

30 May 2011Page 70 of 156


2.15.3. Goods Item Itinerary

The Goods item Itinerary (GII) specifies the route and time schedule for a transport item and is issuedfrom the Transport Service Provider to the Transport User. It may contain one or more transport segmentswith different TEPs with different Transport Service Providers. One transport service (one TEP) may beresponsible for more than one segment (leg).

In addition to providing an overview of the initial route and time schedule, the GII is used to record theactual progress in the form of new estimated times for departure and/or arrival and the actual departureand arrival times.The GII therefore contains information that may be used for analyzing the performance(in time) of transport services and for tracing the progress of cargo, if such analysis is required.

Figure 60. Goods Item Itinerary

2.15.4.Transport Execution Status

The Transport Execution Status (TES) provides the status of the execution of a Transport ExecutionPlan (TEP). The TES must always refer to the TEP identifier and will return both the progress status ofthe transport execution and the condition status of the goods items being transported.

The TES may be sent from the Transport Service Provider as a response to a request, or it may be sentas a push operation based on trigger events.

30 May 2011Page 71 of 156


Figure 61. Transport Execution Status Process

2.15.5.Transport Progress Status

The Transport Progress Status (TPS) collects and reports information about the status of the transportmeans. The Transport Service Provider requests the Transportation Network Manager to provide statusinformation related to a specific transport vehicle, using the vehicle identification number.The Transport-ation Network Manager then provides information about the location and time schedule status to theTransport Service Provider. The most typical use of TPS is to ask assistance from the TransportationNetwork Manager when estimated times of arrival are established. Reporting on the status of the goodsthemselves is covered by the Transport Execution Status process (Section 2.15.4, “Transport ExecutionStatus”) and Freight Status Reporting process (Section 2.16, “Freight Status Reporting”).

30 May 2011Page 72 of 156


Figure 62. Transport Progress Status Process

2.16. Freight Status ReportingFreight Status Reporting is the process by which a Freight Forwarder (also known as the TransportService Provider) communicates the status of shipments currently under their management to the Con-signee and/or Consignor (also known as the Transport Users).

A Transportation Status document is provided by the Freight Forwarder, either through an individualspecific request or through an agreed status reporting procedure.

30 May 2011Page 73 of 156


Figure 63. Freight Status Reporting Process

2.17. Certification of Origin of GoodsWhen an Exporter ships certain goods they may be required to attest to the origin of the goods. A Certi-ficate of Origin is a document required by governments declaring that goods in a particular internationalshipment are of a certain origin.

It is the responsibility of the Exporter to sign the Certificate of Origin document and submit it to a localchamber of commerce or designated government agency or board. These parties are the endorser andissuer of the Certificate of Origin. The Endorser must have access to other documents, such as thecommercial invoice and Bill of Lading, in order to verify the Exporter’s claims that the goods originatedin that country. Finally, the issued Certificate of Origin is sent to the Importer.

30 May 2011Page 74 of 156


Figure 64. Certification of Origin of Goods Process

2.18. Document TypesUBL 2.1 defines various document types to support the business processes detailed in the precedingsections. The following table lists all the UBL 2.1 document types together with their target businessprocesses and roles for parties who would typically submit and receive them.

30 May 2011Page 75 of 156


Table 1. Summary of UBL 2.1 Document Types

Receiver RoleSubmitterRole

Processes In-volved

DescriptionDocument Name

ReceiverSenderAnyA document to indicate the application s response to a transaction. This

may be a business response and/or a technical response, sent automat-

ically by an application or initiated by a user.

Application Response

ReceiverSenderAnyA UBL wrapper that allows a document of any kind to be packaged with

the UBL document that references it.

Attached Document

TenderingThe document used to communicate the contract award to the winnerAwarded Notification

Consignor (or

Consignee),

Freight For-

warder, Carrier

Freight Man-

agement

The Bill of Lading is issued by the party who acts as an agent for the

carrier or other agents to the party who gives instructions for the trans-

Bill Of Lading

Freight For-

warder

portation services (shipper, consignor, etc.) stating the details of the

transportation, charges, and terms and conditions under which the

transportation service is provided. The party issuing this document does

not necessarily provide the physical transportation service. It corresponds

to the information on the Forwarding Instruction. It is used for any mode

of transport. A Bill of Lading can serve as a contractual document 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, and by which the carrier undertakes to deliver the

goods against surrender of the document. 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.

TendererContracting

Authority

TenderingThe document used for a Contracting Party to define the procurement

project to buy goods, services or works during an specified period.

Call For Tenders

Contracting

Party

SellerCatalogueThe document that describes items, prices, and price validity.Catalogue

Contracting

Party

SellerCatalogueThe document used to cancel an entire Catalogue.Catalogue Deletion

Contracting

Party

SellerCatalogueThe document used to update information about Items (e.g., technical

descriptions and properties) on an existing Catalogue.

Catalogue Item Specific-

ation Update

Contracting

Party

SellerCatalogueThe document used to update information about prices on an existing

Catalogue.

Catalogue Pricing Up-

date

SellerContracting

Party

CatalogueThe document used to request a Catalogue.Catalogue Request

Issuer, Import-

er

Exporter, Is-

suer

Certification of

Origin of

Goods

A document that describes the Certificate of Origin.Certificate Of Origin

TendererContracting

Authority

TenderingThe document published by a Contracting Party to announce the awarding

of a procurement project.

Contract Award Notice

TendererContracting

Authority

TenderingThe document used for a Contracting Party to announce the project to

buy goods, services or works.

Contract Notice

Customer Ac-

counting Party

Supplier Ac-

counting Party

BillingThe document used to specify credits due to the Debtor from the Creditor.Credit Note

Supplier Ac-

counting Party

Customer Ac-

counting Party

BillingThe document used to specify debits made by the Debtor.Debit Note

DeliveryDespatchFulfilmentThe document used to describe the despatch or delivery of goods and

services.

Despatch Advice

30 May 2011Page 76 of 156



Processes In-volved


Party request-

ing Status on

collaboration

Party currently

controlling

Status of the

collaboration

Any collabora-

tion

A document used to provide information about document status.Document Status

Party currently

controlling

Status of the

collaboration

Party request-

ing Status on

collaboration

Any collabora-

tion

A document used to request the status of another document.Document Status Re-

quest

Collaborative

Planning, Fore-

casting and

Replenishment

Used to specify basic information about the content of the message in-

cluding version number, creation date and time.

Exception Criteria

Collaborative

Planning, Fore-

casting and

Replenishment

The document used to notify an exceptionException Notification

Collaborative

Planning, Fore-

casting and

Replenishment

The document used to specify a forecast.Forecast

Collaborative

Planning, Fore-

casting and

Replenishment

The document used to revise a Forecast.Forecast Revision

Freight For-

warder, Carrier

Consignor (or

Consignee),

Freight For-

warder

Freight Man-

agement

The document issued to a forwarder, giving instructions regarding the

action to be taken for the forwarding of goods described therein. Forward-

ing Instructions is used by any party who gives instructions for the trans-

portation services required for a consignment of goods to any party who

is contracted to provide the transportation services.The parties who issue

this document are commonly referred to as the shipper or consignor,

while the parties who receive this document are forwarders, carriers,

shipping agents, etc. Note that this document may also be issued by a

forwarder or shipping agent in their capacity as a shipper .This document

can be used to arrange for the transportation (1) of different types of

goods or cargoes; (2) whether containerized or non-containerized; (3)

through different modes of transport including multi-modal; and (4) from

any origin to any destination.

Forwarding Instructions

Consignor or

Consignee

Freight For-

warder

Freight BillingA document stating the charges incurred for the logistics service.Freight Invoice

Transport UserTransport Ser-

vice Provider

Intermodal

Freight Man-

agement

A document specifying the route and the time schedule for a transport of

a Goods Item for all segments in a transport service.

Goods Item Itinerary

Contracting

Authority

TendererTenderingA document to notify the deposit of a guarantee.Guarantee Certificate

Cyclic Replen-

ishment Pro-

gram

This document is used to initiate a return of goods. The producer is re-

questing products which are badly sold either for use in other places or

just to free the area from it.

Instruction For Returns

Cyclic Replen-

ishment Pro-

gram

Report about the quantities of each item which are or will be on stock.Inventory Report

30 May 2011Page 77 of 156



Processes In-volved


Customer Ac-

counting Party

Supplier Ac-

counting Party

BillingThe document used to request payment.Invoice

Collaborative

Planning, Fore-

casting and

Replenishment

The document used to request product activity, forecast, or performance

data.

Item Information Re-

quest

SellerBuyerOrderingThe document used to order goods and services.Order

SellerBuyerOrdering, Fulfil-

ment

The document used to cancel an entire Order.Order Cancellation

SellerBuyerOrdering, Fulfil-

ment

The document used to specify changes to an existing Order.Order Change

BuyerSellerOrderingThe document used to indicate detailed acceptance or rejection of an

Order or to make a counter-offer.

Order Response

BuyerSellerOrderingThe document used to indicate simple acceptance or rejection of an entire

Order.

Order Response

Simple

Freight For-

warder

ConsignorFreight Man-

agement

A document stating the detail of how goods are packed.Packing List

Cyclic Replen-

ishment Pro-

gram

Performance History represents a collection of values gathered for key

performance metrics in the trading partner relationship.

Performance History

TenderingThe document used for a Contracting Party to declare the intention to

buy goods, services or works during an specified period.

Prior Information Notice

Cyclic Replen-

ishment Pro-

gram

Product activity represents movement of a product through a location in

terms of the base unit of measure for the item.

Product Activity

OriginatorSellerQuotationThe document used to quote for the provision of goods and services.Quotation

DespatchDeliveryFulfilmentThe document used to describe the receipt of goods and services.Receipt Advice

Customer Ac-

counting Party

and/or Payee

Supplier Ac-

counting Party

and/or Payee

BillingThe document used to remind the customer of payments overdue.Reminder

Customer Ac-

counting Party

and/or Payee

Supplier Ac-

counting Party

and/or Payee

PaymentThe document used to specify details of an actual payment.Remittance Advice

SellerOriginatorQuotationThe document used to request a Quotation for goods and services from

a Seller.

Request For Quotation

Cyclic Replen-

ishment Pro-

gram

The document used to specify basic information about the content of the

Retail Event Meassage message including version number, creation date

and time.

Retail Event

Supplier Ac-

counting Party

Customer Ac-

counting Party

BillingThe Credit Note created by the Debtor in a Self Billing arrangement with

a Creditor; Self Billed Credit Note replaces Debit Note in such arrange-

ments.

Self Billed Credit Note

Supplier Ac-

counting Party

Customer Ac-

counting Party

BillingThe Invoice document created by the Customer (rather than the Supplier)

in a Self Billing relationship.

Self Billed Invoice

Customer Ac-

counting Party

Supplier Ac-

counting Party

BillingThe document used to specify the status of Orders, Billing, and Payment.

This document is a Statement of Account and not intended as a summary

Invoice

Statement

30 May 2011Page 78 of 156



Processes In-volved


Cyclic Replen-

ishment Pro-

gram

Report about the quantities of each item which are or will be on stock.Stock Availability Re-

port

Contracting

Authority

TendererTenderingA message which a tenderer offers a tender to the tendering organization

for bid.

Tender

Contracting

Authority

TendererTenderingA document used for the Tenderer to declare things about his own condi-

tion.

Tenderer Qualification

TendererContracting

Authority

TenderingA message which the procurement organization sends to an economic

operator in order to notify its admision or exclusion to/from the tendering

process

Tenderer Qualification

Response

TendererContracting

Authority

TenderingA message sent by the Contracting Party to an Economic Operator in

order to notify the reception of the tendering offer

Tender Receipt

Collaborative

Planning, Fore-

casting and

Replenishment

This document is used to send trade item attributes which are focused

on replenishment policies.

Trade Item Location

Profile

Consignee,

Consignor

Freight For-

warder

Freight Status

Reporting

A message to report the transport status and/or change in the transport

status (i.e. event) between agreed parties.

Transportation Status

Transport Ser-

vice Provider,

Transport User

Transport

User, Trans-

port Service

Provider

Intermodal

Freight Man-

agement

A document which is used in the negotiation of a transport service between

a transport user and a transport service provider

Transport Execution

Plan


vice Provider

Intermodal

Freight Man-

agement

The Transport Execution Status is used to provide the transport user with

timing and condition status information about the transport operation

Transport Execution

Status

Transport Ser-

vice Provider

Transportation

Network Man-

ager

Intermodal

Freight Man-

agement

A document being sent from Transportation Network Manager to Transport

Service Provider giving a status on the transport means

Transport Progress

Status


vice Provider

Intermodal

Freight Man-

agement

A document being sent from the Transport Service Provider to the

Transport User in order to announce a transport service

Transport Service De-

scription

TendererContracting

Authority

TenderingThe document used to communicate the contract has been awarded to

another tenderer

Unawarded Notification

Customer Ac-

counting Party

Supplier Ac-

counting Party

Utility BillingThe Utility Statement contains information on the consumption of services

provided by utility suppliers to private and public customers. These utilities

include electricity, gas, water and telephony services.The Utility Statement

is therefore a supplement to an Invoice or CreditNote.

Utility Statement

Consignor (or

Consignee),

Freight For-

warder

Freight For-

warder, Carrier

Freight Man-

agement

The Waybill is 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. The party issuing this document could be a party other than

that providing the physical transportation. It corresponds to the information

on the Forwarding Instruction. It is used for all modes of transport. It can

serve as a contractual document between the parties for the transportation

service.The document made out by the carrier or on behalf of the carrier

evidencing the contract for the transport of cargo.

Waybill

30 May 2011Page 79 of 156


2.19. Party RolesIn the UBL supply chain processes, two main actors, Customer and Supplier, represent the key organ-izations or people involved in the processes. Each of these actors may play various roles. Some processesmay 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 andDelivery Party as applied to the Procurement process may differ in the Transportation process. In otherwords, whether the Consignor in a Transportation process is actually equal to the Despatch Party orSeller in the Procurement process depends on the specific circumstances.

The following table contains a description of the typical roles for the actor known as Party. Note thatsome roles require an extension of the information entities required. In UBL 2.1, the following are rolesthat extend the Party structure: Customer Party, Supplier Party, Contracting Party, Endorser Party, andQualifying Party.

30 May 2011Page 80 of 156


Table 2. Party Roles

ReceivesSendsSynonymsExampleDescriptionRoleActor

QuotationRequest for

Quotation

If an employee requests

a computer, the employ-

The party that had the original

demand for the goods and/or

OriginatorCustomer Party

ing company may be-services and therefore initiated

come the Buyer, but thethe procurement transaction.The

employee is the Origin-Originator participates in pre-or-

ator. They need to re-dering activity either through

ceive information about

the order.

RFQ and Quotation or by receiv-

ing 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 Re-

sponse.

Order ResponseOrder, Order

Change, and Or-

der Cancellation

Order PointA company may deleg-

ate the task of purchas-

ing to a specialized

The party that purchases the

goods or services on behalf of

the Originator. The Buyer may

BuyerCustomer Party

group to consolidate or-be referred to in Order Re-

ders and gain greater

discounts.

sponse, Despatch Advice, In-

voice, Self Billed Invoice, Credit

Note, and Account Statement.

Despatch AdviceReceipt AdviceDelivery Point,

Destination

If a municipality buys a

wheelchair for a citizen,

The party to whom goods should

be delivered. The Delivery Party

DeliveryCustomer Party

Party, Receiver,

Recipient

the wheelchair must be

delivered to the citizen

may be the same as the Originat-

or. The Delivery Party must be

(the Delivery Party). Inreferred to at line item level in

such cases the citizenRFQ, Quotation, Order, Order

may be notified beforechange, Order Cancellation, and

delivering the wheel-

chair.

Order Response. The Delivery

Party may be referred to at line

level in Invoice, Self Billed In-

voice, Credit Note, and Debit

Note. The Delivery Party may be

stipulated in a transport contract.

In a traditional

Billing scenario:

In a traditional

Billing scenario:

Invoicee, Ac-

counts Payable,

Debtor

If a kindergarten buys

some toys they may be

the Originator, Buyer,

The party responsible for making

settlement relating to a purchase

and resolving billing issues using

Accounting Cus-

tomer

Customer Party

Invoice, CreditDebit Note, Ac-

and Delivery Party, buta Debit Note. The Accounting Note, and State-count Re-

the municipality mayCustomer must be referred to in ment of Accountsponse, and Re-

play the role of Account-an Order and may be referred to In a Self Billingmittance Advice

ing Customer—they are

going to pay for it.

in an Order Response. In a Self

Billing scenario, the Accounting

scenario: Credit

Note, Account

In a Self Billing

scenario: Self

Customer is responsible for cal-

culating and issuing tax invoices.

Response, and

Statement of Ac-

count

Billed Invoice,

Self Billed Credit

Note, and Remit-

tance Advice

30 May 2011Page 81 of 156



RFQ, Order, Or-

der Change, Or-

der Cancellation,

Request for

Catalogue

Quotation, Order

Response, Or-

der Response

Simple, Cata-

logue, Cata-

logue Deletion,

Catalogue Item

Specification

Update, Cata-

logue Pricing

Update

Sales Point,

Provider, Cus-

tomer Manager

The organization that

sells wheelchairs to mu-

nicipalities.

The party responsible for hand-

ling Originator and Buyer ser-

vices. The Seller party is legally

responsible for providing the

goods to the Buyer. The Seller

party receives and quotes

against RFQs and may provide

information to the Buyer’s requis-

itioning process through Cata-

logues and Quotations.

SellerSupplier Party

Receipt AdviceDespatch Ad-

vice

Despatch Point,

Shipper, Sender

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.

The party where goods are to be

collected from. The Despatch

Party may be stipulated in a

transport contract.

DespatchSupplier Party

In a traditional

Billing scenario:

Debit Note, Ac-

count Response,

and Remittance

Advice In a Self

Billing scenario:

Self Billed In-

voice, Self

Billing Credit

Note, and Remit-

tance Advice

In a traditional

Billing scenario:

Invoice, Credit

Note, and State-

ment of Account

In a Self Billing

scenario: Credit

Note, Account

Response and

Statement of Ac-

count

Accounts Receiv-

able, Invoice Is-

suer, Creditor

There are cases where

the Accounting Supplier

is not the Seller party.

For example, factoring,

where the invoicing is

outsourced to another

company.

The party who claims the pay-

ment and is responsible for

resolving billing issues and arran-

ging settlement.

Accounting Sup-

plier

Supplier Party

Remittance Ad-

vice

Accounts Receiv-

able, Creditor

The Accounting Suppli-

er may not be the party

to be paid due to

changes in the organiza-

tion, e.g., a company

merger.

The party to whom the Invoice is

paid.

PayeeSupplier Party

Catalogue,

Catalogue Dele-

tion, Catalogue

Item Specifica-

tion Update,

Catalogue Pri-

cing Update

Request for

Catalogue

Central Cata-

logue Party,

Purchasing

Manager

An organization has a

central office for main-

taining catalogues of

approved items for pur-

chase.

The party responsible for the

contract to which the Catalogue

relates.

ContractorCustomer Party

Catalogue,

Catalogue Dele-

tion, Catalogue

Item Specifica-

tion Update,

Catalogue Pri-

cing Update

The manufacturer may

publish and maintain the

data sheets about a

product.

The party responsible for the in-

tegrity of the information provided

about an item.

ProviderParty

30 May 2011Page 82 of 156



Catalogue,

Catalogue Dele-

tion, Catalogue

Item Specifica-

tion Update,

Catalogue Pri-

cing Update, Ap-

plication Re-

sponse

A marketplace may re-

ceive an Application

Response.

The party receiving a document.

The party receiving a Catalogue.

Catalogue items may never be

ordered, so the recipient of the

catalogue is not an Originator or

a Buyer.

ReceiverParty

Application Re-

sponse

A marketplace may

send an Application Re-

sponse.

The party sending a document.SenderParty

Bill of Lading,

Waybill, Freight

Invoice, Trans-

portation Status

Forwarding In-

structions, Pack-

ing List

Despatch Point,

Shipper,

Sender, Trans-

port User


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 ware-

house also plays the

role of Despatch Party

to the Freight Forward-

er.

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.

ConsignorParty

Bill of Lading,

Waybill, Freight

Invoice, Trans-

portation Status

Forwarding In-

structions,

Freight Invoice

Delivery Point,

Transport Ser-

vice Buyer

The party taking re-

sponsibility for the re-

ceipt of the consignment

covering the wheelchair.

The party receiving a consign-

ment of goods as stipulated in

the transport contract.

ConsigneeParty

Bill of Lading,

Waybill, Packing

List

Forwarding In-

structions,

Freight Invoice,

Transportation

Status

Shipping Agent,

Broker, Courier,

Transport Ser-

vice Provider

The Consignor may

have a contract with this

Freight Forwarder,

which is a Transport

Services Provider, to

arrange all their trans-

port needs.

The party arranging the carriage

of goods, including connected

services and/or associated form-

alities, on behalf of a Consignor

or Consignee. Also known as the

Transport Service Provider. The

Freight Forwarder may also be

the Carrier.The Freight Forward-

er may create an invoice and bill

to the Transport Service Buyer

for the transportation service

provided.

Freight Forward-

er

Party

Forwarding In-

structions

Bill of Lading,

Waybill

Freight Haulier,

Shipper, Ships

Agent, Shipping

Company, Air-

line, Rail Operat-

or, Road Haulier

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.

The party providing physical

transport services.

CarrierParty

30 May 2011Page 83 of 156



Application Re-

sponse

Certificate of

Origin

Seller, Con-

signor


has to apply for a Certi-

ficate of Origin in order

to sell the chairs over-

seas.

The party who makes regulatory

export declarations, or on whose

behalf regulatory export declara-

tions 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 ac-

cepted.

ExporterParty

Certificate of

Origin

Certificate of

Origin, Applica-

tion Response

Authorized Or-

ganization, Em-

bassy

The Government

agency validates all the

information provided by

Exporter for Certificate

of Origin approval.

The party appointed by the Gov-

ernment of a country who has the

right to certify a Certificate of

Origin. This endorsement re-

stricts goods imported from cer-

tain countries for political or other

reasons.

EndorserParty

Certificate of

Origin

Order Point, De-

livery Party,

Buyer, Custom-

er, Consignee

A specialized group in a

company consolidates

the purchase request

and handles the receiv-

ing of goods.

The party who makes, or on

whose behalf an agent or other

authorized person makes, an

import declaration. This may in-

clude a person who has posses-

sion of the goods or to whom the

goods are consigned.

ImporterParty

30 May 2011Page 84 of 156


3. UBL 2.1 SchemasThe UBL 2.1 XSD schemas are the only normative representations of the UBL 2.1 document types andlibrary components.

All of the UBL 2.1 XSD schemas are contained in the xsd subdirectory of the UBL 2.1 release package(see Appendix A, Release Notes (Non-Normative) for more information regarding the structure of the2.1 release package and Section 3.3, “Schema Dependencies” for information regarding dependenciesamong the schema modules). The xsd directory is further subdivided into xsd/maindoc andxsd/common subdirectories.

For convenience in implementing the schemas, a parallel (and technically non-normative) “runtime” setwith the annotation elements stripped out is provided in the xsdrt directory.

3.1. UBL Document SchemasXSD schemas defining the UBL 2.1 document types are located in the xsd/maindoc directory, as listedbelow.

ApplicationResponsexsd/maindoc/UBL-ApplicationResponse-2.1.xsd

AttachedDocumentxsd/maindoc/UBL-AttachedDocument-2.1.xsd

AwardedNotificationxsd/maindoc/UBL-AwardedNotification-2.1.xsd

BillOfLadingxsd/maindoc/UBL-BillOfLading-2.1.xsd

CallForTendersxsd/maindoc/UBL-CallForTenders-2.1.xsd

Cataloguexsd/maindoc/UBL-Catalogue-2.1.xsd

CatalogueDeletionxsd/maindoc/UBL-CatalogueDeletion-2.1.xsd

CatalogueItemSpecificationUpdatexsd/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xsd

CataloguePricingUpdatexsd/maindoc/UBL-CataloguePricingUpdate-2.1.xsd

CatalogueRequestxsd/maindoc/UBL-CatalogueRequest-2.1.xsd

CertificateOfOriginxsd/maindoc/UBL-CertificateOfOrigin-2.1.xsd

ContractAwardNoticexsd/maindoc/UBL-ContractAwardNotice-2.1.xsd

ContractNoticexsd/maindoc/UBL-ContractNotice-2.1.xsd

30 May 2011Page 85 of 156


xsd/maindoc/UBL-ApplicationResponse-2.1.xsd

xsd/maindoc/UBL-AttachedDocument-2.1.xsd

xsd/maindoc/UBL-AwardedNotification-2.1.xsd

xsd/maindoc/UBL-BillOfLading-2.1.xsd

xsd/maindoc/UBL-CallForTenders-2.1.xsd

xsd/maindoc/UBL-Catalogue-2.1.xsd

xsd/maindoc/UBL-CatalogueDeletion-2.1.xsd

xsd/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xsd

xsd/maindoc/UBL-CataloguePricingUpdate-2.1.xsd

xsd/maindoc/UBL-CatalogueRequest-2.1.xsd

xsd/maindoc/UBL-CertificateOfOrigin-2.1.xsd

xsd/maindoc/UBL-ContractAwardNotice-2.1.xsd

xsd/maindoc/UBL-ContractNotice-2.1.xsd

CreditNotexsd/maindoc/UBL-CreditNote-2.1.xsd

DebitNotexsd/maindoc/UBL-DebitNote-2.1.xsd

DespatchAdvicexsd/maindoc/UBL-DespatchAdvice-2.1.xsd

DocumentStatusxsd/maindoc/UBL-DocumentStatus-2.1.xsd

DocumentStatusRequestxsd/maindoc/UBL-DocumentStatusRequest-2.1.xsd

ExceptionCriteriaxsd/maindoc/UBL-ExceptionCriteria-2.1.xsd

ExceptionNotificationxsd/maindoc/UBL-ExceptionNotification-2.1.xsd

Forecastxsd/maindoc/UBL-Forecast-2.1.xsd

ForecastRevisionxsd/maindoc/UBL-ForecastRevision-2.1.xsd

ForwardingInstructionsxsd/maindoc/UBL-ForwardingInstructions-2.1.xsd

FreightInvoicexsd/maindoc/UBL-FreightInvoice-2.1.xsd

GoodsItemItineraryxsd/maindoc/UBL-GoodsItemItinerary-2.1.xsd

GuaranteeCertificatexsd/maindoc/UBL-GuaranteeCertificate-2.1.xsd

InstructionForReturnsxsd/maindoc/UBL-InstructionForReturns-2.1.xsd

InventoryReportxsd/maindoc/UBL-InventoryReport-2.1.xsd

Invoicexsd/maindoc/UBL-Invoice-2.1.xsd

ItemInformationRequestxsd/maindoc/UBL-ItemInformationRequest-2.1.xsd

Orderxsd/maindoc/UBL-Order-2.1.xsd

OrderCancellationxsd/maindoc/UBL-OrderCancellation-2.1.xsd

OrderChangexsd/maindoc/UBL-OrderChange-2.1.xsd

30 May 2011Page 86 of 156


xsd/maindoc/UBL-CreditNote-2.1.xsd

xsd/maindoc/UBL-DebitNote-2.1.xsd

xsd/maindoc/UBL-DespatchAdvice-2.1.xsd

xsd/maindoc/UBL-DocumentStatus-2.1.xsd

xsd/maindoc/UBL-DocumentStatusRequest-2.1.xsd

xsd/maindoc/UBL-ExceptionCriteria-2.1.xsd

xsd/maindoc/UBL-ExceptionNotification-2.1.xsd

xsd/maindoc/UBL-Forecast-2.1.xsd

xsd/maindoc/UBL-ForecastRevision-2.1.xsd

xsd/maindoc/UBL-ForwardingInstructions-2.1.xsd

xsd/maindoc/UBL-FreightInvoice-2.1.xsd

xsd/maindoc/UBL-GoodsItemItinerary-2.1.xsd

xsd/maindoc/UBL-GuaranteeCertificate-2.1.xsd

xsd/maindoc/UBL-InstructionForReturns-2.1.xsd

xsd/maindoc/UBL-InventoryReport-2.1.xsd

xsd/maindoc/UBL-Invoice-2.1.xsd

xsd/maindoc/UBL-ItemInformationRequest-2.1.xsd

xsd/maindoc/UBL-Order-2.1.xsd

xsd/maindoc/UBL-OrderCancellation-2.1.xsd

xsd/maindoc/UBL-OrderChange-2.1.xsd

OrderResponsexsd/maindoc/UBL-OrderResponse-2.1.xsd

OrderResponseSimplexsd/maindoc/UBL-OrderResponseSimple-2.1.xsd

PackingListxsd/maindoc/UBL-PackingList-2.1.xsd

PerformanceHistoryxsd/maindoc/UBL-PerformanceHistory-2.1.xsd

PriorInformationNoticexsd/maindoc/UBL-PriorInformationNotice-2.1.xsd

ProductActivityxsd/maindoc/UBL-ProductActivity-2.1.xsd

Quotationxsd/maindoc/UBL-Quotation-2.1.xsd

ReceiptAdvicexsd/maindoc/UBL-ReceiptAdvice-2.1.xsd

Reminderxsd/maindoc/UBL-Reminder-2.1.xsd

RemittanceAdvicexsd/maindoc/UBL-RemittanceAdvice-2.1.xsd

RequestForQuotationxsd/maindoc/UBL-RequestForQuotation-2.1.xsd

RetailEventxsd/maindoc/UBL-RetailEvent-2.1.xsd

SelfBilledCreditNotexsd/maindoc/UBL-SelfBilledCreditNote-2.1.xsd

SelfBilledInvoicexsd/maindoc/UBL-SelfBilledInvoice-2.1.xsd

Statementxsd/maindoc/UBL-Statement-2.1.xsd

StockAvailabilityReportxsd/maindoc/UBL-StockAvailabilityReport-2.1.xsd

Tenderxsd/maindoc/UBL-Tender-2.1.xsd

TenderReceiptxsd/maindoc/UBL-TenderReceipt-2.1.xsd

TendererQualificationxsd/maindoc/UBL-TendererQualification-2.1.xsd

TendererQualificationResponsexsd/maindoc/UBL-TendererQualificationResponse-2.1.xsd

30 May 2011Page 87 of 156


xsd/maindoc/UBL-OrderResponse-2.1.xsd

xsd/maindoc/UBL-OrderResponseSimple-2.1.xsd

xsd/maindoc/UBL-PackingList-2.1.xsd

xsd/maindoc/UBL-PerformanceHistory-2.1.xsd

xsd/maindoc/UBL-PriorInformationNotice-2.1.xsd

xsd/maindoc/UBL-ProductActivity-2.1.xsd

xsd/maindoc/UBL-Quotation-2.1.xsd

xsd/maindoc/UBL-ReceiptAdvice-2.1.xsd

xsd/maindoc/UBL-Reminder-2.1.xsd

xsd/maindoc/UBL-RemittanceAdvice-2.1.xsd

xsd/maindoc/UBL-RequestForQuotation-2.1.xsd

xsd/maindoc/UBL-RetailEvent-2.1.xsd

xsd/maindoc/UBL-SelfBilledCreditNote-2.1.xsd

xsd/maindoc/UBL-SelfBilledInvoice-2.1.xsd

xsd/maindoc/UBL-Statement-2.1.xsd

xsd/maindoc/UBL-StockAvailabilityReport-2.1.xsd

xsd/maindoc/UBL-Tender-2.1.xsd

xsd/maindoc/UBL-TenderReceipt-2.1.xsd

xsd/maindoc/UBL-TendererQualification-2.1.xsd

xsd/maindoc/UBL-TendererQualificationResponse-2.1.xsd

TradeItemLocationProfilexsd/maindoc/UBL-TradeItemLocationProfile-2.1.xsd

TransportExecutionPlanxsd/maindoc/UBL-TransportExecutionPlan-2.1.xsd

TransportExecutionStatusxsd/maindoc/UBL-TransportExecutionStatus-2.1.xsd

TransportProgressStatusxsd/maindoc/UBL-TransportProgressStatus-2.1.xsd

TransportServiceDescriptionxsd/maindoc/UBL-TransportServiceDescription-2.1.xsd

TransportationStatusxsd/maindoc/UBL-TransportationStatus-2.1.xsd

UnawardedNotificationxsd/maindoc/UBL-UnawardedNotification-2.1.xsd

UtilityStatementxsd/maindoc/UBL-UtilityStatement-2.1.xsd

Waybillxsd/maindoc/UBL-Waybill-2.1.xsd

3.2. UBL Common SchemasThe 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 componentsfrom which the UBL document schemas are assembled.

The name of each schema file together with a brief description of its contents is given below.

3.2.1. Reusable BIE Schemas

CommonBasicComponentsxsd/common/UBL-CommonBasicComponents-2.1.xsd

The CommonBasicComponents schema defines the global Basic Business Inform-ation Entities (BBIEs) that are used throughout UBL, serving, in effect, as a “globalBBIE type database” for constructing documents. BBIEs are the “leaf nodes” of UBLdocuments, corresponding to individual data fields in traditional printed businessforms.

CommonAggregateComponentsxsd/common/UBL-CommonAggregateComponents-2.1.xsd

The CommonAggregateComponents schema defines the Aggregate Business In-formation Entities (ABIEs) that are used throughout UBL, serving, in effect, as an“ABIE type database” for constructing the main documents.

3.2.2. Reusable Data Type Schemas

CCTS_CCT_SchemaModulexsd/common/CCTS_CCT_SchemaModule-2.1.xsd

30 May 2011Page 88 of 156


xsd/maindoc/UBL-TradeItemLocationProfile-2.1.xsd

xsd/maindoc/UBL-TransportExecutionPlan-2.1.xsd

xsd/maindoc/UBL-TransportExecutionStatus-2.1.xsd

xsd/maindoc/UBL-TransportProgressStatus-2.1.xsd

xsd/maindoc/UBL-TransportServiceDescription-2.1.xsd

xsd/maindoc/UBL-TransportationStatus-2.1.xsd

xsd/maindoc/UBL-UnawardedNotification-2.1.xsd

xsd/maindoc/UBL-UtilityStatement-2.1.xsd

xsd/maindoc/UBL-Waybill-2.1.xsd

xsd/common/UBL-CommonBasicComponents-2.1.xsd

xsd/common/UBL-CommonAggregateComponents-2.1.xsd

xsd/common/CCTS_CCT_SchemaModule-2.1.xsd

This schema provides Core Component Types as defined by [CCTS]. These typesare used to construct higher-level data types in a standardized and consistentmanner. This schema is defined by UN/CEFACT and should not be modified. It isimported by the UBL Unqualified Data Type Schema, and its types are the basisupon which UBL's unqualified data types are defined.

UnqualifiedDataTypesxsd/common/UBL-UnqualifiedDataTypes-2.1.xsd

This schema defines Unqualified Data Types for BBIE definition. These types arederived from the Core Component Types in CCTS_CCT_SchemaModule. Wherean unqualified type is not based solely on an XSD data type, all CCTS supplementarycomponents are made available in the UBL UDT from the CCTS CCT.

QualifiedDataTypesxsd/common/UBL-QualifiedDataTypes-2.1.xsd

[CCTS] permits the definition of Qualified Datatypes as derivations from CCTS-specified Unqualified Datatypes. In UBL 2.1, all data type qualifications are expressedin the [CVA] file cva/UBL-DefaultDTQ-2.1.cva.The UBL-QualifiedDataTypes-2.1.xsdfile in the UBL 2.1 release is included among the schema modules imported by theCommon Library and all document-level schema fragments in order to be consistentwith the relationship of types in a CCTS framework, though the schema module itselfhas no declarations.

See Appendix F, Data Type Qualifications in UBL (Non-Normative) for informationregarding UBL 2.1 data type derivation.

3.2.3. Documentation Metadata Schema

CoreComponentParametersxsd/common/UBL-CoreComponentParameters-2.1.xsd

The CoreComponentParameters schema defines the structure of the annotation/doc-umentation sections that appear in all the other schemas, providing a consistentformat for metadata such as object class, representation terms, semantic descrip-tions, and other supplementary information.

While not required by UBL schemas, this module is provided to encourage consist-ency in the documentation of customized extensions.

3.2.4. Extension Content Schemas

UBL extensions enable the validation of user-defined additions to the standard schemas, which aresometimes needed to satisfy legal requirements and can perform other useful functions as well. UBL2.1 schemas are supplied with a predefined standard extension that supports advanced digital signatures;see Section 5, “UBL Extension for XML Digital Signatures” and Section 3.3, “Schema Dependencies”.For further information regarding the UBL extension mechanism, see [Customization].

CommonExtensionComponentsxsd/common/UBL-CommonExtensionComponents-2.1.xsd

The CommonExtensionComponents schema defines the extension structures thatare used in all UBL document types, providing metadata regarding the use of anextension embedded in a UBL document instance.

ExtensionContentDatatypexsd/common/UBL-ExtensionContentDataType-2.1.xsd

30 May 2011Page 89 of 156


xsd/common/UBL-UnqualifiedDataTypes-2.1.xsd

xsd/common/UBL-QualifiedDataTypes-2.1.xsd

xsd/common/UBL-CoreComponentParameters-2.1.xsd

xsd/common/UBL-CommonExtensionComponents-2.1.xsd

xsd/common/UBL-ExtensionContentDataType-2.1.xsd

The ExtensionContentDataType schema specifies the actual structural constraintsof the extension element containing the foreign non-UBL content. This is deliveredas both a functional component and illustration of the definition of an extensionschema by importing the UBL Signature Extension module and namespace. Tosupport the constraints additional extension structures, this content module is aug-mented with other schema import directives. No changes are required to the complextype declaration. Note that the constraints of only the imported constructs are beingdeclared, not the constraints of unknown constructs. Constructs for which there isno declaration are not constrained by validation.

3.2.5. Signature Extension Schemas

See Section 5, “UBL Extension for XML Digital Signatures” for further information regarding the UBLextension supporting digital signatures such as XAdES.

CommonSignatureComponentsxsd/common/UBL-CommonSignatureComponents-2.1.xsd

The CommonSignatureComponents schema defines the scaffolding structurescontaining the IETF/W3C Digital Signature information XML elements related toeither the entire document or particular signature business objects found within thedocument.

XAdESv132xsd/common/UBL-XAdESv132-2.1.xsd

This is a copy of the XAdES v1.3.2 schema file [http://uri.etsi.org/01903/v1.3.2/XAdES.xsd], modified only to change the importing URI for the XML digital signaturecore schema file.

The presence of this schema file does not oblige the use of XAdES. It is providedonly as a convenience for those users who choose to include an XAdES extensioninside of a digital signature.

XAdESv141xsd/common/UBL-XAdESv141-2.1.xsd

This is a copy of the XAdES v1.4.1 schema file [http://uri.etsi.org/01903/v1.4.1/XAdESv141.xsd], modified only to change the importing URI for the XAdES v1.3.2schema file.

The presence of this schema file does not oblige the use of XAdES. It is providedonly as a convenience for those users who choose to include an XAdES extensioninside of a digital signature.

xmldsig-core-schemaxsd/common/UBL-xmldsig-core-schema-2.1.xsd

This is a copy of the IETF/W3C Digital Signature core schema file [http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd], modified only to remove the unneces-sary PUBLIC and SYSTEM identifiers from the DOCTYPE.

3.2.6. Signature Components

SignatureBasicComponentsxsd/common/UBL-SignatureBasicComponents-2.1.xsd

The SignatureBasicComponents schema defines those Basic Business InformationEntities (BBIEs) that are used for signature constructs not defined in the common

30 May 2011Page 90 of 156


xsd/common/UBL-CommonSignatureComponents-2.1.xsd

xsd/common/UBL-XAdESv132-2.1.xsd

http://uri.etsi.org/01903/v1.3.2/XAdES.xsd

xsd/common/UBL-XAdESv141-2.1.xsd

http://uri.etsi.org/01903/v1.4.1/XAdESv141.xsd

xsd/common/UBL-xmldsig-core-schema-2.1.xsd

http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

xsd/common/UBL-SignatureBasicComponents-2.1.xsd

library. BBIEs are the “leaf nodes” of UBL documents, expressing simple stringvalues.

SignatureAggregateComponentsxsd/common/UBL-SignatureAggregateComponents-2.1.xsd

The SignatureAggregateComponents schema defines those Aggregate BusinessInformation Entities (ABIEs) that are used for signature constructs not defined inthe common library. ABIEs are the “branch nodes” of UBL documents, expressingcomponent values composed of leaf nodes and other branch nodes.

3.3. Schema DependenciesThe following diagram shows the dependencies among the schema modules making up a UBL 2.1document schema.

Figure 65. UBL Schema Dependencies

The UBL schemas are delivered supporting the UBL standardized extension for digital signatures, definingthe content of the extension to be a single element either in or out of the UBL signature extensionnamespace. As shown on the bottom right in this diagram, a set of UBL schemas supporting a differentuser-customized extension is created by replacing the delivered ExtensionContentDataType schemafragment with one also importing the required custom schema fragments that define the custom content.For more regarding the signature extension, see Section 5, “UBL Extension for XML Digital Signatures”.

The relationship of the UBL schemas to the UBL data model is illustrated in Figure C.1, “UBL SpreadsheetRealization”.

30 May 2011Page 91 of 156


xsd/common/UBL-SignatureAggregateComponents-2.1.xsd

4. Additional Document ConstraintsIn addition to the UBL 2.1 document constraints formally expressed by the schemas in Section 3, “UBL2.1 Schemas”, UBL mandates several other rules governing conformant UBL 2.1 instances that cannotbe 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 herebecause logically they belong with the great majority of UBL instance constraints specified in theschemas. To aid in coordinating references between these various publications, the rules below retaintheir original “IND” labels. The former IND4 was removed in the revision process leading to UBL 2.0.

4.1. ValidationThe 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 processingand corresponding business cycle actions are reflective of the purpose, intent, and information contentagreed to by both trading partners. Schemas provide the necessary mechanism for ensuring that instancedocuments do in fact support these requirements.

[IND1] All UBL instance documents MUST validate to a corresponding schema.

4.2. Character EncodingXML supports a wide variety of character encodings. Processors must understand which character en-coding is employed in each XML document. XML 1.0 supports a default value of UTF-8 for characterencoding, but best practice is to always identify the character encoding being employed.

[IND2] All UBL instance documents MUST identify their character encoding within theXML 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 liaisonmember of the ISO IEC ITU UN/CEFACT eBusiness Memorandum of Understanding ManagementGroup (MOUMG). Resolution 01/08 (MOU/MG01n83) requires the use of UTF-8.

[IND3] In conformance with ISO IEC ITU UN/CEFACT eBusiness Memorandum ofUnderstanding Management Group (MOUMG) Resolution 01/08 (MOU/MG01n83) asagreed to by OASIS, all UBL XML SHOULD be expressed using UTF-8.

Example:

<?xml version="1.0" encoding="UTF-8"?>

4.3. Empty ElementsUse 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 applicablefor 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—data not provided by a trading partner. In informationexchange environments, different trading partners may allow, require, or ban empty elements. UBL has

30 May 2011Page 92 of 156


determined that empty elements do not provide the level of assurance necessary for business informationexchanges and therefore will not be used.

[IND5] UBL conformant instance documents MUST NOT contain an element devoid ofcontent or containing null values, except in the case of extension, where the UBL Exten-sionContent element is used.

To ensure that no attempt is made to circumvent rule IND5, UBL also prohibits attempting to conveymeaning by not conveying an element.

[IND6] The absence of a construct or data in a UBL instance document MUST NOTcarry meaning.

30 May 2011Page 93 of 156


5. UBL Extension for XML Digital SignaturesUBL extensions enable user-defined additions to the standard schemas. The UBL 2.1 schemas in thisdistribution are provided with a predefined standard extension that supports IETF/W3C Digital Signatureprofiles. These include advanced IETF/W3C XML digital signatures conforming to the ETSI XAdESspecification [XAdES], 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 Sec-tion 5.8, “Notes for Extension Creators (Non-Normative)”. Further information on the UBL extensionmechanism can be found in [Customization].

UBL's implementation of XML digital signatures puts all the signatures relating to a document in a singleextension, which is engaged in validation by the UBL-ExtensionContentDataType-2.1.xsd schemamodule. A detailed analysis and description of the digital signature methodology is given in the UBLSecurity Subcommittee document UBL Digital Signature Profiles Version 1.0, which can be found in thedoc subdirectory of this distribution.

5.1. NamespacesAs is true for the UBL document schemas and common library, the UBL digital signature extension ismodeled with three namespaces: one for the apex element (a parallel to the document schema), onefor new aggregate constructs (a parallel to the common aggregate schema), and one for new basicconstructs (a parallel to the common basic schema). See Figure 65, “UBL Schema Dependencies”.

The urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2namespace is used for the apex element, the urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2 namespace is used for new aggregate elements, andthe urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2namespace is used for new basic elements. The IETF/W3C digital signature [xmldsig] standardnamespace http://www.w3.org/2000/09/xmldsig# is also used in this extension. Thesenamespaces are bound to the sig:, sac:, sbc: and ds: prefixes respectively, but any prefix or eventhe 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# andhttp://uri.etsi.org/01903/v1.4.1# are included and engaged in UBL 2.1 for the convenienceof users of the XAdES specification.There is no obligation to use the XAdES extension in the IETF/W3Cdigital signature.

5.2. IdentificationThis UBL extension is distinguished from other extensions and identified using the URI urn:oasis:names:specification:ubl:dsig:enveloped in the <ext:ExtensionURI> element.

Note

In addition to Enveloped signatures, the UBL Digital Signatures Profiles specification includedin the doc subdirectory of this distribution also provides methods to be used with Detachedsignatures (i.e., digital signatures that stand outside the document being signed). Since Detachedsignatures constitute an independent technique without associated UBL artefacts, they are notdocumented further here, but an example instance showing detached signatures is included inthis package; see Section 5.6, “Digital Signature Examples”.

30 May 2011Page 94 of 156


5.3. ValidationThe UBL-ExtensionContentDataType-2.1.xsd module links UBL validation to all needed extensionsby importing the apex schema fragment of each extension vocabulary. The distribution version of thismodule supports IETF/W3C XML digital signatures by declaring that the <ext:ExtensionContent>element can contain elements from the UBL Digital Signature extension namespace. Accordingly, asingle <sig:UBLDocumentSignatures> element is used as the apex of all the document's electronicsignatures.

The <ext:ExtensionContent> element alternatively allows any other namespace apex element inorder to allow other foreign extensions in the same document.

5.4. StructureThe signature extension structure exists to contain one or more IETF/W3C standard digital signatureconstructs. The UBL scaffolding for this extension starts with a <ext:UBLExtension> element withtwo children: <ext:ExtensionURI> (for extension distinction and identification) and<ext:ExtensionContent> (for containing the extension information, in this case the actual signaturesand supporting information):

<ext:UBLExtension> <ext:ExtensionURI>urn:oasis:names:specification:ubl:dsig:enveloped</ext:ExtensionURI> <ext:ExtensionContent>

All signature information for the document is then contained under the <sig:UBLDocumentSignatures>apex element, a single child of <ext:ExtensionContent>:

<ext:ExtensionContent> <sig:UBLDocumentSignatures>

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 aggregatescan be in the extension as is needed, each one containing the information for a single digital extension.

An aggregate can optionally 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 tobe identified external to the document, but its use is not obligatory.The identifier used can be any value,but for convenience the URI of a URN beginning with urn:oasis:names:specification:ubl:signatures: and ending with a number value is reserved for this purpose for UBL users. An exampleis urn:oasis:names:specification:ubl:signatures:3. As with all identifiers, each should beunique across all identifier values in a given UBL instance.

An aggregate can optionally make reference to an existing <cac:Signature> business object in thesame 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, but for convenience the URI of a URN beginning with urn:oasis:names:specification:ubl:signatures: and ending with the local name of the parent of thesignature business object and optionally followed with a colon and number, as in the urn:oasis:names:specification:ubl:signatures:IssuerEndorsement example, is reserved for thispurpose for UBL users. As with all identifier references, the referenced identifier should exist and shouldbe unique across all such identifier values in a given UBL instance.

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 UBLscaffolding is added by an earlier process. However, the signature information is semantically incompletewithout the IETF/W3C-defined element. To support countersignatures countersigning this signature,

30 May 2011Page 95 of 156


this element must use the Id= attribute with a value unique from other attributes of schema type ID inthe instance.

A skeleton example of a single signature is as follows:

<ext:ExtensionContent> <sig:UBLDocumentSignatures xmlns:sig= "urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2" xmlns:sac= "urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2" xmlns:sbc= "urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2"> <sac:SignatureInformation> <cbc:ID>urn:oasis:names:specification:ubl:signature:1</cbc:ID> <sbc:ReferencedSignatureID>urn:oasis:names:specification:ubl:signature:Invoice</sbc:ReferencedSignatureID> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id=...> <ds:SignedInfo> ... <ds:Reference URI=...> ... <ds:Transform> ... </ds:Transform> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> ... </ds:SignatureValue> <ds:KeyInfo> ... </ds:KeyInfo> <ds:Object> ... </ds:Object> </ds:Signature> </sac:SignatureInformation> </sig:UBLDocumentSignatures></ext:ExtensionContent>

Note

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 schemafragments versioned 1.3.2 and 1.4.1 for the convenience of users who choose to use theseversions of XAdES. Users of the UBL signature extension are not obliged to use any XAdESextensions.

Note

A document with multiple <sac:SignatureInformation> elements is simply a documentthat is co-signed. By the appropriate use of the <ds:Reference> element, all such signaturesare signing the content of the document but not each other. A countersigning document signature,on the other hand, signs signatures already present in the document at the time it is counter-signed. A digital countersignature <ds:Signature> includes additional <ds:Reference>elements, each pointing to the <ds:Signature> elements being signed.The XAdES specific-ation supports an alternative countersignature approach where a <ds:Signature> elementpointing to the countersigned signature is embedded in the <ds:Object> of the countersigningsignature.

30 May 2011Page 96 of 156


The user MAY choose to indicate in a <cac:Signature> element that the signature details are foundin the signature extension. The URI urn:oasis:names:specification:ubl:dsig:envelopedis reserved as a value for <cbc:SignatureMethod> to signal this. Additionally, the user MAY includea <cbc:ID> child of <cac:Signature> for referencing purposes from the enveloped signature. Theidentifier used can be any value, but for convenience the URI of a URN beginning with urn:oasis:names:specification:ubl:signature: and ending with the local name of the parent of the sig-nature 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 forUBL users. As with all identifier references, the referenced identifier should exist and should be uniqueacross all such identifier values in a given UBL instance. An example corresponding to the digital signatureexample would be:

<cac:Signature> <cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID> <cbc:SignatureMethod>urn:oasis:names:specification:ubl:dsig:enveloped</cbc:SignatureMethod> <cac:SignatoryParty> <cac:PartyIdentification> <cbc:ID>MyParty</cbc:ID> </cac:PartyIdentification> </cac:SignatoryParty> </cac:Signature>

5.5.TransformationThe content to be signed is indicated in the URI= attribute of <ds:Reference>. Using the empty stringindicates that the entire document (i.e. the enveloping UBL instance) is what is being signed:

<ds:Reference URI="">

A requirement when using digital signatures is to express in XPath that address that qualifies all nodesin the referenced content to be included in the calculation of the digital signature hash. For a signatureadded to a document to remain valid, none of the information can change, nor can any information beadded or removed from that portion of the document included in the hash calculation.

There are two such transformation expressions that can be used in the UBL signature extension; usersshould choose the appropriate one to meet the objectives of the signature being added to the document.Adding non-signature information to the UBL document will invalidate all signatures already in the exten-sion. The choice to make is whether to support additional signatures after adding the signature with thetransformation expression.

The following transformation element in a digital signature flexibly prevents the signature from being in-validated by the subsequent addition of other signatures within the extension:

<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"> count(ancestor-or-self::sig:UBLDocumentSignatures | here()/ancestor::sig:UBLDocumentSignatures[1]) > count(ancestor-or-self::sig:UBLDocumentSignatures) </XPath> </Transform>

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 subsequentaddition of other signatures to the document:

30 May 2011Page 97 of 156


<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> count(ancestor-or-self::ds:Signature | here()/ancestor::ds:Signature[1]) > count(ancestor-or-self::ds:Signature) </XPath> </Transform>

Multiple separate items of extra-document content (e.g., attachments) or embedded W3C signaturecontent can be included in the same signature by using sibling <ds:Reference> elements with otherURI= attribute values. For example, to countersign another signature in the same UBL document, makea local reference to that signature's unique identifier, as in:

<ds:Reference URI="#{Id attribute of ds:Signature}">

Note

To digitally sign only a portion of standard UBL content and not the entire document of UBLcontent, one uses an appropriate XPointer address for URI=.This requires XPointer awarenesson the part of the digital signature tools being used.

5.6. Digital Signature ExamplesThe xml/UBL-Invoice-2.0-Enveloped.xml sample document illustrates the embedding of threeextensions 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 detaching of a digitalsignature outside of the UBL file. A <cac:Signature> element makes reference to the external signa-ture.

The xml/UBL-Invoice-2.0-Detached-Signature.xml instance is a bona fide verifiable digitalsignature of the xml/UBL-Invoice-2.0-Detached.xml instance.

5.7. Extension Validation Methodology (Non-Normative)The single extension built into the UBL 2.1 distribution validates transparently, and the UBL extensionmechanism allows the addition of other extensions in the same instance.

Users wishing to validate other extensions found in the instance simply revise theUBL-ExtensionContentDataType-2.1.xsd schema fragment. An <xsd:import> directive isadded to incorporate the schema constraints of the apex of another extension to be validated in thesingle pass of XSD validation. Figure 65, “UBL Schema Dependencies” shows the replacement of theschema 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 theapex element declared. The lax validation permits any element declared in any schema fragment to bethe apex of an extension. Thus, an instance will pass when a known extension element not permittedby the user to be an apex element is in the place of an apex element. This is simply regarded bydownstream processes as an unknown extension and will likely be ignored.

30 May 2011Page 98 of 156


xml/UBL-Invoice-2.0-Enveloped.xml

xml/UBL-Invoice-2.0-Detached.xml

xml/UBL-Invoice-2.0-Detached-Signature.xml


5.8. Notes for Extension Creators (Non-Normative)The UBL Digital Signature extension has been modeled as an example to follow when designing andwriting other custom extensions. The following points should be noted:

• Extension designers should follow the example in providing separate namespaces for apex element,aggregate constructs, and basic constructs if they wish the new items to be considered for inclusionin future UBL releases. This structures the new items for inclusion in the UBL common library. Seexml/MyTransportationStatus.xml for a document instance exemplifying the recommendedtreatment of namespaces.

• Whenever possible, existing UBL common library aggregate and basic constructs should be usedin extensions rather than inventing new items with the same semantics. However, a common libraryaggregate construct should only be used when the entire aggregate and all of its descendants areapplicable in the extension context without any changes. If any items must be removed, then a newextension aggregate with a new local name should be used. If all the constructs are applicable butsome items need to be added, then a new extension aggregate with the same local name as thecommon library aggregate should be used, and the common library aggregate should be copied withthe new constructs inserted.

30 May 2011Page 99 of 156


xml/MyTransportationStatus.xml

6. ConformanceConformance (as applied to UBL documents and schemas) and the distinction between UBL conformanceand UBL compatibility is described in detail in the UBL 2 Guidelines for Customization [Customization].

30 May 2011Page 100 of 156


Appendix A. Release Notes (Non-Normative)

A.1. AvailabilityOnline and downloadable versions of this release are available from the locations specified at the topof this document.

A.2. Status of This ReleaseRelease of this package to the public begins its second public review. The UBL Technical Committeeactively solicits input from the user community regarding this release. See Status for procedures to beused in submitting comments to the Committee. Note that the UBL TC cannot accept input from anyoneoutside the UBL TC (including OASIS members) unless it is submitted via the comment list.

THIS RELEASE IS FOR TESTING PURPOSES ONLY AND SHOULD NOT BE USED FOR PRODUC-TION SYSTEMS.

A.3. Package StructureThe second public review draft of the UBL 2.1 specification is published as a zip archive named prd2-UBL-2.1.zip. Unzipping this archive creates a directory named prd2-UBL-2.1 containing a master DocBookXML file (UBL-2.1.xml), a generated hypertext version of this file (UBL-2.1.html), a generated PDF versionof this file (UBL-2.1.pdf), and a number of subdirectories.The files in these subdirectories, linked to fromUBL-2.1.xml, UBL-2.1.html, and UBL-2.1.pdf, contain the various normative and informational piecesof the 2.1 release. A description of each subdirectory is given below. Note that while the UBL-2.1.xmlfile is the “original” of this specification, it may not be viewable in all currently available web browsers.

artDiagrams and illustrations used in this specification

asnASN.1 UBL 2.1 schema; see Section G.1, “ASN.1 UBL 2.1 Specification”

clCode list specification files; see Appendix D, UBL 2.1 Code Lists and Two-phaseValidation (Non-Normative)

cssCSS stylesheets for viewing UBL-2.1.html

cvaArtefacts expressing data type qualifications; see [CVA] in Section 1.2, “NormativeReferences” and Figure F.1, “Data Type Qualification in UBL 2.1” in Appendix F,Data Type Qualifications in UBL (Non-Normative)

dbDocBook stylesheets for viewing UBL-2.1.xml

docDocuments and ancillary specifications included with this release

etcMiscellaneous supporting information

30 May 2011Page 101 of 156


modSpreadsheet data models; see Appendix C, The UBL 2.1 Data Model (Non-Norm-ative)

rncAlternative versions of the UBL 2.1 schemas in RELAX NG (compact syntax); seeSection G.2, “UBL 2.1 RELAX NG Schemas”

valTest harness for demonstrating UBL 2.1 two-phase validation; see Appendix D,UBL 2.1 Code Lists and Two-phase Validation (Non-Normative)

xmlSample UBL 2.1 instances; see Appendix E, UBL 2.1 Example Document Instances(Non-Normative)

xsdXSD schemas; see Section 3, “UBL 2.1 Schemas”

xsdrt“Runtime” XSD schemas; see Section 3, “UBL 2.1 Schemas”

A.4. SupportUBL is a volunteer project of the international business community. Inquiries regarding UBL may beposted 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/

A.5. Expected Additions in PRD3Two additional document types, CatalogueTemplate and PurchaseConditions, are expected to be addedto UBL 2.1 following this second public review (PRD2), that is, in the third public review cycle (PRD3).Note that the names of these document types may change before their inclusion in PRD3.

A.6.Taxation RulesUBL does not provide documents for tax reporting purposes. Instead, it provides structures to supportthe information on which taxes are based. These aim to be generic and not based on any specific taxregime.

A.7. UBL CustomizationUBL provides a vocabulary that, for many user communities, can be used "as is." However, it is recognizedthat 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 Cus-tomization [Customization] has been published to aid such users in developing custom solutions basedon UBL.

30 May 2011Page 102 of 156


http://lists.oasis-open.org/archives/ubl-dev/

http://www.oasis-open.org/mlmanage/index.php

http://ubl.xml.org/

The goal of UBL customization is to maintain a common understanding of the meaning of informationbeing exchanged between specific implementations. The factors governing when to customize may bebusiness-driven, technically driven, or both.The decision should be based on real-world needs balancedagainst perceived economic benefits.

A.8. Upgrading from UBL 2.0 to UBL 2.1For current UBL implementers, the most important thing to know about UBL 2.1 is that it is completelybackward-compatible with UBL 2.0. In other words, any document that validates against a UBL 2.0schema will validate against the UBL 2.1 version of that schema.The remaining differences relate mainlyto functionality that has been added to the 2.0 framework 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 specificset 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 andmay help owners of existing UBL 1.0 and 2.0 installations decide whether to upgrade to 2.1. New 2.1users, on the other hand, can simply install 2.1 and rest assured that their software will interoperate withUBL documents generated by existing conformant UBL 2.0 installations. For more on the concept ofconformance, see [Customization].

A.9. Dictionary Entry Name Corrections in UBL 2.1Dictionary Entry Names (DENs) uniquely identify every BIE in the UBL library using the methodologydescribed in [CCTS]. Several errors in dictionary entry naming were discovered and corrected in thecourse of preparing UBL 2.1. These corrections have no effect on processing, validation, or instancegeneration, but they are listed in Section B.3.3, “Changes from UBL 2.0 (As Updated) to UBL 2.1 PRD2”and Section B.3.4, “Changes from UBL 2.1 PRD1 to UBL 2.1 PRD2” for completeness in documentation.

30 May 2011Page 103 of 156


Appendix B. Revision History (Non-Normative)Since its first release as an OASIS Standard in 2004, UBL has experienced one major and one minorversion upgrade.

B.1. UBL 1.0Though apparently limited in scope, the eight document types provided in UBL 1.0 (2004) are applicableto a very large number of real-world use cases and have been widely deployed. These original 1.0document types, later updated in UBL 2.0 and continued here in 2.1, are Order, OrderResponse, Order-ResponseSimple, OrderChange, OrderCancellation, DespatchAdvice, ReceiptAdvice, and Invoice. Thefigure 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 TraditionalBilling processes described in the text (see Section 2.6, “Ordering”, Section 2.7, “Fulfilment”, and Sec-tion 2.8.2, “Traditional Billing”).

Figure B.1. UBL 1.0 Order-to-Invoice Business Process

Because later versions of UBL (versions 2.0 and following) do not maintain backward compatibility withUBL 1.0 document instances (that is, UBL 1.0 document instances will not validate against schemasfrom UBL 2.0 and later), use of UBL 1.0 in new installations is deprecated. All the business functionalityof UBL 1.0 (including suitably revised versions of the original eight document types) is maintained inlater versions.

B.2. Major Revision: UBL 2.0Adoption of UBL 1.0 following ratification as an OASIS standard in November 2004 resulted in majorinputs of new business content beyond the eight basic order-to-invoice business documents specifiedin the original release. In particular, contributions from representatives of government procurement,taxation, and transportation agencies in Europe, Asia, and North America resulted in greatly expandedpre-order and post-invoice capabilities together with the addition of several transport-related documenttypes, 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 in-stances and therefore necessitating designation as a major revision, signified by incrementing the version

30 May 2011Page 104 of 156


number from 1.0 to 2.0 rather than 1.1.The original eight UBL 1.0 document types were revised to reflectthese changes.

UBL 2.0 achieved OASIS Standardization in December 2006, and the package was updated and correctedin 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, CatalogueDeletion, Cata-logueItemSpecificationUpdate, CataloguePricingUpdate, CatalogueRequest, Quotation,RequestForQuotation

Added UBL 2.0 document types for fulfilment: BillOfLading, CertificateOfOrigin,ForwardingInstructions, PackingList, TransportationStatus, Waybill

Added UBL 2.0 document types for billing: CreditNote, DebitNote, FreightInvoice,Reminder, SelfBilledCreditNote, SelfBilledInvoice

Added UBL 2.0 document types for payment: RemittanceAdvice, Statement

Added UBL 2.0 supplementary document types: ApplicationResponse, AttachedDoc-ument

B.3. Minor Revision: UBL 2.1

B.3.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, nota major one. However, it does add 31 new document types as of this second public review draft, bringingthe total number of UBL business documents to 62. (This second public review draft adds two moredocument types, GoodsItemItinerary and TransportServiceDescription, to the 29 new 2.1 documenttypes added in the first public review draft.)

Added UBL 2.1 document types for eTendering: AwardedNotification, CallForTenders,ContractAwardNotice, ContractNotice, GuaranteeCertificate, Tender, TenderReceipt,TendererQualification, TendererQualificationResponse, UnawardedNotification

Added UBL 2.1 document types for Collaborative planning, forecasting, and re-plenishment: ExceptionCriteria, ExceptionNotification, Forecast, ForecastRevision,ItemInformationRequest, PriorInformationNotice, TradeItemLocationProfile

Added UBL 2.1 document types for Vendor Managed Inventory: InstructionForRe-turns, InventoryReport, PerformanceHistory, ProductActivity, RetailEvent, StockAvailab-ilityReport

Added UBL 2.1 document types for Intermodal Freight Management: GoodsItemIt-inerary, TransportExecutionPlan, TransportExecutionStatus, TransportProgressStatus,TransportServiceDescription

Added UBL 2.1 document type for Utility billing: UtilityStatement

Added UBL 2.1 supplementary document types: DocumentStatus, DocumentStatus-Request

B.3.2. Financial Information Enhancements in UBL 2.1

UBL 2.1 has been enhanced to support the financial information required for downstream processingof Invoices within financial services. Through standardization, business vocabularies such as UBL for

30 May 2011Page 105 of 156


eBusiness and ISO 20022 for eFinance enable Straight Through Processing (STP) and paperlesstrading along the entire Financial Supply Chain.

Based on analysis conducted during the current development cycle by the UBL Financial InformationRequirements Task Group (FIRTG), the following enhancements have been included in UBL 2.1:

Financial account: Aligned with today's needs and designed for truly global usage(AliasName, AccountTypeCode, ...). A financial account can be now associated to thePerson information aggregate, not only to a Party.

Payment mandate information can optionally be sent as part of the Order; this can beconsidered a simplification for small businesses.

Trade financing: UBL 2.1 is designed to support basic trade financing practices (invoicefinancing, factoring, pre-shipment/order financing, Letter of Credit, ...)

Payments reconciliation: UBL Invoice and Remittance Advice can be used togetherwith financial messages to ensure end-to-end transport of reconciliation identifiers (in-voicing party references). In particular, UBL provides a solution for advanced externalremittance, where the UBL Remittance Advice is used to transmit the details of complexremittance information associated with the payment initiation process (see ISO20022guides for details). Person is now enriched with a person identification, which is oftenrequired by the banking sector for legal reasons.

Currency Amounts: UBL 2.1 features improved handling of alternative currencyamounts.

UBL 2.1 also includes enhancements to legal information.

Party Legal Entity: The Party's legal information has been considerably enriched withinformation required by advanced procurement and global usage.

Service Provider Party: The electronic trade is increasingly supported and executedthrough Service Providers into several forms like the outsourcing and ASP modes.

UBL Party is now improved to keep track of services handled by one or more serviceproviders.

Power of Attorney can now be associated to a Party.

B.3.3. Changes from UBL 2.0 (As Updated) to UBL 2.1 PRD2

The following three tables show the differences between the elements and attributes in UBL 2.0 (asupdated in 2008) and those in UBL 2.1 (Second Public Review Draft). All changes in 2.1 schemas arebackward-compatible with valid UBL 2.0 instances. Changes include the addition of new elements andattributes; 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 justone); and corrections to Dictionary Entry Names (DENs).

B.3.3.1. Changes to Library Elements (UBL 2.0 to UBL 2.1 PRD2)

This table sums up all the differences between the XML elements in the UBL 2.0 common library andthose in the UBL 2.1 (PRD2) common library.

30 May 2011Page 106 of 156


Table B.1. Changes to Library Elements (UBL 2.0 to UBL 2.1 PRD2)

Changes for UBL 2.1Basic or Association BIEAggregate BIE

AddedActivityDataLine

AddedActivityProperty

Address

Changed cardinality from 0..1 to0..n

LocationCoordinate

AllowanceCharge

AddedPerUnitAmount

AddedAppealTerms

AddedAuctionTerms

AddedAwardingCriteria

AddedAwardingCriteriaResponse

AddedAwardingTerms

AddedBudgetAccount

AddedBudgetAccountLine

AddedBudgetAmount

AddedCapability

CatalogueLine

AddedKeywordItemProperty

AddedCertificate

CertificateOfOriginApplica-tion

AddedExporterParty

AddedImporterParty

ClassificationScheme


Note

AddedCompletedTask

Consignment

AddedCarrierAssignedID

AddedConsigneeAssignedID

AddedConsignorAssignedID

AddedFreightForwarderAssignedID

AddedBrokerAssignedID

AddedContractedCarrierAssignedID

AddedPerformingCarrierAssignedID

AddedAnimalFoodIndicator

AddedHumanFoodIndicator

AddedLivestockIndicator

AddedBulkCargoIndicator

AddedContainerizedIndicator

AddedGeneralCargoIndicator

30 May 2011Page 107 of 156



AddedSpecialSecurityIndicator

AddedThirdPartyPayerIndicator

AddedCarrierServiceInstructions

AddedCustomsClearanceServiceInstructions

AddedForwarderServiceInstructions

AddedSpecialServiceInstructions

AddedSequenceID

AddedShippingPriorityLevelCode

AddedHandlingCode

AddedHandlingInstructions

AddedInformation

AddedTotalGoodsItemQuantity

AddedTotalTransportHandlingUnitQuantity

AddedInsuranceValueAmount

AddedDeclaredForCarriageValueAmount

AddedDeclaredStatisticsValueAmount

AddedFreeOnBoardValueAmount

AddedSpecialInstructions

AddedSplitConsignmentIndicator

AddedDeliveryInstructions

AddedConsignmentQuantity

AddedConsolidatableIndicator

AddedHaulageInstructions

AddedLoadingSequenceID

AddedPerformingCarrierParty

AddedSubstituteCarrierParty

AddedLogisticsOperatorParty

AddedTransportAdvisorParty

AddedHazardousItemNotificationParty

AddedInsuranceParty

AddedMortgageHolderParty

AddedBillOfLadingHolderParty

AddedCollectPaymentTerms

AddedDisbursementPaymentTerms

AddedPrepaidPaymentTerms

AddedExtraAllowanceCharge

AddedMainCarriageShipmentStage

AddedPreCarriageShipmentStage

AddedOnCarriageShipmentStage

AddedTransportHandlingUnit

AddedFirstArrivalPortLocation

30 May 2011Page 108 of 156



AddedLastExitPortLocation

AddedConsolidatedShipment

AddedConsumption

AddedConsumptionAverage

AddedConsumptionHistory

AddedConsumptionLine

AddedConsumptionPoint

AddedConsumptionReport

AddedConsumptionReportRefer-ence

Contact


Note

Contract

AddedNominationDate

AddedNominationTime

AddedNote

AddedVersionID

AddedDescription

AddedNominationPeriod

AddedContractualDelivery

AddedContractExecutionRequire-ment

AddedContractExtension

AddedContractingParty

AddedCorrection

CreditNoteLine


Note

AddedPaymentPurposeCode

AddedFreeOfChargeIndicator

AddedInvoicePeriod

AddedOrderLineReference

AddedOriginatorParty

AddedPaymentTerms

AddedAllowanceCharge

AddedDeliveryTerms

AddedSubCreditNoteLine

DebitNoteLine


Note



30 May 2011Page 109 of 156



AddedSubDebitNoteLine

AddedDeclaration

Delivery

AddedReleaseID

AddedAlternativeDeliveryLocation

AddedCarrierParty

AddedNotifyParty

AddedDeliveryTerms

AddedMinimumDeliveryUnit

AddedMaximumDeliveryUnit

AddedShipment

DeliveryTerms

AddedAmount

AddedDependentPriceReference

Despatch

AddedGuaranteedDespatchDate

AddedGuaranteedDespatchTime

AddedReleaseID

AddedInstructions

AddedDespatchLocation

AddedCarrierParty

AddedNotifyParty

AddedEstimatedDespatchPeriod

AddedRequestedDespatchPeriod

DespatchLine


Note

DocumentReference

AddedIssueTime

AddedLanguageID

AddedLocaleCode

AddedVersionID

AddedDocumentStatusCode

AddedDocumentDescription

AddedValidityPeriod

AddedIssuerParty

AddedResultOfVerification

DocumentResponse

Changed cardinality from 1 to 1..nDocumentReference

AddedDuty

AddedEconomicOperatorShortList

AddedEnergyTaxReport

30 May 2011Page 110 of 156



AddedEnergyWaterSupply

AddedEnvironmentalEmission

AddedEvaluationCriteria

AddedEvent

AddedEventComment

AddedEventLineItem

AddedEventTactic

AddedEventTacticEnumeration

AddedEvidence

AddedExceptionCriteriaLine

AddedExceptionNotificationLine

ExternalReference

AddedHashAlgorithmMethod

AddedMimeCode

AddedFormatCode

AddedEncodingCode

AddedCharacterSetCode

AddedFileName

AddedDescription

FinancialAccount

AddedAliasName

AddedAccountFormatCode

AddedFinancialGuarantee

AddedForecastException

AddedForecastExceptionCriteri-aLine

AddedForecastLine

AddedForecastRevisionLine

AddedFrameworkAgreement

GoodsItem

Changed cardinality from 1 to 0..1ID

AddedChargeableQuantity

AddedReturnableQuantity

AddedDelivery

AddedPickup

AddedDespatch

AddedMeasurementDimension

AddedContainingPackage

AddedShipmentDocumentReference

AddedImmobilizedSecurity

AddedInstructionForReturnsLine

AddedInventoryReportLine

30 May 2011Page 111 of 156



InvoiceLine


Note


AddedInvoicePeriod

AddedSubInvoiceLine

Item

AddedCertificate

AddedDimension

ItemComparison

Changed dictionary entry namefrom "Item Comparison. Price.Amount" to "Item Comparison.Price Amount. Amount"

PriceAmount

AddedItemInformationRequest-Line

ItemInstance

AddedBestBeforeDate

ItemLocationQuantity

AddedPackage



AddedItemManagementProfile

ItemProperty

AddedID

AddedNameCode

AddedTestMethod

Changed cardinality from 1 to 0..1Value

AddedValueQuantity

AddedValueQualifier

AddedImportanceCode

AddedListValue

AddedRangeDimension

AddedItemPropertyRange

ItemPropertyGroup

AddedImportanceCode


LineItem


Note

AddedWarrantyInformation

AddedSubLineItem

AddedWarrantyValidityPeriod

30 May 2011Page 112 of 156



AddedWarrantyParty

Location

AddedLocationTypeCode

AddedInformationURI

AddedSubsidiaryLocation

AddedLocationCoordinate

LocationCoordinate

AddedAltitudeMeasure

AddedMeter

AddedMeterProperty

AddedMeterReading

AddedMiscellaneousEvent

MonetaryTotal

Changed dictionary entry namefrom "Monetary Total. AllowanceTotal Amount. Amount" to "Monet-ary Total. Allowance_ TotalAmount. Amount"

AllowanceTotalAmount

Changed dictionary entry namefrom "Monetary Total. Charge TotalAmount. Amount" to "MonetaryTotal. Charge_ Total Amount.Amount"

ChargeTotalAmount

AddedPayableAlternativeAmount

AddedNotificationRequirement

AddedOnAccountPayment

OrderLine


Note

OrderReference

Changed dictionary entry namefrom "Order Reference. Sales Or-der Identifier. Identifier" to "OrderReference. Sales_ Order Identifier.Identifier"

SalesOrderID

AddedOrderTypeCode

Package

AddedTraceID

AddedContainingTransportEquipment

AddedDelivery

AddedPickup

AddedDespatch

Party

AddedIndustryClassificationCode

30 May 2011Page 113 of 156




Person

AddedServiceProviderParty

AddedPowerOfAttorney

AddedFinancialAccount

PartyLegalEntity

AddedRegistrationDate

AddedRegistrationExpirationDate

AddedCompanyLegalFormCode

AddedSoleProprietorshipIndicator

AddedCompanyLiquidationStatusCode

AddedCorporateStockAmount

AddedFullyPaidSharesIndicator

AddedHeadParty

AddedShareholderParty

AddedPaymentMandate

PaymentMeans

AddedPaymentMandate

AddedTradeFinancing

PaymentTerms


PaymentMeansID

AddedPaymentPercent

AddedSettlementDiscountAmount

AddedPenaltyAmount

AddedPaymentTermsDetailsURI

AddedPaymentDueDate

AddedInstallmentDueDate

AddedInvoicingPartyReference

AddedExchangeRate

AddedValidityPeriod

AddedPerformanceDataLine

Person

AddedID

AddedNationalityID

AddedGenderCode

AddedBirthDate

AddedContact

AddedFinancialAccount

AddedIdentityDocumentReference

AddedPickup

AddedPowerOfAttorney

30 May 2011Page 114 of 156



Price

AddedPricingExchangeRate

AddedProcessJustification

AddedProcurementProject

AddedProcurementProjectLot

AddedPromotionalEvent

AddedPromotionalEventLineItem

AddedPromotionalSpecification

AddedQualificationResolution

AddedQualifyingParty

QuotationLine


Note

AddedRequestForQuotationLineID

AddedAlternativeLineItem

AddedRequestLineReference

ReceiptLine


Note

AddedQuantityDiscrepancyCode

Changed dictionary entry namefrom "Receipt Line. OversupplyQuantity. Quantity" to "ReceiptLine. Oversupply_ Quantity.Quantity"

OversupplyQuantity

AddedRegulation

ReminderLine


Note

AddedPenaltySurchargePercent

AddedAmount


RemittanceAdviceLine


Note



AddedRenewal

RequestForQuotationLine


Note

AddedOptionalLineItemIndicator

AddedPrivacyCode

AddedSecurityClassificationCode

30 May 2011Page 115 of 156



AddedRequestForTenderLine

Response

Changed cardinality from 1 to 0..1ReferenceID

AddedEffectiveDate

AddedEffectiveTime

AddedStatus

AddedResultOfVerification

AddedRetailPlannedImpact

AddedSalesItem

AddedServicePoint

AddedServiceProviderParty


Shipment

AddedConsignmentQuantity

Changed cardinality from 1 to 1..nConsignment

AddedReturnAddress

ShipmentStage

AddedEstimatedDeliveryDate

AddedEstimatedDeliveryTime

AddedRequiredDeliveryDate

AddedRequiredDeliveryTime

AddedLoadingSequenceID

AddedSuccessiveSequenceID

AddedInstructions

AddedDemurrageInstructions

AddedLoadingTransportEvent

AddedExaminationTransportEvent

AddedAvailabilityTransportEvent

AddedExportationTransportEvent

AddedDischargeTransportEvent

AddedWarehousingTransportEvent

AddedTakeoverTransportEvent

AddedOptionalTakeoverTransportEvent

AddedDropoffTransportEvent

AddedActualPickupTransportEvent

AddedDeliveryTransportEvent

AddedReceiptTransportEvent

AddedStorageTransportEvent

AddedAcceptanceTransportEvent

AddedTerminalOperatorParty

AddedCustomsAgentParty

30 May 2011Page 116 of 156



Signature


Note

Changed dictionary entry namefrom "Signature. Validator Identifi-er. Identifier" to "Signature.Validat-or. Identifier"

ValidatorID

Changed cardinality from 1 to 0..1SignatoryParty

StatementLine


Note



Status

Changed dictionary entry namefrom "Status. Reference_ Date.Date" to "Status. Reference Date.Date"

ReferenceDate

Changed dictionary entry namefrom "Status. Reference_ Time.Time" to "Status. Reference Time.Time"

ReferenceTime


Description


StatusReason

Changed dictionary entry namefrom "Status. Sequence. Identifier"to "Status. Sequence Identifier.Identifier"

SequenceID


Text

AddedConditionValueMeasure

AddedReliabilityPercent

AddedStockAvailabilityReportLine

AddedSubcontractTerms

AddedSubscriberConsumption

AddedSupplierConsumption

TaxTotal

AddedTaxIncludedIndicator

AddedTelecommunicationsSer-vice

AddedTelecommunicationsSupply

AddedTelecommunicationsSup-plyLine

AddedTenderLine

30 May 2011Page 117 of 156



AddedTenderPreparation

AddedTenderRequirement

AddedTenderResult

AddedTenderedProject

AddedTendererPartyQualification

AddedTendererQualificationRe-quest

AddedTendererRequirement

AddedTenderingProcess

AddedTenderingTerms

AddedTradeFinancing

TransportEquipment

AddedReferencedConsignmentID

AddedAirFlowPercent

AddedHumidityPercent

AddedAnimalFoodApprovedIndicator

AddedHumanFoodApprovedIndicator

AddedDangerousGoodsApprovedIndicator

AddedRefrigeratedIndicator

AddedCharacteristics

AddedDamageRemarks

AddedDescription

AddedSpecialTransportRequirments

AddedGrossWeightMeasure

AddedGrossVolumeMeasure

AddedTareWeightMeasure

AddedTrackingDeviceCode

AddedPowerIndicator

AddedTraceID

AddedSupplierParty

AddedOwnerParty

AddedOperatingParty

AddedUnloadingLocation

AddedStorageLocation

AddedPositioningTransportEvent

AddedQuarantineTransportEvent

AddedDeliveryTransportEvent

AddedPickupTransportEvent

AddedHandlingTransportEvent

AddedLoadingTransportEvent

AddedTransportEvent

AddedApplicableTransportMeans

30 May 2011Page 118 of 156



AddedHaulageTradingTerms

AddedHazardousGoodsTransit

AddedPackagedTransportHandlingUnit

AddedServiceAllowanceCharge

AddedFreightAllowanceCharge

AddedAttachedTransportEquipment

AddedGoodsItem

AddedDelivery

AddedContainedInTransportEquipment

AddedPickup

AddedDespatch


TransportEvent

AddedLocation

AddedTransportExecutionTerms

TransportHandlingUnit

AddedTransportMeans

AddedGoodsItem

AddedFloorSpaceMeasurementDimension

AddedPalletSpaceMeasurementDimension


AddedStatus

AddedTransportLocation

TransportMeans

AddedTransportMeansTypeCode

AddedTradeServiceCode

AddedOperatorParty

AddedTransportSchedule

AddedTransportStatus

AddedTransportationSegment

TransportationService

AddedTransportationServiceDescription

AddedTransportationServiceDetailsURI

AddedNominationDate

AddedNominationTime

AddedUnstructuredPrice

AddedUtilityItem

AddedWebSiteAccess

B.3.3.2. Changes to Document Elements (UBL 2.0 to UBL 2.1 PRD2)

This table sums up all the differences between the XML elements in the UBL 2.0 document schemasand those in the UBL 2.1 (PRD2) document schemas.

30 May 2011Page 119 of 156


Table B.2. Changes to Document Elements (UBL 2.0 to UBL 2.1 PRD2)


ApplicationResponse

AddedProfileExecutionID

Changed dictionary entry name from"Application Response.Version Identi-

VersionID

fier. Identifier" to "Application Re-sponse. Version. Identifier"

Changed cardinality from 1..n to 0..nDocumentResponse

AttachedDocument


AddedParentDocumentVersionID

AddedParentDocumentLineReference

AddedAwardedNotification

BillOfLading


AddedCallForTenders

Catalogue


AddedActionCode

AddedSourceCatalogueReference

AddedDocumentReference

CatalogueDeletion


AddedEffectiveDate

AddedEffectiveTime

CatalogueItemSpecifica-tionUpdate


CataloguePricingUpdate


CatalogueRequest


AddedSignature

CertificateOfOrigin


Changed dictionary entry name from"Certificate Of Origin.Version Identifier.

VersionID

Identifier" to "Certificate Of Origin.Version. Identifier"

AddedSignature

AddedContractAwardNotice

AddedContractNotice

CreditNote

30 May 2011Page 120 of 156




AddedStatementDocumentReference

AddedOriginatorDocumentReference

AddedBuyerCustomerParty

AddedSellerSupplierParty

AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms

DebitNote






AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms

DespatchAdvice


AddedDocumentStatus

AddedDocumentStatusRequest

AddedExceptionCriteria

AddedExceptionNotification

AddedForecast

AddedForecastRevision

ForwardingInstructions


FreightInvoice


AddedGoodsItemItinerary

AddedGuaranteeCertificate

AddedInstructionForReturns

AddedInventoryReport

Invoice


AddedDueDate


AddedItemInformationRequest

Order

30 May 2011Page 121 of 156




Changed dictionary entry name from"Order. Sales Order Identifier. Identifi-er" to "Order. Sales_ Order Identifier.Identifier"

SalesOrderID

AddedOrderTypeCode

Changed dictionary entry name from"Order. Customer Reference. Text" to"Order. Customer_ Reference. Text"

CustomerReference

AddedCatalogueReference

Changed cardinality from 0..1 to 0..nPaymentMeans

AddedPaymentTerms

AddedTaxExchangeRate


AddedPaymentExchangeRate

OrderCancellation


OrderChange


Changed dictionary entry name from"Order Change. Sales Order Identifier.Identifier" to "Order Change. Sales_Order Identifier. Identifier"

SalesOrderID

Changed dictionary entry name from"Order Change. Sequence_ Number.Identifier" to "Order Change. SequenceNumber. Identifier"

SequenceNumberID

Changed dictionary entry name from"Order Change. Customer Reference.Text" to "Order Change. Customer_Reference. Text"

CustomerReference


AddedPaymentTerms




OrderResponse


Changed dictionary entry name from"Order Response. Sales Order Identifi-er. Identifier" to "Order Response.Sales_ Order Identifier. Identifier"

SalesOrderID

AddedOrderResponseCode

Changed dictionary entry name from"Order Response. Customer Refer-ence. Text" to "Order Response. Cus-tomer_ Reference. Text"

CustomerReference

30 May 2011Page 122 of 156




AddedPaymentTerms




OrderResponseSimple


PackingList


Changed dictionary entry name from"Packing List. Version Identifier. Identi-fier" to "Packing List. Version. Identifi-er"

VersionID

AddedPerformanceHistory

AddedPriorInformationNotice

AddedProductActivity

Quotation


ReceiptAdvice


Reminder


RemittanceAdvice


RequestForQuotation


AddedSubmissionDueDate

AddedRequestedValidityPeriod


AddedRetailEvent

SelfBilledCreditNote


AddedPaymentCurrencyCode

AddedPaymentAlternativeCurrencyCode





AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms

30 May 2011Page 123 of 156




AddedPaymentAlternativeExchangeRate

SelfBilledInvoice


Statement


AddedStatementTypeCode


AddedStockAvailabilityReport

AddedTender

AddedTenderReceipt

AddedTendererQualification

AddedTendererQualificationRe-sponse

AddedTradeItemLocationProfile

AddedTransportExecutionPlan

AddedTransportExecutionStatus

AddedTransportProgressStatus

AddedTransportServiceDescrip-tion

TransportationStatus


AddedUnawardedNotification

AddedUtilityStatement

Waybill


B.3.3.3. Changes to Attributes (UBL 2.0 to UBL 2.1 PRD2)

This table lists all the attributes added since the release of UBL 2.0.

30 May 2011Page 124 of 156


Table B.3. Changes to Attributes (UBL 2.0 to UBL 2.1 PRD2)

Changes for UBL 2.1AttributeType

Amount

AddedCurrencyCodeListVersionID

Measure

AddedUnitCodeListVersionID

Numeric

Addedformat

Percent

Addedformat

Rate

Addedformat

Quantity

AddedUnitCodeListID

AddedUnitCodeListAgencyID

AddedUnitCodeListAgencyName

Text

AddedlanguageLocalID

Name

AddedlanguageLocalID

B.3.4. Changes from UBL 2.1 PRD1 to UBL 2.1 PRD2

The following two tables show the differences between the elements in the first public review draft ofUBL 2.1 (PRD1) and those in this second public review draft (PRD2). No attributes were added followingPRD1.

This information is provided for reviewers of PRD2. It will be omitted in the final release.

B.3.4.1. Changes to Library Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2)

This table sums up all the differences between the XML elements in the UBL 2.1 PRD1 common libraryand those in the UBL 2.1 PRD2 common library.

30 May 2011Page 125 of 156


Table B.4. Changes to Library Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2)

Changes for PRD2Basic or Association BIEAggregate BIE

Address

Changed cardinality from 0..1 to 0..nLocationCoordinate

ConsumptionHistory

AddedMeterNumber

AddedAmount

ConsumptionReportRefer-ence

AddedTotalConsumedQuantity

Contract

AddedNominationDate

AddedNominationTime

AddedVersionID

AddedDescription

CreditNoteLine

AddedFreeOfChargeIndicator

AddedInvoicePeriod

AddedOrderLineReference

AddedOriginatorParty

AddedPaymentTerms

AddedDeliveryTerms

DebitNoteLine


Delivery

AddedReleaseID

AddedCarrierParty

AddedNotifyParty


Despatch

AddedReleaseID

AddedDespatchLocation

AddedCarrierParty

AddedNotifyParty

AddedEstimatedDespatchPeriod

AddedRequestedDespatchPeriod

DocumentReference

AddedVersionID

AddedDocumentStatusCode

AddedDocumentDescription

DocumentResponse

Changed cardinality from 1 to 1..nDocumentReference

30 May 2011Page 126 of 156



Duty

Changed dictionary entry name from"Duty. Details Duty. Duty. Text" to"Duty. Details"

Duty

Changed dictionary entry name from"Duty. Details Duty. Duty. Text" to"Duty. Duty. Text"

Duty


EnergyWaterSupply



ExceptionCriteriaLine

AddedExceptionResolutionCode

ExternalReference

AddedDescription

ForecastException

AddedForecastPurposeCode

GoodsItem

Changed cardinality from 1 to 0..1ID

AddedMeasurementDimension

AddedContainingPackage


ItemLocationQuantity



ItemProperty

AddedID

Changed cardinality from 0..1 to 1Name

AddedTestMethod

Changed cardinality from 0..n to 0..1Value

AddedListValue



LineItem

AddedWarrantyInformation

Location

AddedInformationURI

Changed cardinality from 0..1 to 0..nSubsidiaryLocation

Changed dictionary entry name from"Location. Subsidiary Location" to"Location. Subsidiary_ Location.Location"

SubsidiaryLocation

Changed cardinality from 0..1 to 0..nLocationCoordinate

30 May 2011Page 127 of 156



Meter

AddedMeterProperty

AddedMeterProperty

MeterReading

AddedMeterReadingMethod

AddedMeterReadingMethodCode

AddedMeterReadingComments


OnAccountPayment

AddedEstimatedConsumedQuantity

Package

AddedContainingTransportEquipment

PartyLegalEntity

AddedCompanyLegalFormCode

AddedSoleProprietorshipIndicator

AddedFullyPaidSharesIndicator

AddedHeadParty


PaymentTerms

AddedPaymentTermsDetailsURI


Person

AddedNationalityID

AddedGenderCode

AddedBirthDate

AddedIdentityDocumentReference

ProcessJustification

AddedProcessReasonCode

AddedProcessReason

ProcurementProject

AddedProcurementTypeCode

AddedProcurementSubTypeCode

AddedRequestedDeliveryDate

AddedEstimatedOverallContractQuantity

Changed cardinality from 0..1 to 0..nRealizedLocation

QuotationLine

AddedRequestLineReference

RemittanceAdviceLine


ResultOfVerification

AddedValidationResultCode

30 May 2011Page 128 of 156



AddedServicePoint


StatementLine


Status

Changed dictionary entry name from"Status. Reference_ Date. Date" to"Status. Reference Date. Date"

ReferenceDate

Changed dictionary entry name from"Status. Reference_ Time. Time" to"Status. Reference Time. Time"

ReferenceTime

SubscriberConsumption

AddedConsumptionID

AddedSpecificationTypeCode

Changed cardinality from 1 to 0..1Consumption

TelecommunicationsService

AddedID

AddedRoamingPartnerName

TenderResult

AddedTenderResultCode

AddedContractFormalizationPeriod

TenderingTerms

AddedCallForTenderDocumentReference

TransportEquipment

AddedPowerIndicator


TransportExecutionTerms

AddedDeliveryTerms



TransportHandlingUnit

AddedTransportMeans


AddedStatus

AddedTransportLocation

TransportMeans

AddedTransportMeansTypeCode

AddedOperatorParty

AddedTransportSchedule

TransportStatus

AddedTimeDeviationIndicator

AddedConditionDeviationIndicator

30 May 2011Page 129 of 156



AddedUpdatedDelivery

AddedUpdatedDespatch

AddedReferencedTransportHandlingUnit

AddedTransportationSegment

TransportationService

AddedNominationDate

AddedNominationTime

UnstructuredPrice

AddedPriceAmount

AddedTimeAmount

B.3.4.2. Changes to Document Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2)

This table sums up all the differences between the XML elements in the UBL 2.1 PRD1 documentschemas and those in the UBL 2.1 PRD2 document schemas.

30 May 2011Page 130 of 156


Table B.5. Changes to Document Elements (UBL 2.1 PRD1 to UBL 2.1 PRD2)


AttachedDocument

AddedParentDocumentVersionID

AddedParentDocumentLineReference

AwardedNotification

AddedAdditionalDocumentReference

CallForTenders

AddedSignature

CatalogueRequest

AddedSignature

CertificateOfOrigin

AddedSignature

ContractAwardNotice

AddedSignature

ContractNotice

AddedRequestedPublicationDate

AddedSignature

CreditNote



AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms

DebitNote



AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms

AddedGoodsItemItinerary

Invoice

AddedDueDate


PriorInformationNotice

AddedSignature


AddedPaymentCurrencyCode

AddedPaymentAlternativeCurrencyCode


30 May 2011Page 131 of 156




AddedDelivery

AddedDeliveryTerms

AddedPaymentMeans

AddedPaymentTerms


AddedPaymentAlternativeExchangeRate

Statement

AddedStatementTypeCode

TendererQualification


TransportExecutionPlan

AddedCopyIndicator

AddedUUID

AddedNote

AddedSequenceNumberID


AddedTransportUserResponseDeadlinePeriod

AddedTransportServiceProviderResponseDeadlinePeriod

TransportExecutionStatus

AddedID

AddedCopyIndicator

AddedUUID

AddedReferenceDate

AddedReferenceTime

AddedNote

AddedTransportExecutionPlanReferenceID

AddedTransportStatus

AddedTransportProgressStatus

AddedTransportServiceDescription

UnawardedNotification


30 May 2011Page 132 of 156


Appendix C.The UBL 2.1 Data Model (Non-Normative)Following the principles of the ebXML Core Components Technical Specification (CCTS), the UBL datamodel is based on a conceptual library of reusable information items known as Business InformationEntities (BIEs). BIEs include BBIEs (“basic” individual pieces of information), ABIEs (aggregations ofother BIEs), and ASBIEs (associations to other ABIEs). See [CCTS] for a further explanation of theseterms. Each business document defined by UBL is an ABIE created by assembling items appropriateto that document type from the BIE library.

Historically, both the UBL common library and the assembly models for the individual UBL documentshave been expressed as spreadsheets using a format specifically developed for UBL business informationmodeling. In former UBL releases, the XSD schemas that serve as the normative expression of UBLsyntax were generated directly from the spreadsheets prepared by business experts according to theUBL Naming and Design Rules, which are typically released as a separate OASIS Committee Specific-ation some time after each version of UBL itself. In UBL 2.0, the entire data model was also entered (viathe spreadsheets) into the internal format of a commercial data management system from GEFEG thatwas used to insure data integrity. In UBL 2.1, that process has been taken one step further; the datamodel is instantiated and maintained in iSurf eDoCreator, and both schemas and spreadsheets aregenerated from that internal model, with the schemas again produced according the UBL Naming andDesign Rules and the spreadsheets serving to provide base-level human-readable documentation andto capture the supplementary metadata required by [CCTS]. By preserving a vendor-neutral represent-ation from which schemas can be generated directly if necessary, the spreadsheets guarantee that theUBL model is not bound to a single production system.

The following diagram shows the conceptual relationships between spreadsheets and schemas in UBL2.1, with spreadsheets on the left and schemas on the right. Compare Figure 65, “UBL Schema Depend-encies”.

Figure C.1. UBL Spreadsheet Realization

30 May 2011Page 133 of 156


C.1.The UBL Common LibraryAs 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. Theentire UBL 2.1 library of Business Information Entities is contained in a single spreadsheet.

mod/common/UBL-CommonLibrary-2.1.odsmod/common/UBL-CommonLibrary-2.1.xls

C.2. UBL Document ModelsA UBL 2.1 document model defines a single “root” Aggregate BIE. This may contain several Basic BIEsand Association BIEs. Assembling the components of all the Association BIEs referenced from this rootcreates the hierarchical structure necessary to represent the document type.There are common patternsin the structure of many UBL 2.1 document models, but UBL does not enforce a "common header" forall business documents.

The document models are provided in this package as Excel and ODF spreadsheets. As noted above,these spreadsheets function as a basic form of documentation. A more accessible form of documentationis provided by HTML reports contributed by Crane Softwrights and included here by permission. Eachdocument report summarizes business object definitions and selected columns of the correspondingspreadsheet in a hyperlinked form that omits unused elements to facilitate rapid review of each documentmodel.

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, see

mod/summary/readme-Reports.html

ApplicationResponse

mod/maindoc/UBL-ApplicationResponse-2.1.odsmod/maindoc/UBL-ApplicationResponse-2.1.xlsmod/summary/reports/UBL-ApplicationResponse-2.1.html

AttachedDocument

mod/maindoc/UBL-AttachedDocument-2.1.odsmod/maindoc/UBL-AttachedDocument-2.1.xlsmod/summary/reports/UBL-AttachedDocument-2.1.html

AwardedNotification

mod/maindoc/UBL-AwardedNotification-2.1.odsmod/maindoc/UBL-AwardedNotification-2.1.xlsmod/summary/reports/UBL-AwardedNotification-2.1.html

BillOfLading

mod/maindoc/UBL-BillOfLading-2.1.odsmod/maindoc/UBL-BillOfLading-2.1.xlsmod/summary/reports/UBL-BillOfLading-2.1.html

CallForTenders

mod/maindoc/UBL-CallForTenders-2.1.ods

30 May 2011Page 134 of 156


mod/common/UBL-CommonLibrary-2.1.ods

mod/common/UBL-CommonLibrary-2.1.xls

mod/summary/reports/UBL-AllDocuments-2.1.html

mod/summary/readme-Reports.html

mod/maindoc/UBL-ApplicationResponse-2.1.ods

mod/maindoc/UBL-ApplicationResponse-2.1.xls

mod/summary/reports/UBL-ApplicationResponse-2.1.html

mod/maindoc/UBL-AttachedDocument-2.1.ods

mod/maindoc/UBL-AttachedDocument-2.1.xls

mod/summary/reports/UBL-AttachedDocument-2.1.html

mod/maindoc/UBL-AwardedNotification-2.1.ods

mod/maindoc/UBL-AwardedNotification-2.1.xls

mod/summary/reports/UBL-AwardedNotification-2.1.html

mod/maindoc/UBL-BillOfLading-2.1.ods

mod/maindoc/UBL-BillOfLading-2.1.xls

mod/summary/reports/UBL-BillOfLading-2.1.html

mod/maindoc/UBL-CallForTenders-2.1.ods

mod/maindoc/UBL-CallForTenders-2.1.xlsmod/summary/reports/UBL-CallForTenders-2.1.html

Catalogue

mod/maindoc/UBL-Catalogue-2.1.odsmod/maindoc/UBL-Catalogue-2.1.xlsmod/summary/reports/UBL-Catalogue-2.1.html

CatalogueDeletion

mod/maindoc/UBL-CatalogueDeletion-2.1.odsmod/maindoc/UBL-CatalogueDeletion-2.1.xlsmod/summary/reports/UBL-CatalogueDeletion-2.1.html

CatalogueItemSpecificationUpdate

mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.odsmod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xlsmod/summary/reports/UBL-CatalogueItemSpecificationUpdate-2.1.html

CataloguePricingUpdate

mod/maindoc/UBL-CataloguePricingUpdate-2.1.odsmod/maindoc/UBL-CataloguePricingUpdate-2.1.xlsmod/summary/reports/UBL-CataloguePricingUpdate-2.1.html

CatalogueRequest

mod/maindoc/UBL-CatalogueRequest-2.1.odsmod/maindoc/UBL-CatalogueRequest-2.1.xlsmod/summary/reports/UBL-CatalogueRequest-2.1.html

CertificateOfOrigin

mod/maindoc/UBL-CertificateOfOrigin-2.1.odsmod/maindoc/UBL-CertificateOfOrigin-2.1.xlsmod/summary/reports/UBL-CertificateOfOrigin-2.1.html

ContractAwardNotice

mod/maindoc/UBL-ContractAwardNotice-2.1.odsmod/maindoc/UBL-ContractAwardNotice-2.1.xlsmod/summary/reports/UBL-ContractAwardNotice-2.1.html

ContractNotice

mod/maindoc/UBL-ContractNotice-2.1.odsmod/maindoc/UBL-ContractNotice-2.1.xlsmod/summary/reports/UBL-ContractNotice-2.1.html

CreditNote

mod/maindoc/UBL-CreditNote-2.1.odsmod/maindoc/UBL-CreditNote-2.1.xlsmod/summary/reports/UBL-CreditNote-2.1.html

DebitNote

mod/maindoc/UBL-DebitNote-2.1.odsmod/maindoc/UBL-DebitNote-2.1.xls

30 May 2011Page 135 of 156


mod/maindoc/UBL-CallForTenders-2.1.xls

mod/summary/reports/UBL-CallForTenders-2.1.html

mod/maindoc/UBL-Catalogue-2.1.ods

mod/maindoc/UBL-Catalogue-2.1.xls

mod/summary/reports/UBL-Catalogue-2.1.html

mod/maindoc/UBL-CatalogueDeletion-2.1.ods

mod/maindoc/UBL-CatalogueDeletion-2.1.xls

mod/summary/reports/UBL-CatalogueDeletion-2.1.html

mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.ods

mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.1.xls

mod/summary/reports/UBL-CatalogueItemSpecificationUpdate-2.1.html

mod/maindoc/UBL-CataloguePricingUpdate-2.1.ods

mod/maindoc/UBL-CataloguePricingUpdate-2.1.xls

mod/summary/reports/UBL-CataloguePricingUpdate-2.1.html

mod/maindoc/UBL-CatalogueRequest-2.1.ods

mod/maindoc/UBL-CatalogueRequest-2.1.xls

mod/summary/reports/UBL-CatalogueRequest-2.1.html

mod/maindoc/UBL-CertificateOfOrigin-2.1.ods

mod/maindoc/UBL-CertificateOfOrigin-2.1.xls

mod/summary/reports/UBL-CertificateOfOrigin-2.1.html

mod/maindoc/UBL-ContractAwardNotice-2.1.ods

mod/maindoc/UBL-ContractAwardNotice-2.1.xls

mod/summary/reports/UBL-ContractAwardNotice-2.1.html

mod/maindoc/UBL-ContractNotice-2.1.ods

mod/maindoc/UBL-ContractNotice-2.1.xls

mod/summary/reports/UBL-ContractNotice-2.1.html

mod/maindoc/UBL-CreditNote-2.1.ods

mod/maindoc/UBL-CreditNote-2.1.xls

mod/summary/reports/UBL-CreditNote-2.1.html

mod/maindoc/UBL-DebitNote-2.1.ods

mod/maindoc/UBL-DebitNote-2.1.xls

mod/summary/reports/UBL-DebitNote-2.1.html

DespatchAdvice

mod/maindoc/UBL-DespatchAdvice-2.1.odsmod/maindoc/UBL-DespatchAdvice-2.1.xlsmod/summary/reports/UBL-DespatchAdvice-2.1.html

DocumentStatus

mod/maindoc/UBL-DocumentStatus-2.1.odsmod/maindoc/UBL-DocumentStatus-2.1.xlsmod/summary/reports/UBL-DocumentStatus-2.1.html

DocumentStatusRequest

mod/maindoc/UBL-DocumentStatusRequest-2.1.odsmod/maindoc/UBL-DocumentStatusRequest-2.1.xlsmod/summary/reports/UBL-DocumentStatusRequest-2.1.html

ExceptionCriteria

mod/maindoc/UBL-ExceptionCriteria-2.1.odsmod/maindoc/UBL-ExceptionCriteria-2.1.xlsmod/summary/reports/UBL-ExceptionCriteria-2.1.html

ExceptionNotification

mod/maindoc/UBL-ExceptionNotification-2.1.odsmod/maindoc/UBL-ExceptionNotification-2.1.xlsmod/summary/reports/UBL-ExceptionNotification-2.1.html

Forecast

mod/maindoc/UBL-Forecast-2.1.odsmod/maindoc/UBL-Forecast-2.1.xlsmod/summary/reports/UBL-Forecast-2.1.html

ForecastRevision

mod/maindoc/UBL-ForecastRevision-2.1.odsmod/maindoc/UBL-ForecastRevision-2.1.xlsmod/summary/reports/UBL-ForecastRevision-2.1.html

ForwardingInstructions

mod/maindoc/UBL-ForwardingInstructions-2.1.odsmod/maindoc/UBL-ForwardingInstructions-2.1.xlsmod/summary/reports/UBL-ForwardingInstructions-2.1.html

FreightInvoice

mod/maindoc/UBL-FreightInvoice-2.1.odsmod/maindoc/UBL-FreightInvoice-2.1.xlsmod/summary/reports/UBL-FreightInvoice-2.1.html

GoodsItemItinerary

mod/maindoc/UBL-GoodsItemItinerary-2.1.odsmod/maindoc/UBL-GoodsItemItinerary-2.1.xlsmod/summary/reports/UBL-GoodsItemItinerary-2.1.html

30 May 2011Page 136 of 156


mod/summary/reports/UBL-DebitNote-2.1.html

mod/maindoc/UBL-DespatchAdvice-2.1.ods

mod/maindoc/UBL-DespatchAdvice-2.1.xls

mod/summary/reports/UBL-DespatchAdvice-2.1.html

mod/maindoc/UBL-DocumentStatus-2.1.ods

mod/maindoc/UBL-DocumentStatus-2.1.xls

mod/summary/reports/UBL-DocumentStatus-2.1.html

mod/maindoc/UBL-DocumentStatusRequest-2.1.ods

mod/maindoc/UBL-DocumentStatusRequest-2.1.xls

mod/summary/reports/UBL-DocumentStatusRequest-2.1.html

mod/maindoc/UBL-ExceptionCriteria-2.1.ods

mod/maindoc/UBL-ExceptionCriteria-2.1.xls

mod/summary/reports/UBL-ExceptionCriteria-2.1.html

mod/maindoc/UBL-ExceptionNotification-2.1.ods

mod/maindoc/UBL-ExceptionNotification-2.1.xls

mod/summary/reports/UBL-ExceptionNotification-2.1.html

mod/maindoc/UBL-Forecast-2.1.ods

mod/maindoc/UBL-Forecast-2.1.xls

mod/summary/reports/UBL-Forecast-2.1.html

mod/maindoc/UBL-ForecastRevision-2.1.ods

mod/maindoc/UBL-ForecastRevision-2.1.xls

mod/summary/reports/UBL-ForecastRevision-2.1.html

mod/maindoc/UBL-ForwardingInstructions-2.1.ods

mod/maindoc/UBL-ForwardingInstructions-2.1.xls

mod/summary/reports/UBL-ForwardingInstructions-2.1.html

mod/maindoc/UBL-FreightInvoice-2.1.ods

mod/maindoc/UBL-FreightInvoice-2.1.xls

mod/summary/reports/UBL-FreightInvoice-2.1.html

mod/maindoc/UBL-GoodsItemItinerary-2.1.ods

mod/maindoc/UBL-GoodsItemItinerary-2.1.xls

mod/summary/reports/UBL-GoodsItemItinerary-2.1.html

GuaranteeCertificate

mod/maindoc/UBL-GuaranteeCertificate-2.1.odsmod/maindoc/UBL-GuaranteeCertificate-2.1.xlsmod/summary/reports/UBL-GuaranteeCertificate-2.1.html

InstructionForReturns

mod/maindoc/UBL-InstructionForReturns-2.1.odsmod/maindoc/UBL-InstructionForReturns-2.1.xlsmod/summary/reports/UBL-InstructionForReturns-2.1.html

InventoryReport

mod/maindoc/UBL-InventoryReport-2.1.odsmod/maindoc/UBL-InventoryReport-2.1.xlsmod/summary/reports/UBL-InventoryReport-2.1.html

Invoice

mod/maindoc/UBL-Invoice-2.1.odsmod/maindoc/UBL-Invoice-2.1.xlsmod/summary/reports/UBL-Invoice-2.1.html

ItemInformationRequest

mod/maindoc/UBL-ItemInformationRequest-2.1.odsmod/maindoc/UBL-ItemInformationRequest-2.1.xlsmod/summary/reports/UBL-ItemInformationRequest-2.1.html

Order

mod/maindoc/UBL-Order-2.1.odsmod/maindoc/UBL-Order-2.1.xlsmod/summary/reports/UBL-Order-2.1.html

OrderCancellation

mod/maindoc/UBL-OrderCancellation-2.1.odsmod/maindoc/UBL-OrderCancellation-2.1.xlsmod/summary/reports/UBL-OrderCancellation-2.1.html

OrderChange

mod/maindoc/UBL-OrderChange-2.1.odsmod/maindoc/UBL-OrderChange-2.1.xlsmod/summary/reports/UBL-OrderChange-2.1.html

OrderResponse

mod/maindoc/UBL-OrderResponse-2.1.odsmod/maindoc/UBL-OrderResponse-2.1.xlsmod/summary/reports/UBL-OrderResponse-2.1.html

OrderResponseSimple

mod/maindoc/UBL-OrderResponseSimple-2.1.odsmod/maindoc/UBL-OrderResponseSimple-2.1.xlsmod/summary/reports/UBL-OrderResponseSimple-2.1.html

30 May 2011Page 137 of 156


mod/maindoc/UBL-GuaranteeCertificate-2.1.ods

mod/maindoc/UBL-GuaranteeCertificate-2.1.xls

mod/summary/reports/UBL-GuaranteeCertificate-2.1.html

mod/maindoc/UBL-InstructionForReturns-2.1.ods

mod/maindoc/UBL-InstructionForReturns-2.1.xls

mod/summary/reports/UBL-InstructionForReturns-2.1.html

mod/maindoc/UBL-InventoryReport-2.1.ods

mod/maindoc/UBL-InventoryReport-2.1.xls

mod/summary/reports/UBL-InventoryReport-2.1.html

mod/maindoc/UBL-Invoice-2.1.ods

mod/maindoc/UBL-Invoice-2.1.xls

mod/summary/reports/UBL-Invoice-2.1.html

mod/maindoc/UBL-ItemInformationRequest-2.1.ods

mod/maindoc/UBL-ItemInformationRequest-2.1.xls

mod/summary/reports/UBL-ItemInformationRequest-2.1.html

mod/maindoc/UBL-Order-2.1.ods

mod/maindoc/UBL-Order-2.1.xls

mod/summary/reports/UBL-Order-2.1.html

mod/maindoc/UBL-OrderCancellation-2.1.ods

mod/maindoc/UBL-OrderCancellation-2.1.xls

mod/summary/reports/UBL-OrderCancellation-2.1.html

mod/maindoc/UBL-OrderChange-2.1.ods

mod/maindoc/UBL-OrderChange-2.1.xls

mod/summary/reports/UBL-OrderChange-2.1.html

mod/maindoc/UBL-OrderResponse-2.1.ods

mod/maindoc/UBL-OrderResponse-2.1.xls

mod/summary/reports/UBL-OrderResponse-2.1.html

mod/maindoc/UBL-OrderResponseSimple-2.1.ods

mod/maindoc/UBL-OrderResponseSimple-2.1.xls

mod/summary/reports/UBL-OrderResponseSimple-2.1.html

PackingList

mod/maindoc/UBL-PackingList-2.1.odsmod/maindoc/UBL-PackingList-2.1.xlsmod/summary/reports/UBL-PackingList-2.1.html

PerformanceHistory

mod/maindoc/UBL-PerformanceHistory-2.1.odsmod/maindoc/UBL-PerformanceHistory-2.1.xlsmod/summary/reports/UBL-PerformanceHistory-2.1.html

PriorInformationNotice

mod/maindoc/UBL-PriorInformationNotice-2.1.odsmod/maindoc/UBL-PriorInformationNotice-2.1.xlsmod/summary/reports/UBL-PriorInformationNotice-2.1.html

ProductActivity

mod/maindoc/UBL-ProductActivity-2.1.odsmod/maindoc/UBL-ProductActivity-2.1.xlsmod/summary/reports/UBL-ProductActivity-2.1.html

Quotation

mod/maindoc/UBL-Quotation-2.1.odsmod/maindoc/UBL-Quotation-2.1.xlsmod/summary/reports/UBL-Quotation-2.1.html

ReceiptAdvice

mod/maindoc/UBL-ReceiptAdvice-2.1.odsmod/maindoc/UBL-ReceiptAdvice-2.1.xlsmod/summary/reports/UBL-ReceiptAdvice-2.1.html

Reminder

mod/maindoc/UBL-Reminder-2.1.odsmod/maindoc/UBL-Reminder-2.1.xlsmod/summary/reports/UBL-Reminder-2.1.html

RemittanceAdvice

mod/maindoc/UBL-RemittanceAdvice-2.1.odsmod/maindoc/UBL-RemittanceAdvice-2.1.xlsmod/summary/reports/UBL-RemittanceAdvice-2.1.html

RequestForQuotation

mod/maindoc/UBL-RequestForQuotation-2.1.odsmod/maindoc/UBL-RequestForQuotation-2.1.xlsmod/summary/reports/UBL-RequestForQuotation-2.1.html

RetailEvent

mod/maindoc/UBL-RetailEvent-2.1.odsmod/maindoc/UBL-RetailEvent-2.1.xlsmod/summary/reports/UBL-RetailEvent-2.1.html

30 May 2011Page 138 of 156


mod/maindoc/UBL-PackingList-2.1.ods

mod/maindoc/UBL-PackingList-2.1.xls

mod/summary/reports/UBL-PackingList-2.1.html

mod/maindoc/UBL-PerformanceHistory-2.1.ods

mod/maindoc/UBL-PerformanceHistory-2.1.xls

mod/summary/reports/UBL-PerformanceHistory-2.1.html

mod/maindoc/UBL-PriorInformationNotice-2.1.ods

mod/maindoc/UBL-PriorInformationNotice-2.1.xls

mod/summary/reports/UBL-PriorInformationNotice-2.1.html

mod/maindoc/UBL-ProductActivity-2.1.ods

mod/maindoc/UBL-ProductActivity-2.1.xls

mod/summary/reports/UBL-ProductActivity-2.1.html

mod/maindoc/UBL-Quotation-2.1.ods

mod/maindoc/UBL-Quotation-2.1.xls

mod/summary/reports/UBL-Quotation-2.1.html

mod/maindoc/UBL-ReceiptAdvice-2.1.ods

mod/maindoc/UBL-ReceiptAdvice-2.1.xls

mod/summary/reports/UBL-ReceiptAdvice-2.1.html

mod/maindoc/UBL-Reminder-2.1.ods

mod/maindoc/UBL-Reminder-2.1.xls

mod/summary/reports/UBL-Reminder-2.1.html

mod/maindoc/UBL-RemittanceAdvice-2.1.ods

mod/maindoc/UBL-RemittanceAdvice-2.1.xls

mod/summary/reports/UBL-RemittanceAdvice-2.1.html

mod/maindoc/UBL-RequestForQuotation-2.1.ods

mod/maindoc/UBL-RequestForQuotation-2.1.xls

mod/summary/reports/UBL-RequestForQuotation-2.1.html

mod/maindoc/UBL-RetailEvent-2.1.ods

mod/maindoc/UBL-RetailEvent-2.1.xls

mod/summary/reports/UBL-RetailEvent-2.1.html


mod/maindoc/UBL-SelfBilledCreditNote-2.1.odsmod/maindoc/UBL-SelfBilledCreditNote-2.1.xlsmod/summary/reports/UBL-SelfBilledCreditNote-2.1.html

SelfBilledInvoice

mod/maindoc/UBL-SelfBilledInvoice-2.1.odsmod/maindoc/UBL-SelfBilledInvoice-2.1.xlsmod/summary/reports/UBL-SelfBilledInvoice-2.1.html

Statement

mod/maindoc/UBL-Statement-2.1.odsmod/maindoc/UBL-Statement-2.1.xlsmod/summary/reports/UBL-Statement-2.1.html

StockAvailabilityReport

mod/maindoc/UBL-StockAvailabilityReport-2.1.odsmod/maindoc/UBL-StockAvailabilityReport-2.1.xlsmod/summary/reports/UBL-StockAvailabilityReport-2.1.html

Tender

mod/maindoc/UBL-Tender-2.1.odsmod/maindoc/UBL-Tender-2.1.xlsmod/summary/reports/UBL-Tender-2.1.html

TenderReceipt

mod/maindoc/UBL-TenderReceipt-2.1.odsmod/maindoc/UBL-TenderReceipt-2.1.xlsmod/summary/reports/UBL-TenderReceipt-2.1.html

TendererQualification

mod/maindoc/UBL-TendererQualification-2.1.odsmod/maindoc/UBL-TendererQualification-2.1.xlsmod/summary/reports/UBL-TendererQualification-2.1.html

TendererQualificationResponse

mod/maindoc/UBL-TendererQualificationResponse-2.1.odsmod/maindoc/UBL-TendererQualificationResponse-2.1.xlsmod/summary/reports/UBL-TendererQualificationResponse-2.1.html

TradeItemLocationProfile

mod/maindoc/UBL-TradeItemLocationProfile-2.1.odsmod/maindoc/UBL-TradeItemLocationProfile-2.1.xlsmod/summary/reports/UBL-TradeItemLocationProfile-2.1.html

TransportExecutionPlan

mod/maindoc/UBL-TransportExecutionPlan-2.1.odsmod/maindoc/UBL-TransportExecutionPlan-2.1.xlsmod/summary/reports/UBL-TransportExecutionPlan-2.1.html

30 May 2011Page 139 of 156


mod/maindoc/UBL-SelfBilledCreditNote-2.1.ods

mod/maindoc/UBL-SelfBilledCreditNote-2.1.xls

mod/summary/reports/UBL-SelfBilledCreditNote-2.1.html

mod/maindoc/UBL-SelfBilledInvoice-2.1.ods

mod/maindoc/UBL-SelfBilledInvoice-2.1.xls

mod/summary/reports/UBL-SelfBilledInvoice-2.1.html

mod/maindoc/UBL-Statement-2.1.ods

mod/maindoc/UBL-Statement-2.1.xls

mod/summary/reports/UBL-Statement-2.1.html

mod/maindoc/UBL-StockAvailabilityReport-2.1.ods

mod/maindoc/UBL-StockAvailabilityReport-2.1.xls

mod/summary/reports/UBL-StockAvailabilityReport-2.1.html

mod/maindoc/UBL-Tender-2.1.ods

mod/maindoc/UBL-Tender-2.1.xls

mod/summary/reports/UBL-Tender-2.1.html

mod/maindoc/UBL-TenderReceipt-2.1.ods

mod/maindoc/UBL-TenderReceipt-2.1.xls

mod/summary/reports/UBL-TenderReceipt-2.1.html

mod/maindoc/UBL-TendererQualification-2.1.ods

mod/maindoc/UBL-TendererQualification-2.1.xls

mod/summary/reports/UBL-TendererQualification-2.1.html

mod/maindoc/UBL-TendererQualificationResponse-2.1.ods

mod/maindoc/UBL-TendererQualificationResponse-2.1.xls

mod/summary/reports/UBL-TendererQualificationResponse-2.1.html

mod/maindoc/UBL-TradeItemLocationProfile-2.1.ods

mod/maindoc/UBL-TradeItemLocationProfile-2.1.xls

mod/summary/reports/UBL-TradeItemLocationProfile-2.1.html

mod/maindoc/UBL-TransportExecutionPlan-2.1.ods

mod/maindoc/UBL-TransportExecutionPlan-2.1.xls

mod/summary/reports/UBL-TransportExecutionPlan-2.1.html

TransportExecutionStatus

mod/maindoc/UBL-TransportExecutionStatus-2.1.odsmod/maindoc/UBL-TransportExecutionStatus-2.1.xlsmod/summary/reports/UBL-TransportExecutionStatus-2.1.html

TransportProgressStatus

mod/maindoc/UBL-TransportProgressStatus-2.1.odsmod/maindoc/UBL-TransportProgressStatus-2.1.xlsmod/summary/reports/UBL-TransportProgressStatus-2.1.html

TransportServiceDescription

mod/maindoc/UBL-TransportServiceDescription-2.1.odsmod/maindoc/UBL-TransportServiceDescription-2.1.xlsmod/summary/reports/UBL-TransportServiceDescription-2.1.html

TransportationStatus

mod/maindoc/UBL-TransportationStatus-2.1.odsmod/maindoc/UBL-TransportationStatus-2.1.xlsmod/summary/reports/UBL-TransportationStatus-2.1.html

UnawardedNotification

mod/maindoc/UBL-UnawardedNotification-2.1.odsmod/maindoc/UBL-UnawardedNotification-2.1.xlsmod/summary/reports/UBL-UnawardedNotification-2.1.html

UtilityStatement

mod/maindoc/UBL-UtilityStatement-2.1.odsmod/maindoc/UBL-UtilityStatement-2.1.xlsmod/summary/reports/UBL-UtilityStatement-2.1.html

Waybill

mod/maindoc/UBL-Waybill-2.1.odsmod/maindoc/UBL-Waybill-2.1.xlsmod/summary/reports/UBL-Waybill-2.1.html

C.3. Business Information Entity DocumentationThe 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 ABIEs andASBIEs in table form.

mod/UBL-Entities-2.1.gcmod/UBL-ABIE-Reuse-Table-2.1.html

30 May 2011Page 140 of 156


mod/maindoc/UBL-TransportExecutionStatus-2.1.ods

mod/maindoc/UBL-TransportExecutionStatus-2.1.xls

mod/summary/reports/UBL-TransportExecutionStatus-2.1.html

mod/maindoc/UBL-TransportProgressStatus-2.1.ods

mod/maindoc/UBL-TransportProgressStatus-2.1.xls

mod/summary/reports/UBL-TransportProgressStatus-2.1.html

mod/maindoc/UBL-TransportServiceDescription-2.1.ods

mod/maindoc/UBL-TransportServiceDescription-2.1.xls

mod/summary/reports/UBL-TransportServiceDescription-2.1.html

mod/maindoc/UBL-TransportationStatus-2.1.ods

mod/maindoc/UBL-TransportationStatus-2.1.xls

mod/summary/reports/UBL-TransportationStatus-2.1.html

mod/maindoc/UBL-UnawardedNotification-2.1.ods

mod/maindoc/UBL-UnawardedNotification-2.1.xls

mod/summary/reports/UBL-UnawardedNotification-2.1.html

mod/maindoc/UBL-UtilityStatement-2.1.ods

mod/maindoc/UBL-UtilityStatement-2.1.xls

mod/summary/reports/UBL-UtilityStatement-2.1.html

mod/maindoc/UBL-Waybill-2.1.ods

mod/maindoc/UBL-Waybill-2.1.xls

mod/summary/reports/UBL-Waybill-2.1.html

mod/UBL-Entities-2.1.gc

mod/UBL-ABIE-Reuse-Table-2.1.html

Appendix D. UBL 2.1 Code Lists and Two-phaseValidation (Non-Normative)

D.1. IntroductionCode 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 (W3CSchema) processors. However, the specification of the default values directly in the schemas also madeit difficult to modify the code lists to suit individual trading partner relationships and impossible to extendthe 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 thestandard UBL schemas, UBL 2.0 introduced a two-phase validation model that has now been fully im-plemented in UBL 2.1. In the first phase, the UBL instance is checked for structure and vocabularyagainst a standard UBL schema using a generic schema validator (or custom-built software performingthe same function). This is exactly the same procedure used for validation in UBL 1.0, except that theschemas 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 listconfiguration files using an XSLT 1.0 processor driven by an XSLT 1.0 stylesheet. The default code listvalues assumed by the UBL 2.1 specification are expressed as data type qualifications in a file namedUBL-2.1-DefaultDTQ.xsl located in the val directory, as described in more detail below. Publiclyavailable tools were used to create the XSL file using the methodology described in the "Validation"section of [Customization], the UBL Guidelines for Customization.

Separating the checking of structure and vocabulary from the checking of code values allows tradingpartners to easily and precisely specify code list subsets and extensions and to apply them not just toindividual UBL document types but also to particular elements and subtrees within UBL document in-stances. Another way to say this is that the the UBL code list methodology allows different versions ofthe same code list to be used in different document contexts. Thus, for example, a business in Canadamight agree with a business in the United States to use a set of code list configuration files that allowthe Buyer to be associated with either a U.S. state or a Canadian province but restrict the Seller to justU.S. states—that is, to apply a code list subset containing state and province codes in one place in adocument instance and a different code list subset containing just state codes in another place in theinstance.

D.2. Default Validation SetupTo facilitate the processing of UBL 2.1 instances using the two-phase method, an “out-of-the-box” col-lection of open-source software that can be used to demonstrate default validation of UBL 2.1 documentsis included in the val directory of this release package. The validation harness assumes a Linux orWindows 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 xercesschema parser. If necessary, download and install the latest JRE from the following location beforecontinuing:

http://www.java.com/en/download/manual.jsp

To demonstrate UBL 2.1 default validation:

30 May 2011Page 141 of 156


http://www.java.com/en/download/manual.jsp

1. Change to the val directory.

2. 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 Figure D.1(the spacing has been manually adjusted to make the output easier to read).

Figure D.1. Validation test output

3. From within the val directory, you can now validate any UBL document against the UBL 2.1schemas 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> isthe path of the UBL 2.1 schema for that document type (Order, Invoice, etc.). For example, thescripts val/testsamples.bat and val/testsamples.sh show this process being used tovalidate the sample XML instances in the xml directory.

D.3. Discussion of the Default Validation TestThe test output displayed above demonstrates the default validation process with three test files: a validUBL Order (order-test-good.xml); a UBL Order containing a bad (misspelled) element(order-test-bad1.xml); and a UBL Order that is schema-valid but contains an illegal code list value(order-test-bad2.xml). The file test.bat (Windows) or test.sh (Linux) is used to run the scriptvalidate.bat or validate.sh against each of the test files.

The first run using order-test-good.xml demonstrates both phases of the default validation processrunning normally. In the first phase, a standard W3C Schema (XSD) validator, xerces, is invoked from

30 May 2011Page 142 of 156


val/testsamples.bat

val/testsamples.sh

w3cschema.bat (or w3cschema.sh) to validate the specified UBL document (.xml) against thespecified UBL 2.1 runtime schema (.xsd). Since the input is a valid UBL Order, the output of the firstphase 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 ofvarious codes used in the UBL document to be tested (currency codes, packaging types, etc.) are validin terms of the default UBL 2.1 code list values specified in UBL-DefaultDTQ-2.1.xsl. Here theoutput line “No code list validation errors” from the validate script indicates that the saxon run (invokedfrom xslt.bat or xslt.sh) finds no illegal code values in the document.

The second run shows what happens when the input document (order-test-bad1.xml) containsan actual structure or vocabulary error, in this case due to omission of the trailing “e” from the elementnamed cbc:ChannelCode. When the xerces parser encounters the malformed element name, it emitsthe error message shown in the example, and the validate script reacts to a non-zero status codefrom 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 Orderschema, but it contains an illegal code list value (the ChannelCode “AL” for cell phone has been mistypedas “LA”).Thus it passes the first phase when tested against the schema but fails the second phase whentested against UBL-DefaultDTQ-2.1.xsl.

To summarize, input documents are checked in the first validation phase for correctness of structureand vocabulary, using the constraints expressed in the appropriate UBL schema, and then they arechecked in the second phase for correctness of default code list values, using the default constraintsexpressed in the XSLT file UBL-DefaultDTQ-2.1.xsl. This process is illustrated in the followingdiagram.

Figure D.2. Two-phase Default UBL 2.1 Validation

It should be clear from the foregoing that the second phase of the default validation process can safelybe 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 itwill not give reliable results if run in the absence of the first (schema) validation phase.

30 May 2011Page 143 of 156


D.4. Customizing the Default XSLT FileThe 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 thesame code list with different parts of the same UBL document by substituting a custom process (be itXSLT or some other language or process) for the default UBL-DefaultDTQ-2.1.xsl provided in theUBL 2.1 distribution. This allows extensive code list management without the need to change thestandard UBL 2.1 schemas. Schematron-based techniques for generating a custom XSLT file to takethe place of UBL-DefaultDTQ-2.1.xsl are explained in [CVA] and [Customization]. See also Ap-pendix F, Data Type Qualifications in UBL (Non-Normative) for more about UBL data type qualifications.

Since XSLT is a very powerful general-purpose XML transformation tool, the same framework can beextended to perform fairly sophisticated business rule checking by manually coding additional logic intothe XSLT file that drives the second validation phase. Such modification is beyond the scope of thecustomization methodologies associated specifically with UBL, but a business analyst willing to performXSLT programming can use this mechanism to offload a large proportion of input filtering from thebackend business application to a simpler input processing area. Additional XSLT scripts can be addedto extract logical subtrees of incoming UBL documents for allocation to different downstream processesand to perform even more extensive front-end processing.

D.5. Sources for the Default Validation FrameworkComponents 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 files resolver.jar and xercesImpl.jar are from the xerces-j 2.8.0 binary distribution at

http://archive.apache.org/dist/xml/xerces-j/Xerces-J-bin.2.8.0.zip

• The file xjparse.jar (renamed from xjparse-1.0.jar) is from the xjparse 1.0 distribution at

http://nwalsh.com/java/xjparse/

• The file saxon.jar is from the saxon 6.5.5 distribution at

http://prdownloads.sourceforge.net/saxon/saxon6-5-5.zip

D.6. Code Lists Included in UBL 2.1The code lists included in the UBL 2.1 distribution use an OASIS Standard XML format for code listscalled [genericode]. Each code list in the distribution occupies its own genericode file. Documentationon 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 andcl/gc/special-purpose.

D.6.1. cl/gc/default

The code lists in the cl/gc/default directory contain the default code values represented inUBL-DefaultDTQ-2.1.xsl. A second-phase code list check using an unmodified version of the testsetup from this distribution as described above will verify all occurrences of code values from these listsagainst the values specified in the cl/gc/default directory. These are the code lists expected to beused in most application contexts.

30 May 2011Page 144 of 156


http://archive.apache.org/dist/xml/xerces-j/Xerces-J-bin.2.8.0.zip

http://nwalsh.com/java/xjparse/

http://prdownloads.sourceforge.net/saxon/saxon6-5-5.zip


cl/gc/default/AllowanceChargeReasonCode-2.1.gccl/gc/default/BinaryObjectMimeCode-2.1.gccl/gc/default/ChannelCode-2.1.gccl/gc/default/CurrencyCode-2.1.gccl/gc/default/PackagingTypeCode-2.1.gccl/gc/default/PaymentMeansCode-2.1.gccl/gc/default/TransportEquipmentTypeCode-2.1.gccl/gc/default/TransportModeCode-2.1.gccl/gc/default/UnitOfMeasureCode-2.1.gc

D.6.2. cl/gc/special-purpose

This directory contains genericode versions of code lists that are used only in certain application contexts.They are not included in the UBL-DefaultDTQ-2.1.xsl file included in this distribution, but areprovided here in the cl/gc/special-purpose directory to make them available for incorporation intocustom XSLT scripts.

The files in this directory are as follows:

cl/gc/special-purpose/AdjustmentReasonCode-2.1.gccl/gc/special-purpose/CollaborationPriorityCode-2.1.gccl/gc/special-purpose/ComparisonDataSourceCode-2.1.gccl/gc/special-purpose/DataSourceCode-2.1.gccl/gc/special-purpose/DisplayTacticTypeCode-2.1.gccl/gc/special-purpose/ExceptionStatusCode-2.1.gccl/gc/special-purpose/ForecastPurposeCode-2.1.gccl/gc/special-purpose/ForecastTypeCode-2.1.gccl/gc/special-purpose/LanguageCode-2.1.gccl/gc/special-purpose/MiscellaneousEventTypeCode-2.1.gccl/gc/special-purpose/PerformanceMetricCriterionCode-2.1.gccl/gc/special-purpose/PromotionalEventTypeCode-2.1.gccl/gc/special-purpose/ResolutionCode-2.1.gccl/gc/special-purpose/RetailEventStatusCode-2.1.gccl/gc/special-purpose/RevisionStatusCode-2.1.gccl/gc/special-purpose/StatusCode-2.1.gccl/gc/special-purpose/SupplyChainActivityTypeCode-2.1.gccl/gc/special-purpose/ThresholdValueComparisonCode-2.1.gccl/gc/special-purpose/TimeFrequencyCode-2.1.gccl/gc/special-purpose/TransportationStatusCode-2.1.gc

30 May 2011Page 145 of 156


cl/gc/default/AllowanceChargeReasonCode-2.1.gc

cl/gc/default/BinaryObjectMimeCode-2.1.gc

cl/gc/default/ChannelCode-2.1.gc

cl/gc/default/CurrencyCode-2.1.gc

cl/gc/default/PackagingTypeCode-2.1.gc

cl/gc/default/PaymentMeansCode-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/special-purpose/AdjustmentReasonCode-2.1.gc

cl/gc/special-purpose/CollaborationPriorityCode-2.1.gc

cl/gc/special-purpose/ComparisonDataSourceCode-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/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

Appendix E. UBL 2.1 Example Document In-stances (Non-Normative)The xml directory of this distribution contains a number of sample UBL documents that can be used fortesting purposes.The testsamples.bat batch file and the testsamples.sh script in the val directoryof this distribution can be used to demonstrate the validity of these examples in Windows and Linuxoperating environments. See Appendix D, UBL 2.1 Code Lists and Two-phase Validation (Non-Normative)for a general discussion of UBL validation methodology.

Example instances containing extensions

xml/MyTransportationStatus.xmlxml/UBL-Invoice-2.0-Enveloped.xml

Example instances related to signatures (see Section 5.6, “Digital Signature Ex-amples”)

xml/UBL-Invoice-2.0-Detached-Signature.xmlxml/UBL-Invoice-2.0-Detached.xmlxml/UBL-Invoice-2.0-Enveloped.xml

Example instances with unconventional use of namespace bindings

xml/UBL-Invoice-2.0-Example-NS1.xmlxml/UBL-Invoice-2.0-Example-NS2.xmlxml/UBL-Invoice-2.0-Example-NS3.xmlxml/UBL-Invoice-2.0-Example-NS4.xml

Example instances of different versions of different document types

xml/UBL-CreditNote-2.0-Example.xmlxml/UBL-CreditNote-2.1-Example.xmlxml/UBL-DebitNote-2.1-Example.xmlxml/UBL-DespatchAdvice-2.0-Example.xmlxml/UBL-ExceptionCriteria-2.1-Example.xmlxml/UBL-ExceptionNotification-2.1-Example.xmlxml/UBL-Forecast-2.1-Example.xmlxml/UBL-ForecastRevision-2.1-Example.xmlxml/UBL-ForwardingInstructions-2.0-Example-International.xmlxml/UBL-FreightInvoice-2.1-Example.xmlxml/UBL-GoodsItemItinerary-2.1-Example.xmlxml/UBL-InstructionForReturns-2.1-Example.xmlxml/UBL-InventoryReport-2.1-Example.xmlxml/UBL-Invoice-2.0-Example.xmlxml/UBL-Invoice-2.1-Example.xmlxml/UBL-Order-2.0-Example-International.xmlxml/UBL-Order-2.0-Example.xmlxml/UBL-Order-2.1-Example.xmlxml/UBL-OrderCancellation-2.1-Example.xmlxml/UBL-OrderChange-2.1-Example.xmlxml/UBL-OrderResponse-2.1-Example.xmlxml/UBL-OrderResponseSimple-2.0-Example.xmlxml/UBL-OrderResponseSimple-2.1-Example.xmlxml/UBL-PerformanceHistory-2.1-Example.xmlxml/UBL-ProductActivity-2.1-Example-1.xmlxml/UBL-ProductActivity-2.1-Example-2.xml

30 May 2011Page 146 of 156


xml/MyTransportationStatus.xml


xml/UBL-Invoice-2.0-Detached-Signature.xml



xml/UBL-Invoice-2.0-Example-NS1.xml




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-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-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-PerformanceHistory-2.1-Example.xml

xml/UBL-ProductActivity-2.1-Example-1.xml


xml/UBL-ProductActivity-2.1-Example-3.xmlxml/UBL-Quotation-2.0-Example.xmlxml/UBL-Quotation-2.1-Example.xmlxml/UBL-ReceiptAdvice-2.0-Example.xmlxml/UBL-Reminder-2.1-Example.xmlxml/UBL-RemittanceAdvice-2.0-Example.xmlxml/UBL-RequestForQuotation-2.0-Example.xmlxml/UBL-RequestForQuotation-2.1-Example.xmlxml/UBL-RetailEvent-2.1-Example.xmlxml/UBL-SelfBilledCreditNote-2.1-Example.xmlxml/UBL-Statement-2.0-Example.xmlxml/UBL-StockAvailabilityReport-2.1-Example.xmlxml/UBL-TradeItemLocationProfile-2.1-Example.xmlxml/UBL-TransportationStatus-2.1-Example.xmlxml/UBL-TransportExecutionPlan-2.1-Example.xmlxml/UBL-TransportExecutionStatus-2.1-Example.xmlxml/UBL-TransportProgressStatus-2.1-Example.xmlxml/UBL-TransportServiceDescription-2.1-Example.xmlxml/UBL-Waybill-2.0-Example-International.xml

30 May 2011Page 147 of 156



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-TransportExecutionPlan-2.1-Example.xml

xml/UBL-TransportExecutionStatus-2.1-Example.xml

xml/UBL-TransportProgressStatus-2.1-Example.xml

xml/UBL-TransportServiceDescription-2.1-Example.xml

xml/UBL-Waybill-2.0-Example-International.xml

Appendix F. Data Type Qualifications in UBL(Non-Normative)All UBL data types ultimately derive either from the UN/CEFACT Core Components Technical Specific-ation [CCTS] Core Component Types (CCT) or from the W3C Schema specification [XSD2] itself; thisderivation takes place in the UBL UDT module.The following table lists the CCTS 2.01 Core ComponentTypes.

Table F.1. CCTS Unqualified Data Types

DefinitionCCTS Data Type

A number of monetary units specified in a currency where the unit of currencyis explicit or implied.

Amount. Type

A set of finite-length sequences of binary octets.Binary Object. Type

A character string (letters, figures or symbols) that for brevity and/or languageindependence may be used to represent or replace a definitive value or textof an Attribute together with relevant supplementary information.

Code. Type

A particular point in the progression of time together with relevant supplement-ary information.

Date Time. Type

A character string to identify and distinguish uniquely, one instance of anobject in an identification scheme from all other objects in the same schemetogether with relevant supplementary information.

Identifier. Type

A list of two mutually exclusive Boolean values that express the only possiblestates of a Property.

Indicator. Type

A numeric value determined by measuring an object along with the specifiedunit of measure.

Measure. 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.

Numeric. Type

A counted number of non-monetary units possibly including fractions.Quantity. Type

A character string (i.e. a finite set of characters) generally in the form of wordsof a language.

Text. Type

The UBL unqualified data types include the CCTS unqualified data types (named per UBL NDR) and afew others, as listed in the following table.

30 May 2011Page 148 of 156


Table F.2. UBL Unqualified Data Types

DefinitionUBL Unqualified DataType

A number of monetary units specified in a currency where the unit of thecurrency is explicit or implied.

AmountType

A set of finite-length sequences of binary octets.BinaryObjectType

A diagram, graph, mathematical curves, or similar representation.GraphicType

A diagram, graph, mathematical curves, or similar representation.PictureType

A diagram, graph, mathematical curves, or similar representation.SoundType

A diagram, graph, mathematical curves, or similar representation.VideoType

A character string (letters, figures, or symbols) that for brevity and/or lan-guange independence may be used to represent or replace a definitive valueor text of an attribute together with relevant supplementary information.

CodeType

A particular point in the progression of time together with the relevant supple-mentary information.

DateTimeType

One calendar day according the Gregorian calendar.DateType

The instance of time that occurs every day.TimeType

A character string to identify and distinguish uniquely, one instance of anobject in an identification scheme from all other objects in the same schemetogether with relevant supplementary information.

IdentifierType

A list of two mutually exclusive Boolean values that express the only possiblestates of a property.

IndicatorType

A numeric value determined by measuring an object along with the specifiedunit of measure.

MeasureType


NumericType


ValueType


PercentType

Numeric information that is assigned or is determined by calculation, counting,or sequencing. It does not require a unit of quantity or unit of measuret.

RateType

A counted number of non-monetary units possibly including fractions.QuantityType

A character string (i.e. a finite set of characters) generally in the form of wordsof a language.

TextType

A character string that consititues the distinctive designation of a person,place, thing or concept.

NameType

Some UBL BBIEs have data type qualifications based on the unqualified UBL types. These qualifiedtypes are all code types, and their definitions are the mechanism whereby a specific set of values isassociated with each code.

UBL data type qualifications are expressed formally in an OASIS [CVA] (Context/Value Association) filecontained in the cva directory of the 2.1 distribution.The specification of the CVA mechanism and formatis maintained by the OASIS Code List Representation Technical Committee.

cva/UBL-DefaultDTQ-2.1.cva

A human-readable version is provided in an accompanying HTML file, which also serves as primarydocumentation on the UBL codes defined as qualified data types.

30 May 2011Page 149 of 156


cva/UBL-DefaultDTQ-2.1.cva


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 toperform a check of code list values. See Appendix D, UBL 2.1 Code Lists and Two-phase Validation(Non-Normative) 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.

Figure F.1. Data Type Qualification in UBL 2.1

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 datatypes (B) and the data types defined in a file of UBL 2.1 unqualified data types (C). The latter inheritsthe data type definitions in the UN/CEFACT CCTS CCT schema module Ver. 1.1 050114 (D). The UBL2.1 CVA file (E) controls the creation of the UBL 2.1 XSLT stylesheet (F) used in validation. While thisXSLT file, UBL-2.1-DefaultDTQ.xsl, can, in theory, apply to qualified data type qualifications ingeneral (such as field length restrictions and value range restrictions), the version of this file includedin 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 typequalifications if desired by preparing a custom CVA (G) and creating a custom XSLT file (H) to replacethe 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 containsrelative URIs that expect the UBL 2.0 code lists from the UBL 2.0 Update Package in a sibling directorynamed os-UBL-2.0. This is irrelevant to users of the precompiled val/UBL-DefaultDTQ-2.1.xslfile contained in the UBL 2.1 package, but users wishing to create their own CVA file must first installthe UBL 2.0 release and then the UBL 2.0 update.To properly install the update, first download and installthe original UBL 2.0 release:

http://docs.oasis-open.org/ubl/os-UBL-2.0.zip

30 May 2011Page 150 of 156



val/UBL-DefaultDTQ-2.1.xsl

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, theos-UBL-2.0 directory thus created must be a sibling to the directory created by installing the UBL 2.1package.

30 May 2011Page 151 of 156


http://docs.oasis-open.org/ubl/os-UBL-2.0-update-delta.zip

Appendix G. Alternative Representations of theUBL 2.1 Schemas (Non-Normative)UBL 2.1 continues the practice, adopted at the beginning of the UBL effort, of creating its normativeXML specifications using W3C Schema (XSD) syntax. Included in this release are two additional altern-ative specifications of the same content: a set of UBL 2.1 ASN.1 modules and a set of UBL 2.1 RELAXNG (compact syntax) schemas. These alternative representations are technically non-normative, butboth are generated directly from the XSD and, with the exception of the UBL 2.1 digital signature extension(see Section 5, “UBL Extension for XML Digital Signatures”), both are intended to implement the samedocument instance constraints.

G.1. ASN.1 UBL 2.1 SpecificationThe UBL ASN.1 specification linked below provides an alternative schema definition for UBL documentsin accordance with ITU-T X.680-X.693 [ASN.1]. The UBL ASN.1 specification defines the same UBLdocuments 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 conjunctionwith the ASN.1 Packed Encoding Rules, it provides a specification for an efficient binary encoding ofUBL messages.

The zip archive below contains the ASN.1 modules corresponding to the UBL 2.1 document schemasas individual text files. The ASN.1 modules were created using a tool from OSS Nokalva [http://www.oss.com/] that conforms to ITU-T Recommendation X.694 | ISO/IEC 8825-5 for converting XSDSchema to ASN.1.

UBL 2.1 ASN.1 Modulesasn/ASN.1-UBL-2.1-text.zip

After conversion from XSD, the generated ASN.1 was formatted by the PrettyPrint tool at the ASN.1Information Site [http://asn1.elibel.tm.fr/] to produce the following HTML documentation file.

UBL 2.1 ASN.1 Specificationasn/ASN.1-UBL-2.1.html

G.2. UBL 2.1 RELAX NG Schemas[RELAX NG] (compact syntax) versions of the UBL schemas contributed by Crane Softwrights [http://cranesoftwrights.com/] and used here by permission are located in the rnc directory.The Crane packageincludes 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 schemas are made accessible separately as listed below. In this release(PRD1), these schemas do not support the signature extension described in Section 5, “UBL Extensionfor XML Digital Signatures”.

ApplicationResponsernc/versions/UBL-ApplicationResponse-2.1.rnc

AttachedDocumentrnc/versions/UBL-AttachedDocument-2.1.rnc

AwardedNotificationrnc/versions/UBL-AwardedNotification-2.1.rnc

30 May 2011Page 152 of 156


http://www.oss.com/

asn/ASN.1-UBL-2.1-text.zip

http://asn1.elibel.tm.fr/

http://asn1.elibel.tm.fr/

asn/ASN.1-UBL-2.1.html

http://cranesoftwrights.com/

rnc/readme-rnc.html

rnc/versions/UBL-ApplicationResponse-2.1.rnc

rnc/versions/UBL-AttachedDocument-2.1.rnc

rnc/versions/UBL-AwardedNotification-2.1.rnc

BillOfLadingrnc/versions/UBL-BillOfLading-2.1.rnc

CallForTendersrnc/versions/UBL-CallForTenders-2.1.rnc

Cataloguernc/versions/UBL-Catalogue-2.1.rnc

CatalogueDeletionrnc/versions/UBL-CatalogueDeletion-2.1.rnc

CatalogueItemSpecificationUpdaternc/versions/UBL-CatalogueItemSpecificationUpdate-2.1.rnc

CataloguePricingUpdaternc/versions/UBL-CataloguePricingUpdate-2.1.rnc

CatalogueRequestrnc/versions/UBL-CatalogueRequest-2.1.rnc

CertificateOfOriginrnc/versions/UBL-CertificateOfOrigin-2.1.rnc

ContractAwardNoticernc/versions/UBL-ContractAwardNotice-2.1.rnc

ContractNoticernc/versions/UBL-ContractNotice-2.1.rnc

CreditNoternc/versions/UBL-CreditNote-2.1.rnc

DebitNoternc/versions/UBL-DebitNote-2.1.rnc

DespatchAdvicernc/versions/UBL-DespatchAdvice-2.1.rnc

DocumentStatusrnc/versions/UBL-DocumentStatus-2.1.rnc

DocumentStatusRequestrnc/versions/UBL-DocumentStatusRequest-2.1.rnc

ExceptionCriteriarnc/versions/UBL-ExceptionCriteria-2.1.rnc

ExceptionNotificationrnc/versions/UBL-ExceptionNotification-2.1.rnc

Forecastrnc/versions/UBL-Forecast-2.1.rnc

ForecastRevisionrnc/versions/UBL-ForecastRevision-2.1.rnc

ForwardingInstructionsrnc/versions/UBL-ForwardingInstructions-2.1.rnc

30 May 2011Page 153 of 156


rnc/versions/UBL-BillOfLading-2.1.rnc

rnc/versions/UBL-CallForTenders-2.1.rnc

rnc/versions/UBL-Catalogue-2.1.rnc

rnc/versions/UBL-CatalogueDeletion-2.1.rnc

rnc/versions/UBL-CatalogueItemSpecificationUpdate-2.1.rnc

rnc/versions/UBL-CataloguePricingUpdate-2.1.rnc

rnc/versions/UBL-CatalogueRequest-2.1.rnc

rnc/versions/UBL-CertificateOfOrigin-2.1.rnc

rnc/versions/UBL-ContractAwardNotice-2.1.rnc

rnc/versions/UBL-ContractNotice-2.1.rnc

rnc/versions/UBL-CreditNote-2.1.rnc

rnc/versions/UBL-DebitNote-2.1.rnc

rnc/versions/UBL-DespatchAdvice-2.1.rnc

rnc/versions/UBL-DocumentStatus-2.1.rnc

rnc/versions/UBL-DocumentStatusRequest-2.1.rnc

rnc/versions/UBL-ExceptionCriteria-2.1.rnc

rnc/versions/UBL-ExceptionNotification-2.1.rnc

rnc/versions/UBL-Forecast-2.1.rnc

rnc/versions/UBL-ForecastRevision-2.1.rnc

rnc/versions/UBL-ForwardingInstructions-2.1.rnc

FreightInvoicernc/versions/UBL-FreightInvoice-2.1.rnc

GoodsItemItineraryrnc/versions/UBL-GoodsItemItinerary-2.1.rnc

GuaranteeCertificaternc/versions/UBL-GuaranteeCertificate-2.1.rnc

InstructionForReturnsrnc/versions/UBL-InstructionForReturns-2.1.rnc

InventoryReportrnc/versions/UBL-InventoryReport-2.1.rnc

Invoicernc/versions/UBL-Invoice-2.1.rnc

ItemInformationRequestrnc/versions/UBL-ItemInformationRequest-2.1.rnc

Orderrnc/versions/UBL-Order-2.1.rnc

OrderCancellationrnc/versions/UBL-OrderCancellation-2.1.rnc

OrderChangernc/versions/UBL-OrderChange-2.1.rnc

OrderResponsernc/versions/UBL-OrderResponse-2.1.rnc

OrderResponseSimplernc/versions/UBL-OrderResponseSimple-2.1.rnc

PackingListrnc/versions/UBL-PackingList-2.1.rnc

PerformanceHistoryrnc/versions/UBL-PerformanceHistory-2.1.rnc

PriorInformationNoticernc/versions/UBL-PriorInformationNotice-2.1.rnc

ProductActivityrnc/versions/UBL-ProductActivity-2.1.rnc

Quotationrnc/versions/UBL-Quotation-2.1.rnc

ReceiptAdvicernc/versions/UBL-ReceiptAdvice-2.1.rnc

Reminderrnc/versions/UBL-Reminder-2.1.rnc

RemittanceAdvicernc/versions/UBL-RemittanceAdvice-2.1.rnc

30 May 2011Page 154 of 156


rnc/versions/UBL-FreightInvoice-2.1.rnc

rnc/versions/UBL-GoodsItemItinerary-2.1.rnc

rnc/versions/UBL-GuaranteeCertificate-2.1.rnc

rnc/versions/UBL-InstructionForReturns-2.1.rnc

rnc/versions/UBL-InventoryReport-2.1.rnc

rnc/versions/UBL-Invoice-2.1.rnc

rnc/versions/UBL-ItemInformationRequest-2.1.rnc

rnc/versions/UBL-Order-2.1.rnc

rnc/versions/UBL-OrderCancellation-2.1.rnc

rnc/versions/UBL-OrderChange-2.1.rnc

rnc/versions/UBL-OrderResponse-2.1.rnc

rnc/versions/UBL-OrderResponseSimple-2.1.rnc

rnc/versions/UBL-PackingList-2.1.rnc

rnc/versions/UBL-PerformanceHistory-2.1.rnc

rnc/versions/UBL-PriorInformationNotice-2.1.rnc

rnc/versions/UBL-ProductActivity-2.1.rnc

rnc/versions/UBL-Quotation-2.1.rnc

rnc/versions/UBL-ReceiptAdvice-2.1.rnc

rnc/versions/UBL-Reminder-2.1.rnc

rnc/versions/UBL-RemittanceAdvice-2.1.rnc

RequestForQuotationrnc/versions/UBL-RequestForQuotation-2.1.rnc

RetailEventrnc/versions/UBL-RetailEvent-2.1.rnc

SelfBilledCreditNoternc/versions/UBL-SelfBilledCreditNote-2.1.rnc

SelfBilledInvoicernc/versions/UBL-SelfBilledInvoice-2.1.rnc

Statementrnc/versions/UBL-Statement-2.1.rnc

StockAvailabilityReportrnc/versions/UBL-StockAvailabilityReport-2.1.rnc

Tenderrnc/versions/UBL-Tender-2.1.rnc

TenderReceiptrnc/versions/UBL-TenderReceipt-2.1.rnc

TendererQualificationrnc/versions/UBL-TendererQualification-2.1.rnc

TendererQualificationResponsernc/versions/UBL-TendererQualificationResponse-2.1.rnc

TradeItemLocationProfilernc/versions/UBL-TradeItemLocationProfile-2.1.rnc

TransportExecutionPlanrnc/versions/UBL-TransportExecutionPlan-2.1.rnc

TransportExecutionStatusrnc/versions/UBL-TransportExecutionStatus-2.1.rnc

TransportProgressStatusrnc/versions/UBL-TransportProgressStatus-2.1.rnc

TransportServiceDescriptionrnc/versions/UBL-TransportServiceDescription-2.1.rnc

TransportationStatusrnc/versions/UBL-TransportationStatus-2.1.rnc

UnawardedNotificationrnc/versions/UBL-UnawardedNotification-2.1.rnc

UtilityStatementrnc/versions/UBL-UtilityStatement-2.1.rnc

Waybillrnc/versions/UBL-Waybill-2.1.rnc

30 May 2011Page 155 of 156


rnc/versions/UBL-RequestForQuotation-2.1.rnc

rnc/versions/UBL-RetailEvent-2.1.rnc

rnc/versions/UBL-SelfBilledCreditNote-2.1.rnc

rnc/versions/UBL-SelfBilledInvoice-2.1.rnc

rnc/versions/UBL-Statement-2.1.rnc

rnc/versions/UBL-StockAvailabilityReport-2.1.rnc

rnc/versions/UBL-Tender-2.1.rnc

rnc/versions/UBL-TenderReceipt-2.1.rnc

rnc/versions/UBL-TendererQualification-2.1.rnc

rnc/versions/UBL-TendererQualificationResponse-2.1.rnc

rnc/versions/UBL-TradeItemLocationProfile-2.1.rnc

rnc/versions/UBL-TransportExecutionPlan-2.1.rnc

rnc/versions/UBL-TransportExecutionStatus-2.1.rnc

rnc/versions/UBL-TransportProgressStatus-2.1.rnc

rnc/versions/UBL-TransportServiceDescription-2.1.rnc

rnc/versions/UBL-TransportationStatus-2.1.rnc

rnc/versions/UBL-UnawardedNotification-2.1.rnc

rnc/versions/UBL-UtilityStatement-2.1.rnc

rnc/versions/UBL-Waybill-2.1.rnc

Appendix H. AcknowledgementsThe OASIS UBL Technical Committee thanks Altova for its contribution of XML Spy licenses for use inUBL schema design; Sparx Systems for its contribution of Enterprise Architect licenses for use in devel-oping UML content models; Syncro Soft for its contribution of oXygen licenses used in DocBook authoringof UBL documentation; RenderX for its contribution of XEP licenses used in generating PDF documentsfrom DocBook originals; SRDC for developing iSurf eDoCreator (supported by European CommissionFP7 ICT-213031 iSurf Project) and providing technical assistance in its use as an online repository andediting environment for UBL 2.1 document models and the generation of UBL schemas; OSS Nokalvafor its contribution of ASN.1 UBL 2.1 specifications; and Crane Softwrights for permission to include acopy of their publicly-available HTML reports and UBL 2.1 RELAX NG schema resources.

30 May 2011Page 156 of 156
