Universal Business Language v2.0

Standard, 12 December 2006

Document identifier:
UBL-2.0 ( XML , HTML , PDF )
Locations:
Persistent version: http://docs.oasis-open.org/ubl/os-UBL-2.0/
Current version: http://docs.oasis-open.org/ubl/os-UBL-2.0/
Technical committee:
OASIS Universal Business Language (UBL) TC
Chairs:
Jon Bosak, Sun Microsystems 
Tim McGrath 
Editors:
Jon Bosak, Sun Microsystems 
Tim McGrath 
G. Ken Holman, Crane Softwrights Ltd. 
Subject / Keywords:
Universal Business Language, UBL
OASIS Conceptual Model Topic Area:
Electronic Commerce
Abstract:

This specification defines the Universal Business Language, version 2.0.

Related Work:

This specification supersedes UBL 1.0.

Status:

This document was last revised or approved by the UBL TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.

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

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

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/ubl/.

See Appendix A, Release Notes (Informative) for more information regarding this release package.

Notices:

Copyright © OASIS Open 2006. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’s procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.


Table of Contents

1. Introduction (Informative)
1.1. Acknowledgements
2. Terms and Definitions
3. Symbols and Abbreviations
4. UBL 2.0 Context of Use
4.1. General Business Requirements
4.1.1. Items
4.1.2. Item Identification
4.1.3. Item Instances
4.1.4. Item Pricing
4.1.5. Hazardous Items
4.1.6. Parties
4.1.7. Multilingual Text
4.2. Business Processes
4.2.1. Party Roles
4.3. Sourcing
4.3.1. Catalogue Provision
4.3.2. Customer Initiated Sourcing
4.3.3. Sourcing Punchout
4.4. Ordering
4.4.1. Ordering Business Rules Assumed
4.4.2. Order Response Simple
4.4.3. Order Response
4.4.4. Order Change
4.4.5. Order Cancellation
4.5. Fulfilment
4.5.1. Despatch Advice Business Rules Assumed
4.5.2. Receipt Advice Business Rules Assumed
4.6. Billing
4.6.1. Billing Business Rules Assumed
4.6.2. Traditional Billing
4.6.3. Self Billing
4.6.4. Freight Billing
4.6.5. Reminder For Payment
4.7. Payment
4.7.1. Report State of Accounts
4.8. Initiate Transport Services
4.8.1. Forwarding Instructions
4.8.2. Bill of Lading
4.8.3. Waybill
4.8.4. Packing List
4.9. Certification of Origin of Goods
4.10. Report Status of Goods
4.11. Document Types
5. UBL 2.0 Schemas
5.1. UBL 2.0 Document Schemas
5.2. UBL Common Schemas
5.2.1. Reusable BIE Schemas
5.2.2. Reusable Datatype Schemas
5.2.3. Documentation Metadata Schema
5.2.4. Imported Code List Schemas
5.2.5. Extension Content Schemas
5.3. Schema Dependencies
6. Additional Document Constraints
6.1. Validation
6.2. Character Encoding
6.3. Empty Elements

Appendices

A. Release Notes (Informative)
A.1. Availability
A.2. Package Structure
A.3. Support
A.4. Support Package
A.5. Taxation Rules
A.6. UBL Customization
B. Upgrading from UBL 1.0 to UBL 2.0 (Informative)
B.1. The Original UBL 1.0 Order-to-Invoice Process
B.2. New in UBL 2.0
B.3. Other Differences between UBL 1.0 and UBL 2.0
B.3.1. Global Scoping
B.3.2. New Approach to Code List Validation
B.3.3. New Extension Element
B.3.4. Changes to Basic Information Entities
B.3.5. Changes to Attributes
C. UBL Development Methodology (Informative)
D. UBL 2.0 Document Models (Informative)
D.1. The Common Library
D.2. Document Assembly Models
D.3. Qualified Datatypes
E. UBL 2.0 Code Lists and Two-phase Validation (Informative)
E.1. Introduction
E.2. Default Validation Setup
E.3. Discussion of the Default Validation Test
E.4. Customizing the Default XSLT file
E.5. Sources for the Default Validation Framework
E.6. Code List Documentation
E.6.1. cl/gc/default
E.6.2. cl/gc/cefact
E.6.3. cl/gc/special-purpose
E.6.4. cl/xsdcl
F. UBL 2.0 Naming and Design Rules (Informative)
G. ASN.1 Specification (Informative)
References

1. Introduction (Informative)

Since its approval as a W3C recommendation in 1998, XML has been adopted in a number of industries as a framework for the definition of the messages exchanged in electronic commerce. The widespread use of XML has led to the development of multiple industry-specific XML versions of such basic documents as purchase orders, shipping notices, and invoices.

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

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

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

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

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

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

  • A library of XML schemas for reusable data components such as “Address,” “Item,” and “Payment” — the common data elements of everyday business documents.

  • A set of XML schemas for common business documents such as “Order,” “Despatch Advice,” and “Invoice” that are constructed from the UBL library components and can be used in generic procurement and transportation contexts.

