acronym: peppol grant agreement number: 224974 title: pan … · receiver participants in any...

Guideline

Acronym: PEPPOL

Grant Agreement number: 224974

Title: Pan-European Public Procurement Online

PEPPOL Transport Infrastructure Policy for using Identifiers

Version: 1.0

Authors: Gert Sylvest, NITA/Avanada Heveen Kejiou, NITA/Software Teams Jens Jakob Andersen, NITA Klaus Vilstrup Pedersen, DIFI Nisha Appanah, NITA/Software Teams (editor)

Project co-funded by the European Commission within the ICT Policy Support Programme

Dissemination Level

P Public X

C Confidential, only for members of the consortium and the Commission Services

PEPPOL Transport Infrastructure

Policy for using Identifiers

2

Revision History

Version Date Author Organisation Description

1.0 20100215 Nisha

Appanah

NITA/Software

Teams

First version (pending EC approval)

Statement of originality

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of

others has been made through appropriate citation, quotation or both.

Statement of copyright

This deliverable is released under the terms of the Creative Commons Licence accessed

through the following link: http://creativecommons.org/licenses/by/3.0/.

In short, it is free to

Share — to copy, distribute and transmit the work

Remix — to adapt the work

Under the following conditions

Attribution — You must attribute the work in the manner specified by the author or licensor

(but not in any way that suggests that they endorse you or your use of the work).



3

Contributors

Organisations

DIFI (Direktoratet for forvaltning og IKT)1, Norway, www.difi.no

NITA (IT- og Telestyrelsen)2, Denmark, www.itst.dk

Persons

Gert Sylvest, NITA/Avanada

Heveen Kejiou, NITA/Software Teams Jens Jakob Andersen, NITA

Klaus Vilstrup Pedersen, DIFI

Nisha Appanah, NITA/Software Teams (editor)

Tim McGrath, Document Engineering Services

Sven Rostgaard Rasmssen, NITA

Sverre Bauck , DIFI

Jostein Frømyr, EDIsys

1 English: Agency for Public Management and eGovernment

2 English: National IT- and Telecom Agency

http://www.difi.no/

http://www.itst.dk/



4

Table of Content

1 Introduction .................................................................................................................................... 5

1.1 Objective ................................................................................................................................. 5 1.2 Scope ....................................................................................................................................... 5

2 Policy for PEPPOL Party Identification ......................................................................................... 8 2.1 Format ..................................................................................................................................... 8 2.2 Issuing Agency Code Values .................................................................................................. 9

3 Policy on Identifying Services supported by PEPPOL ................................................................ 15 3.1 Format ................................................................................................................................... 15 3.2 Document ID Values ............................................................................................................. 16

4 Governance ................................................................................................................................... 19

5 References .................................................................................................................................... 20



5

1 Introduction

1.1 Objective

Identifiers are information elements that establish the identity of objects, such as organizations,

products, places, etc. The PEPPOL project uses many identifiers in both its transport infrastructure

and within the documents exchanged across that infrastructure. Two of the significant identifiers are

those for Parties (organizations, persons, etc.) and Services (business profiles, document types, etc).

These are the ―who‖ and the ―what‖ of PEPPOL business exchanges.

This document outlines the policy for using the correct identifiers specifically for these two areas but

it also introduces principles for any identifiers used in the PEPPOL environment. Implementers

failing to adhere to these policies seriously jeopardize the interoperability of the information being

exchanged. This policy should form a requirement of any PEPPOL participation agreements.

1.2 Scope

This specification relates to the Technical Transport Layer i.e. BusDox specifications. The BusDox

specifications can be used in many interoperability settings. In the PEPPOL context, it provides

transport for procurement documents as specified in the PEPPOL Profiles.

Firstly, the policy of a federated scheme for identifying Parties.

Parties in the BusDox infrastructure play the role of Participants. There are sender and

receiver Participants in any exchange, but the BusDox Service Metadata only publishes

services defined for the receiver Participant. The technical name for this identifier in

BusDox is the Participant Identifier (or isoiec_actorid_15459)3.

3 PEPPOL Identifier Schemes defines a set of identifier schemes that will be used in the context of the

