UBL basics

Let's explore the origins and some of the features of UBL, including how UBL allows local customization within a supply chain. Then we will examine how UBL is being used in real world situations.

Tim McGrath, one of the creators of UBL, observed, "UBL is not a technology breakthrough; it is a breakthrough in the application of a technology" (see Resources).

Bower and Christensen coined the phrase disruptive technology to describe a technology that unexpectedly displaces an established sustaining technology. Sustaining technologies usually rely on incremental improvements, while a disruptive technology may come from a source that wasn't designed for how it is finally used to displace the other technology.

Hence, if UBL is not a disruptive technology, it is certainly what Christensen later called a disruptive innovation with the potential of "allowing a whole new population of consumers access to a product or service that was historically only accessible to consumers with a lot of money or a lot of skill" (see Resources).

Background

UBL is not a new technology, and its foundations are certainly not new. UBL became an OASIS standard in 2004, with subsequent releases in the following years. Table 1 provides a chronology of UBL releases.

UBL conforms to the Extensible Markup Language (XML) recommendation (V1.0 - World Wide Web Consortium recommendation, 1998), which is based on the Standard Generalized Markup Language (SGML) that became an International Organization for Standardization standard in 1986. SGML descended from IBM's General Markup Language (GML) developed in the 1960's by Charles Goldfarb, Edward Mosher, and Raymond Lorie. There is almost a half century of solid technical development in the domain of general markup languages.

SGML focused on solving very large scale documentation problems experienced by the military, aerospace, and automotive industries, and large publishing houses. The U.S. Department of Defense (DoD), for example, received technical information from thousands of suppliers in a multitude of proprietary formats. This created a big problem when they tried to integrate all the information within a common electronic framework. Their solution was to demand that all suppliers use SGML. Suppliers had to provide technical information in SGML based on a continuous acquisition and life-cycle support (CALS) definition, or else the DoD would not do business with them. The result was that the DoD received all information received in a common markup language, which eliminated a lot of problems. We are in a similar situation with the exchange of business documents.

UBL is an XML markup language aimed at business documents being exchanged between companies on the Internet. The UBL effort is meant to fuel global e-commerce by simplifying the currently paper intensive exchange of business information. UBL 2.0 defines an open, royalty-free library of 31 standard electronic XML business documents such as purchase orders, invoices, and dozens of other standard business documents that can be used globally. UBL 2.1 (in development) has over 60 documents. UBL's design objective is to plug directly into existing business, legal, auditing, and records management practices, to eliminate the re-keying of data in existing fax and paper-based supply chains, and to provide an entry point into electronic commerce for small and medium-sized businesses.

It is important to understand that when implementing a UBL solution, you don't need to change the way you currently do business, nor change the software applications you currently use. UBL can replace the exchange of paper business documents with reliable electronic documents that can be understood globally. In many cases, the end user might not be aware of the use of UBL, since they carry out their tasks normally using their current applications. Business practices honed over many years are simply applied to the electronic world.

Back to top

Business Information Entity

UBL is built on existing standards. For example, UBL uses the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Core Components as defined in Part 8 of the Core Components Technical Specification (see Resources). This specification defines a Core Component solution as "a methodology for developing a common set of semantic building blocks that represent the general types of business data in use today and provides for the creation of new business vocabularies and restructuring of existing business vocabularies".

A core component is a semantic building block that can be used for all aspects of data and information modelling and exchange. Core components are the linchpin for creating interoperable business process models and business documents. Core components are conceptual in nature and are used for creating context-specific Business Information Entities (BIEs).

UBL defines a set of business definitions that utilize these core components as a base. Figure 1 illustrates how UBL maps onto these core components.

The BIE is a key concept in the UBL assembly process. A BIE can be a Basic BIE (BBIE), an Aggregate BIE (ABIE) or an Association BIE (ASBIE).

A Basic BIE is an atomic entity, not composed of other entities. An Aggregate BIE can be composed of Basic BIEs and other Aggregate BIEs. The Association BIE defines an association between an ABIE and another ABIE. A set of standard business documents, such as purchase orders and invoices, are then assembled from the BIE. See Figure 1 for details.

