SIST EN 17015-2:2026

• Abstract:

  This document describes the transaction information requirements of the transactions used in the basic; collaborations described in EN 17015-1 Electronic Public Procurement – Catalogue – Choreographies. ; For each transaction there is an overview, the transaction business requirements and the transaction information requirements model containing definitions of terms, usage descriptions and cardinality of the information elements. ; The document describes the following transactions:; 1) Catalogue;; 2) Catalogue Response; 3) Pre-award Catalogue Request; 4) Pre-award Catalogue; 5) Shopping Cart; How to claim compliance to a transaction is described in paragraph 6.; How to claim conformance to a transaction is described in paragraph 6.

• Status: Published
• Public Enquiry End Date: 19-May-2024
• Publication Date: 14-Jun-2026
• ICS: 03.100.10 - Purchasing. Procurement. Logistics
• ICS: 35.240.20 - IT applications in office work
• ICS: 35.240.63 - IT applications in trade
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 18-May-2026
• Due Date: 23-Jul-2026
• Completion Date: 15-Jun-2026
• Ref Project: EN 17015-2:2026 - Electronic Public Procurement - Catalogue - Part 2: Transactions

• Referred By: SIST EN 17015-1:2024 - Electronic Public Procurement - Catalogue - Part 1: Choreographies
• Effective Date: 28-Jan-2026
• Referred By: SIST-TS CEN/TS 17011-3:2025 - Electronic Public Procurement - Architecture - Part 3: Customisation Guideline
• Effective Date: 28-Jan-2026

SIST EN 17015-2:2026 is the Slovenian national standard identical to EN 17015-2:2026 for electronic public procurement catalogues. It specifies the transaction information requirements for five catalogue-related transactions used with the choreography defined in EN 17015-1. The document is for organizations and software implementers that need a common way to exchange catalogue, response, pre-award and shopping-cart information.

What does SIST EN 17015-2:2026 specify?

SIST EN 17015-2:2026 specifies the information content of the transactions used in the basic collaborations for electronic public procurement catalogues. It gives an overview, business requirements, information models with cardinalities and usage notes, and business rules for each transaction.

The document applies to these transactions:

Transaction	What it covers
Catalogue	A catalogue of items offered for purchase
Catalogue Response	Acceptance or rejection of a catalogue
Pre-award Catalogue Request	Request-side requirements for tendering a catalogue
Pre-award Catalogue	A catalogue submitted as a tender
Shopping Cart	A subset of a catalogue used for ordering

The document separates transaction content from choreography. The choreography of the collaborations is specified in EN 17015-1:2024, while Clause 6 links the transactions to the catalogue choreographies. Clause 7 explains how to claim compliance and conformance, and Clauses 8 to 10 define business requirements, data models, and business rules.

Annex	What it covers
Annex A	Overview of the clauses and subclauses that fall under derivative use
Annex B	Relationship between business terms and the corresponding eProcurement Ontology (ePO) concepts

What are the key requirements of SIST EN 17015-2:2026?

SIST EN 17015-2:2026 sets common transaction rules first, then adds transaction-specific rules for each of the five messages. In practice, this makes the document useful for designing data structures, validating messages, and checking whether exchanged business documents can be processed without ambiguity.

Common requirements for all transactions

Clause 8.1 requires every transaction to identify itself, state its type, issue date, validity, sender and receiver, and the business process variant it belongs to. It also requires all amounts in a transaction to use the same currency, and all prices and quantities to be non-negative. This matters because implementers can validate basic message integrity before processing the business content.

Clause 8.1 also requires transactions to contain all information needed for their use and not rely on external item repositories. That supports stand-alone processing, which is important when buying systems need to evaluate a catalogue locally.

Catalogue transaction requirements

Clause 8.2 makes the Catalogue transaction suitable for versioned item offers. A catalogue can carry version history, an action code for how updates should be applied, a validity period, a language, and contract details when the catalogue is based on a contract or framework agreement. This matters because a buyer can see whether a catalogue replaces, updates or deletes earlier content.

Clause 8.2 also supports practical purchasing details: item identifiers, item names, additional descriptions and keywords, item pricing, standardized order units, delivery-related information, classifications, structured properties, sustainability evidence, hazardous-item information, retrieval URL, and payment arrangements. For buyers, this is what makes a catalogue searchable, comparable and usable for ordering.