A standard basis for XML business schemas provides the following advantages:

  • Lower cost of integration, both among and within enterprises, through the reuse of common data structures.

  • Lower cost of commercial software, because software written to process a given XML tag set is much easier to develop than software that can handle an unlimited number of tag sets.

  • An easier learning curve, because users need master just a single library.

  • Lower cost of entry and therefore quicker adoption by small and medium-size enterprises (SMEs).

  • Standardized training, resulting in many skilled workers.

  • A universally available pool of system integrators.

  • Standardized, inexpensive data input and output tools.

  • A standard target for inexpensive off-the-shelf business software.

UBL is designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees.

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

1.1. Acknowledgements

The OASIS UBL TC thanks Altova for its contribution of XML Spy licenses for use in UBL schema design and Sparx Systems for its contribution of Enterprise Architect licenses for use in developing UML content models. Special thanks are due to GEFEG for its contribution of FX (EDIFIX) and technical expertise in the generation and quality review of UBL schemas.

2. Terms and Definitions

Assembly model

A tree-structured model of ABIEs that can be implemented as a document schema.

Class diagram

A graphical notation used by [UML] to describe the static structure of a system, including object classes and their attributes and associations.

Context

The circumstance or events that form the environment within which something exists or takes place.

Document

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

Spreadsheet model

A representation of an assembly model in tabular form.

XSD schema

An 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 Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with the meanings given in [CCTS].

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

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

3. Symbols and Abbreviations

ABIE

Aggregate Business Information Entity

ASBIE

Association Business Information Entity

BBIE

Basic Business Information Entity

BIE

Business Information Entity

CC

Core Component

CV2

Credit Card Verification Numbering System

EDI

Electronic Data Interchange

ISO

International Organization for Standardization

NDR

UBL Naming and Design Rules (see Appendix F)

UML

Unified Modeling Language [UML]

UN/CEFACT

United Nations Centre for Trade Facilitation and Electronic Business

UNDG

United Nations Dangerous Goods

URI

Uniform Resource Identifier

UUID

Universally Unique Identifier

XML

Extensible Markup Language [XML]

XPath

The XML Path Language

XSD

W3C XML Schema Language [XSD1] [XSD2]

4. UBL 2.0 Context of Use

The processes described in this section, and the business rules associated with them, define a context for the use of UBL 2.0 business documents. They are normative insofar as they provide semantics for the UBL document schemas, but they should not be construed as limiting the application of those schemas.

UBL 2.0 extends the order-to-invoice processes of UBL 1.0 to cover a supply chain from sourcing to payment, including the commercial collaborations of international trade. The following diagram illustrates the process context assumed by UBL 2.0 documents.

Figure 1. Processes Covered by UBL 2.0

[Use Case Diagram]

It is important to note that the UBL 2.0 library is designed to support the construction of a wide variety of document types beyond those provided in the 2.0 package. It is expected that implementers will develop their own customized document types and components and that other UBL document types will be added as the library evolves.

4.1. General Business Requirements

This section describes some of the requirements and general business rules that are assumed for collaborations and document exchanges in UBL 2.0.

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

4.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 requires additional descriptive information to precisely identify it.

  • Customer Defined Item

    This is an item that the customer describes according to his need, and in the specification of which the customer may make some reference to comparable “standard” items.

  • Item Requiring Measurements

    This is an item for which it is necessary to specify one or more measurements as part of the descriptive specification of the item.

4.1.3. Item Instances

Certain Items may be identified and ordered as individual, unique objects, for example, a specific car rather than a make and model of a car. This form of identification may also be needed for product tracing (e.g., perishable goods) or because of the nature of the commodity (e.g., used, collectible, specialized, or rare).

In data modeling terms, an Item Instance is an extension of an Item.

4.1.4. Item Pricing

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

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

4.1.5. Hazardous Items

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

4.1.6. Parties

In UBL, a party is defined as an individual, a group, or a body having a role in a business function.

Dependent on the business process, a Party may play various roles in the document exchange.

4.1.7. Multilingual Text

Some textual components, such as Notes and Description, may be specified in several languages. Each should be a separate occurrence of the component, using the language attribute to define its presentation. However, multiple occurrences of the same textual components should not be in the same language.

4.2. Business Processes

The UBL 2.0 documents and library are designed to support the typical business processes outlined in Figure 1.

The following sections describe each business process in more detail. But first we should explain the roles that the parties involved in these processes may perform.

4.2.1. Party Roles

In the UBL supply chain processes, two main actors, Customer and Supplier, represent the key organizations or individuals involved in the processes. Each of these actors may play various roles. Processes may also involve supplementary roles that may be provided by different parties.

The actual role undertaken is dependent on the context of use. For example, the Despatch Party and Delivery Party as applied to the Procurement process may differ in the Transportation process. In other words, whether the Consignor in a Transportation process is actually equal to the Despatch Party or Seller in the Procurement process depends on the specific circumstances.

The following table contains a description of the typical roles for the actors known as Party, Customer Party, and Supplier Party.

Table 1. Party Roles

Actor

Role

Description

Example

Synonyms

Sends

Receives

Customer Party

Originator

The party that had the original demand for the goods and/or services and therefore initiated the procurement transaction.

The Originator participates in pre-ordering activity either through RFQ and Quotation or by receiving a Quotation as a response to a punchout transaction on a marketplace or Seller’s website.

If the Originator subsequently places an Order, the Originator adopts the role of Buyer.

The Originator is the typically the contact point for queries regarding the original requirement and may be referred to in an Order Change, Order Cancellation, or Order Response.

