Sie sind auf Seite 1von 19

Specification

Project Acronym:

PEPPOL

Grant Agreement number:

224974

Project Title:

Pan-European Public Procurement Online

PEPPOL Business Interoperability Specification


Profile 1a Basic Catalogue only
Revision: 1.01

Authors:
Giancarlo De Stefano (Consip)
Peter Borresen (NITA/ebConnect)

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

Public

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

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

Revision History
Revision Date
Author
1.00
20100430 Peter Borresen
1.01
20101001 Klaus Vilstrup
Pedersen

Organisation
ebConnect
DIFI

Description
First version
EC approved

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).

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

Contributors
Organisations

Consip, Italy, http://www.eng.consip.it/on-line/en/Home.html


CSI (CSI Piemonte), Italy, http://www.csipiemonte.it/en/home.shtml
DIFI (Direktoratet for forvaltning og IKT)1, Norway, www.difi.no
NITA (IT- og Telestyrelsen)2, Denmark, www.itst.dk
Persons
Giancarlo De Stefano (Consip)
Klaus V. Pedersen, DIFI
Peter Borresen, NITA/ebConnect (editor)
Tim McGrath, DIFI/Document Engineering Services
Vania.Rostagno, CSI

1
2

English: Agency for Public Management and eGovernment


English: National IT- and Telecom Agency

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

Table of Contents
1

Introduction ............................................................................................................................................... 5
1.1 Audience ........................................................................................................................................... 5
1.2 PEPPOL Profile Business Interoperability Context .......................................................................... 5
1.3 Profile 1a Scope ............................................................................................................................... 6
1.4 Profile 1a Status ............................................................................................................................... 6

Legal Interoperability ................................................................................................................................ 7


2.1 Post award Catalogues ..................................................................................................................... 7

Organizational Organization/Business Interoperability ........................................................................ 9


3.1 Organizational scope ........................................................................................................................ 9
3.2 Organisation Requirements .............................................................................................................. 9

Organizational Process Interoperability ............................................................................................... 10


4.1 CEN ISSS WS/BII Profile................................................................................................................ 10

Semantic Interoperability ....................................................................................................................... 13


5.1 Core Catalogue ............................................................................................................................... 13
5.2 Catalogue line ................................................................................................................................. 15
5.3 Accept and Reject Catalogue Data model ...................................................................................... 16
5.4 Identifiers ........................................................................................................................................ 17
5.5 Code Lists ....................................................................................................................................... 17

Technical Interaction Interoperability (Process and Semantic Implementation) ............................. 19

Technical Interaction Interoperability (eSignature Validation) ........................................................... 19

Technical Transport Interoperability ..................................................................................................... 19

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

1 Introduction
1.1

Audience

The audience for this document is organizations wishing to be PEPPOL enabled for exchanging
eCatalogues, and/or their ICT-suppliers. These organizations may be:
Service providers
Contracting Authorities
Economic Operators

1.2

PEPPOL Profile Business Interoperability Context

The set of formal requirements for ensuring interoperability of pan-European Public eProcurement are
specified as PEPPOL Profiles. These Profiles follow an open interoperability architecture based on:
the European Interoperability Framework 2.0
the CEN ISSS WS/BII Profiles and
the PEPPOL certificate validation architecture
the BusDox transport specifications.
PEPPOL Profiles divide the Legal, Organizational, Semantic and Technical layers of the European
Interoperability Framework into 8 layers as shown in the figure below.

Figure 1 PEPPOL's Interoperability Framework


Therefore, a PEPPOL Profile is a technical specification describing:
The Legal scope of the specification.
The Organization/Business scope of the specification.
The choreography of the business process(es) covered, i.e. a detailed description of the way the
business partners collaborate, play their respective roles and share responsibilities to achieve
mutually agreed goals with the support of their respective information systems.
The electronic business transactions exchanged as part of the business process and the sequence
in which these transactions are exchanged.

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