The Catalogue information model in Clause 9.3 reflects this structure with fields for catalogue identity, source catalogue, validity period, contract reference, provider and receiver details, and catalogue-line information. That means software can separate document-level data from line-level item data and enforce cardinalities on each.

Catalogue Response requirements

Clause 8.3 defines the Catalogue Response as a formal reply from the receiver to the provider. It must identify the original catalogue, record when the response was sent, and state whether the catalogue was accepted or rejected, including reasons for rejection or partial rejection. In practice, this gives the catalogue provider a clear correction path and gives the receiver a traceable acceptance decision.

Clause 9.4 adds line-level response information, so a response can cover the whole catalogue and individual catalogue lines. That is useful when only part of a catalogue is acceptable and the rest needs correction.

Pre-award Catalogue Request requirements

Clause 8.4 makes the Pre-award Catalogue Request a tendering document. It must reference the corresponding call for tenders, support structured and vendor-neutral item requests, and state what information is required in the pre-award catalogue to be submitted. This matters because it allows buyers to ask for comparable offers without naming a supplier.

The clause also supports item relationships, item property requests, allowed values or ranges, and whether a property is mandatory, optional or not allowed. It can also require sustainability-related proof such as labels or certificates. In practice, this helps buyers validate tenders automatically and describe what they need in a way suppliers can answer consistently.

Pre-award Catalogue requirements

Clause 8.5 requires the Pre-award Catalogue to reference the relevant call for tenders or the Pre-award Catalogue Request, and to reference the matching request lines when it is based on a request. It may also reference a tender.

A key point is that the Pre-award Catalogue shall be reusable as a catalogue in post-award processes, depending on related agreements. That matters because the same data can move from tender evaluation into later ordering without rebuilding the offer.

Shopping Cart requirements

Clause 8.6 defines the Shopping Cart as a subset of a catalogue used for selecting items for an order. If the shopping cart is based on a contract, it must include the contract details. It may also carry a validity period, item availability period, item identifiers, pricing, classification, sustainability and hazardous-item details, and supporting documents.

This is practical for punch-out and order preparation: the buyer can select items in a supplier environment, bring the cart back, and place the final order with controlled item and price information. Clause 8.6 also allows a complete-cart indicator, which signals whether the cart must be ordered as-is or can still be changed.

Data model and business-rule checks

Clause 9 defines the information elements, their cardinality and their semantic data types. Clause 10 then adds consistency checks such as date order, timezone handling, and rules for item properties, quantities, prices, and catalogue updates. These checks matter because they let software reject inconsistent transactions before they reach purchasing or tendering workflows.

What terms does SIST EN 17015-2:2026 define?

SIST EN 17015-2:2026 defines the core vocabulary used in the transaction models.

• agent - a person, organization, or system that acts in procurement or can act in procurement.
• business process - a sequence or network of activities and collaborations between two or more agents.
• catalogue - a document that describes a set of items offered for purchase and can be processed electronically.
• catalogue provider - the role of the agent that compiles and supplies a catalogue.
• catalogue receiver - the role of the agent that processes a catalogue, including receiving, validating, or processing it.
• transaction - the content of data exchanged or shared between agents in a collaboration.
• pre-award catalogue - a catalogue submitted as a tender in response to a call for tenders.
• shopping cart - a document containing selected items from a catalogue for placing an order.

These terms matter because the same roles are used throughout the document to describe who sends, receives, validates, or reuses the data.

Who uses SIST EN 17015-2:2026?

SIST EN 17015-2:2026 is intended for organizations looking for guidance on implementing and using electronic procurement deliverables, and for organizations developing or implementing software applications related to electronic procurement. The document explicitly names software providers, business entities, and national authorities.

In practice, it is used by:

• public procurement teams and contracting authorities that publish or evaluate catalogues
• suppliers and sellers that send catalogues or shopping carts
• buyers that receive catalogues, issue requests, and assess offers
• software architects and integrators who need transaction data models and validation rules
• compliance and quality managers who need to check whether a transaction is acceptable as a catalogue, response, request, tender catalogue, or shopping cart

Which standards are used with SIST EN 17015-2:2026?

The document names no normative references in Clause 2, but it is used together with related standards and parts in the same architecture:

