Online OIOUBL Documentation
Introduktion to OIOUBLIntroduction to Statute.Statute about OIOUBL electronic Invoice with initial date Monday 12 th., April 2010. The Statute can be found on Statute (PDF) OIOUBL Statute covers a total of four OIOUBL documents relating to Invoice
There are two profiles which public authorities must support under this Statute: Procurement-BilSim and NES Profile 5 BasicBilling. The NES Profile 5 BasicBilling profile consists of the documents, invoice and CreditNote. This is the profile that are most equal to the present format of OIOXML electronic bill. The NES Profile 5, is required in cases where the supplier is sending an Invoice/CreditNote and not technically able to receive an ApplicationResponse. The Procurement-BilSim profile consists of the documents, Invoice, CreditNote, Reminder and ApplicationResponse. If both the public authority and the supplier support the Procurement-BilSim profile this must be used. Introduction to OIOUBL 2.02.National IT and Telecom Agency have updated OIOUBL in connection with the update of the statute concerning electronic Invoice. OIOUBL version 2.02 which is now the current version is described in Danish only. Everything you see on this page is therefore OIOUBL version 2.01. OIOUBL contains specifications for all required business document types supporting the business process from catalogue to invoice. The package contains both informative and normative descriptions as well as examples of the use of these business documents. All businesses, including small businesses and small public institutions, are expected to support the basic procurement process (see also the Profiles section). This involves the following business documents:
The OIOUBL package also specifies a series of additional business document types that support more advanced ordering processes:
About OIOUBL in generalOIOUBL is a customization for Danish business requirements of the international UBL 2.0 standard from OASIS (the Organization for the Advancement of Structured Information Standards). The business documents that are included in OIOUBL constitute a subset of the UBL 2.0 documents and have been selected in collaboration with the Danish Sector Standardization Committee for eBusiness. The primary advantage of OIOUBL is the standardization of business documents for different uses. And because UBL 2.0 is a flexible, international standard that supports many business requirements, documents can be exchanged across national borders. Another advantage of OIOUBL is the possibility of developing fully automated procurement processes in which the electronic documents are validated and matched automatically. This creates financial savings though the cost of human resources normally required for clerical processing. The relationship between OIOUBL and UBL 2.0As mentioned above, OIOUBL is a subset of UBL 2.0. This means that UBL 2.0 contains a number of business documents in addition to the ones in OIOUBL. For example international transportation documents. These additional business documents are fully compatible with and may be used with the OIOUBL documents. However, no Danish language instructions or guidelines are provided for these documents. The OIOUBL specifications are based directly upon the UBL 2.0 XML schemas. No additional XML schemas have been developed or are required for OIOUBL. It should be noted that, for business reasons, a few elements from the UBL 2.0 schemas have been excluded in the OIOUBL customization. These elements have been judged as not applicable in Denmark, either because of specific Danish legislation, or because they are of not relevant in a Danish context. These omitted elements will not be present in the OIOUBL specifications, and if these fields were to be used they will not pass the document validator published by the National IT and Telecom Agency. The Common Class LibraryThe backbone of OIOUBL is the Common Class Library (Ref G30). This Library contains general descriptions of all information elements that exist within the different business documents. The philosophy behind the Library is to achieve the highest reusability for the different elements. Classes that are used the same way in all business documents are described in the Common Class Library (Ref. G30). The types that the information elements in each class refer to are described in the Datatypes guideline (ref. G29). Document guidelinesFor each of the 15 business documents, from catalogue to statement of account, a document guideline has been prepared describing the document's overall class. This class will contain elements and classes from the Class Library . If any elements and classes are used differently from the way described in the Common Class Library, they will be specified in the relevant document guideline. Common guidelinesA series of guidelines describe the use of certain classes across different types of business documents. These classes have a particular guideline because they are either complex in their use and require further explanation, or they are used differently in the individual business documents and profiles (that is, they are context dependent). The following sections identify the common classes and information elements that are particularly important for understanding OIOUBL. PartyFor each OIOUBL business document two mandatory parties have been defined, namely the party sending the document, and the party receiving it. Apart from these a document may contain other parties that are relevant for the processing of the document contents. The parties have different titles in different documents. The different titles express the different roles they play in the business process. For example, the customer in an order is called the "BuyerCustomerParty" and the debtor in an invoice is called the "AccountingCustomerParty". Both parties are of the "CustomerParty" type, because "Buyer" and "Accounting" express the role of the customer. A party must also be assigned a unique identifier in addition to any identification as a legal entity. For example, a party may use an EAN number for its identification, and a CVR number for its specification as a legal entity. Thus different identification schemes may be used for the same legal entity. EndpointIDEndpointID is a unique identification of the destination where the electronic document is to be delivered. An EndpointID must be specified for the two parties exchanging the document, and for other parties that are relevant within the document's context. An EndpointID must be recognizable by the established address register for the receiver to be uniquely identifiable. The National IT and Telecom Agency will in the fall of 2007 establish a common address register across public sectors (UDDI), which can contain endpoints from private companies. For more details see: www.softwareborsen.dk/projekter/softwarecenter/serviceorienteret-infrastruktur. Code listsAnother significant part of OIOUBL is code lists. Code lists are specifically used to restrict the values allowed for an information element. Code lists are widely used in UBL 2.0 for managing a range of fixed value sets for a given information element, such as currency or country codes. One of the aims of OIOUBL is to achieve the fully automated processing of exchanged data. Code lists allow the possibility to set up checks in various IT systems that only accept codes within the allowed value sets, and thus reduce the need for manual validation of data. If more than one value can be used in a code or Id field a code list is specified. OIOUBL operates with four types of code:
For the Danish OIOUBL customization a series of code lists has been prepared. For example TaxSchemeID (Ref. K18), is used for specifying the required values for tax scheme codes. In all the situations where the use of publicly known code lists or OIOUBL code lists has been defined, the standard code list name must be specified when using the code. This name is used to differentiate between codes belonging to the OIOUBL standard and any bilaterally agreed codes. In certain situations, the option is given to use several different qualifiers for one information element. For example, when entering the identification of a partner and endpoints. Here, e.g. a CVR, SE or DUNS number may be specified. In these cases it is specified which qualifier apply to the code list. ProfilesWithin OIOUBL the use of profiles is encouraged with the intention that both the sender and receiver of the business documents specify which documents they support and expect to receive in a given process. A profile is an overall description of one or more interconnected business processes, each of which may exchange one or more document types. A profile expresses an agreement on the exchange of documents, covering:
The profiles within OIOUBL have been developed based on the overall business model for UBL 2.0. The profiles has been worked out on the basis of a logical delimitation of which business documents are naturally connected, and which should be supportet at a given level. The different levels in the profiles are made, so that the electronic business process can support both the simple and the more advanced business process. There are three so called minimum profiles in OIOUBL, that constitutes the minimum demand for the public customers and their supplers who wish to use OIOUBL. The three profies include simple invoicing (Procurement BillSim), a simple order to invoice flow (Procurement OrdSimR-BillSim) and basic catalogue exchange (Catalogue CatBas). Additionally there is a minimum profile that the public organization must offer to support, if their suppliers wish to receive catalogue requests electronically (Catalogue CatSim) In the Common Profile Guideline (Ref. G26) different profiles and their uses are described in further detail. Scenario descriptionsAnother important element of OIOUBL are the scenario packages. Their purpose is to illustrate the procurement process from a business perspective and to show how these processes can be implemented using OIOUBL documents. The experiences gained during the development of OIOUBL demonstrated that it is too complicated to describe procurement as one single process. There are simply too many possible combinations available for the various document types. The solution to this has been to describe some of these possibilities as scenarios. Scenarios can be considered descriptions of the expected reactions of sender and receiver in the specific situations. The scenario packages complement the other elements in the OIOUBL package but unlike many of these, the scenarios are not normative. The introduction to the six scenario descriptions (Ref. S01) identifies the six scenario packages prepared for OIOUBL, covering the following areas:
|