The business rules governing the execution of that business process(es), its business collaborations
and business transactions, as well as any constraints on information elements used in the
transaction data models.
The information content of the electronic business transactions exchanged by referencing a common
data model for each of the business transactions.
The technical implementation of the business specifications and semantic specifications.
Relationships with the PEPPOL eSignature and Transport Infrastructure.
In order to comply with a PEPPOL Profile specification, it is necessary to comply with each interoperability
layer.

1.3

Profile 1a Scope

PEPPOL Profile 1a only covers part of the eProcurement processes.

Figure 2 Scope of eCatalogues


Figure 2 indicates that postaward electronic catalogues can be based on a preaward catalogue and that it
sets the foundation for reliable eOrdering and eInvoicing.
The (optional) underlying eSignature validation supports digital signing of eCatalogues to ensure
eSignatures work end-to-end between the participants. The (mandatory) PEPPOL transport infrastructure
ensures secure and reliable communication of eCatalogues.

1.4

Profile 1a Status

Test Pilot
Production Pilot
Production

1.0

First Version of Profile

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

2 Legal Interoperability
This chapter describes the legal implications of adopting the PEPPOL Profile 1a. It also analyzed any legal
obligations coming from existing European Directives.
At general level, the relevant directives referring to the procurement procedure are the directives 2004/17/EC
and 2004/18/EC. Public Procurement legislation documents can be found following the link
http://ec.europa.eu/internal_market/publicprocurement/legislation_en.htm

2.1

Post award Catalogues

In post-award, the use of eCatalogues falls within the domain of Private Law. According to an analysis
carried out by WP3 participants during the design phase, neither national nor at European level can be found
requirements referring to Catalogue formats as such in private legislation.
Hence, agreements between the parties of a contract can take the most various shapes and conditions.
Considering that eCatalogues are also electronic documents, national and EU legilsation on electronic
documents apply; the analysis of the legislative implications are analysed in the following paragraph
EU Mandatory Legal requirements
As previously seen, according to the Recital 20 of the Directive, the use of e-Catalogues for the submission
of tenders relies on the use of electronic means of communications.
Both the Directives 2004/17/EC and 2004/18/EC provide at the article 1.12 a definition of electronic means
of communication, stating that electronic means means using electronic equipment for the processing
(including digital compression) and storage of data which is transmitted, conveyed and received by wire, by
radio, by optical means or by other electromagnetic means.
The article 42 of the Directive 18/2004/EC provides for rules applicable to electronic communications and the
tools to be used for communicating by electronic means. In particular, the means of communication chosen
must be generally available and thus not restrict economic operators' access to the tendering procedure
(paragraph 2).
Moreover, communication and the exchange and storage of information shall be carried out in such a way as
to ensure that the integrity of data and the confidentiality of tenders and requests to participate are
preserved, and that the contracting authorities examine the content of tenders and requests to participate
only after the time limit set for submitting them has expired (paragraph 3).
Finally, the paragraph 4, prescribes that the tools to be used for communicating by electronic means, as well
as their technical characteristics, must be non-discriminatory, generally available and interoperable with
the information and communication technology products in general use.
Therefore, according to the aforementioned provisions, when making use of electronic means of
communications in tender procedure, contracting authorities should comply with the following legal
requirements, strictly related to the principles as explicitly referred by the EU Directives.
In particular the choice of the electronic means of communications chosen by a contracting authorities
should ensure:

general availability: any electronic mean of communication used by a contracting authority in a


tender procedure shall be commonly accessible and easily usable so as to ensure the compliance
with the general principle of equal treatment and non-discrimination, and offering, at the same time,

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

a real openness to the market and the grounds for effective competition. Moreover, just to achieve
unrestricted and full direct access to all the tender documents, all relevant documents must be
accessible on a precise site and around the clock from the date of publication of the contract notice
until the expiry of the deadline for submitting tenders. In this sense, contracting authorities shall
guarantee free, available and reliable access to the contracting authoritys connection to an open
network, in order to guarantee that access to the tendering procedure is not restricted and to ensure
equal treatment and effective competition.

interoperability: the electronic means used and any electronic tool made available by a contracting
authority shall be able to function and interact with commonly used equipment and applications as
well as with commonly used hardware and software equipment available on the market and normally
used by economic operators. In particular, such means and tool shall not represent barriers for
cross-border suppliers or certain groups of suppliers