As mentioned before, the BIE is a key concept in the UBL assembly process, just as the core component is in the core component assembly process. The BIE takes 3 forms: a basic BIE (BBIE), an aggregate BIE (ABIE), or an association BIE (ASBIE). A BIE is a piece of business data or a group of pieces of business data with a unique business semantic definition. There is a special ABIE named the Document ABIE reserved for the different document types such as a purchase order or invoice. Each of these in turn will consist of a set of ABIEs, ASBIEs and BBIEs.

The BBIE is an atomic entity, not composed of any other entities. It represents the semantic building block and maps directly to the Basic Core Component. An example of a BBIE might be AddressTypeCode — a code specifying the type of address such as business address or home address. An Address is an ABIE, a structured set of information about an address. A DeliveryAddress or AddressLine would be an example of an ASBIE. DeliveryAddress inherits the properties of the more general Address while AddressLine inherits the properties of the more general Line.

Sample Business Information Entity

To see a fragment of code from the UBL-CommonAggregateComponents-2.0.xsd that illustrates how the various forms of BIEs are constructed and related, view Listing 1. Sample Business Information Entity. The pieces dealing with the notion of an address have been extracted including element definitions for Address and AddressLine.

The common basic core components, upon which the BIEs are based, belong to the XML namespace cbc. AddressLine (an ASBIE) is also part of the definition of AddressType which has the attribute type="AddressLineType".

AddressLine, with an attribute type="AddressLineType", is an ABIE consisting of one or more Line elements (a BBIE also belonging to the XML Namespace cbc). Line is defined as "a line of address expressed as unstructured text".

All of this code defines an Address (an ABIE) consisting of a number of optional elements (BBIEs), including AddressLine (an ASBIE). AddressLine (ABIE) consists of one or more Line elements (BBIE).

Back to top

UBL customizations

UBL designers didn't try to force all users into a single, all-encompassing, centrally-managed solution. Rather, they designed UBL to fit 80-90 percent of the global requirements and recognized that there are local requirements that users would have to manage through customization.

For example, you might only use certain UBL documents within a given community. You might only need certain portions of those UBL documents. And you might add custom extensions to them for your community. You could even restrict the values that individual information items may take.

UBL designers made a unique decision to separate structural and lexical validation from value validation. This is quite different from other XML-based business vocabularies that conflate the two validations into a single schema.

In UBL, structural and lexical constraints are defined (and validated) via the schema; a second abstract expression of code lists (using Xpath, genericode, and context to value association) and other value constraints are used for value validation. Figure 2 illustrates this separation. This secondary value validation step allows a community of interest (say a supplier and a set of customers) to agree and specify a set of values to be used only within that community. For example, a product code might be constrained to the set of products offered by the supplier.

In Figure 2, you can see how the standard W3C XSD schema is for structural and lexical validation. As in all XML, an input instance can be declared valid if it belongs to the class of documents formally described by the W3C Schema.