If an employee requests a computer, the employing company may become the Buyer, but the employee is the Originator. They need to receive information about the order.

 

Request for Quotation

 

Quotation

Customer Party

Buyer

The party that purchases the goods or services on behalf of the Originator.

The Buyer may be referred to in Order Response, Despatch Advice, Invoice, Self Billed Invoice, Credit Note, and Account Statement.

A company may delegate the task of purchasing to a specialized group to consolidate orders and gain greater discounts.

Order Point

Order, Order Change, and Order Cancellation

Order Response

Supplier Party

Delivery

The party to whom goods should be delivered.

The Delivery Party may be the same as the Originator.

The Delivery Party must be referred to at line item level in RFQ, Quotation, Order, Order change, Order Cancellation, and Order Response.

The Delivery Party may be referred to at line level in Invoice, Self Billed Invoice, Credit Note, and Debit Note.

The Delivery Party may be stipulated in a transport contract.

If a municipality buys a wheelchair for a citizen, the wheelchair must be delivered to the citizen (the Delivery Party). In such cases the citizen may be notified before delivering the wheelchair.

Delivery Point, Destination Party, Receiver, Recipient

Receipt Advice

Despatch Advice

Customer Party

Accounting Customer

The party responsible for making settlement relating to a purchase and resolving billing issues using a Debit Note.

The Accounting Customer must be referred to in an Order and may be referred to in an Order Response.

In a Self Billing scenario, the Accounting Customer is responsible for calculating and issuing tax invoices.

If a kindergarten buys some toys they may be the Originator, Buyer, and Delivery Party, but the municipality may play the role of Accounting Customer — they are going to pay for it.

Invoicee, Accounts Payable, Debtor

In a traditional Billing scenario: Debit Note, Account Response, and Remittance Advice

In a Self Billing scenario: Self Billed Invoice, Self Billed Credit Note, and Remittance Advice

In a traditional Billing scenario: Invoice, Credit Note, and Statement of Account

In a Self Billing scenario: Credit Note, Account Response, and Statement of Account

Supplier Party

Seller

The party responsible for handling Originator and Buyer services.

The Seller party is legally responsible for providing the goods to the Buyer.

The Seller party receives and quotes against RFQs and may provide information to the Buyer’s requisitioning process through Catalogues and Quotations.

The organization that sells wheelchairs to municipalities.

Sales Point, Provider, Customer Manager

Quotation, Order Response, Order Response Simple, Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update

RFQ, Order, Order Change, Order Cancellation, Request for Catalogue

Supplier Party

Despatch

The party where goods are to be collected from.

The Despatch Party may be stipulated in a transport contract.

The wheelchair Supplier may store chairs at a local warehouse. The warehouse will actually despatch the chair to the Delivery Party.

The local warehouse is then the Despatch Party.

Despatch Point, Shipper, Sender

Despatch Advice

Receipt Advice

Supplier Party

Accounting Supplier

The party who claims the payment and is responsible for resolving billing issues and arranging settlement.

There are cases where the Accounting Supplier is not the Seller party. For example, factoring, where the invoicing is outsourced to another company.

Accounts Receivable, Invoice Issuer, Creditor

In a traditional Billing scenario: Invoice, Credit Note, and Statement of Account

In a Self Billing scenario: Credit Note, Account Response and Statement of Account

In a traditional Billing scenario: Debit Note, Account Response, and Remittance Advice

In a Self Billing scenario: Self Billed Invoice, Self Billing Credit Note, and Remittance Advice

Supplier Party

Payee

The party to whom the Invoice is paid.

The Accounting Supplier may not be the party to be paid due to changes in the organization, e.g., a company merger.

Accounts Receivable, Creditor

 

Remittance Advice

Customer Party

Contractor

The party responsible for the contract to which the Catalogue relates.

An organization has a central office for maintaining catalogues of approved items for purchase.

Central Catalogue Party, Purchasing Manager

Request for Catalogue

Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update

Party

Provider

The party responsible for the integrity of the information provided about an item.

The manufacturer may publish and maintain the data sheets about a product.

 

Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update

 

Party

Receiver

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.

A marketplace may receive an Application Response.

 

 

Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update, Application Response

Party

Sender

The party sending a document.

A marketplace may send an Application Response.

 

Application Response

 

Party

Consignor

The party consigning the goods as stipulated in the transport contract. A Buyer, Delivery, Seller, or Despatcher Party may also play the role of Consignor.

Also known as the Transport Service Buyer.

The Consignor may be stipulated in a transport contract.

The wheelchair Supplier may source from a local warehouse. The Freight Forwarder will collect the chair from the local warehouse, which is thus the Consignor. In this case, the warehouse also plays the role of Despatch Party to the Freight Forwarder.

Despatch Point, Shipper, Sender, Transport Service Buyer

Forwarding Instructions, Packing List

Bill of Lading, Waybill, Freight Invoice, Transportation Status

Party

Consignee

The party receiving a consignment of goods as stipulated in the transport contract.

The party taking responsibility for the receipt of the consignment covering the wheelchair.

Delivery Point, Transport Service Buyer

Forwarding Instructions, Freight Invoice

Bill of Lading, Waybill, Freight Invoice, Transportation Status

Party

Freight Forwarder

The party arranging the carriage of goods, including connected services and/or associated formalities, on behalf of a Consignor or Consignee.