integrity, confidentiality and security: the tools and means used for the transmission and storage
of all information concerning a tender procedure shall be realised in a way to safeguard the integrity
of transmitted data, ensuring that data exchanged between contracting authorities and economic
operators or stored within an electronic platform or system is not accessible to other parties and that
the aforementioned data and information may not be modified or tampered with (on purpose or
accidentally) by the contracting authorities themselves or by third parties.

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

3 Organizational Organization/Business Interoperability


This chapter explains how interoperability are met from an organizational view and addresses the issues of
how parties initiates electronic busniness and their business benefits in using standard based electronic
catalogues instead of paper based catalogues.

3.1

Organizational scope

The use case diagram below shows the scope of the exchange of catalogues in this profile specification
uc CENBII01 - Partners and Roles

Sourcing
Catalogue Receiv er

Catalogue Prov ider

Customer

Supplier

Buyer

Seller

An Economic Operator (Supplier) expresses what he can supply in the catalogue that is issued to the
Contracting Authority (Customer). The supplier is legally bound to the offers he expresses in the catalogues,
for example regarding pricing.
The scope for the tendering process is only the ability to express what the contracting authority wants to
purchase using or reusing a catalogue. The procedural issues, requirements for suppliers, the tendering
method and others issues required to complete a call for tender document are not covered.

3.2

Organisation Requirements

A Contracting Authority is bound from time to time to renew its contracts of goods and services. In the
tendering phase a catalogue is a helpful way to express what the Contracting Authority wants to purchase for
instance an existing catalogue can be used to fill out the call for tender document by leaving out the parts
that identify the items.
The Contracting Authority also benefits from having a legally binding catalogue from the supplier in an
electronic format. This can be used as a picking list for its electronic orders and it can be helpful to know the
exact price when a need comes into its internal organization, without spending time on exploring the market.

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

4 Organizational Process Interoperability


4.1

CEN ISSS WS/BII Profile

For post-award use of eCatalogues PEPPOL profile 1a is based on CENBII profile 01, Catalogue only.
When a tender has been awarding he becomes a supplier. The catalogue is now a list of actual goods and
services that the purchasing authority can use in the sourcing process according to a contract.
They use their local system to send eCatalogues, receive eCatalogues or to send and receive a Catalogue
response (Acceptance or Rejection). The sending and receiving documents is dependent on the
transformation of documents (if necessary) and the validation.

Send eCatalogue: This use case enables the actor Supplier to send electronic Catalogues via the
PEPPOL infrastructure. As this is an outgoing documents have to be transformed (if necessary) to
the PEPPOL format and validated before it is transported via the infrastructure.

Receive eCatalogue: This use case enables the actor Buyer to receive electronic catalogues via
the PEPPOL infrastructure. Incoming documents are validated and transformed (if necessary) to the
national/contracting authority format and then processed by the authoritys system.

Send eCatalogue Response: This use case enables the actor Buyer to send an eCatalogue
response (thereby accepting or rejecting the Catalogue in full) via the PEPPOL infrastructure. As this
is an outgoing document it has to be transformed (if necessary) to the PEPPOL format and validated
before it is transported via the infrastructure.

Receive eCatalogue Response: This use case enables the actor Supplier to receive an electronic
catalogue response via the PEPPOL infrastructure. Incoming documents are validated and
transformed (if necessary) to the national/suppliers format and then processed by the suppliers
system.

Transform document: The previously introduced use cases depend on this use case. The scope of
this use case is the transformation from national/contracting authority/supplier format to the PEPPOL
format and vice versa.

Validate document: The scope of this use case is the validation of the sent documents according to
the PEPPOL business rules, and in the case of post-award eCatalogues according to the contract
specific rules. Only valid documents can be transported via the PEPPOL infrastructure.

Transport document: The scope of this use case is to transport the documents via the PEPPOL
infrastructure.

This can either be accepted or rejected by the contracting authority. The following figure shows the
collaboration of the CENBII Profile 1:

