This release is protected by Creative Commons License, Naming 2.5

Similar documents
This release is protected by Creative Commons License, Naming 2.5

Information Model Architecture. Version 1.0

Office of the Government Chief Information Officer XML SCHEMA DESIGN AND MANAGEMENT GUIDE PART I: OVERVIEW [G55-1]

Guideline Data Format. Version 2.0

This is a preview - click here to buy the full publication TECHNICAL REPORT. Part 101: General guidelines

INTERNATIONAL STANDARD

Purchase Order & Invoicing standards for Swiss Re Denmark Services A/S

TQUK Level 3 Diploma in Design Engineer Construct! The Digital Built Environment (RQF) Purpose Statement Qualification Number: 603/1993/8

ISO/IEC INTERNATIONAL STANDARD. Information technology Multimedia content description interface Part 5: Multimedia description schemes

Business Interoperability Specification

Buyer user guide Contract Management. Table of Contents

BWI Group. Supplier EDI Specification. Remittance Advice Message REMADV. EDIFACT REMADV D.99.B BWI Version 1.0

Framework for building information modelling (BIM) guidance

Welcome to the Live Webinar #9: Understanding UBL and CII

INTERNATIONAL STANDARD

BRP Inc. ELECTRONIC DATA INTERCHANGE (EDI) IMPLEMENTATION GUIDE 865 VERSION 4010 FROM SUPPLIER. Document version 1.5

Welcome to the Vale Vendor Portal Guide

COLES B2B - ORDERS Purchase order message

COLES DSD INVOIC Invoice message

Proposed Revisions to ebxml Technical Architecture Specification v ebxml Business Process Project Team

DIGITAL CENTRAL ASIA SOUTH ASIA (CASA) PROGRAM. Transport and ICT Global Practice World Bank

HACHETTE BOOK GROUP USA 850 Purchase Order VERSION 4010 IMPLEMENTATION GUIDE

E-payment. Service description. September 2016

Basware Portal for Receiving Basware Commerce Network

19_Amend Supplier Contract

APERAK. Application error and acknowledgement message. Edition 2012

E-payment. Service description

ISO/IEC INTERNATIONAL STANDARD. Conformity assessment Supplier's declaration of conformity Part 1: General requirements

Munis EFT Processing. Procedural Documentation. For more information, visit

Corporate-to-Bank Guidelines

860 Purchase Order Change Request (Buyer Initiated) X12 Version Version: 2.0

ISO/IEC INTERNATIONAL STANDARD

A Common Identification System for The Electricity Industry. The ETSO Identification Coding Scheme EIC

COLES B2B INVOIC Invoice message

ITU Asia-Pacific Centres of Excellence Training on Conformity and Interoperability. Session 2: Conformity Assessment Principles

INTERNATIONAL STANDARD

e-invoicing on the e-prior Supplier Portal

ISO/IEC Information technology Security techniques Code of practice for information security controls

ISO/TS TECHNICAL SPECIFICATION

GENRAL. General purpose message. Edition 2016

INTERNATIONAL TELECOMMUNICATION UNION

ISO/IEC INTERNATIONAL STANDARD

Preface Entity Identifiers Directory Publication BIC Usage...7

SUBJECT: PRESTO operating agreement renewal update. Committee of the Whole. Transit Department. Recommendation: Purpose: Page 1 of Report TR-01-17

"Charting the Course... ITIL 2011 Managing Across the Lifecycle ( MALC ) Course Summary

UBL Library Content Methodology

E-invoice. Service Description

TERMS AND CONDITIONS

Redistributions of documents, or parts of documents, must retain the FISWG cover page containing the disclaimer.

(The mandatory fields are marked with an * asterix)

EDI IMPLEMENTATION GUIDELINES KANBAN ODETTE V2. EDI COMPETENCE CENTER KANBANV2.doc

INTERNATIONAL STANDARD

Conformance Requirements Guideline Version 0.1

4.3 Case Study #09: National ehealth network in Denmark

850 Purchase Order. Version: X12

INTERNATIONAL STANDARD

E-invoicing Standard Solution

Management of Metadata and XML Schemas for e-justice. Pim Keizer Pim van der Eijk

Liquor - Direct to Store Purchase order message - ORDERS D01B

Adobe - EDIFACT SLSRPT D93.A

FINSTA. Financial statement of an account message. Edition 2008

Purchase Order Change Request - Buyer Initiated

Creative Business Cup Privacy Policy

ISO TC46/SC4/WG7 N ISO Information and documentation - Directories of libraries and related organizations

ISO/IEC Information technology Software asset management. Part 2: Software identification tag

EDI 860 Mapping. Instructions. Version 1.0 September 16, 2016

CURRICULUM The Architectural Technology and Construction. programme

JR Simplot Corporate 810 Invoice

CORRECTING INVOICE CONFIRMATION. Message. Version 1.0 EANCOM 97/EDIFACT D.96A

People. Processes. Integrating Globally.

Software engineering Guidelines for the application of ISO 9001:2008 to computer software

This is a preview - click here to buy the full publication PUBLICLY AVAILABLE SPECIFICATION. Pre-Standard

