What is UBL?
January 1, 2017
Table of Contents
The world of business is fueled by documents such as orders, invoices and waybills that are sent between trading partners such as buyers, sellers, shippers and warehouses. For many years, expensive Electronic Data Interchange (EDI) implementations on costly value-added networks have fulfilled the need to express such documents in a machine-processable form for software applications to act on the contents found therein. Until the first publishing of the OASIS Universal Business Language (UBL) in 2003 as an open, customizable and extensible XML vocabulary of business documents, custom-tailored XML-based replacements had come and gone in experimental forms and proposals by vendors, never gaining the traction needed to be adopted by business or sanctioned by governments for use over the Internet. Growing in scope and use in new releases, the global perspective and acceptance of OASIS UBL was bolstered in 2015 when governments worldwide ratified OASIS UBL as International Standard ISO/IEC 19845.
There are a number of established XML vocabularies for families of document types. The Text Encoding Initiative (TEI), as an example, is for electronic texts for scholarly research such as prose, drama and poetry. The Organization for the Advancement of Structured Information Standards (OASIS) is responsible for a number of other examples. OASIS DocBook is for technical documentation comprising books and articles. The OASIS Open Document Format (ODF), internationally standardized as ISO/IEC 26300, is for office applications including spreadsheets, documents and presentations.
The commercial invoice is but one of a family of 65 document types formally described as semantic business objects in business documents, each with an associated XML schema, in the OASIS Universal Business Language (UBL) Standard, also internationally standardized as ISO/IEC 19845.
In 2004 a study for the Danish Government by KPMG, a professional services company, reported
that Danish public institutions received approximately 1.25 million paper invoices per month at
an approximate cost of processing that paper of €10 per invoice. The use of OASIS UBL was
legislated for all government procurement to start in February 2005. By October 2005 95% of all
invoices sent to Danish public institutions were in UBL XML. The government reported in http://www.oasis-open.org/committees/download.php/36397 that by
2010 more than 30,000 public sector endpoints received invoices from 175,000 private companies,
all using XML invoices in the UBL vocabulary. In that time a documented total of €500 million
had been saved just by the government, net of the costs of development and deployment. This
doesn't include the savings for companies in private industry who dealt with the government and
also jumped onto the national network to send invoices to each other.
In September 2008 European stakeholders in public procurement with government created the
Pan-European Public Procurement On-line (PEPPOL) project jointly funded by the European
Commission to support business-to-government supply. In http://www.peppol.eu/news/electronic-invoicing-in-norway-a-story-of-success
it is reported that at the beginning of 2014 over 50% of the network was being used for
business-to-business transactions:
In January 2014, an important milestone was reached when the entity number 10.000 was registered as a recipient ... Most of these organisations have capability to receive eInvoices. ... Among the over 10.000 organisations, approximately 10% are public sector recipients (including all central government entities and a majority of municipalities and counties) while approximately 90% are private. Out of the first million transactions exchanged over the PEPPOL network, nearly 50% were Business-to-Government, and the remaining was Business-to-Business.
Not only are governments spearheading the use of UBL XML, but private industry also is embracing the specification. The Tradeshift cloud-based worldwide business network uses UBL procurement schemas for its business documents on its backbone, including as well their own custom documents built using the UBL common library. A Dutch online department store uses UBL procurement and transportation schemas for its business documents on its backbone between departments and with their warehouses and their shipping companies.
Research projects in the US (Electronic Freight Management - EFM) and Europe (eFreight, iCargo and e-Impact) are successfully deploying UBL transportation documents in the field and are also feeding back to the committee requirements to address future needs.
UBL XML is also being chosen as the interface document between a user and applications acting on the business information. The Tradeshift API accepts and produces UBL documents for transmission between tenants using UBL and non-tenants not using UBL. The Xalgorithms Foundation web service accepts a skeleton UBL document for augmentation with business logic information, producing a fleshed-out UBL document complete with the algorithmic additions.
Just the nature of business requires that business documents be exchanged between trading partners. When your company needs to express business information in an unambiguous fashion for another company to consume, the extensible OASIS UBL XML vocabulary is there to use off the shelf and to augment with any custom needs. No longer must a vendor, a business, an industry sector or a government have to create from scratch the structures needed to convey such information in a structured rigorous format.
1. The task at hand
You are part of a business that has established practices built around the tools you use for business functions. Your trading partners will have their own practices based on their tools and their history.
Not all businesses follow the same internal business practices because the nature of business varies as much as business itself varies. But between trading partners there are established business documents that represent transactions such as purchasing, where an order document requests goods or services and in return an invoice document demands payment for them. There may also be despatch notices informing the buyer that the goods have been sent, and receipt notices informing the seller that the goods have arrived. There yet may be transportation planning documents to route shipments and transportation event messages indicating the progress of them.
When automated using software, the sender's application preparing the business document to be sent to the receiver frames the information around the content found in the sender's data model reflecting the sender's business practices. The information is typically then prepared in paper form, perhaps even electronically in paper form using PDF. This document insulates the sender from following or just even knowing about the receiver's business practices. The receiver of the document then needs somehow to convey that information into their application that has its own data model reflecting their business practices. This can be illustrated as follows.
Presuming that the sender's application is working properly and puts the correct information into the paper document in the first place, there are still opportunities for errors to creep into the process at the point that the paper document is ingested by the receiver's application through scan or key entry. Should errors be introduced at this point, the receiver's data model receives the incorrect data and the business processes work with incorrect information. Errors only exacerbate the time taken to deal with the paper, let alone the expense of handling the paper and filing the physical copies. On top of the expense is the cost of staff for data entry and operating the scanning hardware, plus the cost of paper itself and any need to ship or mail the paper by the truckload when dealing with a million invoices a month.
Moving to the electronic interchange of information involves three aspects of the interaction between trading partners. The choreography of exchanges (if any) needs to be agreed upon, the structure and use of the documents within each choreography must be unambiguously processable, and the platforms on which each party runs their software must be able to communicate with each other.
The choreography can be non-existent with only a single uni-directional transmission, such as an invoice-only profile. The choreography can be very simple with a request/response mechanism. It can be quite complex with multiple documents exchanged for catalogues, ordering, invoicing and credit notes. The European standards organization CEN created the Business Interoperability Interchange (BII) project to enumerate and describe in detail dozens of profiles of document exchanges for different business processes following European regulation and legislation. Participants in the project included all of the stakeholders such as product/service suppliers, government buyers and technology vendors. The European Commission PEPPOL project adopted many of the BII profiles in its deployment.
For a document format, the OASIS Universal Business Language (UBL) is an open and royalty-free library of standard XML business document types. UBL is made freely available to download without any registration or cost, for users to cherry-pick which constructs are going to convey which business information is needed to be exchanged. Validation tools are included to automate the checking of content against the document constraints.
A real-world example of a simple request/response exchange for transportation status messages is seen in the US Department of Transportation Electronic Freight Management (EFM) project shipping Victoria's Secret clothing from a supplier in China to a buyer in Cincinnati. There were 11 different parties involved in the handling of a single shipment from source to target, including transportation, customs and warehousing. Each party has their own business practices, data models and applications. The project's work product was a single aggregation application able to report shipment status information in HTML to a user. The application requests each party to respond with a UBL Transportation Status message with details of the desired shipment as known only to the party being asked. Those who received the request and could respond to it returned the information in a UBL-schema-valid XML document. The aggregation software then assembled the information into a single report for the user. In effect, the aggregation software was accessing a distributed, federated and fault-tolerant database of information about shipments. The best information available at the time was made accessible using the standard format.
A community of trading partners (as small as two, as large as a group of countries) agrees on which documents are to be exchanged when, what information goes into each document and how the documents are communicated between parties. It is a detailed suite of agreements to negotiate. But typical business practices guide the creation of the choreography and available communication specifications and software enable systems to communicate with each other.
As the UBL awareness and adoption grows worldwide, vendors will make more and more tools compatible with the specification. Already in Europe all of the major invoicing software packages have profiles supporting UBL in order for their European customers to effect business with electronic documents with each other and with governments. Vendors have announced the use of UBL as the application programming interface format for conveying business document information to their solutions. As happened with hypertext and information publishing over the web, UBL is already becoming the HTML of business documents.
2. The scope of the UBL specification
UBL has grown from an initial 7 document types in UBL 0.7 in 2003 now to 65 document types in UBL 2.1 - ISO/IEC 19845:2015. This growth has been in response to user requirements received from the communities of users of UBL, and the active participation of committee members championing their own submissions for new document types. As of mid-2016, another couple dozen new documents are being considered for UBL 2.2, the next backward-compatible minor revision to this specification.
The four high-level categories of documents to date are pre-award sourcing, post-award sourcing, procurement, transportation and a fifth general catch-all category for a few functional documents. See Section 8, “Summary list of document types in UBL 2.1 - ISO/IEC 19845:2015” for the detailed list of all document types, complete with their purpose as described in UBL's semantic dictionary.
Pre-award sourcing involves those aspects of tendering in advance of a successful vendor being chosen by a buyer. Candidate vendors make themselves known and their catalogues are made available for the buyer to make their decision.
Post-award sourcing involves those aspects of tendering once a vendor has been chosen. The unsuccessful candidates need to be notified. Successful candidates need to be vetted. Catalogues may need updating. Quotations need to be formalized.
Procurement is the act of ordering, fulfilling and demanding payment for the goods and services being purchased. It also includes the steady processes of replenishment and the forecasting and managing of inventory over the long term.
Transportation documents are complementary to the purchasing process, with the planning, arranging and tracking of shipments using intermodal freight, possibly across international customs borders.
The online summary of all of the 65 document types and the complete description of their
constituent common library components in UBL 2.1 is accessed at http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html.
As an example, find the Invoice hyperlink around the middle of the initial pack of index links
in order to find the identifiers, time stamps, codes and other information items that make up
the invoice. Clicking on the last row's entry for the invoice, the InvoiceLine, brings up the details of a line item and its parts. And so on
through the entire invoice.
3. Customizing and extending UBL
As big as UBL is, you may be in the position where you know you have unique information requirements, perhaps because of the industry you are in or simply because as a community you have established agreements that business documents contain semantically special elements. The UBL Technical Committee recognized at the beginning of the project that it would not be possible to know, let alone to satisfy, all of the requirements of all possible users of an XML business document vocabulary. But general principles of accounting and of transportation concepts are commonly understood, commonly expected and commonly accepted across all users, and so these are already found within the package.
For example, at a minimum a commercial invoice is an identifiable demand for payment of a particular party, from a particular party, on a given date, to pay a specific amount for identified goods or services. If no other information was included on the invoice, it is possible to still transact business with that invoice if the parties agreed out-of-band on all other aspects of the transaction. And so it is in the UBL invoice that these are the only mandatory elements for the XML. All other business objects in the UBL invoice are optional and so, too, the elements that represent them. But dozens more business objects have been made available based on the experiences of the committee members building the document models.
As a result of having all of the available optional elements at hand, the 65 document types and the common library that supports them have a total of over 4,000 business objects described as XML elements, not counting reusing the business objects in different contexts.
User communities are expected to cherry-pick which subset of UBL elements are to be important to their transacting of business, and to document how individuals in the community are expected to use the elements to represent information in a common fashion. This isn't a task of selecting which additional elements are mandatory, but simply which elements make up that subset of UBL the community is going to focus on, without taking on the burden of supporting all 4,000 elements. The business processes and anticipated document exchanges are going to govern this selection of elements, and which of them remain optional or are made mandatory by the community.
The UBL schemas are normative components in the UBL specification. When receiving a UBL document it is most appropriate to validate the document against the entire UBL schema to ensure the standard, at the least, has been satisfied. Only then does it make sense to check the schema against a particular subset defined by a community. This can be done with a subset schema, or with a technology such as ISO/IEC 19757-3 Schematron, or by the application itself, knowing at the least that the instance is schema-valid as a UBL document. Publicly-available free tools can create XSD expressions of a subset of the elements in UBL documents and the common library.
The subset schema also has a role in methods of creating UBL documents, typically when doing so by hand. With 4,000 elements it may be that applications trying to ingest the UBL schemas will choke due to limited capacities. Moreover, allowing a community of users to create UBL elements that are not part of the community UBL subset would be confusing and would create instances that would fail downstream business tests. But creating a subset schema of only the elements of interest to the user community will create artefacts that software tools will be able to ingest more easily and will present the users with a user interface limited only to the agreed-upon constructs.
Communities in need of documents not described by UBL can still take advantage of the
standard. All of the document types published in UBL share the use of the UBL common library.
The document schemas are an onion-skin of top-level children of the apex document element,
where those children may reference items in the common library. Items in the common library
may reference other items in the common library, but they do not reference any apex document
types. This common library is available to be used for a community's custom document type, so
sharing the XML expression of the business objects across standardized documents and bespoke
documents. For example, Tradeshift has need of an "Application Message" document type not
found in UBL and so created the <ApplicationMessage> element in its own
namespace, building a new document entirely from UBL common library components as children of
that document element.
Communities in need of elements that are not in UBL documents, but need to use the UBL documents for what they currently offer, can take advantage of the extension point available as the first child element of every UBL apex document element. A document can have any number of extensions and each extension can have arbitrary content. Users can choose to import schemas for extension content to be validated, but any content for which there is no schema is accepted without complaint. With this design, an application with no interest in the extended content won't be interfered with when accessing the standardized content. Consider the example of an invoice for services rendered, where the community requires a time sheet to be included with the invoice. Such data can be added under the extension point without interfering with the line items and legal monetary totals needed by ERP software to act on the financial aspect of the invoice. It is expected that entire industry sectors will have their own extension definitions to be included in UBL documents.
The Xalgorithms Foundation project is putting the extension point to interesting use by placing there any history of document change information. When the skeleton UBL document is returned from the web service with content added according to business rules, the document is annotated not only with a list of changes to the data, but also the reasons for the changes to the data. This information lives on with the UBL document as a record of its life, but in such a way so as not to interfere with the document information standardized by the committee, and so is innocuous to UBL-enabled applications.
4. The governance of UBL
Do you think your extension elements have the semantic definition that will be of interest to many users of UBL? Do you feel the committee has overlooked a particular document type that is needed in general? If so, UBL governance allows you to participate in the UBL development process, either by joining OASIS and becoming a member of the committee, or by using the available public comment list. For intellectual property reasons, these are the only two ways a Technical Committee can receive input. OASIS has worked hard to ensure that its committees' work products are available to be used by anyone. The membership constraints and the public comment list subscription constraints impose obligations on contributors that that which is submitted by them is allowed to be openly used in work products published by OASIS.
The UBL Technical Committee has long acknowledged that in the early days the active committee participation by representatives from Denmark to describe business documents they needed for their government procurement helped tremendously in producing the first versions of UBL. Requirements from other European projects have been the primary driver, but not the only driver, in the growth of UBL since the early days, because the European Commission fostered an environment specifying multiple business processes needing multiple document exchanges. Important additions to the transportation documents came in from research projects.
There are generally two kinds of requirements that come in to the committee. Most requirements are for semantic additions to the OASIS business objects in the common library, in existing document elements or with new document elements. Submitters are asked to document the information needed, to justify the reasons for adding the information to the models and to supply examples of the information to incorporate into sample test documents.
Sometimes the committee will receive requirements for syntactic additions, pointing to existing XML vocabularies, asking the committee to mimic an established set of elements with a new set of UBL elements. In such cases the committee will point the submitter to the UBL extension point. When an XML vocabulary has an established and active governance of its own, it makes no sense to recast a set of new elements and try to keep up their maintenance in parallel. It is best for the submitter to simply create the extension scaffolding in which the foreign vocabulary is to be placed under the extension point.
To help the community understand the available options, the UBL TC published the UBL
governance overview at http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/cn01/UBL-Governance-v1.0-cn01.html.
As with all volunteer standards organizations, growing membership in the UBL Technical Committee will always be welcome. More hands make for lighter work, and there is a lot of work to be done for UBL 2.2.
5. Modeling and reifying validation artefacts
UBL can be held up as an example of how XML interchange documents are developed. The methodology used has been proposed to develop solutions for other domains where international interchange documents are needed.
The international standard ISO/IEC 14662 formally describes the Open-edi reference model. This model distinguishes at a high level the business semantic perspective of an eBusiness relationship from the functional services perspective of its implementation. ISO/IEC 15944-20 Linking business operational view to functional service view is the international standard detailing at a lower level the components of a user community's Open-edi configuration in these two views. From a technology perspective of eBusiness the two normative components of UBL map easily into this model as shown as follows.
The semantic business objects of UBL describe the abstract information bundles of the business operational view of eBusiness. This describes the composition, granularity and cardinality of the information needed to be exchanged to effect the business relationship. The UBL schema XSD validation artefacts and other constraints formally describe the functional implementation of the user data representing the information bundles.
The diagram illustrates the role of the naming and design rules (NDR) that guide the mechanical production of XSD schemas for user data from the semantic descriptions of the information bundles. The UBL NDR Version 3.0 committee note documents the committee's application of the OASIS Business Document Naming and Design Rules Version 1.0 committee specification. These important business document rules have been applied in other projects, such as the OASIS Business Document Envelope Version 1.1. Rather than hand-crafting XSD files, the automated generation of the validation artefacts accurately projects the information bundles into user data schemas without the opportunity for human error.
The information bundles are described formally in UBL using the UN/CEFACT Core Component Technical Specification (CCTS) 2.01. This is a highly structured approach to the rigourous representation of information components based not on W3C XSD data types, but on a limited set of CCTS core component data types for business information. Committee members on four continents work interactively with Google spreadsheets describing the 4,000 business objects using CCTS, then download the spreadsheet as the normative documentation artefact describing all of the semantic information bundles. These can be seen in the hyperlinked HTML document summary reports cited earlier. For user manipulation this information is published in the distribution as an XML file using OASIS genericode. The committee uses freely available tools to convert the downloaded spreadsheet file into the XSD files.
The XSD schemas are the only normative validation artefacts, and by design they only address the structural (elements) and lexical (text characters) constraints of expressing the business objects in XML. The UBL Technical Committee recognized that the validity of values found in business documents is subject to real-world deployment situations that are out of scope of the committee's mandate. For example, the UBL schemas cannot include enumerations for all the world's currency codes because the code list for currency codes is constantly in flux under the custody of another organization. OASIS cannot be responsible for issuing new schemas for every update to values used in UBL documents. Moreover, trading partners may decide to constrain the selection of currency codes to only a few, rather than allow all currency codes. If UBL baked in the code list for currency codes as an XSD enumeration, then the UBL schemas need to be touched to be used in the community. By separating value validation from structural and lexical validation, the UBL schemas remain sacrosanct (except, by design, for the one extension fragment) and can be cited in contractual agreements.
As a service to the UBL community, the UBL TC includes a sample set of value constraints in the form of an XSLT stylesheet created from the XML expressions of code lists (using OASIS genericode files) and the XML expression of the application of code lists to a document (using an OASIS CVA file). In the following data flow diagram this XSLT (2) is run against the document being validated after the XSD (1) has been used to check the document. The UBL appendix on two-phase validation includes the following diagram.
6. Planning to deploy UBL
The impact of implementing UBL is going to affect your particular environment in two areas: the transfer of the content of the XML document from and to your existing application, and the communication of that document with your trading partner. They will have the same impacts on their end. This can be seen overlaid on the earlier diagram illustrating the differences between the sender and receiver systems and practices.
In regard to the transfer of the XML content, two approaches are available based on whether the application currently supports XML or not. Consider first an application that does not have its own XML ingestion process. In such a situation, it is necessary to implement import and export functions conveying information found in the application data structures from and to the elements in a UBL document. Where no such item exists in UBL, the content is placed or found under the extension point.
Consider next an application that does have its own XML ingestion process. Here it is necessary only to transform the content, creating instances of the application's XML from the UBL XML, and instances of the UBL XML from the application's XML. A technology such as XSLT can be used to effect these transformations. Again, where no such application element exists in UBL, the content is placed or found under the extension point.
Effecting the document interchange in communication with the trading partner varies based on the connectivity available. Simple email could be used as XML documents compress well as attachments or could even be conveyed in clear text. An FTP write-only account can also provide an easy-to-use depository for sending a document and being unable to read documents that others have sent to the account.
When dealing with communities of users, the historical approach is to have a central server provide the connectivity between trading partners in what is called a 3-corner model. This has inherent instability (the single point of failure with the central server) and limited growth potential (either the server needs to accommodate every possible constituent, or every possible constituent has to accommodate the server). Nevertheless, it seems in some areas, governments and organizations refuse to move away from this archaic community network implementation.
The PEPPOL project brought to light the opportunities available when implementing connectivity between trading partners in what is called a 4-corner model. This model is inspired by the interconnectivity of national telephone networks, with each country implementing differing standards, yet a long distance call can be made through each country's international access point that agrees to service level agreements of data formats and connectivity between each other. In PEPPOL there are already over 100 independent access points, some using off-the-shelf open-source software, serving their own constituencies of users, from single companies to single government departments to communities of users with custom requirements. With such a model, growth is quick and limitless as new constituencies wanting to connect to PEPPOL need only address their own needs of connecting with a new access point, and the provision of that access point becomes a market opportunity for someone willing to meet the networking obligations.
The interoperability layer of choreography profiles, open document specifications such as UBL XML and secure and reliable transport mechanisms brings together, through access points, any number of agencies, companies and other communities.
On a personal note
I have long been trying to get governments in Canada and the US to move away from the
archaic 3-corner model of government procurement implementations they continue to be
tendering for, towards the 4-corner model implemented in Europe and in Australia. If you
have contacts with governments, even at regional and municipal levels, the essay at http://www.linkedin.com/pulse/open-specifications-marketplaces-ken-holman
may be of interest to those wanting to foster an open environment with open
specifications.
7. Conclusion
Paper-based business document interchange incurs costs, delays and potential data entry and conversion errors that are all mitigated when the interchange is implemented by electronic means. eBusiness models underscore that the key to the interchange is the common document format used to express the semantic business information in an electronic manner that the sender can create and the receiver can consume.
Rather than create one's own structures for electronic business documents, the OASIS Universal Business Language (ISO/IEC 19845) is a royalty-free, openly downloadable set of business document semantics and associated XML schemas, developed and maintained in a transparent fashion in a vendor-, application- and platform-independent environment.
Robustly modeled using a UN-approved scheme and realized using OASIS naming and design rules, the UBL XML vocabulary can be subset for one's own purposes and can be extended for one's own additional semantics.
Growing adoption by governments and companies worldwide is driving UBL towards becoming the HTML of e-commerce, the go-to document markup representation of semantic business information in XML for use over the Internet.
8. Summary list of document types in UBL 2.1 - ISO/IEC 19845:2015
The following is a list of all document types, grouped by function, including the semantic description for each extracted verbatim from the specification.
Sourcing processes
Pre-award phase
Tendering documents
UBL-PriorInformationNotice-2.1.xsd- A document used by a contracting party to declare the intention to buy goods, services, or works during a specified period.UBL-ContractNotice-2.1.xsd- A document used by a Contracting party to announce a project to buy goods, services, or works.UBL-CallForTenders-2.1.xsd- A document used by a Contracting Party to define a procurement project to buy goods, services, or works during a specified period.UBL-TenderQualification-2.1.xsd- A document declaring the qualifications of a tenderer.UBL-TenderQualificationResponse-2.1.xsd- A document issued by a procurement organization to notify an economic operator whether it has been admitted to or excluded from the tendering process.UBL-Tender-2.1.xsd- A document whereby an economic operator (the tenderer) makes a formal offer (the tender) to a contracting authority to execute an order for the supply or purchase of goods, or for the execution of work, according to the terms of a proposed contract.UBL-TenderReceipt-2.1.xsd- A document sent by a contracting party to an economic operator acknowledging receipt of a Tender.Catalogue documents
UBL-CatalogueRequest- A document used to request a Catalogue.UBL-Catalogue- A document that describes items, prices, and price validity.
Post-award phase
Tendering documents
UBL-AwardedNotification-2.1.xsd- The document used to communicate a contract award to the winner.UBL-UnawardedNotification-2.1.xsd- A document communicating to a tenderer that the contract has been awarded to different tenderer.UBL-ContractAwardNotice-2.1.xsd- A document published by a Contracting Party to announce the awarding of a procurement project.UBL-GuaranteeCertificate-2.1.xsd- A document to notify the deposit of a bid bond guarantee.Catalogue documents
UBL-CatalogueItemSpecificationUpdate-2.1.xsd- A document used to update information (e.g., technical descriptions and properties) about Items in an existing Catalogue.UBL-CataloguePricingUpdate-2.1.xsd- A document used to update information about prices in an existing Catalogue.UBL-CatalogueDeletion-2.1.xsd- A document used to cancel an entire Catalogue.Quotation and Punch-out documents
UBL-RequestForQuotation-2.1.xsd- A document used to request a Quotation for goods and services from a Seller.UBL-Quotation-2.1.xsd- A document used to quote for the provision of goods and services.
Procurement processes
Ordering documents
UBL-Order-2.1.xsd- A document used to order goods and services.UBL-OrderResponseSimple-2.1.xsd- A document used to indicate simple acceptance or rejection of an entire Order.UBL-OrderResponse-2.1.xsd- A document used to indicate detailed acceptance or rejection of an Order or to make a counter-offer.UBL-OrderChange-2.1.xsd- A document used to specify changes to an existing Order.UBL-OrderCancellation-2.1.xsd- A document used to cancel an entire Order.Fulfilment documents
UBL-DespatchAdvice-2.1.xsd- A document used to describe the despatch or delivery of goods and services.UBL-FulfilmentCancellation-2.1.xsd- A document used to cancel an entire fulfilment document (Despatch Advice or Receipt Advice).UBL-ReceiptAdvice-2.1.xsd- A document used to describe the receipt of goods and services.Billing and Invoicing documents
UBL-Invoice-2.1.xsd- A document used to request payment.UBL-CreditNote-2.1.xsd- A document used to specify credits due to the Debtor from the Creditor.UBL-DebitNote-2.1.xsd- A document used to specify debts incurred by the Debtor.UBL-SelfBilledInvoice-2.1.xsd- An Invoice document created by the Customer (rather than the Supplier) in a Self Billing relationship.UBL-SelfBilledCreditNote-2.1.xsd- A credit note created by the debtor in a self billing arrangement with a creditor; Self Billed Credit Note replaces Debit Note in such arrangements.UBL-Reminder-2.1.xsd- A document used to remind a customer of payments past due.Freight Billing document
UBL-FreightInvoice-2.1.xsd- A document stating the charges incurred for a logistics service.Utility Billing document
UBL-UtilityStatement-2.1.xsd- A supplement to an Invoice or Credit Note, containing information on the consumption of services provided by utility suppliers to private and public customers, including electricity, gas, water, and telephone services.Payment documents
UBL-RemittanceAdvice-2.1.xsd- A document that specifies details of an actual payment.UBL-Statement-2.1.xsd- A document used to report the status of orders, billing, and payment. This document is a statement of account, not a summary invoice.Replenishment processes
Collaborative Planning, Forecasting and Replenishment documents
UBL-ExceptionCriteria-2.1.xsd- A document used to specify the thresholds for forecast variance, product activity, and performance history beyond which exceptions should be triggered.UBL-RetailEvent-2.1.xsd- A document used to specify basic information about retail events (such as promotions, product introductions, and community or environmental events) that affect supply or demand.UBL-TradeItemLocationProfile-2.1.xsd- A document specifying trade item attributes relating to replenishment policies.UBL-ItemInformationRequest-2.1.xsd- A document used to request product activity, forecast, or performance data.UBL-ProductActivity-2.1.xsd- A document reporting the movement of goods at specified retail locations for inventory tracking purposes.UBL-Forecast-2.1.xsd- A document used to forecast sales or orders.UBL-ForecastRevision-2.1.xsd- A document used to revise a Forecast.UBL-ExceptionNotification-2.1.xsd- A document used to notify an exception in forecast variance, product activity, or performance history.Vendor Managed Inventory document
UBL-InstructionsForReturns-2.1.xsd- A document used to initiate a return of goods. The producer is requesting the return of products that are not selling well, either to use in other places or to free up rack or shelf space.Cyclic Replenishment Program documents
UBL-InventoryReport-2.1.xsd- A report on the quantities of each item that are, or will be, in stock. This document is sent by a Buyer (for example a retailer) to a Seller (for example a producer).UBL-StockAvailabilityReport-2.1.xsd- A report on the quantities of each item that are, or will be, in stock. This document is sent by a Seller (for example a producer) to a Buyer (for example a retailer).
Transportation processes
International Freight Management documents
UBL-ForwardingInstructions-2.1.xsd- A document issued to a forwarder, giving instructions regarding the action to be taken for the forwarding of goods described therein. Forwarding Instructions is 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. This document may also be issued by a forwarder or shipping agent in its 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.UBL-PackingList-2.1.xsd- A document describing how goods are packed.UBL-BillOfLading-2.1.xsd- A document issued by the party who acts as an agent for a transportation 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. The information in the Bill of Lading corresponds to the information on the Forwarding Instructions. 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, 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.UBL-Waybill-2.1.xsd- A transport document describing a shipment It is issued by the party who undertakes to provide transportation services, or undertakes to arrange for their provision, to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the instructions for the beneficiary and may contain the details of the transportation, charges, and terms and conditions under which the transportation service is provided.Freight Status documents
UBL-TransportationStatusRequest-2.1.xsd- A document requesting a Transportation Status report.UBL-TransportationStatus-2.1.xsd- A document to circulate reports of transportation status or changes in status (events) among a group of participants.Origin of Goods document
UBL-CertificateOfOrigin-2.1.xsd- A document that describes the Certificate of Origin.Intermodal Freight Management documents
UBL-TransportServiceDescriptionRequest-2.1.xsd- A document requesting a Transport Service Description, sent from a party with a transport demand (transport user) to a party providing transport services (transport service provider).UBL-TransportServiceDescription-2.1.xsd- A document sent by a transport service provider to announce the availability of a transport service.UBL-TransportExecutionPlanRequest-2.1.xsd- A document sent by a transport user to request a transport service from a transport service provider.UBL-TransportExecutionPlan-2.1.xsd- A document used in the negotiation of a transport service between a transport user and a transport service provider.UBL-GoodsItemItinerary-2.1.xsd- A document providing details relating to a transport service, such as transport movement, identification of equipment and goods, subcontracted service providers, etc.UBL-TransportProgressStatusRequest-2.1.xsd- A document sent from a transport service provider to a transportation network manager requesting a Transport Progress Status.UBL-TransportProgressStatus-2.1.xsd- A document sent from a Transportation Network Manager to a Transport Service Provider giving the status of the whereabouts and schedule of the transport means involved in a transport service.
General documents
UBL-ApplicationResponse-2.1.xsd- A document to indicate the application's response to a transaction. This may be a business response initiated by a user or a technical response sent automatically by an application.UBL-AttachedDocument-2.1.xsd- A wrapper that allows a document of any kind to be packaged with the UBL document that references it.UBL-DocumentStatusRequest-2.1.xsd- A document used to request the status of another document.UBL-DocumentStatus-2.1.xsd- A document used to provide information about document status.