10

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

act BiiColl009 - CatalogueSubmission


Supplier in the role of Catalogue Provider

Customer in the role of Catalogue Receiver

BiiTrns019
SubmitCatalogue

Receiv e and process


SubmitCatalogue

Create and send


SubmitCatalogue
Start

Is the
catalogue
transaction
accepted?

+no

Create and send


Rej ectCatalogue

BiiTrns058
RejectCatalogue

Process
Rej ectCatalogue
Cataloge transaction
rejected

+yes

Create and send


AcceptCatalogue

BiiTrns057
AcceptCatalogue

Process
AcceptCatalogue

Apply to trade
Process ends

Apply to trade
Catalogue transaction
accepted

The submission of a catalogue triggers a workflow that assigns somebody from contracting authority to
review the catalogues. This is done manually by looking at the styled version of the catalogue document.
PEPPOL Rule 3.5.3:

The contracting authorities application must be able to a) receive and b) display a


Catalogue Document corresponding to transaction data model for CENBII
SubmitCatalogue.

Depending on the outcome of the review, the Contracting Authority submits an Application Response
according to the document model in the CENBII transaction data model RejectCatalogue or
AcceptCatalogue
PEPPOL Rule 3.5.4:

The contracting authorities application must be able to a) produce an Application


Response according to the document model in the CENBII transaction data model
RejectCatalogue and AcceptCatalogue

When processing an eCatalogue the following business rules are applied:


1. A catalogue transaction without a stated validity period is assumed to be valid until cancelled.
2. The catalogue should be regarded as the Suppliers standing offer, and the Supplier is thereby
obligated to supply the catalogue items according to the terms identified in the catalogue.
3. If the Catalogue Provider party is not the Supplier of the products, it is possible to specify Supplier
Party.
4. A catalogue transaction either refers to one contract/agreement or none.
5. Catalogue transactions are subordinate to the contracts/agreements on which they are based.
6. A catalogue transaction must contain an identifier for the catalogue it represents or updates.
7. It is the Suppliers responsibility that data contained in the catalogue transaction is valid from a
technical as well as business point of view.
8. The Supplier is obligated to provide catalogue transactions updating items when item attributes
change in the targeted catalogue, according to agreements.
9. It is the Contracting Authoritys responsibility to compile received catalogue transactions into a
catalogue and confirm action trough accept.
10. The receiver can reject a transaction if it does not conform to the agreement under which the
transaction is delivered.

11

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

11. A receiver must accept and implement a transaction if it conforms to an agreement.


These business rules states the context of using the exchanging systems.

12

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

5 Semantic Interoperability
3

CEN/ISSS WS/BII BiiCoreTrdm specifications defines transaction data models for the permitted information
content of a business transaction exchanged within the scope of a profile i.e. the Business Documents.
This PEPPOL profile defines how the PEPPOL Community uses the BII01 Order (BiiCoreTrdm019) in a
cross-border context.
The customizations for PEPPOL include additional rules that may constrain the use or value of a business
transaction information element such as:
Restrictions on cardinality

Optional information elements are made mandatory.

Optional information elements are not permitted.

Possible information element restrictions include:


Precision in semantics of information elements.
Precision in formats of information elements.
Choice of Code lists.
Restrictions on values in codelist.
Dependency constraints between values in information elements.
Business Documents for CEN ISSS WS/BII Profile 01 Catalogue Only
Core Catalogue - CEN/ISSS WS/BII BiiCoreTrdm019

5.1

Core Catalogue

The PEPPOL post-award core catalogue document represents a list of purchasable items with their price
structures, identifiers and warranty references. In this usage it complies fully with the CENBII core catalogue
except for one restriction and two extensions:

1. Catalogue/Seller_ Supplier Party. Supplier Party/Party/PartyTaxScheme is made mandatory


2. An identifier has been added to Item Property (to support eClass)
3. An identifier has been added to Item Property Group (to support eClass)
The following table shows the elements in a Core Catalogue.
The elements with a comment Article 225 is referring to which section of the VAT directive they
comply to.
The elements marked with boldface are mandatory elements.
The elements marked with italics are optional elements.
Min
1
1
1
1
0
1
0
0
0
0
0
3