The value validation involves code lists. Code lists, or controlled vocabularies, are specifically used to restrict the values allowed for an information element. Code lists can be managed globally (such as two-character country codes) or locally (such as a supplier's list of product codes in their catalog).

We won't go into a long description of code lists here, but the UBL 2.0 Frequently Asked Questions describes how code lists are processed:

“UBL 2.0 also features an answer to the problem of code list management. Instead of binding default code list values directly into the document schemas, which makes trading-partner-specific adjustment of code lists virtually impossible, UBL 2.0 expresses code list values in separate files using the new genericode format. The default values are then used to generate an XSLT script that validates the code values independent of the standard schemas. This two-phase approach not only solves most code list management problems; it also allows different code list subsets to be associated with different contexts in the same document instance, provides great flexibility in specifying the code values accepted in each trading relationship, and establishes a platform for sophisticated business rule implementation — all without modifying the standard UBL 2.0 schemas.”

For a link to the UBL 2.0 FAQ, see Resources.

OASIS UBL 2 Guidelines for Customization, First Edition provides a detailed description of how to deal with customization (see the link in Resources).

Back to top

Problems with exchanging business documents

Now let's examine the problem of exchanging business data between companies in a supply chain. A company might act as a customer to a supplier that will provide the customer with the goods or services the customer requires to carry out their business. Each customer typically has N suppliers (see Figure 3).

Table 2 shows activities typical of this business arrangement.

If we generate a plot of companies where the vertical axis is the number of suppliers and the horizontal axis is an ordering of all customers by number of suppliers, we see a standard Pareto curve. About 20 percent of customers have a large number of suppliers and typically have large scale applications installed to handle these large number of suppliers. These might be electronic data interchange (EDI) systems that can deliver a transaction such as an invoice to another EDI user electronically (see Figure 4).

The other 80 percent of customers have fewer suppliers and use less sophisticated applications (or even office tools like a spreadsheet or word processor) to generate business transactions like an invoice. Many of these customers use paper as the medium to transmit the business transaction to the supplier.

The problem for the customer with a very large number of suppliers is that they have a system that requires the invoice data to be entered into their system electronically. When they receive invoices from suppliers as a printed page through regular mail or perhaps a PDF sent by e-mail, they spend time and resources to rekey the information or perform a scan and OCR to get the information in electronic form. In Europe, one cost estimate for processing a typical invoice is around €7-15. Eliminating this cost could amount to huge savings for a large enterprise.

For example, consider the Government of Denmark who has to process 1.4 million invoices per month from 440,000 suppliers. Going after these savings can be very cost effective. KPMG, in their formal analysis of the Danish situation in 2003, found that it would be possible to eliminate at least ten minutes of invoice handling per invoice, resulting in savings of €94M. Eliminating the 17 minutes spent matching invoice to purchase order would produce an additional €160M in cost savings.

The problem for the customer with a very small number of suppliers is that many existing systems are too complex and too expensive to meet their needs.

Back to top

Applications of UBL

In general, for two businesses to effectively exchange business documents, they must be speaking the same language within these documents and they must have a way of electronically exchanging these documents — without changing their existing business processes. And the process must be scaleable to the size of the businesses involved, from a very small business to a government or a large corporation.

UBL provides the standard language for the business document exchanges based on a common set of semantic standards. Every company can exchange their business documents with other companies and have their documents understood.

For example, OASIS (2006) provides a number of UBL document examples. Listing 2 is an excerpt for a LineItem from an order for 100kg of beeswax.

<cac:LineItem> 
    <cbc:ID>1</cbc:ID> 
    <cbc:SalesOrderID>A</cbc:SalesOrderID> 
    <cbc:LineStatusCode>NoStatus</cbc:LineStatusCode> 
    <cbc:Quantity unitCode="KG">100</cbc:Quantity> 
    <cbc:LineExtensionAmount currencyID="GBP">
        100.00    
    </cbc:LineExtensionAmount> 
    <cbc:TotalTaxAmount currencyID="GBP">17.50</cbc:TotalTaxAmount> 
    <cac:Price> 
        <cbc:PriceAmount currencyID="GBP">100.00</cbc:PriceAmount> 
        <cbc:BaseQuantity unitCode="KG">1</cbc:BaseQuantity> 
    </cac:Price> 
    <cac:Item> 
        <cbc:Description>Acme beeswax</cbc:Description> 
        <cbc:Name>beeswax</cbc:Name> 
        <cac:BuyersItemIdentification> 
            <cbc:ID>6578489</cbc:ID> 
        </cac:BuyersItemIdentification> 
        <cac:SellersItemIdentification> 
            <cbc:ID>17589683</cbc:ID> 
        </cac:SellersItemIdentification> 
    </cac:Item> 
</cac:LineItem>

Note that it is human readable. It is very easy to see that this is an order for 100kg of beeswax, for a total price of 100 GBP plus 17.50 GBP tax. Since it is XML, it can be processed with off-the-shelf components.

The two namespaces, cbc and cac, refer to basic and aggregate components respectively. You can see that <cbc:Name> above is a basic component, while <cac:BuyersItemIdentification> is an aggregate component consisting of a basic component <cbc:ID>. You can also see that <cbc:ID> is also used in <cac:SellersItemIdentification> and is semantically the same but used in different contexts.

The importance of locally controlled code lists external to the schema can be illustrated here. If you tried to include the list of valid values for SellersItemIdentification in the schema definition, you would need a separate schema for each community of users, and you would have to continually maintain each one as the list of valid values changed

In Figure 6, you can see how easy it is to change how companies exchange business data electronically merely by plugging in a back end conversion of their business data from print to electronic exchange, without changing their existing systems.

Back to top

UBL in Europe

Now let's take a look at how various countries have adopted UBL to get a better idea of the power and savings that can be achieved by implementing various UBL solutions.

The Danish experience

Denmark was a very early adopter of UBL as a solution for e-commerce. The government of Denmark realized there could be significant cost reductions in their invoice processing if they could receive all invoices in a standard form, and UBL provided the standard for that implementation. Given their power as a government, they legislated the use of UBL.

Beyond merely legislating the use of UBL, they had to provide the infrastructure for all businesses big and small to comply with the law. They developed a portal for public procurement, an electronic marketplace accessible to all public buyers and suppliers in Denmark, and scanning agencies to provide paper conversion to UBL.

Although the invoice was the first UBL document to be handled by Denmark, it is in fact the last part of the procurement chain. Electronically processing the other documents in the procurement chain from tendering through invoicing can greatly add to the efficiency and cost savings. The work toward this objective and the adoption of UBL 2.0 led to the adoption of a Danish subset of UBL 2.0 named OIOUBL.

The European Union experience

Led by Denmark, representatives from Denmark, Sweden, Norway, Finland, the United Kingdom, and Iceland set up a working group to develop a Northern European Subset (NES) of UBL 2.0 documents.

The purpose of the NES subset is to facilitate harmonization of different types of e-procurement documents in countries that are already using UBL or are considering using UBL 2.0 documents. This provides an opportunity to base e-procurement documents and processes on a coordinated NES subset.

UBL will be the basis for the Pan European Public Procurement On-Line (PEPPOL) project (see Resources). The broad vision of PEPPOL is that any company in the European Union, including small to medium enterprises, can communicate electronically with any European Union governmental institution for all procurement processes.

UBL in North America

Surprisingly, there seems to be very little adoption of UBL in North America. It doesn't even seem to be on anybody's radar screen. One notable exception is the work being carried out by the U.S. Department of Transportation. Their pilot Electronic Freight Management project uses the following UBL documents:

• Transportation Status
• Despatch Advice
• Receipt Advice

This pilot project linked two Chinese apparel manufacturers, two freight forwarders, an air cargo terminal operator, two charter air carriers, a U.S. apparel buyer, a U.S. third party logistics company, and an import broker in a demonstration of state-of-the-art electronic commerce in a complex real world setting. The architecture effectively created a federated database with no single point of failure and no data duplication as in traditional centralized database solutions.

Back to top

UBL as a disruptive innovation

If we examine how UBL might make inroads into North America we see from the European experience various ways this might be accomplished:

• Legislate the use of UBL. Governments can pass laws mandating the use of UBL on all business transactions with the government.
• Decree the use of UBL. Very large organizations (such as the military) can refuse to do business with organizations that do not use UBL.
• Evolve the use of UBL. Current suppliers offer UBL output as an option in their current software offering.

How might the third way come about?

There are two ways:

1. Vendors of existing e-commerce applications can add UBL export and import as features.
2. Vendors can provide new UBL services that can interface to existing applications.

The first option is an example of what Christensen calls sustaining innovation. However, only those who own or purchase that application have access to this ability.

One example of the second is the different approach offered by Tradeshift® (see Resources). They provide a Software as a Service (SaaS) based on cloud computing for the interchange of electronic UBL business documents, including free electronic invoicing. They concentrate on this exchange of UBL documents, not the applications. At the lower end they provide a browser-based interface for generating and exchanging invoices. At the higher end, they provide an Open API so that vendors of existing software may add the UBL back end at a lower cost (see Figure 6). It is interesting to note they added "social networking" functionality to implement a "discussion thread" for every document.

Back to top

A greener planet

As we finally move away from paper based systems toward electronic exchange, we can contribute to a greener planet. For example, up to ten percent of the trees cut down on this planet are used to create the paper that invoices are printed on. Eliminating the need for this paper can contribute to the reduction of de-forestation, just one of the initiatives that the Smart2020 study identifies as to how Information and Communication Technologies can contribute to the low carbon economy in the Information Age.

Back to top

Conclusion

We have demonstrated that UBL is an XML-based technology that is based on over 40 years of solid development in the domain of general markup languages. UBL is designed to plug into existing business, legal, auditing, and record management practices, and through reduction of the use of paper documents, it can contribute to a greener planet.

Rather than trying to replace existing applications in the financial services industry, UBL can be used to convert the current exchanges of business documents between organizations from paper to electronic form based on an international standard.

UBL is designed to handle 80-90 percent of common business requirements with the remaining percentage handled by UBL customizations. Customizations include using subsets of the documents defined by UBL. You can use only those optional pieces of a single UBL document that are required, you can extend a UBL document, or you can even propose a new UBL document. In addition, validation of the contents of information elements can be managed locally with customer-based code lists.

Using UBL can be considered a disruptive innovation as it finally allows a whole new population of consumers (up to 80 percent of current organizations) access to electronic exchanges instead of paper documents to conduct business.

Resources

Learn

• CCTS (2003) — Core Components Technical Specification — Part 8 of the ebXML Framework: Find information to guide in the interpretation or implementation of ebXML concepts.
  
  
• Disruptive Technologies: Catching the Wave (Joseph Bower and Clayton Christensen, Harvard Business Review, January-February 1995): Read the seminal article by Joseph Bower and Clayton Christensen from the Harvard Business Review.
  
  
• Disruptive Innovation: Learn more about this term, coined by Clayton Christensen, that describes a process by which a product or service takes root initially in simple applications at the bottom of a market and then relentlessly moves up market, eventually displacing established competitors.
  
  
• The Need for Disruptive Innovation (Part 1) — Computerworld Blog: Read about innovation in Canada.
  
  
• Cover Pages: Learn more about UBL from Cover Pages, a comprehensive, online reference collection supporting the XML family of markup language standards.
  
  
• Pan-European Public Procurement (PEPPOL): Visit the home page for Pan-European Public Procurement for more information.
  
  
• Crane Softwrights— UBL 2.0 Model Summary Reports: Refer to these sets of 61 HTML files that summarize all of the information items and document model spreadsheets.
  
  
• Electronic Freight Management: Learn more from this USDOT-sponsored project that applies Web technologies to improve data and message transmissions between supply chain partners.
  
  
• OASIS UBL 2 Guidelines for Customization: Read about customizations for UBL.
  
  
• Core Components Technical Specification: See the Core Components Technical Specification from United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT).
  
  
• Oasis UBL FAQ: Find answers to frequently asked questions.
  
  
• SMART 2020: Enabling the low carbon economy in the information age: Examine the impact of information and communication technologies on global warming.
  
  
• Tradeshift: Find Software as a Service based on cloud computing, concentrating on the exchange of UBL documents between customers.
  
  
• IBM developerWorks Industry Zone: See the Industries site for all the latest industry-specific technical resources for developers.
  
  
• developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  

Get products and technologies

• OASIS UBL 2.0 sample UBL documents: Download the sample documents from this directory.
  
  
• IBM trial software: Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• developerWorks blogs: Participate and get involved in the developerWorks community.
  
  

About the author

W. Hugh Chatfield is an Information Systems Professional and principal of CyberSpace Industries 2000 Inc., providing both XML training and consulting and multimedia production services. He holds an honors degrees in Physics and an honors certificate in Documentary Production. With over 40 years experience in Information Technology, he has spent the last 17 years in the general markup languages domain.

Rate this article

Comments

Back to top

Table of contents

• UBL basics
• Business Information Entity
• UBL customizations
• Problems with exchanging business documents
• Applications of UBL
• UBL in Europe
• UBL as a disruptive innovation
• A greener planet
• Conclusion
• Resources
• About the author
• Comments

Dig deeper into Industries on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers