CEN/TS 17011-3:2024

SLOVENSKI STANDARD
01-maj-2025
Elektronska javna naročila - Arhitektura - 3. del: Smernice za prilagajanje
Electronic Public Procurement - Architecture - Part 3: Customisation Guideline
Elektronische öffentliche Auftragsvergabe - Architektur - Teil 3: Leitfaden für die
Anpassung
Marchés publics électroniques - Architecture - Partie 3: Directive de adaptation
Ta slovenski standard je istoveten z: CEN/TS 17011-3:2024
ICS:
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.

CEN/TS 17011-3
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
December 2024
TECHNISCHE SPEZIFIKATION
ICS 35.240.20
English Version
Electronic Public Procurement - Architecture - Part 3:
Customisation Guideline
Marchés publics électroniques - Architecture - Partie 3: Elektronische öffentliche Auftragsvergabe -
Directive de adaptation Architektur - Teil 3: Leitfaden für die Anpassung
This Technical Specification (CEN/TS) was approved by CEN on 16 September 2024 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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. CEN/TS 17011-3: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 The challenge of interoperability . 8
4.1 Interoperability through standardization . 8
4.2 Challenges . 8
4.3 The purpose of Usage Specifications and Extension specifications . 9
4.3.1 Extension specification . 9
4.3.2 Usage specification . 9
4.4 Who will develop Usage or Extension specifications and why? . 9
4.5 Managing Usage and Extension specifications . 10
4.5.1 Publication of specifications . 10
4.5.2 Mapping an Extension Specification to syntax . 10
4.5.3 Relation between different specifications . 10
4.5.4 Governance of Extension and Usage specifications . 11
4.5.5 Identification of Extension and Usage specifications . 11
4.5.6 Validation . 11
5 Business process compliance . 12
6 Rules about Usage specifications . 12
6.1 Semantic compliance . 12
6.2 Compliance of a Usage specification . 12
6.2.1 General . 12
6.2.2 What can be specified in a Usage specification . 13
6.3 Compliance of sending or receiving party . 14
6.4 Compliance of an eProcurement document instance . 15
7 Rules about Extension specifications . 15
7.1 Semantic conformance . 15
7.2 Compliance of an Extension specifications . 15
7.2.1 General . 15
7.2.2 What can be specified in an Exention specification . 16
7.3 Compliance of sending or receiving party . 17
7.4 Conformance of an instance document . 17
8 Methodology . 18
8.1 How parties agree on using an Extension or Usage specifications. 18
8.2 Process for defining Extension specifications . 18
8.3 Statement of objectives . 18
8.4 Gathering business requirements. 18
8.5 Mapping against the norms . 19
8.6 Re-assess requirements or process . 19
8.7 List requirements . 19
8.8 Define required changes. 19
8.9 Create specification . 19
8.10 Evaluate type of changes . 20
8.11 Publish extension specification . 20
8.12 Bind to syntax. 20
Bibliography . 21

European foreword
This document (CEN/TS 17011-3:2024) has been prepared by the Technical Committee CEN/TC 440
“Electronic Public Procurement”, the secretariat of which is held by DIN.
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 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.
— 17014-series: eTendering Business Interoperability Specifications, providing a set of
specifications outlining business choreography, transaction, syntax binding specifications and
guidelines required to support the eTendering processes.
— 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 e-Delivery processes.
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 announce this Technical Specification: 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
To enable flexible and streamlined development of the eProcurement specifications, this document has
been designed to provide generic rules applicable to any eProcurement specification, to support
adaptations required by the context, set out either by national rules or by sectorial needs.
It highlights the needs aimed to be covered, the various solutions and the rules they must adhere to so
that interoperability can be achieved.
The terms “shall”, “shall not”, “should”, “should not”, “may”, “need not” “can” and “cannot” are to be
interpreted according Annex H of Part 3 of the CEN-CENELEC Internal Regulations .

extension://efaidnbmnnnibpcajpcglclefindmkaj/https://boss.cen.eu/media/BOSS%20CENELEC/ref/ir3_e.pdf
1 Scope
This document describes:
— the rationale for building customisation supporting business cases that are specific to their business
environment while maintaining organisational and semantic interoperability with the TC 440
specifications;
— the difference between Usage specification and Extension specification;
— a methodology on how to define customisations on:
— BII Transaction specification,
— Business rules,
— Code lists;
— how to claim compliance or conformance to a customisation of a TC 440 specification;
— the connection to the eProcurement Ontology project.
This specification does not describe the detailed process of building an extension.
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 (all parts), Electronic Public Procurement — Catalogue
EN 17015-2, Electronic Public Procurement — Catalogue — Part 2: Transactions
EN 17016 (all parts), Electronic Public Procurement — Ordering
EN 17016-2, Electronic Public Procurement — Ordering — Part 2: Transactions
EN 17017 (all parts), Electronic Public Procurement — Fulfilment
EN 17017-2, Electronic Public Procurement — Fulfilment — Part 2: Transactions
3 Terms and definitions
3.1
agent
person, organization, or system that act in procurement or have the power to act in procurement