Max
1
1
1
1
1
1
1
1
1
1
1

Catalogue Element

Comment

Catalogue. UBL Version Identifier. Identifier


Catalogue. Customization Identifier. Identifier
Catalogue. Profile Identifier. Identifier
Catalogue. Identifier
Catalogue. Name
Catalogue. Issue Date. Date
Catalogue. Version. Identifier
+Catalogue. Validity_ Period. Period
Period. Start Date. Date
Period. End Date. Date
+Catalogue. Referenced_ Contract. Contract

http://spec.cenbii.eu/Profiles/IndexWG1.html

13

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

1
0
1
0
0
1
0
1
1
0
0
1
0
1
0
1
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
1
0
1
0
0
0
0
0
0
0
0
0
0
1

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

Contract. Identifier
Contract. Contract Type. Text
+Catalogue. Provider_ Party. Party
Party. Endpoint Identifier. Identifier
+Party. Party Identification
Party Identification. Identifier
+Party. Party Name
Party Name. Name
Catalogue. Receiver_ Party. Party
Party. Endpoint Identifier. Identifier
+Party. Party Identification
Party Identification. Identifier
+Party. Party Name
Party Name. Name
Catalogue. Seller_ Supplier Party. Supplier Party
+Supplier Party. Party
Party. Endpoint Identifier. Identifier
Party. Party Identification
Party Identification. Identifier
+Party. Party Name
Party Name. Name
+Party. Postal_ Address. Address
Address. Identifier
Address. Postbox. Text
Address. Street Name. Name
Address. Additional_ Street Name. Name
Address. Building Number. Text
Address. Department. Text
Address. City Name. Name
Address. Postal_ Zone. Text
Address. Country Subentity. Text
+Address. Country
Country. Identification Code. Code
+Party. Contact
Contact. Telephone. Text
Contact. Telefax. Text
Contact. Electronic_ Mail. Text
+Party. Person
Person. First_ Name. Name
Person. Family_ Name. Name
Person. Middle_ Name. Name
Person. Job Title. Text
+Party.PartyTaxScheme
PartyTaxScheme.CompanyIdentifier.Identifier (*)
Catalogue. Contractor_ Customer Party. Customer Party
+Customer Party. Party
Party. Endpoint Identifier. Identifier
Party. Party Identification
Party Identification. Identifier
Party. Party Name
Party Name. Name
+Party. Contact
Contact. Telephone. Text
Contact. Telefax. Text
Contact. Electronic_ Mail. Text
+Party. Person
Person. First_ Name. Name
Person. Family_ Name. Name
Person. Middle_ Name. Name
Person. Job Title. Text
+Address. Country
Country. Identification Code. Code

14

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

0
0
0
0
0
0
0
0
0
0

5.2

1
1
1
1
1
1
1
1
1
n

+Party. Contact
Contact. Telephone. Text
Contact. Telefax. Text
Contact. Electronic_ Mail. Text
+Party. Person
Person. First_ Name. Name
Person. Family_ Name. Name
Person. Middle_ Name. Name
Person. Job Title. Text
Catalogue.CatalogueLine

See 6.2

Catalogue line

The following table shows the content of the core catalogue line:
Min

Max

1
1
1
0
1
0
0
0
0
0
0
0
0
1
1
0
1
0
0
0

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
n
1
1
1
n

0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
0
0
0
0
1
0
0

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

Catalogue

Remark

Catalogue Line. Identifier