Also known as the Transport Service Provider.

The Freight Forwarder may also be the Carrier.

The Freight Forwarder may create an invoice and bill to the Transport Service Buyer for the transportation service provided.

The Consignor may have a contract with this Freight Forwarder, which is a Transport Services Provider, to arrange all their transport needs.

Shipping Agent, Broker, Courier, Transport Service Provider

Forwarding Instructions, Freight Invoice, Transportation Status

Bill of Lading, Waybill, Packing List

Party

Carrier

The party providing physical transport services.

The Freight Forwarder may engage an airline company to deliver the wheelchair. The airline is then the Carrier and delivers the chair to the Delivery Party.

Freight Haulier, Shipper, Ships Agent, Shipping Company, Airline, Rail Operator, Road Haulier

Bill of Lading, Waybill

Forwarding Instructions

Party

Exporter

The party who makes regulatory export declarations, or on whose behalf regulatory export declarations are made, and who is the owner of the goods or has similar right of disposal over them at the time when the declaration is accepted.

The wheelchair Supplier has to apply for a Certificate of Origin in order to sell the chairs overseas.

Seller, Consignor

Certificate of Origin

Application Response

Party

Endorser

The party appointed by the Government of a country who has the right to certify a Certificate of Origin.

This endorsement restricts goods imported from certain countries for political or other reasons.

The Government agency validates all the information provided by Exporter for Certificate of Origin approval.

Authorized Organization, Embassy

Certificate of Origin, Application Response

Certificate of Origin

Party

Importer

The party who makes, or on whose behalf an agent or other authorized person makes, an import declaration. This may include a person who has possession of the goods or to whom the goods are consigned.

A specialized group in a company consolidates the purchase request and handles the receiving of goods.

Order Point, Delivery Party, Buyer, Customer, Consignee

 

Certificate of Origin

4.3. Sourcing

There are three kinds of sourcing:

  • Catalogue provision

  • Customer initiated sourcing

  • Punchout

A Seller Supplier Party, Contractor Customer Party, Originator Customer Party, or Buyer Customer Party may initiate sourcing.

Document types in these processes are Catalogue Request, Application Response, Catalogue Item Specification Update, Catalogue Pricing Update and Catalogue Deletion.

4.3.1. Catalogue Provision

A Catalogue is defined as a document produced by a party in the procurement chain that describes items and prices.

Catalogue provision is the case where a Provider sends information regarding items available for purchase to a Receiver. This may be on request or unsolicited.

Because they are only potential purchasers, a Receiver may never become a Customer Party.

4.3.1.1. Sourcing Business Rules Assumed
  • Any conditions specified in the contract shall overrule those stated in the common Catalogue.

  • A Catalogue exchange shall be between one Provider and one Receiver Party.

  • A classification system may have its own set of properties.

  • A classification scheme shall have metadata.

  • A Catalogue may have a validity period.

  • A Catalogue should include item classifications.

  • Classification schemes should include standard and specific properties.

  • A Catalogue may refer to the lot (sub-section) of a contract.

  • A Catalogue may explicitly specify the framework contract reference.

  • A Catalogue may refer to a DPS contract number.

  • When a Catalogue item is updated, the item shall be replaced in the Catalogue.

  • When a Catalogue item is updated, historical information about replaced or updated items must be available to reconcile with outstanding transactions.

  • Prices may be updated independently of other Catalogue information.

  • Catalogue distribution may be Provider or Receiver Party initiated.

  • If a Receiver initiates a request for a Catalogue, they may request an entire Catalogue or only updates to either pricing or item specification details.

  • Whether Receiver Party initiated or not, the decision to issue a new Catalogue or update an existing one shall be at the discretion of the Provider Party.

  • If an updated Catalogue is issued, then an action code shall define the status of the items in the Catalogue.

4.3.1.2. Create Catalogue

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

Figure 2. Create Catalogue Process

[Create Catalogue Activity Diagram]
4.3.1.3. Update Catalogue Item Specification

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

Figure 3. Update Item Specification Process

[Update Item Specification Activity Diagram]
4.3.1.4. Update Catalogue Pricing

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

Figure 4. Update Catalogue Pricing Process

[Update Catalogue Pricing Activity Diagram]
4.3.1.5. Delete Catalogue

Deletion of a Catalogue is shown in the following diagram.

Figure 5. Delete Catalogue Process

[Delete Catalogue Activity Diagram]

4.3.2. Customer Initiated Sourcing

Customer initiated sourcing is the case where the Originator asks for a quotation, as shown in the following diagram.

Figure 6. Customer Initiated Sourcing Process

[Customer Initiated Sourcing Activity Diagram]

4.3.3. Sourcing Punchout

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

Figure 7. Punchout Sourcing Process

[Sourcing Punchout Activity Diagram]

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

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

4.4. Ordering

Ordering is the collaboration that creates a contractual obligation between the Seller Supplier Party and the Buyer Customer Party.

Document types in these processes are Order, Order Response, Order Response Simple, Order Change, and Order Cancellation.

Figure 8. Ordering Process

[Ordering Activity Diagram]

4.4.1. Ordering Business Rules Assumed

The Order may specify allowance and charge instructions (e.g., freight, documentation, etc.) that identify the type of charge and who pays which charges. The Order may be placed “on account” against a trading credit account held by the Seller, or against a credit/debit card account, or a direct debit agreement. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an Order, additional currencies may be specified both for individual item pricing and for any allowances or charges.