• EN 17015-1:2024 - provides the catalogue choreographies that the transactions in this part support.
• CEN/TS 17011-3:2024 - provides the customization guideline used for the derivative-use sections.
• CEN/TS 17011-4:2025 - listed in the bibliography as a related architecture part.
• prEN 17011-5:202X - listed in the bibliography as a related semantic architecture part.

The document also uses the eProcurement Ontology (ePO) and maps its business terms to ePO concepts in Annex B.

What does the SIST EN 17015-2:2026 document contain?

SIST EN 17015-2:2026 contains the full structure needed to implement and validate the catalogue transactions. It includes transaction identifiers, business requirements, semantic data models, and business rules.

The data model clauses define information elements with identifiers, level, cardinality, business term, description, usage note, requirement ID, and semantic data type. Tables in Clauses 9.3 to 9.7 define the five transaction models, while Tables 16 to 21 define common and transaction-specific business rules.

Annex A marks the clauses and subclauses that fall under derivative use. Annex B provides an electronic .xlsx mapping between the business terms in this document and the corresponding ePO concepts.

SLOVENSKI STANDARD
01-julij-2026
Elektronska javna naročila - Katalog - 2. del: Transakcije
Electronic Public Procurement - Catalogue - Part 2: Transactions
Elektronisches öffentliches Beschaffungswesen - Katalog - Teil 2: Transaktionen
Marchés publics électroniques - Catalogue - Partie 2: Transactions
Ta slovenski standard je istoveten z: EN 17015-2:2026
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-2
EUROPEAN STANDARD
NORME EUROPÉENNE
April 2026
EUROPÄISCHE NORM
ICS 35.240.63
English Version
Electronic Public Procurement - Catalogue - Part 2:
Transactions
Passation électronique des marchés publics - Catalogue Elektronisches öffentliches Beschaffungswesen -
- Partie 2: Transactions Katalog - Teil 2: Transaktionen
This European Standard was approved by CEN on 16 February 2026.

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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17015-2:2026 E
worldwide for CEN national Members.

Contents
European foreword . 3
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Symbols and abbreviated terms . 9
5 Positioning in EIRA .10
6 Collaborations and transactions.10
6.1 Transactions involved in Catalogue choreographies .10
6.2 Transactions identifiers .11
7 Claiming compliance and conformance .11
8 Business requirements .13
8.1 Common business requirements .13
8.2 Catalogue (T-17015-2:20xx-1) specific business requirements .13
8.3 Catalogue Response (T-17015-2:20xx-2) specific business requirements .15
8.4 Pre-award Catalogue Request (T-17015-2:20xx-3) specific business requirements 16
8.5 Pre-award Catalogue (T-17015-2:20xx-4) specific business requirements.17
8.6 Shopping Cart (T-17015-2:20xx-5) specific business requirements .17
9 Data models .18
9.1 Use of the eProcurment ontology .18
9.2 Legend .19
9.3 Catalogue (T-17015-2:20xx-1) .20
9.4 Catalogue Response (T-17015-2:20xx-2) .59
9.5 Pre-award Catalogue Request (T-17015-2:20xx-3).64
9.6 Pre-award Catalogue (T-17015-2:20xx-4) .75
9.7 Shopping Cart (T-17015-2:20xx-5) . 121
9.8 Header only data model . 135
9.8.1 Use of the header only data model . 135
9.8.2 Header only data model description . 135
10 Business rules . 135
10.1 Common business rules . 135
10.2 Catalogue (T-17015-2:20xx-1) business rules . 136
10.3 Catalogue Response (T-17015-2:20xx-2) business rules . 138
10.4 Pre-award Catalogue Request (T-17015-2:20xx-3) business rules . 138
10.5 Pre-award Catalogue (T-17015-2:20xx-4) business rules . 139
10.6 Shopping Cart (T-17015-2:20xx-5) business rules . 141
Annex A (informative) Overview of the clauses and subclauses which fall under derivative
use . 142
Annex B (informative) Relationship between business terms and corresponding concepts
in the eProcurement Ontology (ePO) . 143
Bibliography . 144