Catalogue Line. Action Code. Code
Catalogue Line. Orderable_ Indicator. Indicator
Catalogue Line. Orderable_ Unit. Text
Catalogue Line. Content Unit. Quantity
Catalogue Line. Order Quantity Increment. Numeric
Catalogue Line. Minimum_ Order Quantity. Quantity
Catalogue Line. Maximum_ Order Quantity. Quantity
Catalogue Line. Warranty_ Information. Text
+Catalogue Line. Line Validity_ Period. Period
Period. Start Date. Date
Period. End Date. Date
+Catalogue Line. Item Comparison
Item Comparison. Price. Amount
Item Comparison. Quantity
+Catalogue Line. Required_ Related Item. Related Item
Related Item. Identifier
Related Item. Quantity
Related Item. Description. Text
+Catalogue Line. Required_ Item Location Quantity. Item Location
Quantity
Item Location Quantity. Lead Time. Measure
Item Location Quantity. Minimum_ Quantity. Quantity
Item Location Quantity. Maximum_ Quantity. Quantity
+Item Location Quantity. Applicable Territory_ Address. Address
Address. Identifier
Address. Address Type Code. Code
Address. Street Name. Name
Address. Additional_ Street Name. Name
Address. Building Number. Text
Address. City Name. Name
Address. Postal_ Zone. Text
Address. Country Subentity. Text
Address. Region. Text
+Address. Country
Country. Identification Code. Code
+Item Location Quantity. Price
Price. Price Amount. Amount
Price. Base_ Quantity. Quantity
+Price. Validity_ Period. Period
Period. Start Date. Date
Period. End Date. Date
+Catalogue Line. Item
Item. Description. Text
Item. Pack Quantity. Quantity

15

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

0
0
0
0
1
0
1
0
1
0

1
1
n
1
1
1
1
1
1
1

1
0
0
0
0
1
0
1
1
0
0
0
0
0
0
1
1
1
0
0
1
1
0
1
0
0
1
0
0
1
0
0
0

1
1
1
1
1
1
1
1
n
1
1
n
1
1
1
1
1
1
n
1
1
1
n
1
1
1
1
1
1
1
1
1
1

5.3

Item. Pack Size. Numeric


Item. Name
Item. Keyword. Text
+Item. Sellers_ Item Identification. Item Identification
Item Identification. Identifier
+Item Identification. Extended_ Identifier. Identifier
Item Identification. Identifier
+Item. Standard_ Item Identification. Item Identification
Item Identification. Identifier
+Item. Item Specification_ Document Reference. Document
Reference
Document Reference. Identifier
Document Reference. Document Type. Text
+Document Reference. Attachment
Attachment. Embedded_ Document. Binary Object
+Attachment. External Reference
External Reference. URI. Identifier
+Item. Origin_ Country. Country
Country. Identification Code. Code
+Item. Commodity Classification
Commodity Classification. Commodity Code. Code
Commodity Classification. Item Classification Code. Code
+Item. Hazardous Item
Hazardous Item. UNDG Code. Code
Hazardous Item. Hazard Class Identifier. Identifier
+Item. Classified_ Tax Category. Tax Category
Tax Category. Identifier
+Tax Category. Tax Scheme
Tax Scheme. Identifier
+Item. Additional_ Item Property. Item Property
Item Property.Identifier
Item Property. Name
Item Property. Value. Text
+Item Property. Item Property Group
Item Property Group. Identifier
Item Property Group. Name
+Item. Manufacturers_ Item Identification. Item Identification
Item Manufacturer. Identifier
+Item. Manufacturer_ Party. Party
+Party. Party Name
Party Name. Name
+Item. Item Instance
+Item Instance. Lot Identification
Lot Identification. Expiry Date. Date

Accept and Reject Catalogue Data model

The Accept and Reject catalogue data model are identical in structure. The difference is the value in the
Response Code. For a rejection, the Response Description is mandatory.
Max

Min

Element

1
1
1
1
1
0
0
1
0

1
1
1
1
1
1
1
1
1

Application Response. UBL Version Identifier. Identifier


Application Response. Customization Identifier. Identifier
Application Response. Profile Identifier. Identifier
Application Response. Identifier
Application Response. Issue Date. Date
Application Response. Issue Time. Time
Application Response. Note. Text
+Application Response. Sender_ Party. Party
Party. Endpoint Identifier. Identifier

Comment

16

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

0
1
1
1
1
0
0
1
1
1
1
1
1
0

5.4

1
1
1
1
1
1
1
1
0
1
1
1
1
1

+Party. Party Identification