PEPPOL infrastructure (http://www.peppol.eu/work_in_progress/wp8-



6

Within each business document these are also Parties taking on business roles such as

customer and supplier, etc. Clearly there may be relationships between these Parties and the

Participant Identifier. Sometimes the Supplier Party is the receiver Participant for an Order

document. Another example is that an Invoice may contain an identifier for EndpointID

equates to the receiver Participant in the SMP. But neither of these are a reliable rule. BII

profiles do not (deliberately) include any ‗envelope‘ information linking the document

content to the transport infrastructure. They can generally be considered ignorant of each

other.

So whilst there is a relationship between these various Parties, we have no policy on how this

should be done. This policy relates to the common use of different identification schemes to

identify the appropriate Party within the context required. In other words, they may have

different values but the way we define should be consistent.

Many schemes already exist for identifying Parties. PEPPOL has no intention of developing

another. Our strategy is to recognize a range of different identification schemes and provide a

code list of those recognized schemes based on international standards.

Secondly, the policy for identifying Documents and Services used in PEPPOL business processes.

The BusDox infrastructure requires a Participant sending a document to identify both the

receiving Participant and the service that will receive the document. They (or their Access

Point provider) achieve this by searching the Service Metadata Locator to find the relevant

Service Metadata Publisher that can identify the endpoint address (NB. not the same as the

Endpoint ID in the business document) within the receiving Participant‘s access point. This

endpoint address is the service address where the document will be delivered. Therefore it is

important to define precisely what documents and services can be handled by the receiving

Participant.

The diagram below shows the relationship of these information elements.

Solutions%20architecture%2C%20design%20and%20validation/specifications/v1-0-specifications/peppol-

identifier-schemes/at_download/file)).



7

Note: The identifier used in BusDox (partner463) need not be the same as any Party

identified in the Order itself.

Because PEPPOL implements the CEN BII recommendations these services are identified by

a combination of their Profile, Collaboration, Transaction, Document type and syntax

(possibly with versions thereof). It is also feasible that there may be customizations of these

for specific trading communities. The technical name for this identifier in BusDox is the

Document Identifier (or cenbii_docid_fci).

An example might be:

urn:oasis:names:specification:ubl:schema:xsd:Order-

2::Order##urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0::2.1

:- denotes

Root Namespace Version

urn:oasis:names:specification:ubl:schema:xsd:Order-2 ver1.0

Document element local name

Order

Customization ID

urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0

Version

2.1

The policy for how these service identifiers are defined needs to be formalized, initially by

PEPPOL (WP8) but ultimately for anyone implementing BII within a service oriented

architecture.



8

2 Policy for PEPPOL Party Identification

The following aspects are addressed in this policy:

1. The PEPPOL code list of Party Identification schemes used in BII documents.

CEN BII and its code lists are documented in:

http://www.cen.eu/cwa/bii/specs/Profiles/Guidelines/BII_CodeLists-v1.00.xls

2. The PEPPOL code list of Participant Identification format schemes used in BusDox metadata.

The PEPPOL BusDox transport Infrastructure and its supporting parts are documented in:

http://www.peppol.eu/work_in_progress/wp8-

Solutions%20architecture%2C%20design%20and%20validation/specifications/v1-0-

specifications

PEPPOL will not implement its own scheme for identifying Parties. Instead we will support a

federated system for uniquely identifying parties following the ISO 15459 format scheme for unique

identifiers. This requires defining a controlled set of Issuing Agency Codes4 for identification

schemes (also known as party identifier types5 or Identification code qualifier

6 or International Code

Designators7 or Party ID Type

8) required by PEPPOL Pilots.

Each PEPPOL Party identifier to be used in the federated system is then a combination of the Issuing

Agency Code and the value given by the Issuing Agency. For BusDox, it will be part of the

PEPPOL SMP Provider agreement that SMP Providers have suitable governance of their

identification schemes when they enter, update and delete information on their SMP. For BII

documents, each PEPPOL Participant will be responsible for using the appropriate PEPPOL Party

Identifier.

This section defines the policies for the formatting and the population of values for Party Identifiers

in federation used by PEPPOL. This policy covers the use of the UBL Party Identifier/ID and

Party/EndpointID. It will be a task of CEN/BII2 to analyse if this code list can be used for