European foreword
This document (EN 17015-2:2026) has been prepared by the 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 2026, and conflicting national standards shall
be withdrawn at the latest by October 2026.
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 .
This document is part of a series of multi-part documents prepared, or under preparation, by CEN/TC
440:
• 17011-series: e-Procurement Architecture, providing a set of specifications outlining different
aspects of the e-Procurement architecture for Business Interoperability Specifications.
• 17014-series: Pre-Award Business Interoperability Specifications, providing a set of specifications
outlining choreography, transaction, syntax binding specifications and guidelines required to
support the Pre-Award processes.
• 17015-series: e-Catalogue Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the e-Catalogue processes.
• 17015-series: e-Ordering Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the e-Ordering processes.
• 17017-series: e-Fulfilment Business Interoperability Specifications, providing a set of specifications
outlining business choreography, transaction, syntax binding specifications and guidelines required
to support the e-Delivery processes.
The terms “shall”, “shall not”, “should”, “should not”, “may”, “need not” “can” and “cannot” shall be
interpreted according to Clause 7 of part 3 of the CEN-CENELEC internal regulations .
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.

https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/public-procurement/cen-tc-440-electronic-
public-procurement/
https://boss.cen.eu/media/BOSS%20CENELEC/ref/ir3_e.pdf
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.
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 a 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, 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 are 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 note. The degree to which
the specific content can be modified, is defined in CEN/TS 17011-3:2024 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.
Use of eProcurement Ontology (ePO)
This document uses the eProcurement Ontology (ePO), owned by the European Union, available here
(https://github.com/OP-TED/ePO) and licensed under a CC BY 4.0 licence.
1 Scope
This document describes the transaction information requirements of the transactions used in the basic
collaborations described in EN 17015-1:2024, Electronic Public Procurement – Catalogue – Part 1:
Choreographies. For each transaction there is an overview, the transaction business requirements and
the transaction information requirements model containing definitions of terms, usage descriptions and
cardinality of the information elements, as well as business rules.
The document describes the following transactions:
1) Catalogue;
2) Catalogue Response
3) Pre-award Catalogue Request
4) Pre-award Catalogue
5) Shopping Cart
This document does not apply to the choreographies using in the specified transactions. These
choreographies are specified in the related EN 17015-1:2024. The relationship between the
choreographies and the transaction is described in Clause 6.
The identifier of this transactions document is FprEN 17015-2:202X.
How to claim compliance to these transactions is described in the section 7 “Claiming compliance”
section.
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.
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
agent
person, an organization, or a system that act in procurement or have 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)
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 (3.11)
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.
Note 2 to entry: Usually, the buyer will be a contracting authority.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified Notes 1 and 2 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
single product or service
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
part played by an agent (3.1) in a particular business process (3.2), including its responsibilities (options
and obligations) to perform certain activities and collaborations (3.10) in that business process (3.2)
Note 1 to entry: The role is used to show the division of labour and responsibility amongst the agents involved in
the process or within the organization of an Agent.
[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) legally responsible for providing goods and services bought by a buyer (3.4)
Note 1 to entry: Usually, the seller is an economic operator. May also be called contractor in other contexts.
[SOURCE: eProcurement Ontology, v3.1.0, 2022-12-17, modified Note 1 to entry has been added]
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
predefined set of next steps. An example is the signing of an agreement between the buyer and the seller or placing
a firm order by the buyer.
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 define 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 defined by a data model. The
exchange of a transaction may alter legal obligations between business partners.
3.18
business term
the name of an information element to be used in data models for transactions (3.17)
Note 1 to entry: Usually a business term corresponds to an attribute or a role in the eProcurement Ontology.
3.19
business term group
coherent group of related business term (3.18)
Note 1 to entry: Usually a business term group corresponds to a class in the eProcurement Ontology.
4 Symbols and abbreviated terms
ABB Architectural Building Block
EIF European Interoperability Framework
EIRA European Interoperability Reference Architecture
n/a Not available
5 Positioning in EIRA
This specification is positioned in EIRA as shown in Table 1.
Table 1 — Positioning in EIRA
EIRA ID Title Domain Interface Scope Modality
CEN/EN 17015-2:20xx Electronic Procurement Machine • e-procurement Endorsing
Public /Customer extension of
Procurement - ABB176
Machine
Catalogue - Organisational
/Supplier
Transactions Interoperability
Specification
• e-procurement
extension of
ABB12 Business
Capability,
• e-procurement
extension of
ABB170 Exchange
of Business
Information
• e-procurement
extension of
ABB16 Business
Rule
6 Collaborations and transactions
6.1 Transactions involved in Catalogue choreographies
The relationship between the transactions and the choreographies is shown in Table 2.
Table 2 — Transactions identifiers
Role Capability Collaboration ID Collaborati Transactio Transaction Variant
on n ID
A B C D E
Catal Send BC-17015– Catalogue T-17015– Catalogue M M
ogue Catalogue 1:202x-1 Provider 2:20xx-1
Provi sends
der Catalogue
Catal Receive BC-17015– Catalogue T-17015– Catalogue  M
ogue Catalogue 1:202x-2 Receiver 2:20xx-2 Response
Recei receives
ver Catalogue
Response
Catal Send Pre- BC-17015– Catalogue T-17015– Pre-award    M
ogue award 1:202x-3 Receiver 2:20xx-3 Catalogue
Recei Catalogue sends Pre- Request
ver Request award
Catalogue
Request
Catal Send Pre- BC-17015– Catalogue T-17015– Pre-award   M M
ogue award 1:202x-4 Provider 2:20xx-4 Catalogue
Provi Catalogue sends Pre-
der award
Catalogue
Seller Send BC-17015– Seller T-17015– Shopping Cart     M
Shopping-Cart 1:202x-5 sends 2:20xx-5
Shopping-
cart
6.2 Transactions identifiers
The identifiers and names of all transactions specified in this document are shown in Table 3.
Table 3 — Transactions identifiers
Transaction ID Transaction Name
T-17015–2:20xx-1 Catalogue
T-17015–2:20xx-2 Catalogue Response
T-17015–2:20xx-3 Pre-award Catalogue Request
T-17015–2:20xx-4 Pre-award Catalogue
T-17015–2:20xx-5 Shopping Cart
7 Claiming compliance and conformance
A transaction instance is compliant to a specified transaction, if the following conditions are met
— all specified business terms of that transaction are included according to their cardinalities as well
as all corresponding business rules are fulfilled,
— no additional business terms were added
— additional business rules may have been added, which shall not conflict with the specification
A transaction instance is conformant to a specified transaction, if the following conditions are met
— all specified business terms of that transaction are included according to their cardinalities as well
as all corresponding business rules are fulfilled
— additional business terms may have been added
— additional business rules may have been added, which shall not conflict with the specification
8 Business requirements
8.1 Common business requirements
The business requirements common to all transactions are defined in Table 4.
Table 4 — Common business requirements
ID Description
R-17015–2:20xx-1 A transaction shall provide information about its identity, type, issue date
and validity.
R-17015–2:20xx-2 All amounts in a transaction shall be stated in the same currency.
R-17015–2:20xx-3 A transaction shall contain non-negative prices and quantities.
R-17015–2:20xx-4 The transactions shall contain all information necessary for its application
i.e. it shall not rely on the availability of external references such as a
centralized repository of item information. To ease the processing of a
catalogue, no external data sources are needed.
R-17015–2:20xx-5 A transaction shall contain information on the organisations sending
respectively receiving the transaction.
R-17015–2:20xx-6 A transaction shall provide information about corresponding business
process variant it is used in.
8.2 Catalogue (T-17015-2:20xx-1) specific business requirements
The business requirements for the Catalogue transaction are defined in Table 5.
Table 5 — Catalogue business requirements
ID Description
T-17015–2:20xx-1-R-1 To support changing of the previously sent catalogue, the catalogue shall provide
information on its version history and how changes shall be applied. Changes may
be fully, or partial updates and deletion of information sent in previous version of
a catalogue.
T-17015–2:20xx-1-R-3 To support an easy identification for end-users on the buying side, a name of the
catalogue may be provided in a catalogue.
T-17015–2:20xx-1-R-4 To restrict the validity of a catalogue, a period of time the catalogue is valid may
be defined in the catalogue. A catalogue without a stated validity period is assumed
to be valid until it is cancelled or replaced with a new version. Sometimes products
are offered only for a certain period of time or the prices for the product are
ensured to be fixed by the catalogue provider only during this period of time.