Trade discount may be specified at the Order level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed response from the Seller necessary; see Order Response (5.4.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 alternatives that are acceptable.

4.4.2. Order Response Simple

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

4.4.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 order transaction. It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering. These may include:

  • Delivery date, offered by the Seller if not specifically requested by the Buyer

  • Prices

  • Discounts

  • Charges

  • Item Classification codes

The Seller may advise on replacements or substitutes which will be made, or changes necessary, using the Order Response.

4.4.4. Order Change

The Buyer may change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see 5.4.5) followed by a new, complete replacement Order.

An Order Change reflects the entire current state of an order transaction.

Buyers may initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers may accept or reject the Order Change using either Order Response or Order Response Simple.

4.4.5. Order Cancellation

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

4.5. Fulfilment

Fulfilment is the collaboration in which the goods or services are transferred from the Despatch Party to the Delivery Party.

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

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

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

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

Figure 9. Fulfilment with Despatch Advice Process

[Fulfilment with Despatch Advice Activity Diagram]

4.5.1. Despatch Advice Business Rules Assumed

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:

  • Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver can check the Transport Handling Unit and then contained items. Quantities of the same item on the same Order Line may be separated into different Transport Handling Units, and hence appear on separate Despatch Lines within a Transport Handling Unit.

  • Organization of the delivery set of items by Despatch Line, annotated by the Transport Handling Unit in which they are placed, to facilitate checking against the Order. For convenience, any Order Line split over multiple Transport Handling Units will result in a Despatch Line for each Transport Handling Unit they are contained in.

Additionally, in either case, the Despatch Advice may advise:

  • Full Despatch — advising the Recipient and/or Buyer that all the items on the order will be, or are being, delivered in one complete consignment on a given date.

  • Partial Despatch — advising the Recipient and/or Buyer that the items on the order will be, or are being, partially delivered in a consignment on a given date.

Despatch Lines of the Despatch Advice need not correspond one-to-one with Order Lines, and are linked by a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines from one Order Line. Equally, partial despatch may result in some Order Lines not being matched by any Line in a Despatch Advice.

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

4.5.2. Receipt Advice Business Rules Assumed

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

Figure 10. Fulfilment with Receipt Advice Process

[Fulfilment with Receipt Advice Activity Diagram]

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

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

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

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

4.6. Billing

In the Billing collaboration, a request is made for payment for goods or services that have been ordered, received, or consumed. In practice, there are several ways in which goods or services may be billed.

Document types in these processes are Invoice, Credit Note, Debit Note, and Application Response.

For UBL 2.0, we assume the following methods:

  1. Traditional Billing

    • Using Credit Note

    • Using Debit Note

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

    • Using Credit Note

    • Using Self Billed Credit Note

4.6.1. Billing Business Rules Assumed

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

  • Prepayment invoice (payment expected)

  • Pro-forma invoice (pre advice, payment not expected)

  • Normal Invoice, on despatch for despatched items

  • Invoice after return of Receipt Advice

The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice, or Receipt Advice by a Reference for those documents.

Taxation on the Invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT — Value Added Tax — superimposed). The OASIS TaxML Technical Committee (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tax) is developing UBL implementation profiles for various tax regimes, such as those required by the European Community.

Charges may be specified either as a lump sum or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover:

  • Packaging

  • Delivery/postage

  • Freight

  • Documentation

Each Invoice Line refers to any related Order Line(s) and may also refer to the Despatch Line and/or Receipt Line.

4.6.2. Traditional Billing

Traditional billing is where the supplier invoices the customer when the goods are delivered or the services provided.

In this case, the invoice may be created at the time of despatch or when the Delivery Party acknowledges that the goods have been received (using a Receipt Advice).

When there are discrepancies between the Despatch Advice, Receipt Advice, and/or the Invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an Application Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or another Invoice as required.

A Credit Note or Debit Note may also be issued in the case of retrospective price change.

Credit Notes or Debit Notes may be also issued after the Billing collaboration (as part of the Payment collaboration).

4.6.2.1. Billing using Credit Notes

Billing using Credit Notes is shown in the following diagram.

Figure 11. Billing with Credit Note Process

[Billing with Credit Note Activity Diagram]

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

4.6.2.2. Billing Using Debit Notes

Billing using Debit Notes is shown in the following diagram.

Figure 12. Billing with Debit Note Process

[Billing with Debit Note Activity Diagram]

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

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

4.6.3.1. Self Billing Using Credit Notes

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

Figure 13. Self Billing with Credit Note Process

[Self Billing with Credit Note Activity Diagram]

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

4.6.3.2. Self Billing Using Self Billed Credit Notes

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

Figure 14. Self Billing with Self Billed Credit Note Process

[Self Billing with Self Billed Credit Note Activity Diagram]

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

4.6.4. Freight Billing

An extension of the Billing process is that of Freight Billing. This represents the billing process between the Transport Service Buyer and Transport Service Provider through the use of an Invoice for freight charges.

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

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

Figure 15. Freight Billing Process

[Freight Billing Activity Diagram]

4.6.5. Reminder For Payment

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

Figure 16. Reminder for Payment Process

