Online OIOUBL Dokumentation

Reading guideline

This page presents some information that is useful for understanding the online documentation of the OIOUBL standard.


These pages should be seen as the normative description of the classes described. In case of any conflict, the most specific description will always apply. For example, the description on the lines of a specific element takes precedence of the description at document level. Hence, the descriptions at document level are default values for the lines. The examples in the document and related common guidelines should be seen as descriptive. The guideline text takes precedence of the figures. The actual specification of a class is composed of:
  • A figure showing the class elements that are included in OIOUBL.
  • A text specification of the class.
  • A list of the fields that are included in the class with a corresponding table of key data such as definitions, names, references, and business rules for each of the class fields.
  • A list of the sub-classes that are included in the class with a corresponding table of key data such as definitions, names, references, and business rules for the sub-classes of the class.
  • An example of the class
  • A list of the UBL elements that from a business perspective make no sense in the specific context.

Figure definitions

In the class specifications, the class is shown as schema documentation. Figure Description

Term definitions

In this specification, the following terms will be used in the tables:
Term Explanation
UBL name The name that is found in the UBL 2.0 schemas
DK-name The name in Danish
Use Describes the cardinality, i.e. the rule describing how may instances of the business information entity are allowed:
  • [1] specifies that one and only one instance is allowed.
  • [0..1] means that the business information entity is optional.
  • [0..n] means that null to infinity instances may occur.
  • [1..n] means that no less than one instance to an infinite number of instances may occur.
Alternative term Specifies a term which is also used to describe the business information entity.
Used Determines whether the receiver should be expected to be able to decode the described business information, if it is attached. Information that is not used may still, however, be used upon bilateral agreement.
Business rule Describes the rules that are attached to the business information entity. Business rules are normative, and will be part of the validation of the document in question.
Recommended Specifies that common practice requires the described business information entity to be attached. This is a non-normative guide to the use of the business information entity.
Allowed values: Describes the value set that the business information entity should conform with.
Codelist Refers to the codelist that the value set should be found in.
Class A structure of coherent business information.

How to fill in OIOUBL document instances

  An XML document must follow the related UBL schema, and conform to the rules of this guideline. The instances follow the W3C XML specifications, which means that, unless otherwise stated, the normal XML rules rules apply. It is therefore recommended that an xml encoder is used for reading the documents.


A Namespace is a semantic space in which names are unique and attached to a specific interpretation. Namespaces often occur as libraries, and may be referenced via an alias-variable. The expression: <… xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" …> means that elements with the prefix "cac" (alias variable) belongs to the "…CommomAggregateComponents-2" namespace. The namespace that is referenced by the actual document is indicated by "xmlns =...", i.e. without an alias variable. It is recommended to use the alias variables that are specified in UBL, but this is not a requirement. For an OIOUBL document instance to be validated the following namespaces must be specified:
Alias variable Namespace
  The target namespace of the document in question
cac urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2
ccts urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-2
cbc urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2
sdt urn:oasis:names:specification:ubl:schema:xsd:SpecializedDatatypes-2
udt urn:un:unece:uncefact:data:specification:UnqualifiedDataTypesSchemaModule:2
ext urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2


Comments may be used in document instances to facilitate any manual processing of the document. This is particularly relevant during the introduction phase of new systems that use OIOUBL. For those who wish to formalize these comments, we recommend the Dublin-Core metadata definitions, see "". The following terms are used in the examples of the scenario descriptions [S01-S07] :
DC-Term Description Example
Title Describes the title of the document instance BASPRO_01_01_00_Invoice_v2p0.xml
Replaces Reference to the preceding instance BASPRO_01_01_00_Invoice_v0p1.xml
Publisher Describes who is responsible for the document instance. "IT og Telestyrelsen"
Creator Describes the person or the system that created the instance. "OIOERP v 1.0.2 release 34"
Created Date (and possibly time) of the creation of the document. 2006-09-08
Modified Date (and possibly time) when the document was last modified. 2006-09-08
Issued Date (and possibly time) when it was issued. 2006-09-08
ConformsTo Description of the context that it belongs to. OIOUBL_ScenarioPackage_BASPRO
Description General description "This document is produced as part of the OIOUBL Basic procurement scenario package"
Rights Any copyrights that apply to the instance. "It can be used following the Common Creative License"
Only use meta data that you consider applicable, and only enter valid data. From the above list we particularly recommend using the "Creator" term, as this may ease the troubleshooting at the receiver's system. Comments should be specified within the root element of the document.

Process instructions

Process instructions are instructions that are not covered by the OIOUBL standard, but which may be used for controlling other logics. For example, when specifying that an instance is used for test purposes. A process instruction is specified by "<?name ... ?>" and may contain attributes as shown in the example below. Process instructions should be specified within the root element of the document.
description= "apply your comment here"

Relations to instances of other customizations

An instance is specified as being OIOUBL by entering ”CustomizationID” as ”OIOUBL-2.0”. OIOUBL instances are built upon UBL 2.0, and may therefore be interpreted directly by UBL 2.0 readers. Instances from other UBL 2.0-customizations can be read directly by OIOUBL readers by changing the "CustomizationID", provided the instance conforms to the requirements of this guideline.

Code example

Code examples are available in the scenario descriptions [S01-S07]