Section 7.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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
Section 7.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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
T-17015–2:20xx-1-R-5 If a catalogue is based on a contract, e.g. a framework agreement, a catalogue shall
include details on the contract the catalogue is based on. In such a contract, further
requirements on the catalogue may be specified.
T-17015–2:20xx-1-R-6 To ensure that a catalogue can be understood by the end-users on the buying side,
the agreed language to be used in the catalogue shall be provided.
T-17015–2:20xx-1-R-7 To support use cases where the catalogue receiver is not the buyer, information
on the organization buying the items offered in the catalogue may be provided in
the catalogue.
T-17015–2:20xx-1-R-8 To support cases where the catalogue provider is not the seller, information on the
organization buying the items offered in the catalogue may be provided in the
catalogue.
T-17015–2:20xx-1-R-9 A catalogue shall have information that makes it possible to reference specific
instances of the catalogue.
T-17015–2:20xx-1-R-10 To support offering an item with different condition such as minimum order
quantities, different prices, delivery times, validity periods, orderability,
warranties, packaging etc, an item may be more the once provided in a catalogue
along with the information on the varying condition. Such a combinations of an
item and conditions shall be uniquely identifiable.
T-17015–2:20xx-1-R-11 An item shall be referenceable uniquely by an identifier. Such an identifier may be
an identifier assigned by the seller, buyer, manufacturer or an identifier according