PartyLegalEntity/CompanyID and PartyTaxScheme/CompanyID.

2.1 Format

POLICY 1 (Use of ISO15459 encoding):

Participant and Party Identifiers should adhere to ISO 15459 constraints:

cannot be more than 50 characters long.

4 ISO 15459 terminology

(http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43349

5 CEN/BII terminology

6 ISO 9735 Service Code List (0007) terminology

7 ISO 6523 terminology

8 OASIS ebCore terminology

http://www.cen.eu/cwa/bii/specs/Profiles/Guidelines/BII_CodeLists-v1.00.xls

http://www.peppol.eu/work_in_progress/wp8-Solutions%20architecture%2C%20design%20and%20validation/specifications/v1-0-specifications





9

can only contain characters and numeric digits from the invariant character set of ISO/IEC 646.

POLICY 2 (Use of ISO15459 structure):

A Party identifier used in PEPPOL will comprise of:

An Issuing Agency Code

The Value provided by the Issuing Agency.

POLICY 3 (Coding of Issuing Agencies):

All Issuing Agency Codes for Party Identifiers are to be taken from the normative

version of the code list described in the following section. Currently this is maintained

within PEPPOL but it is intended to transfer this responsibility to the CEN/BII2

workshop in the near future, and for long term sustainability to a permanent standards

organization.

2.2 Issuing Agency Code Values

The values for the initial PEPPOL Issuing Agency Code list were taken from the NESUBL PartyID

code list9 but this has been extended to cover use by all PEPPOL pilots and includes other known

Issuing Agencies (from ISO 6523).

It is significant that this list will need ongoing extension under governance procedures currently

being developed (see section on Governance). To insure sustainability and proper governance it is

proposed to include only Issuing Agency Codes in the scope of: 1. International recognized standard schemes 2. International de-facto accepted schemes 3. Nationally defined schemes

Note that BusDox uses a numeric code value for Issuing Agencies whereas BII uses mnemonic

values. To assist in aligning the mnemonic codes of BII with the numeric codes of BusDox, each BII

mnemonic code has been given a numeric equivalent based on the ISO 6523 set of International

Code Designators. The actual values for numeric International Code Designators were based on the

following allocation criteria: 1. ISO 6523 International Code Designator (if known), or 2. ISO 9735 Identification code qualifier (if known), or 3. An incremental number starting from 9900 (issued by PEPPOL/BII)

Even those these numeric values are based on ISO code sets, they form a separate BII code set

because they contain additional values. Therefore the Issuing Agency for all numeric codes is BII not

ISO 6523.

POLICY 4 (OASIS ebCore URNs):

The proposed OASIS ebCore Party Id Type Technical Specification is defining a mechanism

for referencing party type identification schemes using a formal URN notation.

The general format of the URN is:

9 As currently used in OIOUBL, see relevant lists in http://www.oioubl.info/codelists/da/codelists.html



10

urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-in-catalog

Example:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:bii:gln

:- denotes that the Issuing Agency (catalog-identifier) is BII and the scheme used is the GLN.

POLICY 5 (Numeric Codes for Issuing Agencies):

The numeric ISO6523 code set as used in BII include additional code values not part of the

official ISO 6523 code set and so cannot be referred to as the official ISO 6523 code set10

–

they are CEN/BII‘s customization of this code set. Technically, this scheme could be called

anything, but by re-using the term ―ISO6523‖ as the BII code name it suggests the origin of

many code values used.

The correct URN reference to be used whenever numeric Issuing Agency code values

apply (for example in Participant Identifiers for BusDox) is:

urn:oasis:names:tc:ebcore:partyid-type:unregistered:bii:iso6523

:- denoting that the Issuing Agency (catalog-identifier) is BII and the scheme used is the

CEN/BII ISO6523 code set.

POLICY 6 (XML attributes for Participant Identifiers):

The “scheme” attribute must be populated in all instances of the “ParticipantIdentifier”

element. For example:

<ParticipantIdentifier scheme="urn:oasis:names:tc:ebcore:partyid-

type:unregistered:bii:iso6523”> 0088:4035811991014</ParticipantIdentifier >

POLICY 7 (XML attributes for Party Identifiers in UBL documents):

The “schemeID” attribute must be populated in all instances of the “ID” element when

used within a “PartyIdentification” container and in all instances of the “EndpointID”

element when used within a “Party” container.

For example:

<cac:PartyIdentification>

<cbc:ID schemeID=”GLN” schemeAgencyName=”GS1”

schemeURI=”urn:oasis:names:tc:ebcore:partyid-type:unregistered:bii:gln”>

4035811991014

</cbc:ID>

</cac:PartyIdentification>

and

<cac:Party>

<cbc:EndpointID schemeID=”GLN” schemeAgencyName=”GS1”


4035811991014

</cbc:EndpointID>

</cac:Party>

10 ISO 6523 is currently under revision after a 25 year working period; the new version will meet requirements

imposed by technological development.



11

[Note: the attributes in italic are optional]



12

The initial Issuing Agency code values and metadata are shown in the following table...

code schemeID Scheme Agency Name

numeric

ISO6523

code* schemeURI

GLN GLN GS1 0088

urn:oasis:names:tc:ebcore:partyid-

type:unregistered:bii:gln

DUNS DUNS Dun & Bradstreet 0062


type:unregistered:bii:duns

IBAN IBAN

S.W.I.F.T. Society for

Worldwide Interbank

Financial

Telecommunications s.c. 0021


type:unregistered:bii:iban

ISO6523 ISO6523

ISO (International

Organization for

Standardization) 0028


type:unregistered:bii:iso6523

DK:CPR DK:CPR

Danish Ministry of the Interior

and Health 9901


type:unregistered:bii:dk:cpr

DK:CVR DK:CVR

The Danish Commerce and

Companies Agency 9902


type:unregistered:bii:dk:cvr

DK:P DK:P

The Danish Commerce and

Companies Agency 0096


type:unregistered:bii:dk:p

DK:SE DK:SE

Danish Ministry of Taxation,

Central Customs and Tax Administration 9904


type:unregistered:bii:dk:se

DK:VANS DK:VANS Danish VANS providers 9905


type:unregistered:bii:dk:vans

IT:VAT IT:VAT

Ufficio responsabile gestione

partite IVA 9906


type:unregistered:bii:it:vat

IT:CF IT:CF TAX Authority 9907


type:unregistered:bii:it:cf

IT:FTI IT:FTI Ediforum Italia 0097


type:unregistered:bii:it:fti

IT:SIA IT:SIA Società Interbancaria per l‘Automazione 0135


type:unregistered:bii:it:sia

IT:SECETI IT:SECETI Servizi Centralizzati SECETI 0142


type:unregistered:bii:it:seceti

NO:ORGNR NO:ORGNR

Enhetsregisteret ved

Bronnoysundregisterne 9908


type:unregistered:bii:no:orgnr

NO:VAT NO:VAT

Enhetsregisteret ved

Bronnoysundregisterne 9909


type:unregistered:bii:no:vat

HU:VAT HU:VAT 9910


type:unregistered:bii:hu:vat



13

SE:ORGNR SE:ORGNR 0007


type:unregistered:bii:se:orgnr

FI:OVT FI:OVT Finnish tax board 0037


type:unregistered:bii:fi:ovt

EU:VAT EU:VAT National ministries of Economy 9912


type:unregistered:bii:eu:vat

EU:REID EU:REID Business Registers Network 9913


type:unregistered:bii:eu:reid

FR:SIRET FR:SIRET

INSEE: National Institute for

statistics and Economic studies 0009


type:unregistered:bii:fr:siret

AT:VAT AT:VAT

Österreichische

Umsatzsteuer-

Identifikationsnummer 9914


type:unregistered:bii:at:vat

AT:GOV AT:GOV

Österreichisches

Verwaltungs bzw.

Organisationskennzeichen 9915


type:unregistered:bii:at:gov

AT:CID AT:CID

Firmenidentifikationsnummer

der Statistik Austria 9916


type:unregistered:bii:at:cid

IS:KT IS:KT Icelandic National Registry 9917


type:unregistered:bii:is:kt

The normative (with complete metadata) form of the code list is available at.... < TBD but will be an

XML file (genericode format) >.

Examples of use:

Use in a BusDox SMP:

The following example denotes that the Participant is identified using the ISO 6523

International Code Designator in the CEN/BII set of Issuing Agency Codes. This in turn has

a numeric value of 0088 meaning that the party has a 0088 (GLN) identifier of

―4035811991014‖.



Use in a BII (UBL) document: The following example denotes that the Issuing Agency is ―GS1‖ in the CEN/BII set of

Issuing Agency Codes and the identifier is ―GLN‖. This means that the party has the GLN

identifier ―4035811991014‖.


<cbc:ID schemeID=”GLN” schemeAgencyName=”GS1”


4035811991014

</cbc:ID>


Use in BusDox SMP:



14

The following example denotes that the Participant is identified using the ISO 6523

International Code Designator in the CEN/BII set of Issuing Agency Codes. This in turn has

a numeric value of 9902 meaning that the party has the 9902 (DK:CVR) identifier

―987654321‖.



Use in a BII (UBL) document:

The following example denotes that the Issuing Agency is DK:CVR in the CEN/BII set of

Issuing Agency Codes. This means that the party has the Danish CVR identifier

―987654321‖.


<cbc:ID schemeID=”DK:CVR” schemeAgencyName=”The Danish Commerce and

Companies Agency” schemeURI=”urn:oasis:names:tc:ebcore:partyid-

type:unregistered:bii:dk:cvr”>

987654321

</cbc:ID>


In cases where the BusDox Participant Identifier is extracted from the BII document (e.g. the UBL

Party/EndpointID), the mnemonic PEPPOL Issuing Agency Code has to be replaced by the

equivalent numeric value. For example:

This BII (UBL) document fragment identifies a Party as ―4035811991014‖using the GLN from

GS1:

<cac:Party>

<cbc:EndpointID schemeID=”GLN” schemeAgencyName=”GS1”


4035811991014

</cbc:EndpointID>

</cac:Party>

In BusDox the equivalent Participant Identifier would be expressed as:

<ParticipantIdentifier scheme=" urn:oasis:names:tc:ebcore:partyid-


This means mapping the BII schemeName of ―GLN‖ to the numeric value of ―0088‖. To

then transform an EndpointID into the equivalent Participant Identifier it is necessary to

create a combined string value, e.g. ―0088:4035811991014‖.



15

3 Policy on Identifying Services supported by PEPPOL

3.1 Format

Services used in PEPPOL are identified using the concepts defined in the PEPPOL Identifier

Schemes Version 1.0.011

This states:

The identifier format is an aggregated format that covers the following identifier concepts:

Format Identifier:

Identifies the specific syntax of the document that is being exchanged. For XML documents,

the root element namespace and document element local name are concatenated to represent

the syntax of the document.

Customization Identifier:

Represents a customization of a document, for example a regional customization of the UBL

document format.

Version Identifier:

Identifies the version of a document, according to the versioning conventions of that specific

document.

POLICY 8 (BusDox 1.0.0 Document Identifiers):

The format of the Document Identifier is:

[<root NS>::]<document element local name>## <customization id>[::<version>]

Examples of use:

The following example denotes that the document type capable of being received is a UBL

2.0 Order conforming to the BII transaction for Submit Order known as ―BiiCoreTrdm001

version 1.0‖ (which is used as part of the BII03 and BII06 profiles). It has been further

specified to include the UBL 2.1 minor version additions:

urn:oasis:names:specification:ubl:schema:xsd:Order-

2::Order##urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0::2.1

:- denotes

Root Namespace Version

urn:oasis:names:specification:ubl:schema:xsd:Order-2 ver1.0

Document element local name

Order

Customization ID

urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0

Version

2.1

11 http://www.peppol.eu/work_in_progress/wp8-

Solutions%20architecture%2C%20design%20and%20validation/specifications/v1-0-specifications/peppol-

identifier-schemes/at_download/file



16

3.2 Document ID Values

The current list of Document IDs required by PEPPOL pilots is: Document element

local name Document Identifier (cenbii_docid_fci)

Order urn:oasis:names:specification:ubl:schema:xsd:Order-2::Order##urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0::2.0

OrderResponseSimple urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-

2::OrderResponseSimple##urn:www.cenbii.eu:transaction:biicoretrdm002:ver1.0::2.0

OrderResponseSimple urn:oasis:names:specification:ubl:schema:xsd:OrderResponseSimple-

2::OrderResponseSimple##urn:www.cenbii.eu:transaction:biicoretrdm003:ver1.0::2.0

Invoice urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biicoretrdm010:ver1.0::2.0

ApplicationResponse urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-

2::ApplicationResponse##urn:www.cenbii.eu:transaction:biicoretrdm013:ver1.0::2.0

CreditNote urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2::CreditNote##urn:www.cenbii.eu:transaction:biicoretrdm014:ver1.0::2.0

Invoice urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:www.cenbii.eu:transaction:biicoretrdm015:ver1.0::2.0

Catalogue urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2::Catalogue##urn:www.cenbii.eu:transaction:biicoretrdm018:ver1.0::2.0





Quotation urn:oasis:names:specification:ubl:schema:xsd:Quotation-2::Quotation##urn:www.cenbii.eu:transaction:biicoretrdm056:ver1.0::2.0





The normative version of this list is available at... <TBD but will be an XML file (genericode

format)>. The PEPPOL VCD and pre-award Catalogue documents are currently being defined as

extensions of BII but will be part of BII2. In addition subsets of BII profiles are being created to

support the specific requirements for cross-border eProcurement. The suggested placeholder

Document Identifiers are: Virtual

Company Dossier urn:www.peppol.eu:peppol:schema:xsd:VirtualCompanyDossier-1::VirtualCompanyDossier##urn:www.peppol.eu:transaction:peppoltrdm001:ver1.0::1.0

Virtual

Company Dossier

Package urn:www.peppol.eu:peppol:schema:xsd:VirtualCompanyDossierPackage-

1::VirtualCompanyDossierPackage##urn:www.peppol.eu:transaction:peppoltrdm002:ver1.0::1.0

Catalogue

Template urn:www.peppol.eu:peppol:schema:xsd:CatalogueTemplate-1::CatalogueTemplate##urn:www.peppol.eu:transaction:peppoltrdm012a:ver1.0::1.0

PEPPOL

Catalogue

profile urn:www.peppol.eu:peppol:schema:xsd:Catalogue-1::Catalogue##urn:www.peppol.eu:transaction:peppoltrdm01a:ver1.0::1.0

PEPPOL

Order

profile urn:www.peppol.eu:peppol:schema:xsd:Order-1::Order##urn:www.peppol.eu:transaction:peppoltrdm03a:ver1.0::1.0

PEPPOL Invoice

profile urn:www.peppol.eu:peppol:schema:xsd:Invoice-1::Invoice##urn:www.peppol.eu:transaction:peppoltrdm04a:ver1.0::1.0

These Document Identifiers are used in the Transactions identified in following BII profiles:

Profile BII01 - Catalogue only TransactionID Document Type urn

Collaboration CatalogueSubmission BiiColl009

Transaction SubmitCatalogue

BiiCoreTrdm01

9 Catalogue

urn:oasis:names:specification:ubl:schema:xs

d:Catalogue-2

Transaction AcceptCatalogue

BiiCoreTrdm05

7

Application

Response


d:ApplicationResponse-2

Transaction RejectCatalogue

BiiCoreTrdm05

8

Application

Response





17

Profile BII17 - MultiParty Catalogue TransactionID Document Type urn

Collaboration RequestCatalogue BiiColl08

Transaction SendCatalogueRequest

BiiCoreTrdm01

8

Catalogue

Request


d:CatalogueRequest-2

Transaction RejectCatalogueRequest

BiiCoreTrdm05

5

Application

Response



Collaboration MultiPartyCatalogue BiiColl026

Transaction MultiPartyCatalogue

BiiCoreTrdm05

4 Catalogue


d:Catalogue-2

Profile BII18 - Punch-out

Collaboration QuoteSubmission BiiColl027

Transaction ProvideQuote

BiiCoreTrdm05

6 Quotation


d:Quotation-2

Profile BII03 - Basic Order Only

Collaboration Ordering BiiColl001

Transaction SubmitOrder

BiiCoreTrdm00

1 Order


d:Order-2

Profile BII04 - Basic Invoice only

Collaboration Invoicing BiiColl004

Transaction SubmitInvoice

BiiCoreTrdm01

0 Invoice


d:Invoice-2

Profile BII05 - Billing



BiiCoreTrdm01

0 Invoice


d:Invoice-2

Collaboration

BiiColl005

ResolveInvoiceDispute

collaboration

Transaction CorrectWithCredit

BiiCoreTrdm01

4 Credit Note


d:CreditNote-2

Transaction CorrectWithDebit

BiiCoreTrdm01

5 Invoice


d:Invoice-2

Profile BII06 - Procurement



BiiCoreTrdm00

1 Order


d:Order-2

Collaboration OrderResponse BiiColl003

Transaction RejectOrder

BiiCoreTrdm00

2

Order Response

Simple


d:OrderResponseSimple-2

Transaction AcceptOrder

BiiCoreTrdm00

3

Order Response

Simple





BiiCoreTrdm01

0 Invoice


d:Invoice-2

Collaboration


BiiColl005


BiiCoreTrdm01

4 Credit Note


d:CreditNote-2



18


BiiCoreTrdm01

5 Invoice


d:Invoice-2

Profile

BII07 - Procurement with

Invoice dispute



BiiCoreTrdm00

1 Order


d:Order-2

Collaboration OrderResponse BiiColl003

Transaction RejectOrder

BiiCoreTrdm00

2

Order Response

Simple



Transaction AcceptOrder

BiiCoreTrdm00

3

Order Response

Simple





BiiCoreTrdm01

0 Invoice


d:Invoice-2

Collaboration InvoiceDispute BiiColl029

Transaction InvoiceDispute

BiiCoreTrdm01

3

Application

Response



Collaboration


BiiColl005


BiiCoreTrdm01

4 Credit Note


d:CreditNote-2


BiiCoreTrdm01

5 Invoice


d:Invoice-2



19

4 Governance

This policy needs maintenance by PEPPOL WP8 to ensure it supports new versions of the standards,

extensions to other identification schemes, etc. Currently the CEN BII2 has a code List work item

for updating the current CEN BII CWA in order to create a more complete version for CEN BII2.

PEPPOL needs to ensure participation in this work.

To ensure sustainability and proper governance it is proposed to include only Issuing Agency Codes

in the scope of: 1. International recognized standard schemes (CEN, ISO, UN/ECE) 2. International de-facto accepted schemes (OASIS) 3. Nationally defined schemes

PEPPOL shall ensure each Issuing Agency: a) Authorizes any organisation wishing to allocate unique Party identifiers as part of a PEPPOL Pilot. An

