UBL and NES

• What is UBL 2.0?
• Where does UBL 2.0 come from?
• Can UBL cope with different business requirements?
• What approach uses UBL 2.0 regarding code lists?
• What made EDI hard to spread and implement in the past?
• What is a NES Profile?
• How can NES help implementers and users?
• Will UBL and NES reach the masses?
• What about implementations of UBL and NES?

What is UBL 2.0?

In short, UBL is an XML document standard, a standard for delivering business messages about orders, invoices, shipments and such from one business party to another.
The official defintion from OASIS is:

UBL, the Universal Business Language, is the product of an international effort to define a royalty-free library of standard electronic XML business documents such as purchase orders and invoices. Developed in an open and accountable OASIS Technical Committee with participation from a variety of industry data standards organizations, UBL is designed to plug directly into existing business, legal, auditing, and records management practices, eliminating the re-keying of data in existing fax- and paper-based supply chains and providing an entry point into electronic commerce for small and medium-sized businesses. [OASIS]

Where does UBL 2.0 come from?

The UBL initiative originated in efforts beginning in mid-1999 to create a set of standard XML "office documents" within OASIS and became a joint venture of OASIS and UN/CEFACT by the end of that year. UBL, however has its roots in EDI and has evolved from other XML standards such as CBL and xCBL and is totally based on the ISO 15000-5 (ebXML Core Components Library).

For more information see The History of UBL 2.0.

Can UBL cope with different business requirements?

Yes. Different industries have different data requirments and this has led to profileration of variants even in such tightly controlled standards as X12, EDIFACT and RosettaNet.

UBL does not attempt a complete solution to this problem but instead takes an extremely pragmatic approach that should allow satisfactory solutions in the great majority of real-world cases. Each UBL 2.0 schema contains an optional extension area in which trading partners may, by agreement, include any data not already covered by the very extensive predefined UBL data structure. Maintaining this extension area and coordinating its use is, of course, the responsibility of the trading partners. But this simple strategy allows nearly unlimited flexibility in individual trading relationships without requiring modification of the standard UBL schemas.

What approach uses UBL 2.0 regarding code lists?

Beginning with UBL 2.0 default code list values are no longer bound directly into the document schemas. This made trading-partner-specific adjustment of code lists virtually impossible in UBL 2.0. In UBL 2.0 code list values are expressed in separate files using the new genericode format.

This 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. [NES]

What made EDI hard to spread and implement in the past?

• There are too many choices in the EDIFACT standard.
  
• There was a need to change internal processes.
• Parties needed to make bilateral agreements about the elements and classes used.
• There was a need for pre-synchronization of data.

What is a NES Profile?

"a description of one or more related business processes supported by the exchange of a defined set of electronic business documents in order to fulfil a defined business purpose"

• The NES profiles are designed to support cross country and domestic trade
• The NES profiles are based on legal/fiscal requirements and agreed best practices.
• Each NES profile should be recognised as an independent implementation.
• Compliance to NES is measured against NES profiles in the following way:
  • All elements, mandatory and optional, listed in a profile must be understood by anyone receiving the message and claiming to be compliant with the profile stated in the message.
  • Any bilateral additions to messages in a NES profile means that the companies should not use the NES profile ID in the message.
  • Recipient can reject messages that contain elements outside of the profile or elements not in line with the cardinality of the profile.

How can NES help implementers and users?

• Support for NES profiles will be included in future versions of ERP systems. Since the ERP vendors are often present in many countries this will have a great impact.
• ERP vendors are often present in many countries.
• NES offers a harmonized subset.
• NES takes advantage of a bigger community (UBL worldwide, OIO in Denmark).
• NES is prepared for cross border trade.

Will UBL and NES reach the masses?

• Implementation on NES profiles have started, UBL 0.7 and UBL 1.0 have been used in projects now for quite a time. UBL 2.0 is very mature (See history of UBL).
• The default for NES is that no bilateral agreements are needed (however, agreements on extensions can be made if needed).
• When NES profiles and the UBL standard were defined, reality dictated the terms of how it was done.
• Since these standards are based on XMLSchema and Schematron validation, central validatin services are feasible.
• Real time validation tools exists.
• There has already there has been involvement from ERP vendors.
• UBL and the NES profiles are based on open and free standards.

What about implementations of UBL and NES?

The UBL 0.7 Invoice has been used as directed by the Danish Government since February 2005, when they required all private companies to send invoices to the government. The Swedish Government has used UBL 1.0 as part of its Swedish invoice, SweFactura. In the UK, the electronic marketplace Zanzibar has successfully employed 14 UBL 2.0 documents. Pilot projects with many participants have been conducted in the US.

Denmark has approved UBL 2.0 as part of their business profiles for electronic business OIO in November 2006.

NES will ratify their profiles and other deliverables in the first quorter of 2007 and the first pilot projects are expected to appear in Denmark and Iceland in March 2007.