to an international identification scheme, e.g. a part number.
T-17015–2:20xx-1-R-12 To allow selection of an item by the end-user on the buying side, a name of the item
shall be provided in the catalogue.
T-17015–2:20xx-1-R-13 To support searching for items in buy-side ordering systems, additional names,
e.g. if an item was rebranded, additional descriptions and keywords may be
provided in the catalogue.
T-17015–2:20xx-1-R-14 To support end-users on the buying side, additional documents, e.g. Digital
Product Passport, images, manuals, brochures etc. may be provided in the
catalogue. These documents may be provided by references to external sources.
T-17015–2:20xx-1-R-15 To support the buying decision information on how an items is priced shall be
provided in a catalogue including additional charges like VAT. This also includes
factors that have influence on the price as well as relationships to other parts of
the catalogue that may have impact on the price. The price may also be dependent
on factors, e.g. order size, delivery region (down to the city level), allowance,
charges, currency, etc. Prices shall not be negative.
T-17015–2:20xx-1-R-16 To ease comparing the prices of items in a catalogue, a price for a standardized
order unit may be provided in the catalogue.
T-17015–2:20xx-1-R-17 It shall be possible to specify the kind of the item in the context of its delivery.
T-17015–2:20xx-1-R-18 To support supply-chain due diligence processes, information on the origin of the
item as well as on other involved organization involved in the
production/provision of the item may be provided in the catalogue.
T-17015–2:20xx-1-R-19 An item in the catalogue may be classified according to a standardized goods and
services classification system, e.g. CPV, UNSPSC, ECLASS, or GPC. Such
classifications may be mandated by the Buyer or by legal frameworks.
T-17015–2:20xx-1-R-20 To support the automated evaluation of an item, a structured description
according to a standardized property systems may be provided in a catalogue.
T-17015–2:20xx-1-R-21 To support logistics processes on the buying side, details on transporting and
handling an item in logistics processes may be provided in a catalogue.
T-17015–2:20xx-1-R-22 To support the assessment of the sustainability of an item as well as supply-chain
due diligence processes, information on relevant labels, certificates etc. proofing
the conformance of an item to relevant sustainability requirements may be
provided in a catalogue.
T-17015–2:20xx-1-R-23 To fulfil regulatory requirements on hazardous items, information on the
hazardous nature of an item may be provided in a catalogue.
T-17015–2:20xx-1-R-24 To allow a reload of a catalogue, a URL may be provided in a catalogue, where the
catalogue can be retrieved as well.
T-17015–2:20xx-1-R-25 To support offering perishable goods, dates on the durability, expiration end-of-
life etc. of an item may be provided in catalogue.
T-17015–2:20xx-1-R-26 To support offering items related to a selected item together in an ordering system,
information on the relationship between various items may be provided in a
catalogue. Examples of such relationships are replacement items, accessory items
etc.
T-17015–2:20xx-1-R-27 To support various channels for transmitting transactions electronic end point
identifiers may be provided in a catalogue for buyer and sellers.
T-17015–2:20xx-1-R-28 To support the assessment of the sustainability of an item, information on the
environmental impact of the item may be provided.
T-17015–2:20xx-1-R-29 To support purchasing decision, the payment conditions applying to all items
offered in a catalogue may be provided in a catalogue.
8.3 Catalogue Response (T-17015-2:20xx-2) specific business requirements
The business requirements for the Catalogue Response transaction are defined in Table 6.
Table 6 — Catalogue Response business requirements
ID Description
T-17015–2:20xx-2-R-1 A catalogue response shall contain the date and time when the catalogue response
was sent.
T-17015–2:20xx-2-R-2 A catalogue response shall refer catalogue transaction it is the response to.
T-17015–2:20xx-2-R-3 The catalogue response shall provide information if the related catalogue was
accepted or rejected. In the case of rejection or a partial rejection, the reason for
the rejection shall be provided in the catalogue response. The catalogue receiver
can reject a catalogue transaction if it does not conform to the agreement under
which the catalogue is provided. By proving the information about the rejection,
the catalogue provider will be enabled to submit a valid catalogue.
T-17015–2:20xx-2-R-4 The issuer of the response shall be provided to proof that the catalogue response
is sent by the valid catalogue receiver.
T-17015–2:20xx-2-R-5 The receiver of the response shall be provided to proof that the catalogue response
is sent to the valid provider of the original catalogue transaction.
T-17015–2:20xx-2-R-6 The catalogue response may contain textual notes that may be used to make any
comments or instructions relevant to the response.