ISO INTERNATIONAL STANDARD

daa isupplier User Guide

Oracle FLEXCUBE Direct Banking

ODF and OOXML in Denmark

Market Surveillance Action Plan

Columbus delivers 52% growth in revenue

ACCAB. Accreditation Commission For Conformity Assessment Bodies

Pre-Standard PUBLICLY AVAILABLE SPECIFICATION IEC PAS Batch control. Part 3: General and site recipe models and representation

AUTACK. Secure authentication and acknowledgement message. Edition 2016

JR Simplot Food Group Grocery Products Purchase Order. UCS/V4010/875: 875 Grocery Products Purchase Order Version: 1.0

ISO/TS TECHNICAL SPECIFICATION

Identity fraud. Good advice on how to avoid being cheated by a buyer with a false identity.

ISO/IEC INTERNATIONAL STANDARD

Proposed Revisions to ebxml Technical. Architecture Specification v1.04

The Bank of Russia Standard FINANCIAL MESSAGES IN THE NPS

INTERNATIONAL STANDARD

APERAK. Application error and acknowledgement message. Edition 2016

This document is a preview generated by EVS

Please note: Only the original curriculum in Danish language has legal validity in matters of discrepancy. CURRICULUM

Only the original curriculum in Danish language has legal validity in matters of discrepancy

ISO/IEC INTERNATIONAL STANDARD. Information technology Security techniques Information security risk management

850 - Purchase Order Author: DOT FOODS, INC. Publication: September 24, 2008

INTERNATIONAL TELECOMMUNICATION UNION 4%,%-!4)# 3%26)#%3 4%2-).!, %15)0-%.43!.$ 02/4/#/,3 &/2 4%,%-!4)# 3%26)#%3

AUTACK. Secure authentication and acknowledgement message. Edition 2012

ISO/IEC TR TECHNICAL REPORT. Software and systems engineering Life cycle management Guidelines for process description

ISO 2146 INTERNATIONAL STANDARD. Information and documentation Registry services for libraries and related organizations

IBM TRIRIGA Version Procurement Management User Guide

THE COMDIS MESSAGE EANCOM97/EDIFACT D.96A. agreed-upon by EDI Working Group of ECR Poland. Issue 1.0, April 2011

Transcription:

OIOUBL Intro UBL 2.0 Introduction OIOUBL Introduktion I01 Version 1.1 This release is protected by Creative Commons License, Naming 2.5

Colophon Contact: Danish National IT and Telecom Agency E-mail: oioubl@itst.dk OIOUBL Version 2.01 April 2007 Ministry of Science, Technology and Innovation National IT and Telecom Agency Data Standardization Office Holsteinsgade 63 DK-2100 Copenhagen Ø Phone +45 3545 0000 Fax +45 3545 0010 http://www.itst.dk itst@itst.dk Copyrights for this release are in accordance with Creative Common(s??), Naming 2.5: Permission is granted to: produce processed works based on this document reproduce and make the document available to the public use the document for commercial purposes provided that the Danish National IT & Telecom Agency be clearly referenced as the source of this release. Further information about these rights is available at http://creativecommons.org/licenses/by/2.5/deed.da. OIOUBL Introduction Version 1.1 Page 2

Contents 1. Introduction...4 1.1 Purpose and target audience...4 1.2 How to use this paper...4 1.3 Prerequisites...4 1.4 Use of references...5 2. Introduction to OIOUBL...6 2.1 About OIOUBL in general...6 2.1.1 The relationship between OIOUBL and UBL 2.0...7 2.1.2 OIOUBL and OIOXML Electronic Invoice...7 2.1.3 OIOUBL version 2.01...7 2.1.4 OIOUBL and North European Subset...7 3. Contents of the OIOUBL package...8 3.1 The Common Class Library...8 3.2 Document guidelines...8 3.3 Common guidelines...8 3.3.1 Party...8 3.3.2 EndpointID...9 3.4 Code lists...9 3.5 Profiles...9 3.6 Scenario descriptions...10 4.4. Credentials...12

1. Introduction This paper provides an introduction to the complete package describing the OIOUBL common standard for e-business documents. It provides a general introduction to the complete OIOUBL package, as well as an overall description of the separate elements found in the complete package. A complete overview of all business documents contained in the OIOUBL package is included as an attachment to this introduction (Ref. I02). For specifications of the different sub-elements in the package, please refer to the Introduction to OIOUBL Procurement Scenarios (Ref S01), OIOUBL Guideline Datatypes (Ref G29) and OIOUBL Guideline Profiles (Ref G26). 1.1 Purpose and target audience This paper is intended to give an overall understanding of the content and relationship between the different OIOUBL business documents. The target audience is primarily technical and domain specialists responsible for implementing e- procurement, as well as developers and project managers responsible for implementing ERP systems, work flow systems, and other related systems in the Danish market. The document may also be used as an non-technical overview of the OIOUBL package contents. 1.2 How to use this paper All business documents in OIOUBL were developed after comprehensive consultation among relevant contributors, both within the public and the private sector. References to these contributors may be obtained from the National IT and Telecom Agency. This introduction is divided into the following sections: General Introduction to OIOUBL Contents of OIOUBL including: o OIOUBL Class library o OIOUBL Guidelines o OIOUBL Code lists o OIOUBL Profiles o OIOUBL Scenario descriptions 1.3 Prerequisites Prior knowledge of the use of standardized e-business documents based on XML. OIOUBL Introduction Version 1.1 Page 4