Under preparation. Stage at the time of publication: prEN 17015-2.
Under preparation. Stage at the time of publication: prEN 17016-2.
Under preparation. Stage at the time of publication: prEN 17017-2.
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.4]
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
choreography
set of business processes [3.2] having the same goals
3.5
collaboration
interaction between two or more agents [3.1] that result in the exchange of data between the agents
involved as part of a business process [3.2]
3.6
eProcurement document model
involves all the transactions [3.11] used in the Business Processes [3.2] and in the Business Process
Variants [3.3] as described by CEN/TC 440 Electronic public procurement
3.7
Extension specification
describes the use of additional information elements, i.e., information elements not defined in the core
eProcurement document model [3.6], or other alterations that add functionality
Note 1 to entry: The resulting document model will contain information elements that do not form a strict subset
of the core eProcurement document model and the resulting document instance will be semantically conformant
[3.9] with the eProcurement model. An extension specification may also provide additional explanations and
examples.
3.8
semantically compliant
using all or some features of the eProcurement document model [3.6] in accordance with its rules
Note 1 to entry: Based on TOGAF definition of a compliant specification [2].
3.9
semantically conformant
using all or some features of the eProcurement document model [3.6] in accordance with its rules and
extended with additional features.
Note 1 to entry: Based on TOGAF definition of a conformant specification [2].
3.10
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.5]
Note 1 to entry: Additional information: an activity of an agent or a collaboration may cause the transition of one
state to another in a predefined set of next steps.
3.11
transaction
content of data exchanged or shared between the agents [3.1] in a collaboration [3.5]
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.12
Usage specification
describes and delimitates the use of the information elements of the eProcurement document model [3.6]
in a given context
Note 1 to entry: The resulting document instance will be semantically compliant with the eProcurement document
model. A usage specification may also provide additional explanations and examples
4 The challenge of interoperability
4.1 Interoperability through standardization
The eProcurement document model has been carefully designed to meet the commercial requirements
for electronic eProcurement in the vast majority of public procurement situations, whilst also meeting
the needs for an eProcurement instance document in transactions between business enterprises. The
eProcurement document model is expected to meet the needs of EU Member State legal systems for
public procurement regulations. Information elements will usually be structured and allow for
automated processing, although some may only be available in textual form and thus require human
intervention.
The eProcurement document model thus represents the baseline for semantic interoperability in
eProcurement document exchange.
Trading partners are, however, free to organize the use of appropriate extensions comprising additional
information elements and functionalities not included in the eProcurement document model. Such
extensions should preferably be created on a community basis.
4.2 Challenges
A key challenge to the goal of semantic interoperability is that industry sectors have industry specific
requirements and in specific business processes trading partners may require specific information. Also,
if a higher degree of automation is required due to more complex business processes between trading
partners or within a sector, that may also require the support of additional requirements.
An eProcurement document model that would support all possible requirements would be enormous in
size and very complex in its business rules, and thus impractical to implement. In order to relieve
suppliers from having to support data requirements which are only needed for implementing more
complex and specialized eProcurement scenarios and to enable as many participants as possible to take
part in electronic eProcurement (without bilateral arrangements), a focus on the central, cross-industry
requirements for the transmission of a core eProcurement instance document is necessary.
Additional requirements that are not supported in the eProcurement document model could be analysed
and categorized as sector specific and may be added to the semantic data model as an extension. A sector
extension would then contain information elements that are only a concern to that industry sector or to
a specific community.
It should be noted that extended eProcurement instance documents cannot be expected to be processed
by the recipient without prior bilateral arrangement (direct or indirect).
4.3 The purpose of Usage Specifications and Extension specifications
4.3.1 Extension specification
An extension specification is developed with the objective of supporting one or more stated business
requirements that are not or not sufficiently supported by the eProcurement document model. These
business requirements may be due to specific needs in a trading relationship, special sectoral
requirements, specific legal requirements, or any combination thereof.
Each extension specification describes a set of defined additions to the eProcurement document model
and as required to support the business functions or legal requirements that are its objective.
An extension specification is typically a set of additional information elements and/or additional business
rules that, when followed, result in an extended eProcurement instance document that cannot be
correctly processed by the receiver by only following the rules defined for the eProcurement document
model. Consequently, it can only be used through an agreement between the sender and the receiver that
includes an agreement by the receiver to use a specific extension specification. Through such an
agreement the receiver is committed to take those additions into account and process them accordingly.
The main reasons for developing extension specifications include:
— A receiver requires information that is not provided for in the eProcurement document model.
— A sender or an industry sector defines additional business terms and/or rules that are relevant to its
business for those of its customers who require them.
4.3.2 Usage specification
A usage specification describes a set of descriptions about how values are used in the eProcurement
document model.
4.4 Who will develop Usage or Extension specifications and why?
The creation of an extension specification may be driven by different requirements, including but not
limited to the following:
— A buying party who wishes to increase automation in receiving and processing incoming electronic
eProcurement document may require certain additional information elements to be used in order to
provide information that is needed to drive the automation. Such information may include purchase
order identifiers, commodity codes or other details. If the required elements are not within the
eProcurement document model, the buying party may state these requirements as an extension
specification that they provide to their suppliers when asking them to engage in electronic
eProcurement document exchange. If the suppliers agree to support these requirements the buying
party can implement them in its system according to the specification.
— For an industry that uses information elements that are specific to that industry the relevant
community (industry association or a similar party) may initiate a project to define an extension
specification that defines how these specific information elements are used in addition to the
eProcurement document model. This specification then describes the specific requirements of the
industry and how they are supported by additional information elements. This specification can then
be shared by all companies in this industry to support a business process that is common in that
industry.
— A service provider who intends to provide eProcurement document related services such as order
processing, order dispatch or financing may require the purchaser of the service to include
information in the eProcurement document that is additional to the eProcurement document model.
The service provider may specify an extension specification that describes these additional
requirements and require the user of the service to implement them.
— Extension specifications may be developed with a different functional scope than what is supported
in the eProcurement data model.
— An extension specification may be defined to support a specific function that is common across
several industries. As an example: a particular business process where orders and invoices are
matched along with a dispatch advice and/or a receiving advice. The extension specification would
describe the additional information requirement, but this extension specification may be shared
among any party who uses this business process irrespective of its industry.
Extension specifications should preferably not be developed on a bilateral basis, but instead on a
multilateral basis, e.g. sector. Whilst bilateral agreements are possible, European-wide collaboration
among communities, for example through national standardization bodies, should be encouraged to
preserve semantic interoperability.
4.5 Managing Usage and Extension specifications
4.5.1 Publication of specifications
It is recommended that specifications are documented and made publicly available in an appropriate
repository for retrieval and sharing. The availability of such a repository is expected to foster
convergence over time.
It can also be expected that most business cases that require extensions will fall into groups that share
similarities and can be solved in an identical way. It is therefore expected that over time implementers
will have the option of using shared extensions instead of creating their own specific extensions. Such
shared extensions may themselves even become a standard for solving a specific business case. Sharing
of extensions and attempting to reuse existing extensions rather than creating new ones will foster such
convergence. Such convergence through sharing requires the publication of the extension in searchable
repositories.
Repositories for specifications are expected to be linked to the publication of the core eProcurement
document model and are a preferred venue for publishing extensions.
4.5.2 Mapping an Extension Specification to syntax
An extension specification is implemented through a syntax and each specification may be mapped to one
or more syntaxes.
For clarity and to avoid confusion, extension specifications should have the same “look and feel” and use
identical notation and terminology as is used for the core eProcurement document model itself.
Additions and changes documented in an extension specification shall be mapped to the relevant syntax
in accordance with the same syntax binding methodology as is used for the core eProcurement document
model [4].
4.5.3 Relation between different specifications
An extension specification may build on another extension specification or on a usage specification.
A given sector in a particular country may wish to build its extension specification upon an existing
extension specification or a core eProcurement document usage specification in order to emphasize that
not all changes are driven by the sector and also to take advantage of the fact that most trading parties in
that country can be expected to be supporting the core eProcurement document usage specification
already.
When extension specifications are built upon other specifications, they shall clearly state how they vary
from their underlying specification as well as how they vary from the core eProcurement document
model.
4.5.4 Governance of Extension and Usage specifications
Each specification shall be governed by an identified entity that is responsible for its evolution. A
governing entity can be of any type including but not limited to private entities, public organizations,
trade associations, standard developing organizations or open-source organizations.
Whatever the type of the governing party, the party shall be ident
...