SIST EN 17016-1:2024
(Main)Electronic Public Procurement - Ordering - Part 1: Choreographies
Electronic Public Procurement - Ordering - Part 1: Choreographies
This choreographies document specify ordering between Buyer and Seller where the Buyer wants to reach an agreement with the Seller about an order. It specifies a series of activities that govern communication between the parties and refers to the specifications where information and rules that apply are specified.
The various possible behaviours of the Seller and Buyer subsequent to the first order communication are conveyed by variants of this choreography that are specified in 5.2.
Previous activities (e.g. cataloguing) and subsequent activities (e.g. invoicing) are outside the scope of this document. If performed electronically, their implementation is covered by other choreographies.
The identifier of this choreographies document is EN 17016-1:2024.
How to claim compliance to this choreography is specified in 5.2.3.
Elektronisches öffentliches Beschaffungswesen - Bestellung - Teil 1: Choreographien
Dieses Choreographiendokument legt den Bestellvorgang zwischen Käufer und Verkäufer fest, in dessen Rahmen der Käufer eine Vereinbarung mit dem Verkäufer über eine Bestellung treffen möchte. Es legt eine Reihe von Aktivitäten fest, die die Kommunikation zwischen den Parteien regeln, und bezieht sich auf die Spezifikationen, in denen die geltenden Informationen und Regeln festgelegt sind.
Die verschiedenen möglichen Verhaltensweisen von Verkäufer und Käufer nach der ersten Kommunikation im Rahmen einer Bestellung werden durch Varianten dieser Choreographie vermittelt, die in 5.2 festgelegt sind.
Vorgeschaltete Aktivitäten (z. B. Katalogisierung) und nachgeschaltete Aktivitäten (z. B. Fakturierung) befinden sich außerhalb des Anwendungsbereichs dieses Dokuments. Wenn diese elektronisch durchgeführt werden, ist ihre Implementierung von anderen Choreographien abgedeckt.
Der Identifikator dieses Choreographiendokuments ist EN 17016 1:2024.
Wie die Compliance mit dieser Choreographie beansprucht wird, ist in 5.2.3 festgelegt.
Passation électronique des marchés publics - Gestion des commandes - Partie 1 : Chorégraphies
Le présent document sur les chorégraphies spécifie la procédure de gestion des commandes entre un acheteur et un vendeur lorsque l'acheteur souhaite conclure un accord avec le vendeur au sujet d'une commande. Il spécifie une série d'activités qui régissent la communication entre les parties et renvoie aux spécifications où sont spécifiées les informations et les règles applicables.
Les différents comportements possibles du vendeur et de l'acheteur faisant suite aux échanges d'informations dans le cadre de la première commande sont exprimés par des variantes de cette chorégraphie, qui sont spécifiées en 5.2.
Les activités antérieures (par exemple, l'établissement d'un catalogue) et les activités ultérieures (par exemple, la facturation) n'entrent pas dans le domaine d'application du présent document. Toutefois, si elles sont effectuées par voie électronique, leur mise en œuvre est couverte par d'autres chorégraphies.
Le présent document sur les chorégraphies est identifié par la référence EN 17016-1:2024.
Le paragraphe 5.2.3 précise les critères à respecter pour revendiquer la conformité à cette chorégraphie.
Elektronska javna naročila - Naročanje - 1. del: Koreografije
V tem dokumentu o koreografijah je opisano naročanje med kupcem in prodajalcem, v okviru katerega želi kupec doseči dogovor s prodajalcem v zvezi z naročilom. Opisane so dejavnosti, ki urejajo komunikacijo med strankama, in navedene so specifikacije z opisom informacij in pravil, ki jih je treba upoštevati.
Možne oblike vedenja prodajalca in kupca po prvi komunikaciji so predstavljene z različicami te koreografije, ki so opisane v točki 5.2.
Prejšnje dejavnosti (npr. katalogizacija) in nadaljnje dejavnosti (npr. izdajanje računov) ne spadajo na področje uporabe tega dokumenta. Če se izvajajo elektronsko, je njihova izvedba zajeta v drugih koreografijah.
Oznaka tega dokumenta o koreografijah je EN 17016-1:2022.
Dokazovanje skladnosti s to koreografijo je opisano v točki 5.2.3.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-junij-2024
Elektronska javna naročila - Naročanje - 1. del: Koreografije
Electronic Public Procurement - Ordering - Part 1: Choreographies
Elektronisches öffentliches Beschaffungswesen - Bestellung - Teil 1: Choreographien
Passation électronique des marchés publics - Gestion des commandes - Partie 1 :
Chorégraphies
Ta slovenski standard je istoveten z: EN 17016-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 17016-1
EUROPEAN STANDARD
NORME EUROPÉENNE
April 2024
EUROPÄISCHE NORM
ICS 35.240.63
English Version
Electronic Public Procurement - Ordering - Part 1:
Choreographies
Passation électronique des marchés publics - Gestion Elektronisches öffentliches Beschaffungswesen -
des commandes - Partie 1 : Chorégraphies Bestellung - 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 17016-1:2024 E
worldwide for CEN national Members.
Contents Page
European foreword . 5
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Symbols and abbreviated terms . 8
5 Business environment and high level business requirements . 9
5.1 Choreographies (business) Goals . 9
5.2 Business environment . 9
5.2.1 General. 9
5.2.2 Business context . 9
5.2.3 Positioning in EIRA . 10
5.3 Organization and business partners involved . 11
5.4 High level business process requirements . 11
6 Processes . 13
6.1 General. 13
6.2 Business process variants. 14
6.2.1 General. 14
6.2.2 High level business process variants requirements . 17
6.2.3 Claiming compliance . 17
6.3 Business process variant A – Simple ordering . 18
6.3.1 Business process variant A requirements . 18
6.3.2 Business process variant A state machine diagram [informative] . 18
6.3.3 Business process variant A definition . 18
6.3.4 Business Process variant A Scenarios . 19
6.3.5 Business process variant A business rules . 19
6.3.6 Business process variant A key examples [informative] . 20
6.4 Business process variant B – Buyer managed ordering . 20
6.4.1 Business process variant B requirements . 20
6.4.2 Business process variant B state machine diagram [informative] . 20
6.4.3 Business process variant B definition . 21
6.4.4 Business process variant B scenarios . 23
6.4.5 Business process variant B business rules . 23
6.4.6 Business process variant B key examples [informative] . 24
6.5 Business process variant C – Ordering with simple response . 24
6.5.1 Business process variant C requirements . 24
6.5.2 Business process variant C state machine diagram [informative] . 24
6.5.3 Business process variant C definition . 25
6.5.4 Business process variant C scenarios . 27
6.5.5 Business process variant C business rules . 27
6.5.6 Business process variant C key examples [informative] . 27
6.6 Business process variant D – Buyer managed ordering with Seller’s response . 28
6.6.1 Business process variant D requirements . 28
6.6.2 Business process variant D state machine diagram [informative] . 28
6.6.3 Business process variant D definition . 29
6.6.4 Business process variant D scenarios . 31
6.6.5 Business process variant D business rules. 32
6.6.6 Business process variant D key examples [informative] . 33
6.7 Business process variant E – Ordering . 33
6.7.1 Business process variant E requirements . 33
6.7.2 Business process variant E state machine diagram [informative] . 34
6.7.3 Business process variant E definition . 35
6.7.4 Business process variant E scenarios . 37
6.7.5 Business process variant E business rules . 38
6.7.6 Business process variant E key examples [informative] . 38
6.8 Business process variant F – Advanced ordering . 39
6.8.1 Business process variant F requirements . 39
6.8.2 Business process variant F state machine diagram [informative] . 40
6.8.3 Business process variant F definition . 41
6.8.4 Business process variant F scenarios . 44
6.8.5 Business process variant F business rules . 46
6.8.6 Business process variant F key examples [informative] . 48
6.9 Business process variant G – Simplified advanced ordering . 48
6.9.1 Business process variant G requirements . 48
6.9.2 Business process variant G state machine diagram [informative] . 49
6.9.3 Business process variant G definition . 50
6.9.4 Business process variant F scenarios . 53
6.9.5 Business process variant G business rules . 55
6.9.6 Business process variant G key examples [informative] . 56
6.10 Business process variant H – Order Agreement . 57
6.10.1 Business process variant H requirements . 57
6.10.2 Business process variant H state machine diagram [informative]. 57
6.10.3 Business process variant H definition . 57
6.10.4 Business process variant H scenarios . 58
6.10.5 Business process variant H business rules . 58
6.10.6 Business process variant H key examples [informative] . 59
7 BII Transactions involved . 59
7.1 Summary . 59
7.2 Collaborations . 62
7.3 Buyer sends Order (BC-17016-1:2024-1) . 63
7.4 Buyer changes Order (BC-17016-1:2024-2) . 64
7.5 Buyer cancels Order (BC-17016-1:2024-3) . 65
7.6 Seller acknowledges Order (BC-17016-1:2024-4) . 66
7.7 Seller confirms Order (BC-17016-1:2024-5) . 67
7.8 Seller rejects Order (BC-17016-1:2024-6) . 68
7.9 Seller confirms Order Change (BC-17016-1:2024-7) . 69
7.10 Seller rejects Order Change (BC-17016-1:2024-8) . 70
7.11 Seller confirms Order Cancellation (BC-17016-1:2024-9) . 71
7.12 Seller rejects Order Cancellation (BC-17016-1:2024-10) . 72
7.13 Seller accepts Order partially or with changes (BC-17016-1:2024-11) . 73
7.14 Seller changes Order (BC-17016-1:2024-12) . 74
7.15 Buyer confirms Order Response (BC-17016-1:2024-13) . 75
7.16 Buyer rejects Order Response (BC-17016-1:2024-14) . 76
7.17 Buyer confirms Order Change (BC-17016-1:2024-15) . 77
7.18 Buyer rejects Order Change (BC-17016-1:2024-16) . 78
7.19 Seller sends Order Agreement (BC-17016-1:2024-17) . 79
Annex A (informative) Overview of the clauses and subclauses that fall under derivative use
................................................................................................................................................................... 80
Bibliography . 81
European foreword
This document (EN 17016-1:2024) 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 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 document 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
specified 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
This choreographies document specify ordering between Buyer and Seller where the Buyer wants to
reach an agreement with the Seller about an order. It specifies a series of activities that govern
communication between the parties and refers to the specifications where information and rules that
apply are specified.
The various possible behaviours of the Seller and Buyer subsequent to the first order communication are
conveyed by variants of this choreography that are specified in 5.2.
Previous activities (e.g. cataloguing) and subsequent activities (e.g. invoicing) are outside the scope of
this document. If performed electronically, their implementation is covered by other choreographies.
The identifier of this choreographies document is EN 17016-1:2024.
How to claim compliance to this choreography is specified in 5.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 17016-2:— , Electronic Public Procurement — Ordering — 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 act in procurement or have the power to act in procurement
3.2
business process
sequence or network of activities and collaborations between two or more agents
3.3
business process variant
specification of a business process belonging to a choreography
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 having the same goals
Under preparation. Stage at the time of publication: prEN 17016-2:2023.
3.5
collaboration
interaction between two or more agents that result in the exchange of data between the agents involved
as part of a business process
3.6
role
part played by an agent in a particular business process, including its responsibilities (options and
obligations) to perform certain activities and collaborations in that business process
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.
3.7
state
set of options and obligations of the participating agents at a defined step in a business process to perform
specific activities and collaborations
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.8
transaction
content of data exchanged or shared between the agents in a collaboration
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.
4 Symbols and abbreviated terms
ABB Architectural Building Block
EIF European Interoperability Framework
EIRA European Interoperability Reference Architecture
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 this choreography are specified in Table 1:
Table 1 — Business goals
ID Description
G-17016-1:2024-1 Enable trading partners to communicate without a previous bi-lateral
setup or agreement.
G-17016-1:2024-2 Enable the automation of handling orders in a semi-manual environment.
G-17016-1:2024-3 Enable buyers to set up a standardized acquisition process.
G-17016-1:2024-4 Enable SMEs to offer their trading partners the option of exchanging
standardised documents in a uniform way and thereby move all orders
into electronic form.
The main business benefits to be gained by implementing this choreography are specified in Table 2:
Table 2 — Business benefits
ID Description
G-17016-1:2024-5 Realize significant savings both by buyers and sellers through automating
and streamlining in-house processes of ordering and subsequent activities
as well through increasing quality of data exchanged.
G-17016-1:2024-6 Pave the way for the buyer to enforce a formal process of approval and
cost control within its organization.
G-17016-1:2024-7 Facilitate the processing of the invoice and so faster payments
5.2 Business environment
5.2.1 General
The intended scope for this choreography includes public procurement, but the choreography may also
be used in Business to Business (B2B) relations.
This choreography is intended to support use 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 of this document.
The list of the transactions being part of this choreography is defined in Clause 6.
5.2.2 Business context
This choreography belongs to the eOrdering business process that is specified in Figure 1:
Figure 1— Position of the Ordering BII Choreography in the Procurement process
5.2.3 Positioning in EIRA
EIRA (European Interoperability Reference Architecture) provides a reference model that enables
architects to position the IOP (InterOPerability) specifications. This document provides a domain-specific
IOP specification to which any SBB (Solution Building Block) implementing the ABB (Architecture
Building Block) should be compliant to. The positioning of this document in the EIRA context is specified
in Table 3.
IoP specifications provide a valuable source of information to formulate requirements during
architecture development and solution development. By identifying architectural building blocks
through a common terminology, it
— helps reuse of cross domain building blocks such for instance eSignature Verification and Validation
Service, and eTimestamp Creation Service;
— helps synchronization with European solutions such as CEF eDelivery;
— and will provide guidance in using them to provide the prescribed capability enabling, thus managing
and rationalizing IT portfolios.
Table 3 — Positioning in EIRA
EIRA ID Title Domain Interface Scope Modality
Public /Buyer extension of ABB176
Procurement - Organizational
Machine
Ordering - Interoperability
/Seller
Choreography 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 business partners participate in this BII Choreography, acting in the roles as defined in
Table 4 and Figure 2 below.
Table 4 — Roles
Key Role Description
Buyer A role of an agent that awards the contract. Additional information:
Examples of The Buyer may be the role of contracting authority, contracting
entity, a defence contractor, an international organization, or an
organization awarding a contract subsidized by a contracting authority.
Seller A role played by any natural or legal person or public entity or group of such
persons and/or entities, including any temporary association of
undertakings acting on behalf of a seller who sells goods, works or services
to the buyer
Figure 2 — Ordering BII Choreography Roles
5.4 High level business process requirements
Based on the goals and scope of this choreography the following set of high-level requirements is
identified. Each requirement is connected to a goal.
Additionally, requirements of major business processes that are frequently supported within ordering
are listed.
These requirements are relevant for all variants depicted within this choreography and specified in
Table 5.
Table 5 — High level business requirements
Req. ID Requirement statement Ref. to goal
HLR-17016-1:2024-1 A Buyer submits an Order for delivery of goods, G-17016-1:2024-1
services or works to a Seller.
HLR-17016-1:2024-2 Actors involved in the ordering process require a G-17016-1:2024-2
gradual automation of all information exchange
of the ordering process:
Depending on their capabilities, the
organizations may be willing to exchange
electronically only some transactions
participating in the process.
HLR-17016-1:2024-3 Depending on the general rules of a national G-17016-1:2024-1
environment and/or the sector specific
G-17016-1:2024-2
rules/contractual terms actors may be willing to
G-17016-1:2024-3
exchange electronic documents on the basis of
different business processes.
HLR-17016-1:2024-4 Actors involved in the ordering process require a G-17016-1:2024-2
gradual automation of all information exchange
G-17016-1:2024-3
of the ordering process:
Depending on their capabilities, the
organizations may be willing to exchange
electronically only some core information in a
structured manner.
HLR-17016-1:2024-5 Structured Ordering: The Order transaction G-17016-1:2024-2
should support the structured ordering of goods
G-17016-1:2024-3
and services, using free text or use of identifiers.
The information source of the ordered products
may be a (paper or electronic) catalogue.
HLR-17016-1:2024-6 An Order may refer to framework agreement for G-17016-1:2024-1
its items and conditions. Otherwise the Buyer
terms and conditions apply.
HLR-17016-1:2024-7 An Order may contain items (goods or services) G-17016-1:2024-3
with item identifiers or items with free text
description or item specification,
HLR-17016-1:2024-8 Provided that there is a previous contractual G-17016-1:2024-1
agreement between them about the use of
electronic Orders and that it is acceptable on a
legal basis, if the Order is accepted, a contractual
commitment is established between the Buyer
and the Seller
Req. ID Requirement statement Ref. to goal
HLR-17016-1:2024-9 Accounting: The ordering process shall support G-17016-1:2024-6
the allocation of budgets, so the value amounts of
the ordered products may be stated. The buyer
may provide some information that the seller is
required to place on the invoice for aiding and
automating the invoice processing.
HLR-17016-1:2024-10 Invoice verification: The buyer may provide G-17016-1:2024-7
some information that the seller is required to
place on the invoice for aiding and automating
invoice approval.
HLR-17016-1:2024-11 VAT reporting: VAT reporting is not a general G-17016-1:2024-7
requirement on orders. The level of support in
orders is to:
- Enable VAT reporting in invoices by providing
VAT number of buyers in case of reverse charges.
VAT can be stated as an estimate to enable
buyers to state expected value of order. This can
be helpful in automated matching of orders and
invoices. VAT information is informative and
does not affect the terms of trade.
HLR-17016-1:2024-12 Transport and delivery: Only limited support is G-17016-1:2024-3
in scope for transport related information, but it
is recognized that the buyer needs to be able to
provide some information about requested
delivery location (by use of identifiers or full
textual description).
HLR-17016-1:2024-13 Inventory: Supporting inventory management is G-17016-1:2024-3
not in scope, but structured orders based on
catalogues can be used to automate picking at
seller warehouses.
NOTE Payment: Information about pre-payment or arrangement of payment are not considered core
functionality in order and are therefore not supported.
6 Processes
6.1 General
In order to encompass the various maturity levels of organizations, (see HLR-17016-1:2024-2), the
approach is to specify variants of business processes that use a set of activities around exchanging
information in different combinations, still fulfilling the goals set out in 4.1.
The state machine diagram depicted in Figure 3 provides information on the common states for systems
to get in agreement.
Figure 3 — Ordering State machine diagram [informative]
6.2 Business process variants
6.2.1 General
Eight variants are identified as reported in the following table. They allow for supporting different levels
of interoperability maturity of the organizations willing to automate the exchange of information in the
business area or contractual agreements or legal requirements as defined by High level requirement HLR.
The variants combine in various ways the basic processes defined above through various collaborations
between Buyer and Seller as specified in Table 6.
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.
Table 6 — Business process variants
Business Process Short name Description
Variant
BPV-17016-1:2024:A Simple Ordering The Buyer sends an Order to the Seller.
The Seller does not respond to the Buyer.
BPV-17016-1:2024:B Buyer Managed The Buyer sends an Order to the Seller.
Ordering
The Seller does not respond to the Buyer.
The Buyer may send message/s to the Seller to
change/cancel an Order until the Order is fully
delivered.
The Seller does not respond to the Buyer to
accept/reject changes or cancellation.
BPV-17016-1:2024:C Ordering with The Buyer sends an Order to the Seller.
Simple Response
The Seller responds to the Buyer in any case.
The Seller may:
• accept the Order without changes;
• reject the Order.
BPV-17016-1:2024:D Buyer Managed The Buyer sends an Order to the Seller.
Ordering with
The Seller responds to the Buyer in any case.
Seller’s response
The Seller may:
• accept the Order without changes;
• reject the Order.
The Buyer may send message/s to the Seller to
change/cancel a confirmed Order until the Order is
fully delivered.
The Seller responds to the Buyer to accept/reject
changes or cancellation.
BPV-17016-1:2024:E Ordering The Buyer sends an Order to the Seller.
The Seller responds to the Buyer in any case.
The Seller may:
• state that the Order was received;
• accept the Order with or without changes;
• reject the Order.
The Seller may send message/s to the Buyer to change
a confirmed Order until the Order is fully delivered.
The Buyer does not respond to the Seller to
accept/reject the changes.
Business Process Short name Description
Variant
BPV-17016-1:2024:F Advanced The Buyer sends an Order to the Seller.
Ordering
The Seller responds to the Buyer in any case.
The Seller may:
• state that the Order was received;
• accept the Order with or without changes;
• reject the Order.
The Buyer responds to the Buyer to accept/reject the
changes.
The Buyer may send message/s to the Seller to
change/cancel a confirmed Order until the Order is
fully delivered.
The Seller responds to the Buyer to accept/reject the
changes or cancellation.
The Seller may send message/s to the Buyer to change
a confirmed Order until the Order is fully delivered.
The Buyer responds to the Seller to accept/reject the
changes.
BPV-17016-1:2024:G Simplified The Buyer sends an Order to the Seller.
Advanced
The Seller may respond to the Buyer to:
Ordering
• accept the Order with or without changes;
• reject the Order.
The Buyer may respond to the Buyer to accept/reject
the changes.
The Buyer may send message/s to the Seller to
change/cancel a confirmed Order until the Order is
fully delivered.
The Seller may respond to the Buyer to accept/reject
the changes or cancellation.
The Seller may send message/s to the Buyer to change
a confirmed Order until the Order is fully delivered.
The Buyer may respond to the Seller to accept/reject
the changes.
BPV-17016-1:2024:H Order Agreement The Seller sends an Order Agreement to the Buyer.
The Buyer does not respond to the Seller.
A representation of the relationship between the variants can be given by a decision tree (see Figure 4):
Figure 4 — Ordering decision tree [informative]
6.2.2 High level business process variants requirements
Since only one choreography is defined in this document the common requirements for all variants are
those present in 4.4.1.
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. BPV-17016-1:2024:A.
A business process instance is compliant to a specified variant if all activities and collaborations
performed are defined 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 – Simple ordering
6.3.1 Business process variant A requirements
Table 7 lists the process requirements for this variant:
Table 7 — Business process variant A requirements
Req. ID Requirement statement
R-17016-1:2024:A-1 After the Order is sent, no answer is expected from the Seller.
6.3.2 Business process variant A state machine diagram [informative]
In the Simple Ordering variant, the agreement between Buyer and Seller is that the received Order is not
to be confirmed or cannot be Rejected by an explicit message (see Figure 5).
There is only one synchronization state: Received.
Figure 5 — Business process Variant A state machine
6.3.3 Business process variant A definition
Figure 6 represents the definition of the variant.
Figure 6 — Business process Variant A definition
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.
Table 8 reports the description, pre- and post- conditions, exceptions and scenarios of the process:
Table 8 — Business process variant A description
Category Description
Description The Buyer prepares an electronic Order and sends it to the Seller who
receives it.
Pre-conditions The Buyer and the Seller have identified each other.
The Seller has agreed to receive electronic Orders.
Possibly Buyer and Seller have concluded a contract with general
conditions and/or exchanged a Catalogue with product information
and pricing.
Post-conditions An Order has been received by the Seller.
Exceptions Seller’s acceptance or refusal of an Order are handled externally or by
an agreed silent-consent mechanism.
Buyer’s cancellation or change of an Order are handled externally.
Seller’s cancellation or change of an Order are handled externally.
Fulfilment and invoicing processes are handled externally.
Scenarios An Order sent by the Buyer is received by the Seller.
6.3.4 Business Process variant A Scenarios
Table 9 specifies the Business process variant A scenarios.
Table 9 — Business process variant A scenarios
Role Pre-conditions Collaboration Post- Business rules
conditions
Buyer The Seller may Buyer sends Order Order sent Order compliant or
receive Order conformant
Seller Order sent Buyer sends Order Order received Seller’s capability
to receive Orders
6.3.5 Business process variant A business rules
Table 10 specifies the Business process variant A business rules.
Table 10 — Business process variant A business rules
ID Description
BR-17016-1:2024:A-1 The Order shall be compliant or conformant to EN 17016-2:—.
BR-17016-1:2024:A-2 The Seller has implemented a system that is able to handle an
electronic Order and is able to receive it.
6.3.6 Business process variant A key examples [informative]
A Buyer may wish to issue Orders by using structured documents but for sake of adoption does not
require the Sellers to be able to respond to the Order with a structured message.
A Seller wishes to receive orders in a structured format that allows him to import them automatically
into his sales system but the Buyer is not able to receive or process a response from the Seller.
6.4 Business process variant B – Buyer managed ordering
6.4.1 Business process variant B requirements
Table 11 lists the business process variant requirements taken from the basic process requirements:
Table 11 — Business process variant B requirements
Req. ID Requirement statement
R-17016-1:2024:A-1 After the Order is sent, no answer is expected from the Seller.
R
...
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...