EN 17015-1:2024
(Main)Electronic Public Procurement - Catalogue - Part 1: Choreographies
Electronic Public Procurement - Catalogue - Part 1: Choreographies
The purpose of this deliverable is to specify and describe choreographies for exchanging an electronic product catalogue (“catalogues”) as part of the business processes in the pre-award and post-award area, so that catalogues can serve as a basis for placing orders as well as evaluating tenders. The key aspects covered by this choreography specification are:
- processes for submitting catalogues from the selling to the buying side;
- processes for submitting catalogue-related data as part of a tendering process;
- processes integrating sell-side procurement systems.
This document does not apply to the transactions used in the specified choreographies. These transactions are specified in EN 17015 2. The relationship between the choreographies and the transaction is described in Clause 8.
The identifier of this choreographies document is EN 17015 1:2024.
How to claim compliance to this choreography is specified in 6.2.3.
Elektronisches öffentliches Beschaffungswesen - Katalog - Teil 1: Choreographien
Der Zweck dieses Dokuments besteht darin, Choreographien für den Austausch eines elektronischen Produktkatalogs („Kataloge“) im Rahmen der Geschäftsprozesse im Pre- und Post-Award Bereich festzulegen und zu beschreiben, so dass Kataloge als Grundlage für Bestellungen sowie für die Beurteilung von Angeboten dienen können. Die wesentlichen Aspekte dieser Choreographie-Spezifikation sind:
- Prozesse zur Übermittlung von Katalogen von der Verkäufer- zur Käuferseite;
- Prozesse zur Übermittlung von katalogbezogenen Daten im Rahmen eines Angebotsprozesses;
- Prozesse zur Integration von Beschaffungssystemen auf der Verkäuferseite.
Dieses Dokument ist nicht anwendbar für Transaktionen, die in den festgelegten Choreographien verwendet werden. Diese Transaktionen sind in EN 17015 2 festgelegt. Die Beziehung zwischen den Choreographien und der Transaktion ist in Abschnitt 8 beschrieben.
Der Identifikator dieses Choreographiendokuments ist EN 17015 1:2024.
Wie die Compliance mit dieser Choreographie eingehalten werden kann, ist in 6.2.3 festgelegt.
Passation électronique des marchés publics - Catalogue - Partie 1 : Chorégraphies
Le présent livrable a pour objet de spécifier et de décrire les chorégraphies utilisées pour échanger des catalogues de produits électroniques (« catalogues ») dans le cadre de procédures commerciales, que ce soit dans le domaine de la pré-adjudication ou de la post-adjudication, afin que les catalogues puissent servir de base pour passer des commandes et pour évaluer des offres. Les principaux aspects couverts par cette spécification sur les chorégraphies sont les suivants :
- les procédures de soumission des catalogues tant au niveau du vendeur qu'au niveau de l'acheteur ;
- les procédures de soumission de données relatives au catalogue dans le cadre d'une procédure d'appel d'offres ;
- les procédures d'intégration des systèmes de passation de marchés du côté du vendeur.
Le présent document ne s'applique pas aux transactions utilisées dans les chorégraphies spécifiées. Ces transactions sont spécifiées dans l'EN 17015 2. La relation entre les chorégraphies et les transactions est décrite à l'Article 8.
Le présent document sur les chorégraphies est identifié par la référence EN 17015 1:2024.
Le paragraphe 6.2.3 précise les critères à respecter pour revendiquer la conformité à cette chorégraphie.
Elektronska javna naročila - Katalog - 1. del: Koreografije
Ta dokument zagotavlja specifikacije za poslovne procese za izmenjavo elektronskih katalogov izdelkov (»katalogi«) kot del poslovnih procesov v fazah po oddaji naročila in pred njo (delno), da se lahko katalogi uporabljajo kot osnova za oddajo naročil in vrednotenje ponudb. Ta specifikacija za koreografije zajema naslednje ključne vidike:
• postopki za predložitev katalogov od prodajne do nakupne strani;
• postopki za predložitev podatkov v zvezi s katalogom kot del razpisnih postopkov.
Transakcije, uporabljene v navedenih koreografijah, ne spadajo na področje uporabe. Te transakcije so navedene v povezanih specifikacijah za transakcije v razdelku »Kataloške transakcije«.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-junij-2024
Elektronska javna naročila - Katalog - 1. del: Koreografije
Electronic Public Procurement - Catalogue - Part 1: Choreographies
Elektronisches öffentliches Beschaffungswesen - Katalog - Teil 1: Choreographien
Passation électronique des marchés publics - Catalogue - Partie 1 : Chorégraphies
Ta slovenski standard je istoveten z: EN 17015-1:2024
ICS:
03.100.10 Nabava. Dobava. Logistika Purchasing. Procurement.
Logistics
35.240.20 Uporabniške rešitve IT pri IT applications in office work
pisarniškem delu
35.240.63 Uporabniške rešitve IT v IT applications in trade
trgovini
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EN 17015-1
EUROPEAN STANDARD
NORME EUROPÉENNE
April 2024
EUROPÄISCHE NORM
ICS 35.240.63
English Version
Electronic Public Procurement - Catalogue - Part 1:
Choreographies
Passation électronique des marchés publics - Catalogue Elektronisches öffentliches Beschaffungswesen -
- Partie 1 : Chorégraphies Katalog - Teil 1: Choreographien
This European Standard was approved by CEN on 19 February 2024.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17015-1:2024 E
worldwide for CEN national Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviated terms . 9
5 Business Environment and high-level business requirements . 9
5.1 Choreographies (business) Goals . 9
5.2 Business environment . 10
5.2.1 General. 10
5.2.2 Business context . 10
5.2.3 Positioning in EIRA . 11
5.3 Organization and Business Partners involved . 11
5.4 High-level business process requirements . 12
6 Choreography Catalogue . 13
6.1 General. 13
6.2 Business processes variants . 13
6.2.1 General. 13
6.2.2 High-level business process variants requirements . 14
6.2.3 Claiming compliance . 15
6.3 Business process variant A – Catalogue With Response . 15
6.3.1 Business process variant A requirements . 15
6.3.2 Business process variant A state machine diagram [informative] . 15
6.3.3 Business process variant A definition . 15
6.3.4 Business process variant A scenarios . 17
6.3.5 Business process variant A business rules . 18
6.3.6 Business process variant A key examples [informative] . 18
6.4 Business process variant B – Catalogue Without Response . 19
6.4.1 Business process variant B requirements . 19
6.4.2 Business process variant B state machine diagram [informative] . 19
6.4.3 Business process variant B definition . 19
6.4.4 Business process variant B scenarios . 20
6.4.5 Business process variant B business rules . 21
6.4.6 Business process variant B key examples [informative] . 21
7 Choreography Pre-award catalogue . 22
7.1 General. 22
7.2 Business processes variants . 22
7.2.1 General. 22
7.2.2 High-level business process variants requirements . 23
7.2.3 Claiming compliance . 23
7.3 Business variant C – Simple Pre-award Catalogue . 23
7.3.1 Business process variant C requirements . 23
7.3.2 Business process variant C state machine diagram [informative] . 23
7.3.3 Business process variant C definition . 24
7.3.4 Business process variant C scenarios . 25
7.3.5 Business process variant C business rules . 25
7.3.6 Business process variant C key examples [informative] - Example 1 . 25
7.4 Business process variant D – Advanced Pre-award Catalogue . 25
7.4.1 Business process variant D requirements . 25
7.4.2 Business process variant D state machine diagram [informative] . 26
7.4.3 Business process variant D definition . 26
7.4.4 Business process variant D scenarios . 27
7.4.5 Business process variant D business rules. 28
7.4.6 Business process variant D key examples [informative] - Example 1 . 28
8 Choreography External Catalogue . 29
8.1 General . 29
8.2 Business process variants . 29
8.2.1 General . 29
8.2.2 High-level business process variants requirements . 29
8.2.3 Claiming compliance . 29
8.3 Business process variant E – Punch-out . 30
8.3.1 Business process variant E requirements . 30
8.3.2 Business process variant E state machine diagram [informative] . 30
8.3.3 Business process variant E definition . 30
8.3.4 Business process variant E scenarios . 31
8.3.5 Business process variant E rules . 32
8.3.6 Business process variant E key examples [informative] - Example 1 . 32
9 Transactions involved . 32
9.1 Summary . 32
9.2 Collaborations . 33
9.2.1 General . 33
9.2.2 Catalogue Provider sends Catalogue (BC-17015-1:2024-1) . 33
9.2.3 Catalogue Receiver sends Catalogue Response (BC-17015-1:2024-2) . 34
9.2.4 Catalogue Receiver sends Pre-award Catalogue Request (BC-17015-1:2024-3) . 35
9.2.5 Catalogue Provider sends Pre-award Catalogue (BC-17015-1:2024-4) . 36
9.2.6 Seller sends Shopping-cart (BC-17015-1:2024-5) . 37
Annex A (informative) Overview of the clauses and subclauses which fall under derivative use
................................................................................................................................................................... 38
Bibliography . 39
European foreword
This document (EN 17015-1:2024) has been prepared by Technical Committee CEN/TC 440 “Electronic
Public Procurement”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by October 2024, and conflicting national standards shall
be withdrawn at the latest by October 2024.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document falls under a CEN-CENELEC pilot on derivative use (as approved by the CEN/CA
(Administrative Board) through decision 37/2019). For more information about the implementation of
derivative use in CEN/TC 440 see here: https://www.cencenelec.eu/areas-of-work/cen-cenelec-
topics/public-procurement/cen-tc-440-electronic-public-procurement/
This document is part of a series of multi-part documents prepared, or under preparation, by
CEN/TC 440:
• 17011-series: eProcurement Architecture, providing a set of specifications outlining different aspects
of the eProcurement architecture for Business Interoperability Specifications.
• 17015-series: eCatalogue Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the eCatalogue processes.
• 17016-series: eOrdering Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the eOrdering processes.
• 17017-series: eFulfilment Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the eFulfilment processes.
The terms “shall”, “shall not”, “should”, “should not”, “may”, “can” and “cannot” are interpreted according
to the CEN-CENELEC Internal Regulations Part 3:2022, Clause 7 .
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
https://boss.cen.eu/reference-material/refdocs/pages/
Introduction
Derivative use pilot
This publication falls under a CEN-CENELEC pilot on derivative use (as approved by the CEN/CA
(Administrative Board) through decision 38/2019).
CEN has the copyright to all CEN publications, including their entire content and associated metadata, as
described in CEN-CENELEC Guide 10 “Policy on dissemination, sales and copyright of CEN-CENELEC
Publications”. However, through the derivative use pilot, CEN gives permission to the copying, replication
and translation of content from CEN/TC 440 deliverables in specific circumstances.
Under the derivative use pilot, specific sections of CEN/TC 440 publications may be copied, replicated
and translated in cases where this is a necessary condition for the meaningful implementation of the
publication. The sections which fall under derivative use will typically be elements, such as semantic
definitions and rules related to the use of information elements, and the name, definition and description
of processes and transactions, which are needed in software solutions, whether intended for sale in the
private market or for use in the public sector, and documents guiding the implementation and use in
specific countries and/or business sectors.
Under derivative use, any use of content, which has been copied, replicated or translated from a
CEN/TC 440 publication, should comply with the intended use of the publication. Derivative use cannot
be applied in use cases other than those the publication is intended to support. The intended use of this
publication is set out below.
Intended use of this publication
This document has been developed for any organization looking for guidance on the implementation and
use of electronic procurement deliverables as well as for organizations developing or implementing
software applications related to electronic procurement, such as software providers, business entities
and national authorities. These software applications should be in conformance with this publication.
Parts of the document to which derivative use apply
Each subclause, which falls under derivative use, will be clearly marked with a footnote. The degree to
which the specific content can be modified is specified in CEN/TS 17011-3 , Electronic Public
Procurement — Architecture — Part 3: Customization Guideline.
Annex A provides an overview of the line number references to all subclauses of the publication which
fall under derivative use.
Under preparation.
1 Scope
The purpose of this deliverable is to specify and describe choreographies for exchanging an electronic
product catalogue (“catalogues”) as part of the business processes in the pre-award and post-award area,
so that catalogues can serve as a basis for placing orders as well as evaluating tenders. The key aspects
covered by this choreography specification are:
— processes for submitting catalogues from the selling to the buying side;
— processes for submitting catalogue-related data as part of a tendering process;
— processes integrating sell-side procurement systems.
This document does not apply to the transactions used in the specified choreographies. These
transactions are specified in EN 17015-2. The relationship between the choreographies and the
transaction is described in Clause 8.
The identifier of this choreographies document is EN 17015-1:2024.
How to claim compliance to this choreography is specified in 6.2.3.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 17015-2:— , Electronic Public Procurement — Catalogue — Part 2: Transactions
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org
3.1
agent
person, organization, or system that acts in procurement or has the power to act in procurement
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17]
3.2
business process
sequence or network of activities and collaborations between two or more agents (3.1)
Under preparation. Stage at the time of publication: prEN 17015-2:2024.
3.3
business process variant
specification of a business process (3.2) belonging to a choreography (3.9)
Note 1 to entry: Different variants may support different electronic information exchange or collaborations. Agents
may publicly advertise their capability to support one or more variants in an automated fashion.
3.4
buyer
role (3.14) of an agent (3.1) that awards a contract and/or purchases items
Note 1 to entry: In pre-award, the buyer generally awards the contract, however future purchasers may be
foreseen. In post-award the buyer generally refers to the purchaser of items.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified — Note 1 to entry has been added]
3.5
catalogue
document describing a set of items (3.11) offered for purchase that can be processed in an electronic way
Note 1 to entry: The terms “eCatalogue” and “Post-award Catalogue” are synonyms for this term.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified — Note 1 to entry has been added]
3.6
catalogue provider
role (3.14) of an agent (3.1) compiling and supplying a catalogue (3.5)
Note 1 to entry: The catalogue provider role is usually played by the agent that acts as a seller, or by another agent
that acts on behalf of the seller.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified — Note 1 to entry has been added]
3.7
catalogue receiver
role (3.14) of an agent (3.1) processing a catalogue (3.5)
Note 1 to entry: The catalogue receiver may not only receive it but also validate it, process it, etc. The catalogue
receiver role is usually played by the agent that acts as a buyer, or by another agent that acts on behalf of the buyer.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified Note 1 to entry has been added]
3.8
catalogue response
single message from the catalogue receiver (3.7) to the catalogue provider (3.6) on the acceptance of the
related catalogue (3.5) sent by the catalogue provider (3.6)
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17]
3.9
choreography
set of business processes (3.2) having the same goals
3.10
collaboration
interaction between two or more agents (3.1) that result in the exchange of data between the agents (3.1)
involved as part of a business process (3.2)
3.11
item
product, work, service or any combination of them
Note 1 to entry: An item can be an atomic thing or a composition of things that together are seen as a unit, e.g. a
tetrabrik of milk or an indivisible package of six tetrabriks.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified — Note 1 to entry has been added]
3.12
pre-award catalogue
catalogue (3.5) that is submitted as a tender in response to a call for tenders
3.13
pre-award catalogue request
document describing the requirements on items (3.11) to be tendered and on the catalogue (3.5) that
should be submitted as a tender
3.14
role
relative concept that ties an agent (3.1) to a part they play in a given situational context.
Note 1 to entry: Originally named agent in role in the eProcurement Ontology.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified — Note 1 to entry has been added]
3.15
seller
role (3.14) of an agent (3.1) who transfers the ownership of the procurement results (goods, services or
work) to the buyer (3.4)
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17]
3.16
state
set of options and obligations of the participating agents (3.1) at a defined step in a business process (3.2)
to perform specific activities and collaborations (3.10)
Note 1 to entry: An activity of an agent or a collaboration may cause the transition of one state to another in a
specified set of next steps.
3.17
transaction
content of data exchanged or shared between the agents (3.1) in a collaboration (3.10)
Note 1 to entry: A transaction is the atomic unit that leads to a synchronized state in the information systems of
collaborating agents. It is the basic building block to specify the choreography between agents. When an agent
recognizes an event that changes the state of a business object within a business process, it uses a transaction to
synchronize with the collaborating agent. A transaction therefore changes the state of a business process. It carries
the intention of the initiating agent and is represented by a data structure that is required by a data model. The
exchange of a transaction may alter legal obligations between business partners.
4 Symbols and abbreviated terms
ABB Architectural Building Block
EIF European Interoperability Framework
EIRA European Interoperability Reference Architecture
HLR High-Level Requirement
IoP Interoperability
MRO Maintenance, Repair and Operations
SME Small and Medium-sized Enterprise
5 Business Environment and high-level business requirements
5.1 Choreographies (business) Goals
The business goals supported by implementing these choreographies are described in Table 1:
Table 1 — Business goals
ID Description
G-17015-1:2024-1 Facilitate the comparison of items on the buying side.
G-17015-1:2024-2 Simple storage and automated maintenance of item information on the buying
side.
G-17015-1:2024-3 Correct identification and pricing of items in the ordering processes and
tendering processes.
G-17015-1:2024-4 Enable Sellers to provide tailored item and price information.
The main business benefits to be gained by implementing these choreographies are described in Table 2:
Table 2 — Main business benefits
ID Description
B-17015-1:2024-1 Enables the optimization and automation of the order process the order can
be based on the sellers/providers own item information, in particular the
item identification.
B-17015-1:2024-2 Facilitates preparing of orders.
5.2 Business environment
5.2.1 General
The intended scope for these choreographies includes public procurement, but the choreography may
also be used in Business to Business (B2B) relations.
The choreographies is intended to support transmission of electronic documents for processing in (semi)
automated processes. The legal requirements that were taken into account are requirements from
European legislation, particularly the EU directives, as mentioned in the bibliography section of this
document.
The list of the transactions involved in this choreography is specified in Clause 8.
5.2.2 Business context
The choreographies specified in this document belong to the pre- and post-award area as shown in
Figure 1:
Figure 1 — Position of the catalogue choreographies in the procurement process
5.2.3 Positioning in EIRA
Table 3 — Position in EIRA
EIRA ID Title Domain Interface Scope Modality
• eProcurement
extension of
Procurement – Customer
ABB176
Catalogue –
Machine/
Organisational
Choreographies
Supplier
Interoperability
Specification
• eProcurement
extension of
ABB12 Business
Capability,
• eProcurement
extension of
ABB170
Exchange of
Business
Information
• eProcurement
extension of
ABB16 Business
Rule
5.3 Organization and Business Partners involved
The following key roles participate in this Choreography, acting in the roles as specified in Table 4 and
Figure 2 below.
Table 4 — Roles
Key Role Description
Buyer See Terms and Definitions: 3.4
Seller See Terms and Definitions: 3.15
Catalogue Provider See Terms and Definitions: 3.6
Catalogue Receiver See Terms and Definitions: 3.7
Figure 2 — Catalogue choreographies and roles
5.4 High-level business process requirements
Based on the goals and scope of the choreographies the following set of high-level requirements is found.
Each requirement is connected to a goal. Key examples for each collaboration variant are provided as
well (see Table 5).
Table 5 — High-level business process requirements
Req. ID Requirement statement Ref. to goal
HLR-17015-1:2024-1 For each choreography different variants supporting G-17015-1:2024-4
different levels of maturity shall be provided.
6 Choreography Catalogue
6.1 General
In order to encompass the various maturity levels of organizations (see HLR-17015-1:2024-1), the
approach is to specify variants of business processes that use a set of activities around exchanging
information in different combinations. The main business entities dealt with within this choreography
are Catalogue and Catalogue Response.
The state machine diagram depicted in Figure 3 provides information on the common states for systems
to get in agreement.
Figure 3 — Catalogue state machine diagram [informative]
6.2 Business processes variants
6.2.1 General
Two variants are identified as reported in the following table. They allow for supporting different levels
of interoperability maturity of the organisations willing to automate the exchange of information in the
business area at stake as specified by high-level requirement (HLR).
The variants combine in various ways the basic processes defined above through various collaborations
between Catalogue Provider and Catalogue Receiver as described in Table 6.
Table 6 — Catalogue business process variants overview
Business process Short name Description
variants
BPV-17015-1:2024:A Catalogue With The Catalogue Receiver receives the catalogue and
Response sends a response to the Catalogue Provider confirming
or rejecting the catalogue.
BPV-17015-1:2024:B Catalogue The Catalogue Receiver receives the Catalogue from the
Without Catalogue Provider, but sends no response on
Response acceptance or rejection.
Subclause 6.1 falls under derivative use (as set out in the Introduction). When replicating the section, the content
can be modified as specified in CEN/TS 17011-3.
Subclause 6.2 falls under derivative use (as set out in the Introduction). When replicating the section, the content
can be modified as specified in CEN/TS 17011-3.
6.2.2 High-level business process variants requirements
Table 7 describes the High-level Catalogue business process variants requirements.
Table 7 — High-level business process variants requirements
Req. ID Requirement statement Ref. to goal
HLR-17015-1:2024-2 The Catalogue Receiver shall confirm that the G-17015-1:2024-2
catalogue transaction was received and that the
catalogue transaction is accepted or rejected, in
order to testify on the business level that the
provided catalogue complies with the agreement
under which the catalogue is provided.
HLR-17015-1:2024-3 The Catalogue shall be regarded as the Sellers G-17015-1:2024-1
standing offer, and the Seller is thereby obligated to
supply the Catalogue items according to the terms
identified in the catalogue.
HLR-17015-1:2024-4 Catalogue transactions are subordinate to the G-17015-1:2024-3
agreements on which they are based.
HLR-17015-1:2024-5 The Seller is obligated to provide catalogue G-17015-1:2024-1
transactions updating items when item attributes
change in the targeted catalogue, according to
agreements.
HLR-17015-1:2024-6 The Catalogue Receiver can reject a catalogue G-17015-1:2024-3
transaction, if it does not conform to the agreement
under which the Catalogue is delivered.
HLR-17015-1:2024-7 A Catalogue Receiver shall accept and implement a G-17015-1:2024-4
catalogue transaction, if it conforms to an agreement.
HLR-17015-1:2024-8 The Catalogue Provider sends a catalogue G-17015-1:2024-4
transaction to establish or maintain a Catalogue at
the buying side.
HLR-17015-1:2024-9 It is the Catalogue Provider’s responsibility that data G-17015-1:2024-3
contained in the catalogue transaction is valid from a
technical as well as a business point of view, as it is
the task of the Catalogue Provider to gather and to
compile the data for the catalogue at the selling side.
HLR-17015-1:2024- It is the Catalogue Receiver’s responsibility to G-17015-1:2024-003
10 compile received catalogue transactions into a
catalogue, as it is the task of the Catalogue Receiver
to incorporate the catalogue data in the procurement
systems at the buying side.
HLR-17015-1:2024- Catalogue Provider and Catalogue Receivers G-17015-1:2024-002
11 involved in the catalogue exchange process require a
gradual automation of all information exchange:
Depending on their capabilities, the organizations
may be willing to exchange electronically only some
transactions participating in the process.
6.2.3 Claiming compliance
Please note that when variants are identified, claiming compliance shall refer to a specific variant. Yet,
one can claim compliance to more variants of the choreography.
The identification of a variant uses the technical specification number followed by the variant identifier:
e.g. EN 17015-1:2024:A.
A business process instance is compliant to a specified variant if all activities and collaborations
performed are specified in that specification and are performed at the steps in the business process and
in the sequence in, which they are specified.
6.3 Business process variant A – Catalogue With Response
6.3.1 Business process variant A requirements
Table 8 lists the process requirements for this variant.
Table 8 — Business process variant A requirements
Req. ID Requirement statement Ref. to goal
R-17015-1:2024:A-1 The Catalogue Receiver shall confirm by a G-17015-1:2024-2
catalogue response transaction.
R-17015-1:2024:A-2 It is the Catalogue Receivers responsibility that G-17015-1:2024-4
data contained in the catalogue response
transaction is valid from a technical as well as a
business point of view, as it is his responsibility
to confirm the reception of the catalogue.
R-17015-1:2024:A-3 It is the Catalogue Providers responsibility to G-17015-1:2024-2
compile received catalogue response transaction
into the relevant systems on the selling side.
6.3.2 Business process variant A state machine diagram [informative]
The state machine diagrams depicted in Figure 3 (Catalogue) and Figure 4 provide information on the
common states for systems to get in agreement.
Figure 4 — Catalogue Response state machine diagram [informative]
6.3.3 Business process variant A definition
Figure 5 represents the definition of the variant.
NOTE Internal tasks and gateways in Figure 5 are informative.
Subclause 6.3 falls under derivative use (as set out in the Introduction). When replicating the section, the content
can be modified as specified in CEN/TS 17011-3.
Figure 5 — Business process variant A definition
Table 9 reports the description, pre- and post-conditions, exceptions of the process. Scenarios can be
found in a subchapter.
Table 9 — Business process variant A description
Category Description
Description The Catalogue Provider sends a legally binding electronic catalogue
transaction to the Catalogue Receiver.
The Catalogue Receiver accepts or rejects the catalogue transaction based
on various external business criteria such as contract or price comparison
and reports this to the Supplier by using a response.
If the Catalogue Receiver accepts the catalogue transaction, the Catalogue
Receiver notifies the Catalogue Provider and the catalogue transaction is
applied into the purchasing systems by both parties and used as base for
procurement, i.e. ordering and invoicing. Possibly by adding it to an
existing catalogue.
If the Catalogue Provider needs to remove individual items from an
existing catalogue or add new items to it, he sends a catalogue transaction
with the appropriate action code for each added or deleted item.
The Catalogue Receiver accepts or rejects catalogue additions or
deletions prior to their application.
Pre-conditions The corresponding Catalogue Provider and the Catalogue Receiver have
identified each other and accepted to use this business process variant as
the basis for conducting electronic business.
The related Buyer and Seller have established a business relation that
requires catalogue information.
Post-conditions The Catalogue Provider and the Catalogue Receiver have established
identical catalogue information in their procurement systems and can use
this information for ordering and invoicing and to facilitate accurate
order – invoice matching.
Exceptions None
Scenarios See 6.3.4
6.3.4 Business process variant A scenarios
Table 10 describes the Business process variant A scenarios.
Table 10 — Business process variant A scenarios
Role Pre-conditions Collaboration Post-conditions Business Rules
Catalogue Catalogue is Catalogue Provider Catalogue sent Catalogue compliant
Provider prepared sends Catalogue or conformant
Catalogue Catalogue sent Catalogue Provider Catalogue Catalogue Receiver’s
Receiver sends Catalogue received capability to receive
catalogues
Catalogue Catalogue Catalogue Receiver Catalogue
Receiver received sends Catalogue Response sent
Response
Catalogue Catalogue Catalogue Receiver Catalogue
Provider Response sent sends Catalogue Response
Response received
6.3.5 Business process variant A business rules
Table 11 describes the Business process variant A rules.
Table 11 — Business process variant A rules
ID Description
BR-17015-1:2024:A-1 The Catalogue shall be conformant to EN 17015-2:—.
BR-17015-1:2024:A-2 The Catalogue Receiver has implemented a system that is able to receive
and handle a Catalogue.
BR-17015-1:2024:A-3 The Catalogue Response shall be conformant to EN 17015-2:—.
BR-17015-1:2024:A-4 The Catalogue Provider has implemented a system that is able to receive
and handle a Catalogue Response.
6.3.6 Business process variant A key examples [informative]
6.3.6.1 Example 1
An economic operator won a call for tender and now establishes the post-award processes with the
contracting authority. As part of this activity, he compiles a catalogue describing the products to be
offered by the economic operator. The catalogue is sent to the contracting authority.
The contracting authority checks the sent catalogue, to verify if all information requested by the
contracting authority and specified in the framework agreement between the contracting authority and
the economic operator is contained in the catalogue and that the catalogue complies with the (pre-award)
catalogue that was submitted by the economic operator in the tendering process. As the sent catalogue
fulfils all requirements, the catalogue will be forwarded to the ordering systems. Authorized employees
of the contracting authority are now able to place orders based on the information provided in the
catalogue.
The economic operator will be informed automatically by a catalogue response that the catalogue has
been accepted. The economic operator may receive orders from the contracting authority based on the
sent catalogue.
6.3.6.2 Example 2
An economic operator won a call for tender and now establishes the post-award processes with the
contracting authority. As part of this activity, he compiles a catalogue describing the products to be
offered by the economic operator. The catalogue is sent to the contracting authority.
The contracting authority checks the sent catalogue, to verify if all information requested by the
contracting authority and specified in the framework agreement between the contracting authority and
the economic operator is contained in the catalogue and that the catalogue complies with the (pre-award)
catalogue that was submitted by the economic operator in the tendering process. The catalogue does not
fulfil the requirements, because not all products in the catalogue are classified according to the agreed
classification systems as well as needed packaging information is missing. The catalogue will not be
forwarded to the ordering systems.
The economic operator will be informed automatically by the catalogue response that the catalogue is
rejected. No orders will be placed based on this sent catalogue.
6.4 Business process variant B – Catalogue Without Response
6.4.1 Business process variant B requirements
Table 12 describes the process requirements for this variant.
Table 12 — Business process variant B requirements
Req. ID Requirement statement Ref. to goal
R-17015-1:2024:B-1 The Catalogue Receiver shall send the confirmation G-17015-1:2024-2
or rejection via an alternative channel (e-mail,
phone, etc.).
6.4.2 Business process variant B state machine diagram [informative]
The state machine diagrams depicted in Figure 3 (Catalogue) provides information on the common states
for systems to get in agreement.
6.4.3 Business process variant B definition
Figure 6 represents the definition of the variant.
NOTE Internal tasks and gateways in Figure 6 are informative.
Figure 6 — Business process variant B definition
Subclause 6.4 falls under derivative use (as set out in the Introduction). When replicating the section, the content
can be modified as specified in CEN/TS 17011-3.
Table 13 reports the description, pre- and post-conditions and exceptions of the process. Scenarios can
be found in subchapters.
Table 13 — Business process variant B description
Category Description
Description The Catalogue Provider sends a legally binding electronic catalogue
transaction to the Catalogue Receiver.
The Catalogue Receiver accepts or rejects the catalogue transaction
based on various external business criteria such as contract or price
comparison.
If the Catalogue Receiver accepts the catalogue transaction the
catalogue transaction is applied into the purchasing systems by both
parties and used as base for procurement, i.e. ordering and invoicing.
Possibly by adding it to an existing catalogue.
If the Catalogue
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...