Section 7.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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
8.4 Pre-award Catalogue Request (T-17015-2:20xx-3) specific business requirements
The business requirements for the Pre-award Catalogue Request transaction are defined in Table 7.
Table 7 — Pre-award Catalogue Request business requirements
ID Description
T-17015–2:20xx-3-R-1 As pre-award catalogue request is part of a call for tenders, a pre-award catalogue
request shall contain a reference to the corresponding call for tenders.
T-17015–2:20xx-3-R-2 To ensure a vendor-neutral description of requirements on item to be tendered, a
pre-award catalogue request shall support the structured description according to
a standardized property systems may be provided in a pre-award catalogue
request.
T-17015–2:20xx-3-R-3 As a pre-award catalogue request is part of a call for tenders, a reference to the
corresponding call for tender shall be provided to ensure that the pre-award
catalogue request can evaluated in the corresponding context.
T-17015–2:20xx-3-R-4 To ensure a consistent set up of the post-award process, requirements on the on
the pre-award catalogue to be submitted as a tender may be provided in a pre-
award catalogue request. This includes information requirement on the items
(item request), information requirements on the pre-award catalogue as well as
on how the item can be ordered and how the item will be delivered.
T-17015–2:20xx-3-R-5 To support referencing an item request, an item request shall be uniquely
identifiable.
T-17015–2:20xx-3-R-6 To ease the understanding of an item request, a vendor-neutral name may be
provided for an item request.
An item request in the pre-award catalogue request may be classified according to
T-17015–2:20xx-3-R-7
a standardized good and service classification system, e.g. CPV, UNSPSC, ECLASS,
or GPC. Such classifications may be mandated by the Buyer or by legal frameworks.
T-17015–2:20xx-3-R-8 To provide details on the requested items, information on the relationship
between various item requests may be provided in a pre-award catalogue request.
Examples of such relationships are replacement items, accessory items etc.
T-17015–2:20xx-3-R-9 To support a structured and vendor-neutral description of the requested item, an
item request may be described by providing the requested properties and
specifications on the requested item (item property request).
To support referencing an item property request, the item property request shall
T-17015–2:20xx-3-R-10
be uniquely identifiable.
T-17015–2:20xx-3-R-11 An item property request may be classified according to standardized goods and
services classification systems, e.g. ECLASS or GPC.
T-17015–2:20xx-3-R-12 To support the buyers in offering appropriate goods and services in a pre-award
catalogue, a value range for an item property request may be provided. This
includes a list of allowed values (32 GB, 64 GB or 128 GB for USB sticks) as well
as range using a allowed minimum and maximum value.
Such information allows automatic validation check of a pre-award catalogue
submitted as a tender.
Section 7.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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
T-17015–2:20xx-3-R-13 To ease the understanding of an item property request, a free text description may
be provided.
T-17015–2:20xx-3-R-14 To support the buyers in preparing the pre-award catalogue, information shall be
provided, if the provision of the corresponding item property is mandatory,
optional, or not allowed.
T-17015–2:20xx-3-R-15 To support the buyer on the preparation of a useful and valid pre-award catalogue,
requirements on the information to be provided in the pre-award catalogue may
be specified. This includes information requirements on the items, information
requirements on the pre-award catalogue itself as well as information on how the
item can be ordered and how the item will be delivered.
T-17015–2:20xx-3-R-16 To support the assessment of the sustainability of an item as well as supply-chain
due diligence processes, information may be provided, whether and which labels,
certificates or other means of proofing conformance with required regulations are
required, e.g. a certificate of conformity.
8.5 Pre-award Catalogue (T-17015-2:20xx-4) specific business requirements
The business requirements for the Pre-award Catalogue transaction are defined in Table 8.
Table 8 — Pre-award Catalogue business requirements
ID Description
T-17015–2:20xx-4-R-1 To support the evaluation of the pre-award catalogue, the pre-award catalogue
shall contain a reference to the corresponding call for tenders or a reference to the
pre-award catalogue request.
T-17015–2:20xx-4-R-2 To support the evaluation of the pre-award catalogue, the pre-award catalogue
lines shall contain a reference to the corresponding pre-award catalogue request
line, if the pre-award catalogue is based on a pre-award catalogue request.
T-17015–2:20xx-4-R-3 To support sending a pre-award catalogue as part of a set of tender documents, a
pre-award catalogue may contain a reference to a tender.
T-17015–2:20xx-4-R-4 To facilitate the set-up of post-award processes, a pre-award catalogue shall be
reusable as a catalogue in post-award processes. Depends on related agreements.
8.6 Shopping Cart (T-17015-2:20xx-5) specific business requirements
The business requirements for the Shopping Cart transaction are defined in Table 9.
Table 9 — Shopping Cart business requirements
ID Description
T-17015–2:20xx-5-R-1 If a shopping cart is based on a contract, e.g. a framework agreement, a shopping
cart shall include details on the contract the catalogue is based on. In such a
contract, further requirements on the shopping cart and the punch-out process
may be specified.
Section 7.5 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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
Section 7.6 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 Electronic Public Procurement – Architecture – Part 3: Customization
Guideline.
T-17015–2:20xx-5-R-2 To restrict the validity of a shopping cart, a period of time the shopping cart is valid
may be defined in the shopping cart. A shopping cart without a stated validity
period is assumed to be valid until indefinitely. This may apply for parts of the
shopping cart as well.
T-17015–2:20xx-5-R-3 An item shall be referenceable uniquely by an identifier. Such an identifier may be
an identifier assigned by the seller, buyer, manufacturer, or an identifier according
to an international identification scheme.
T-17015–2:20xx-5-R-4 To support buying an item to different condition such as different prices, minimum
order quantities, delivery times, validity periods, orderability, warranties etc, an
item may be more the once provided in a shopping cart along with the relevant
information on the varying condition. Such a combinations of an item and
conditions shall be uniquely identifiable.
T-17015–2:20xx-5-R-5 To support supply-chain due diligence processes, information on the origin of the
item as well as on other involved organization involved in the
production/provision of the item may be provided in the shopping-cart.
T-17015–2:20xx-5-R-6 To ease the identification of the selected item for the end-users, the name and
description of the item may be provided in the shopping cart.
T-17015–2:20xx-5-R-7 To support the automated evaluation of an item, a structured description
according to a standardized property systems may be provided in a shopping cart.
T-17015–2:20xx-5-R-8 To support the assessment of the sustainability of an item as well as supply-chain
due diligence processes, information on relevant labels, certificates etc. proofing
the conformance of an item to relevant sustainability requirements may be
provided in a shopping cart.
T-17015–2:20xx-5-R-9 An item in the shopping cart may be classified according to a standardized goods
and services classification system, e.g. CPV, UNSPSC, ECLASS, or GPC. Such
classifications may be mandated by the Buyer or by legal frameworks.
T-17015–2:20xx-5-R-10 To support the ordering process, additional documents, e.g. images, manuals,
brochures, specifications etc. may be provided in the catalogue. These documents
may be provided by references to external sources.
To place the final order, information on how an items is priced shall be provided
T-17015–2:20xx-5-R-11
in a catalogue including additional charges like VAT.
...