individual organisation or company wishing to issue unique identifiers shall do so through umbrella organisations such as their trade associations, network provider or a public or state agency;

b) Has defined rules which ensure that every unique identifier issued with their authority shall begin with one of their IACs;

NOTE: The purpose of this is to ensure that the same unique Party identifier can never be

issued by another issuer, no matter which agency is used to ensure unambiguity in the total

marketplace. c) Has defined rules so that a unique party identifier is only re-issued after the previously issued unique

identifier has ceased to be of significant to any user. The length of such period should be dependent upon the environment in which the unique identifier will be used.

These rules mirror those of the ISO 15459 registration Authority (NEN) and will support the option

to transfer the responsibility that authority as part of the PEPPOL sustainability programme. In

effect PEPPOL is taking the role of a governance agency (like NEN) for the pilot period.



20

5 References

BusDox

http://www.peppol.eu/work_in_progress/wp8-

Solutions%20architecture%2C%20design%20and%20validation/specifications/v1-0-

specifications

ISO 15459

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43349

CEN/BII

http://spec.cenbii.eu/

ISO 9735 Service Code List (0007)

http://www.gefeg.com/jswg/cl/v41/40107/cl3.htm

ISO 6523

http://www.iso.org/iso/catalogue_detail?csnumber=25773

OASIS UBL

http://docs.oasis-open.org/ubl/os-UBL-2.0.zip

OASIS ebCore

http://docs.oasis-open.org/ebcore/PartyIdType/v1.0/CD02/PartyIdType-1.0.html