A summary on CCTS and UBL

Please note that clarity is my main focus rather than correctness. For most correct information, please refer to the specifications themselves.

What is CCTS?

Earlier electronic document standards focused on static document definitions, which were inflexible for adapting different requirements. The leading effort for this problem came from the UN/CEFACT Core Component Technology Specification (CCTS) in the early 2000s. The idea behind UN/CEFACT CCTS is to provide re-usable building blocks for business documents, which are available in a common repository. This increases the possibility of discovering and re-using similar document artifacts consumed in different environments for sustaining data interoperability. Furthermore, it constitutes an agreement base for documents through a syntax independent conceptual model.

CCTS can be employed wherever data is being defined, stored, used, shared or exchanged. The objective of the CCTS approach is to identify, capture and maximize the re-use of business information to support and enhance information interoperability.

Technical Aspects of CCTS

The foundational concept of this specification is the core component(CC). Core components can be used for all aspects of data and information modelling and exchange. Using following 3 types of CC and core data types, documents compliant with CCTS can be constructed:

Aggregate CC(ACC): A collection of related pieces of information that together convey a distinct meaning, independent of any business context. Ex: Address Line, Address, Contact, Contract, Location, Period etc.
Association CC(ASCC): Defines a role between ACCs. Example: "Contract" contains an ASCC named "Effective" and the type of this ASCC is "Period". Its meaning in a business is: "Contract is effective in a period"
Basic CC(BCC): Represents a property of an ACC. Example: "Contract" contains a BCC named "ContractId" and the type of this BCC is "Identifier". Its meaning in a business is "Contract has a ContractId"

What is UBL?

UBL is the first standard implementation of the CCTS and approved as an OASIS Standard. UBL defines a common XML library of business documents as well as reusable data components from which an unlimited number of other documents can be constructed.

Core components of CCTS act as conceptual models defining Business Information Entities (BIEs).BIEs may specify a restricted form of its underlying CC and have the same types as expected. Aggregated BIEs(ABIE), Association BIE(ASBIE) and Basic BIE(BBIE) are the BIE types used in UBL. They are the implementations of of ACC, ASCC and BCC, respectively.

UBL also presents the Core Data Types of the CCTS with the name "Unqualified Data Types". These data types are used to create a number of common building blocks(ABIEs). These building blocks are then used to create a number of defined documents. The same building blocks are used in different documents frequently. These data types, ABIEs and documents are what UBL presents to the community through xml, xsd, xsdrt, xls etc formats. The already available documents are in these groups: General Business, Sourcing, Ordering, Billing, Payment, Transport Services etc.

The extensibility of UBL stems from these reusable data components. When a new document is required, UBL allows developers to use available BBIEs, ASBIEs and ABIEs or creating new ones based on the available data types.

How is UBL designed in terms of generality?

The possibility of having different document structures for the same document for each different context and enterprise. This is a big problem (especially in a larger environment) for UBL. UBL committee opted not to use different versions of the same document because of the following reasons:

Developing and maintaining multiple versions of common business documents is a major duplication of effort.
Creating and maintaining multiple adapters to enable trading relationships across domain boundaries is an even greater effort.
The existence of multiple XML formats makes it much harder to integrate XML business messages with back-office systems.
The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find.

Hence, UBL does not offer maximal optimization since optimization requires industry-specific data formats and versions for the documents. Making use of single document structure is the UBL-way although there are differences in the real world.

In UBL, to maintain the universality, documents are extended as much as possible without any duplication in the content. I want to illustrate this with the famous example: Invoice. According to Wikipedia, a typical invoice should contain 13 fields. However, UBL's Invoice has 49 direct fields most of which has inner fields; so the total number of fields is definitely more than 200 (Moreover, recursive structures exist in the Invoice schema so the number can be increasd to infinity). UBL restricts that 6 of these direct fields are required. These fields are Identifier, Issue Date, Supplier and Customer parties... etc. Rest of the fields are optional and used by a various proportions of businesses worldwide.

Is refinement possible for UBL?

UBL supports extensions and refinements.The real power of UBL comes into play through these extensions and refinements. Anyone can make use of UBL for any purpose through extensions.

References

February 2013