[Reminder For Payment Process Diagram]

4.7. Payment

In the payment collaboration, the Payee (who is most often the Accounting Customer) is notified of any funds transferred against the account of the Accounting Supplier using a Remittance Advice.

The document type in this process is the Remittance Advice.

Figure 17. Payment Process

[Payment Activity Diagram]

4.7.1. Report State of Accounts

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

Figure 18. Statement Process

[Statement Activity Diagram]

4.8. Initiate Transport Services

These process define the ordering of logistical services for international trade. With receipt of an order and acknowledgement by the Supplier Party that the goods are available and ready to be shipped, the Consignor or Consignee initiates the transportation arrangements. This includes booking the consignment with a Transport Service Provider such as the Freight Forwarder or Carrier and advising the Delivery Party of the arrangements as needed.

Document types in these processes are Forwarding Instructions, Packing List, Waybill, and Bill of Lading.

It should be noted that these processes do not cover regulatory notifications such as Customs declarations or arrangements between carriers, hauliers, and terminal operators for the physical movement of goods.

Figure 19. Initiate Transport Services Process

[Initiate Transport Services Activity Diagram]

4.8.1. Forwarding Instructions

Forwarding Instructions are normally used by any party who gives instructions for the transportation services required for a consignment of goods (the Transport Service Buyer) to any party who is contracted to provide the transportation services (called the Transport Service Provider). Forwarding Instructions may also be used by any party who requests a booking of shipment space to be made for the transportation services required for a consignment of goods to any party who will provide the underlying transportation services. The parties who issue this document are commonly referred to as the shipper, consignee, or consignor, while the parties who receive this document are forwarders, carriers, shipping agents, etc.

Forwarding Instructions may also be issued by a freight forwarder or shipping agent in their capacity as a Transport Service Buyer. This document may be used to arrange for the transportation:

  • of different types of goods or cargoes

  • whether containerized or non-containerized

  • through different modes of transport, and

  • from any origin to any destination.

4.8.2. Bill of Lading

A Bill of Lading is issued by the party who provides the physical transportation services (e.g., carrier) 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.

It may also be issued by the party who acts as an agent for the carrier or other agents to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided but does not provide the physical transportation service.

A Bill of Lading corresponds to the information on the Forwarding Instructions. It is used for ocean or river 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 goods by 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 to order, or to bearer, constitutes such an undertaking.

4.8.3. Waybill

A Waybill is issued by the party who provides the physical transportation services to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the details of the transportation, charges, and terms and conditions under which the transportation service is provided.

Unlike a Bill of Lading, a Waybill is not negotiable and cannot be assigned to a third party. It is issued as 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 transport service seller.

4.8.4. Packing List

A Packing List is normally issued by the Consignor. It states the distribution of goods in individual packages. Based on this detail, the party who provides the logistic services will make arrangement for the transportation of the goods.

4.9. Certification of Origin of Goods

A Certificate of Origin is a document required by governments declaring that goods in a particular international shipment are of a certain origin.

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

Figure 20. Certification of Origin of Goods Process

[Certification Of Origin Of Goods Activity Diagram]

4.10. Report Status of Goods

The Transportation Status document is a means for a Freight Forwarder (also known as the Transport Service Provider) to communicate to the Consignee or Consignor (also known as the Transport Service Buyer) or Notify Party, the status of shipments that are currently under the Freight Forwarder’s management.

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

Figure 21. Report Status of Goods Process

[Report Status of Goods Activity Diagram]

4.11. Document Types

The following table lists all the UBL 2.0 document types together with their target business processes and roles for parties who would typically submit and receive them.

Table 2. Summary of UBL 2.0 Document Types

Document Name

Description

Processes Involved

Submitter Role

Receiver Role

Catalogue Request

A document to request a Catalogue from a seller. May be either an entire new Catalogue or an update (at the discretion of the Seller).

Create Catalogue, Update Item Specification, Update Pricing

Contracting Party

Seller

Catalogue

A document produced by a party in the procurement chain that describes items and prices. The document typically enables the transmission of information regarding pricing and catalogue details for goods and services offered by a seller to a buyer.

Create Catalogue

Seller

Contracting Party

Catalogue Deletion

A document to cancel an entire Catalogue. All previous Catalogue information becomes obsolete.

Delete Catalogue

Seller

Contracting Party

Catalogue Item Specification Update

A document to update information about Items in an existing Catalogue.

Update Catalogue Item Specification

Seller

Contracting Party

Catalogue Pricing Update

A document to update information about Prices in an existing Catalogue.

Update Catalogue Pricing

Seller

Contracting Party

Request For Quotation

A document to request pricing and availability information about goods or services. The document may requesting a quote on specified goods or services.

Sourcing

Originator

Seller

Quotation

A document to specify pricing and availability information about goods or services. The document which, with a view to concluding a contract, sets out the conditions under which the goods are offered.

Sourcing

Seller

Originator

Order

A document that contains information directly relating to the economic event of ordering products. The document by means of which a customer initiates a transaction with a supplier for the supply of goods or services as specified, according to conditions set out in an offer, or otherwise known to the customer.

Ordering

Buyer

Seller

Order Response

A document responding to the customer to indicate detailed responses against a single order already received.

Ordering

Seller

Buyer

Order Response Simple

