For our absent friend, Michael J. Adcock - il miglior fabbro
The Universal Business Language (UBL) Library is:
The Library has been designed as a collection of object classes and associations expressed as a conceptual model. Specific document types are then assembled from these business information entities (BIES) by organizing them into a specific hierarchy. These hierarchical models are then transformed using the UBL Naming and Design rules [NDR] into XML Schema syntax [XSD1][XSD2]. The analysis and design processes developed by the UBL Library Content team are described in Annex A.
The UBL library is intended for use in business data contexts beyond the specific set of document types provided in this specification. For the purposes of this release, Section 5 below describes the scenario and choreography used in developing this set of documents. For example, the document Order Response may have a limited application, but the re-usable components Party and Item will have relevance to many applications.
The downloadable version of this release is available here: 0p80 Downloadable Release. (This is a zip file that will unpack to give you a replica of the online release directories.)
If there are any problems with the links in this document, you can find the full online version at http://www.oasis-open.org/committees/ubl/lcsc/0p80/ .
The OASIS UBL Technical Committee invite other interested parties to comment on this release directly to the Library Content Subcommittee Editor, Bill Meadows using the recommended feedback form, UBL_Comment-0p1.rtf.
This release comment period applies from NEW DATES - Monday, January 27th until Monday, April 14th 2003. We welcome your comments and will ensure to advise you of our dispositions to any suggestions.
This document and its associated components are Copyright © 2003 OASIS and are protected by applicable law as works in progress within the OASIS Universal Business Language Technical Committee. As works in progress, they do not yet have the status of an OASIS Standard or an OASIS Committee Specification. This draft and its associated components are provided on a royalty-free basis and may be freely circulated for purposes of experimentation and review. While the construction of experimental prototypes based on these materials is encouraged for the purpose of generating input back to the committee process, implementers are strongly advised against basing commercial or mission-critical applications on the draft specifications contained in this package. THESE MATERIALS ARE FURNISHED WITH NO WARRANTY, EXPRESS OR IMPLIED, AS TO THEIR SUITABILITY FOR ANY APPLICATION.
The Library Content part of UBL specifies a library of business information entities to be used in the construction of business documents together with a set of common XML business documents assembled from those entities.
This document contains normative and non-normative references used by UBL: the context scenario and business rules used to construct the business models and business documents; and the schema instances of the business documents.
The terms Core Component and Business Information Entity are used in this specification with the meanings given in [CCTS].
The terms Object Class, Property, Representation Term, and Qualifier are used in this specification with the meanings given in [ISO11179].
The specific context adopted for UBL release 0p80 is based on a typical trading cycle. This section describes the scenario and choreography as well as highlighting some of the business rules used in developing this set of documents.
The design of this particular set of UBL documents also allows it to be used as a basis for extension to create more function-rich, but separately defined, scenarios. When that occurs, it is expected that this section will become one of a list of all available scenarios from different, complementary sources. Such a list and descriptions need to be constructed in such a way that a newcomer will be able to readily identify the scenario that exactly, or most closely, fits their requirement and manner of operation.
This model addresses the requirements of a basic, usable trading cycle from Order to Invoice between Buyer and Seller. It includes specifications for:
It provides for:
It does not provide for:
Different business scenarios to meet different ways of trading cycle operation can, and should, be developed by separate, appropriate teams of business and modelling experts. Ideally they should take advantage of the basic UBL model as a starting point and as an exemplar. They will then need to go through an independent harmonisation review to encourage and to ensure inter-operability, to reduce ambiguity, and to avoid unnecessary overlap.
Suggested other scenarios, for separate development, include situations of:
Other scenarios that are already in development and that should be included in the catalogue of business scenarios include:
Editors' Notes:
It is expected that each of the above suggestions will become at least one separate scenario with a carefully defined scope that describes what the scenario does and does not cover.
It is also expected that wherever possible as much of each model and 'document' will be as common in design as is possible.
It is also expected that there will be a carefully judged balance between, on the one hand, having too many separate and different scenarios and, on the other hand, too few generic 'all-things-to-all-folks' scenarios.
Items are ordered by the Buyer from the Seller. The Buyer and Seller may be in the same country, or in different countries. The Seller confirms with either an Order Response (simple), or an Order Response (complex) if it is necessary to provide the Buyer with additional information. The Seller fulfils the order by sending a Despatch Advice and supplying the items requested. The Buyer returns a Receipt Advice to confirm items have been received. The Seller invoices the items that have been provided. The Buyer reconciles the invoice to the despatch advice and order, and makes a payment which covers one or more invoices within the payment period defined in the invoice payment terms.
Figure 1. Trade Cycle
It is anticipated that there may be a need to change the order details using a Order Change document. The Buyer may indicate potential substitutes that are acceptable; the Seller may advise substitutes which will be made, or changes necessary, using the Order Response (complex). In addition, complete cancelation of the order is allowed.
The Order may specify Allowances and Charges (e.g. freight, documentation etc) instructions that identify the type of charge and who pays which charges. The Order can 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 overall allows only for specification of Currency (e.g. £, $, € etc by ISO currency code) for Pricing, for Invoice presentation, for Tax accounting. In the case of International freight/documentation charges, it may also be necessary to specify the Currency.
Allowances such as trade discounts may be specified at Order level. However, the Buyer may not know the trade discount, in which case it is not specified. This makes a detailed Order Response (complex) necessary [See Order Response (Complex)].
The Order may specify delivery terms and constraints that apply for the delivery location in relation to the following information that would normally not appear until the Despatch Advice:
The Order provides for multiple Order Item Lines.
Each Order Item Line provides for specification of a single place of delivery, and a schedule of quantities and requested delivery dates.
The Order may specify delivery terms, while the Order Item Line may provide instructions for delivery. Partial shipment indication is also allowed, insofar as the only information needed is a yes/no 'partial shipment allowed' indicator for each Order Item Line.
For each Order Item Line, an Allowable Substitute can be included. The substitute item may be specified by any one of the range of Item identifiers. The specified Quantity may change e.g. 20x6-packs substituting for 10x12-packs.
An Item Identifier identifies each Item (e.g. a product identifier), which shall be one of the following:
The Item Identification assumes that each different packaging of an Item (e.g. a 6-pack and a 12-pack of the same item) has a different Item Identifier.
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:
This is an item that is not identified by an unambiguous, machine processable, product code and where it is necessary to provide additional descriptive information about the item to precisely identify what is required.
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.
This is an item in which it is necessary to specify one or more measurements as part of the descriptive specification of the item.
For an Item, price ranges by amount, quantity, etc. are not repeated back to the Seller; only the active price is specified. The Buyer may not know the Item Price, in which case it is not specified. This makes a detailed Order Response (complex) necessary [See Order Response (Complex)].
Ordered items may include Hazardous Material items, insofar as 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.
The Order Response (simple) is the means by which the Seller confirms receipt of the Order, indicating commitment to fulfill without change, to the Buyer. The Seller may also inform the Buyer, using this Order Response, that the Order has been rejected.
The Order Response (complex) is a complete replacement of the Order. 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:
The Buyer can change an Order, subject to the legal contract or trading partner agreement, by sending an Order Change. This replaces (or redefines) any existing Order.
Buyers can initiate a change to a previously accepted order. Buyers may change an order for various reasons such as changing the ordered items, quantity, delivery date, ship-to address, etc. Suppliers can accept or reject the changed order using the Order Response document.
Changes by the Seller would be accomplished through the OrderResponse (Complex).
At any point of the process, a Buyer can cancel an order sent to a Seller. Legal contracts, trading partner agreements and business rules would restrict at what point a Order Cancellation would be ignored (e.g. at the point of manufacture or delivery process initiation). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of a contract formation for business commitments will dictate what if any of these restrictions and/or guidelines will apply.
As described in the Order, the Item Identification within each Item Line may be made by the Buyer's, Seller's, Manufacturer's, or Catalogue identification of the item, or by an identification assigned by a Standards organisation. It may also be accompanied by an indication of the Country of Origin for the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice.
The following information may appear in the Despatch Advice:
The Despatch Advice caters for two situations:
Additionally, in either case, the Despatch Advice can advise:
Note: Item Lines of the Despatch Advice may not correspond one-to-one with Order Item Lines, but each needs to be linked by reference to the Order Item Line Id. The information structure of the Despatch Advice, geared to physical considerations, may result in multiple Despatch Advice Item Lines from one Order Item Line. Equally, partial despatch may result in some Order Item Lines not being matched by any Item Line in a Despatch Advice.
The Receipt Advice is sent by the Receiver (Buyer) to the Seller to confirm receipt of items, and is capable of reporting shortages and/or damaged items.
The Receipt Advice caters for two situations. For ease of processing claimed receipt against claimed delivery, it needs to be organised in the same way as the matching Despatch Advice:
The Receipt Advice allows the Receiver to state any shortages from the claimed despatch quantity, to state any quantities rejected for a reason which is given, and also to indicate cancellation of any 'to follow' quantity advised by the Ship From or Seller party.
Note: As presently arranged the Receipt Line only allows for one rejection quantity and reason. However, any rejection of quantities of same item for different reasons could be achieved by subdividing the Receipt Line so that there are multiple Receipt Lines to one Despatch Line. (How sophisticated, or precise, do you want the reason for rejection to be? Advising the supplier over the phone is generally more expressive than an electronic message!)
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:
The invoice only contains the information that is necessary for invoicing purposes. It does not re-iterate information already established in the Order, Order Change, Order Response (complex), Despatch Advice, or Receipt Advice that is not necessary when invoicing. The Invoice refers to the Order, Despatch Advice or Receipt Advice by the Identifier of those documents.
Taxation on the Invoice allows for Compound Taxes, the sequence of calculation implied by the sequence of information repeated in the data-stream. (e.g., Energy tax, with VAT — Value Added Tax — superimposed).
Charges can be specified either as a lump sum, or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover:
The present Invoice does not cover Debit and Credit Notes. Nor does the cycle include a Customer Account Statement that summarises Invoices, Credit Notes and Debit Notes to be paid.
Each Invoice Item Line refers to the related Order Item Line and may refer to the Despatch Advice Item Line and/or Receipt Advice Item Line.
The UBL Library was developed as business information entities (BIEs) expressed as a conceptual model. These are then assembled into hierarchical document structures and transformed using the UBL Naming and Design rules into XML Schema syntax.
Annex A contains the UBL Conceptual model.
Annex B contains the hierarchical document structures assembled from this model. The non-normative UBL document models contain enough meta-data to allow the automatic generation of XML Schemas based on the UBL Naming and Design Rules.
There are no XML schema with this release, this is a placeholder for the full release later on.
The conceptual data model describes all the Object Classes, Properties and Associations involved in a general trade procurement process, as defined by Section 5 of this Specification.
This data model is presented graphically as a UML Class diagram.
Figure 2. UBL Conceptual Class Diagram
Note that this model does not represent any specific document type. It is a conceptual view of all the necessary information components involved in any of the UBL document types. All the current UBL document types were derived using object classes and associations taken from this model.
All Business Documents are defined in their individual spreadsheets, each references the Re-usable Component Library spreadsheet.
These are provided in both Microsoft(R) Excel and OpenOffice formats.
Class diagrams for the UBL documents are referenced through the identifiers below.
These are provided in both GIF and PDF formats.