1.4 Use of references When other documents are referenced in this, and other OIOUBL publications, reference is made to the document name, and if available its reference number. Both are available in the OIO document list (I02).

2. Introduction to OIOUBL 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: -Catalogue Request -Catalogue -Catalogue Deletion -Catalogue Item Specification Update -Catalogue Pricing Update -Order -Order Response Simple -Order Cancellation -Invoice -Credit Note -Reminder -Application Response The OIOUBL package also specifies a series of additional business document types that support more advanced ordering processes: -Order Change -Order Response -Statement of Account These business documents will be formally described in the Extended OIOUBL document package, which is due for release in May 2008, but out of consideration for the organizations who from the beginning wish to support the complex purchase process, the documents are included in this package. 2.1 About OIOUBL in general OIOUBL 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. OIOUBL Introduction Version 1.1 Page 6

2.1.1 The relationship between OIOUBL and UBL 2.0 As 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. 2.1.2 OIOUBL and OIOXML Electronic Invoice The Invoice within OIOUBL has the same potential uses as the OIOXML electronic invoice, as well as quite a few more. In fact, the Invoice document format in OIOUBL is an extension of the OIOXML electronic invoice. This is because OIOUBL is based on UBL 2.0, a more recent version than the UBL 0.7 used for the OIOXML electronic invoice. The National IT and Telecom Agency will develop tools for mapping between the UBL versions 0.7 and 2.0, just as we already have tools for mapping between UBL 0.7 and 1.0. 2.1.3 OIOUBL version 2.01 OIOUBL 2.01 is a revision of the OIOUBL version that were released on November 13th 2006. It contains a number of changes that were necessary to be compatible with the North European Subset of UBL (NES), which were published April 2007 (See section 2.1.4). Aditionally the revision has been used to correct some errors and shortcomings that were located after the release of OIOUBL in November, which the National IT and Telecom Agency assessed were desirable to correct while the implementation of OIOUBL was still in the making. A list of the changes in OIOUBL 2.01 has been produced, see reference I04. 2.1.4 OIOUBL and North European Subset OIOUBL has been developed in coordination with other Nordic countries and the UK under a collaboration called the "North European Subset" (NES), as an initiative where the involved countries work together on content and use of the electronic business documents based on the UBL 2.0 standard. The intention is for OIOUBL to interact with the guidelines and profiles that exist within the North European Subset. There are some differences between the two implementations which has been documented (See reference I03). For further information on the NES, please refer to www.oio.dk/ehandel (under International standardisering ).

3. Contents of the OIOUBL package The OIOUBL package comprises of a series of components, as described in the following sections. The material can be found in both a danish and an english version. A online guide to the whole package can be found on www.oioubl.info. 3.1 The Common Class Library The 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). 3.2 Document guidelines For 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. 3.3 Common guidelines A 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. 3.3.1 Party For 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. OIOUBL Introduction Version 1.1 Page 8

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. 3.3.2 EndpointID EndpointID 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. 3.4 Code lists Another 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: l Static codes, which are embedded in the standard. l Publicly known codes which can be updated, e. g. ISO 4217. l OIOUBL defined codes, which can be updated, e. g. TaxSchemeID l Bilaterally agreed codes 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. 3.5 Profiles Within 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: which role a Party plays in the business process which documents a given Party can send and/or receive in the business process which documents a given Party must be able to send and/or receive. 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. 3.6 Scenario descriptions Another 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: -Basic Procurement Process (Ref. S02) -Advanced Ordering (Ref. S03) -Complex Delivery (Ref. S04) -Procurement in Complex Organizations (Ref. S05) -Complex Payment Processes (Ref. S06) OIOUBL Introduction Version 1.1 Page 10

-Catalogue Exchange (Ref. S07) A range of XML document examples have been also prepared for the different scenario descriptions, as well as the different value sets in each scenario.

4.4. Credentials The following has contributed to the development of the OIOUBL 2.01 package: Peter L. Borresen, IT- og Telestyrelsen Helle Schade-Sørensen IT- og Telestyrelsen Joachim Florentz Boye, IT og Telestyrelsen Alan Lemming, WM-data Danmark A/S Sven Rasmussen, WM-data Danmark A/S Jan Eliasen, WM-data Danmark A/S Charlotte Dahl Skovhus, mysupply ApS Finn Christensen, mysupply ApS Flemming Beltoft, mysupply ApS Jesper Henckel, KMD With professional contribution and input from a long range of private and public participants, including the danish UBL local committee ehandelsgruppen under the danish Sector Standardization Committee for ebusiness. OIOUBL Introduction Version 1.1 Page 12