A document responding to the customer to indicate simple acceptance or rejection of an entire order. The document acknowledging an undertaking to fulfil an order and confirming conditions or acceptance of conditions.

Ordering

Seller

Buyer

Order Change

A document that contains information directly relating to the economic event of changing an order already sent.

Ordering, Fulfilment

Buyer

Seller

Order Cancellation

A document that advises either party of the cancellation of an Order.

Ordering, Fulfilment

Buyer

Seller

Despatch Advice

A document that describes the content of goods shipped. Document/message by means of which the seller or consignor informs the consignee about the despatch of goods.

Fulfilment

Despatch

Delivery

Receipt Advice

A document that advises the goods received and accepted by the buyer. The document acknowledges the receipt of goods and in addition may indicate receiving conditions.

Fulfilment

Delivery

Despatch

Invoice

A document claiming payment for goods or services supplied under conditions agreed between the supplier and the customer. In most cases this document describes the actual financial commitment of goods or services ordered from the supplier.

Billing

Supplier Accounting Party

Customer Accounting Party

Self Billed Invoice

A document provided by a customer, in the name and on behalf of the supplier, describing the claim for payment for goods or services supplied under conditions agreed between the supplier and the customer.

Billing

Customer Accounting Party

Supplier Accounting Party

Credit Note

A document for a supplier to specify a reduced payment. The document for providing credit information to the relevant party.

Billing

Supplier Accounting Party

Customer Accounting Party

Debit Note

A document for a customer to specify a reduced payment. The document for providing debit information to the relevant party.

Billing

Customer Accounting Party

Supplier Accounting Party

Self Billed Credit Note

A document for a customer to specify a reduced payment in a Self Billing environment. The document indicates that the customer is claiming credit in a self billing environment.

Billing

Customer Accounting Party

Supplier Accounting Party

Statement

A document to list the financial transactions between customer and supplier and notify of their status. This is a Statement of Account and not intended as a summary Invoice.

Billing

Supplier Accounting Party

Customer Accounting Party

Reminder

A document used to request payment.

Billing

Supplier Accounting Party and/or Payee

Customer Accounting Party and/or Payee

Remittance Advice

A document to specify that funds have been transferred from the customer to the supplier. The document advising of the remittance of payment.

Payment

Customer Accounting Party and/or Payee

Supplier Accounting Party and/or Payee

Forwarding Instructions

The document used by any party who gives instructions for the transportation 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 Transport Service Buyer. This document may 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. The document issued to a freight forwarder, giving instructions regarding the action to be taken by the forwarder for the forwarding of goods described therein.

Initiate Transport Services

Consignor (or Consignee), Freight Forwarder

Freight Forwarder, Carrier

Bill of Lading

A document 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 does not necessarily provide the physical transportation service. It corresponds to the information on the Forwarding Instructions. It is used for any mode 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 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. A negotiable document that evidences a contract of carriage by sea and the taking over or loading of goods by carrier, and by which carrier undertakes to deliver goods against surrender of the document.

Initiate Transport Services

Freight Forwarder, Carrier

Consignor (or Consignee), Freight Forwarder

Waybill

A document 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 may not provide the physical transportation service. It corresponds to the information on the Forwarding Instructions. It is used for all modes of transport. It may serve as a contractual document between the parties for the transportation service. A Waybill is a non-negotiable document evidencing the contract for the transport of cargo. It provides information similar to Bill of Lading but is not negotiable and cannot be assigned to a third party.

Initiate Transport Services

Freight Forwarder, Carrier

Consignor (or Consignee), Freight Forwarder

Packing List

A document stating the detail of how goods are packed. The document specifies the distribution of goods in individual packages (in trade environment the despatch advice message is used for the packing list).

Initiate Transport Services

Consignor

Freight Forwarder

Freight Invoice

A document issued by a transport operation specifying freight costs and charges incurred for a transport operation and stating conditions of payment.

Freight Billing

Freight Forwarder

Consignor or Consignee

Certificate of Origin

A document required by governments, declaring that goods in a particular international shipment are of a certain origin. Customs offices will use this document to determine whether or not a preferential duty rate applies on the products being imported and whether a shipment may be legally imported during a specific quota period. The document identifies which authority or body authorized to issue it certifies expressly that the goods to which the certificate relates originate in a specific country. The word "country" may include a group of countries, a region, or a part of a country. This certificate may also include a declaration by the manufacturer, producer, supplier, exporter, or other competent person.

Certification of Origin of Goods

Exporter, Issuer

Issuer, Importer

Transportation Status

A message to report the transport status and/or change in the transportation status (i.e. event) between agreed parties.

Initiate Transport Services

Freight Forwarder

Consignee, Consignor

Application Response

A document to indicate the application’s response to a transaction at the business application level concerning the processing of a document.

All

Sender

Receiver

Attached Document

In effect a ’wrapper’ UBL envelope that may contain anything. This allows a referenced document to be included in the package of documents being exchanged.

All

Sender

Receiver

5. UBL 2.0 Schemas

The UBL 2.0 XSD schemas are the only normative representations of the UBL 2.0 document types and library components.

All of the UBL 2.0 XSD schemas are contained in the xsd subdirectory of the UBL 2.0 release package (see Appendix A for more information regarding the structure of the 2.0 release package and Section 5.3 for information regarding dependencies among the schema modules). The xsd directory is further subdivided into xsd/maindoc and xsd/common subdirectories.

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