Party Identification. Identifier
+Party. Party Name
Party Name. Name
+Application Response. Receiver_ Party. Party
Party. Endpoint Identifier. Identifier
+Party. Party Identification
Party Identification. Identifier
+Party. Party Name
Party Name. Name
+Application Response. Document Response
+Document Response. Response
Response. Reference. Identifier
+Response. Response Code. Code

Response. Description. Text

AP=Accepted,
RE= Rejected
Restriction:
Manatory if
reject

Identifiers
4

PEPPOL has defined a Policy for Use of Identifiers that describes the specific case for Party Identifiers
and principles that should be followed in other cases.
The following eCatalogue identifiers have no additional constraints, for the reasons stated.
Customization Identifier
Profile Identifier
Party Legal Entity Company Identifier
Suppliers Item Identification

5.5

The value is imposed directly by the profile rule so specific


code list rule is not needed.
The value is imposed directly by the profile rule so specific
code list rule is not needed.
These are domestic identifiers so there may be domestic rules
that apply.
No restriction. Suppliers can identify their items as required.

Code Lists

A number of information elements constrain values to be those in a list of codes known as Code Lists.
The CEN BII Code Lists are published on
http://www.cen.eu/cwa/bii/specs/Profiles/Guidelines/BII%20Guideline%2013%20-%20CodeLists%20v1.pdf,
Correct use of Code List values improves interoperability. The specific Code Lists used for the
BiiCoreTrdm019 Catalogue transaction data model (BiiTrns019) must be common between business
partners in order to achieve interoperability.
The following rules regarding code lists are stated in BII documentation.
CL-010-002

CurrencyCode

Currencies in a Catalogue MUST be coded using ISO


currency code (alpha)

http://www.peppol.eu/work_in_progress/wp8Solutions%20architecture%2C%20design%20and%20validation/resources/PEPPOL%20Policy%20for%20u
sing%20Identifiersv1%206.doc/at_download/file

17

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

CL-010-003

CountryCode

Country codes in a Catalogue MUST be coded using ISO


code list 3166-1 (alpha)

The following additional code list rules are applied for PEPPOL implementations in addition to the BII rules:
PCL-010-001
PCL-010-002

Embedded document binary For Mime code in attribute use


object
MIMEMediaType
Party Identifier
Must follow the PEPPOL Policy on the use
5
of Identifiers .

http://www.peppol.eu/work_in_progress/wp8Solutions%20architecture%2C%20design%20and%20validation/resources/PEPPOL%20Policy%20for%20u
sing%20Identifiersv1%206.doc/at_download/file

18

PEPPOL Business Interoperability Profile


Profile 1a Basic Catalogue only

6 Technical Interaction Interoperability (Process and Semantic


Implementation)
PEPPOL Profile 1a semantics will be implemented by binding to the UBL 2.0 syntax. All PEPPOL
eCatalogue documents must be:
capable of validation against the UBL 2.0 Schema located at:
http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/maindoc/UBL-Catalogue-2.0.xsd
conform to rules of the CEN ISSS WS/BII core Catalogue Transaction Data Model (BiiTrns019)

7 Technical Interaction Interoperability (eSignature Validation)


PEPPOL enforces no legal requirements on digital signatures for end-to-end checking of:
Integrity
Authenticity
Non repudiation
And as such PEPPOL eCatalogues do not require the eSignatures.
However, if eCatalogues are digitally signed the recipient party (eg Contracting Authority) may wish to use
the PEPPOL Digital Signature Validation service to confirm validity of the certificate used for the signature.

8 Technical Transport Interoperability


PEPPOL requires all post-award eCatalogues to be transported using the PEPPOL Transport Infrastructure.
This uses a four-corner model based on the BusDox version 1.0 specification suite and ensures
communication of business documents in a secure and reliable way.
The use of this PEPPOL profile is dependent on the connection of both participants to the PEPPOL
Transport Infrastructure. From the perspective of the services, the receiving participant (e.g. the Contracting
Authority) must register their support for PEPPOL Profile 1a in a PEPPOL recognized SMP.

19