5.1. UBL 2.0 Document Schemas

XSD schemas defining the 31 UBL 2.0 document types are located in the xsd/maindoc directory, as listed below.

ApplicationResponse

xsd/maindoc/UBL-ApplicationResponse-2.0.xsd

AttachedDocument

xsd/maindoc/UBL-AttachedDocument-2.0.xsd

BillOfLading

xsd/maindoc/UBL-BillOfLading-2.0.xsd

Catalogue

xsd/maindoc/UBL-Catalogue-2.0.xsd

CatalogueDeletion

xsd/maindoc/UBL-CatalogueDeletion-2.0.xsd

CatalogueItemSpecificationUpdate

xsd/maindoc/UBL-CatalogueItemSpecificationUpdate-2.0.xsd

CataloguePricingUpdate

xsd/maindoc/UBL-CataloguePricingUpdate-2.0.xsd

CatalogueRequest

xsd/maindoc/UBL-CatalogueRequest-2.0.xsd

CertificateOfOrigin

xsd/maindoc/UBL-CertificateOfOrigin-2.0.xsd

CreditNote

xsd/maindoc/UBL-CreditNote-2.0.xsd

DebitNote

xsd/maindoc/UBL-DebitNote-2.0.xsd

DespatchAdvice

xsd/maindoc/UBL-DespatchAdvice-2.0.xsd

ForwardingInstructions

xsd/maindoc/UBL-ForwardingInstructions-2.0.xsd

FreightInvoice

xsd/maindoc/UBL-FreightInvoice-2.0.xsd

Invoice

xsd/maindoc/UBL-Invoice-2.0.xsd

Order

xsd/maindoc/UBL-Order-2.0.xsd

OrderCancellation

xsd/maindoc/UBL-OrderCancellation-2.0.xsd

OrderChange

xsd/maindoc/UBL-OrderChange-2.0.xsd

OrderResponse

xsd/maindoc/UBL-OrderResponse-2.0.xsd

OrderResponseSimple

xsd/maindoc/UBL-OrderResponseSimple-2.0.xsd

PackingList

xsd/maindoc/UBL-PackingList-2.0.xsd

Quotation

xsd/maindoc/UBL-Quotation-2.0.xsd

ReceiptAdvice

xsd/maindoc/UBL-ReceiptAdvice-2.0.xsd

Reminder

xsd/maindoc/UBL-Reminder-2.0.xsd

RemittanceAdvice

xsd/maindoc/UBL-RemittanceAdvice-2.0.xsd

RequestForQuotation

xsd/maindoc/UBL-RequestForQuotation-2.0.xsd

SelfBilledCreditNote

xsd/maindoc/UBL-SelfBilledCreditNote-2.0.xsd

SelfBilledInvoice

xsd/maindoc/UBL-SelfBilledInvoice-2.0.xsd

Statement

xsd/maindoc/UBL-Statement-2.0.xsd

TransportationStatus

xsd/maindoc/UBL-TransportationStatus-2.0.xsd

Waybill

xsd/maindoc/UBL-Waybill-2.0.xsd

5.2. UBL Common Schemas

The xsd/common directory contains schemas referenced by the document schemas in xsd/maindoc. The name of each schema file together with a brief description of its contents is given below.

5.2.1. Reusable BIE Schemas

CommonBasicComponents

xsd/common/UBL-CommonBasicComponents-2.0.xsd

This schema defines the global Basic Business Information Entities (BBIEs) that are used throughout UBL, serving, in effect, as a “global BBIE type database” for constructing documents. BBIEs are the “leaf nodes” of UBL documents.

CommonAggregateComponents

xsd/common/UBL-CommonAggregateComponents-2.0.xsd

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

5.2.2. Reusable Datatype Schemas

CCTS_CCT_SchemaModule

xsd/common/CCTS_CCT_SchemaModule-2.0.xsd

This schema provides Core Component Types as defined by [CCTS]. These types are used to construct higher-level datatypes in a standardized and consistent manner. This schema is defined by UN/CEFACT and should not be modified. It is provided here as a reference for implementers who wish to extend UBL and create new qualified datatypes in a CCTS-conformant manner.

UnqualifiedDataTypeSchemaModule

xsd/common/UnqualifiedDataTypeSchemaModule-2.0.xsd

This schema defines Unqualified Data Types for primary and secondary representation terms as specified by [CCTS]. Derived from Core Component Types, these XSD complexType structures are the basic data types from which all other data types must derive. This schema is defined by UN/CEFACT and should not be modified.

QualifiedDatatypes

xsd/common/UBL-QualifiedDatatypes-2.0.xsd

This schema describes the Qualified Data Types defined by UBL as specified by [CCTS]. These XSD complexType structures are derived from Unqualified Data Types (see above), primarily to document code lists defined for use with UBL. These Types have been customized for UBL and may be further customized to support additional Data Types required for other business contexts.

5.2.3. Documentation Metadata Schema

CoreComponentParameters

xsd/common/UBL-CoreComponentParameters-2.0.xsd

This schema defines the structure of the annotation/documentation sections that appear in all the other schemas, providing a consistent format for metadata such as object class, representation terms, semantic descriptions, and other supplementary information.

While not required by UBL schemas, this module is provided to encourage consistency of customized extensions.