I. Introduction
I.1 Objectives and scope
I.1.1 The Directive
Article 59 of the new Public Procurement Directive 2014/24/EC (henceforth 'the Directive') introduced a new concept, the European Single Procurement Document (ESPD) which is a self-declaration document intended for preliminary evidence in a public procurement procedure. By mapping out equivalent certificates between MS, the ESPD replaces certificates issued by public authorities or a third party involved in a procedure. It is thus a valuable facilitator for cross-border participation of a greater number of potential operators in public procurement procedures and a valuable tool for integrating the European Single Market.
The European Commission (EC) has developed a data model and 'semantic assets' for the exchange of the ESPD between any Procurement stakeholder’s system. This document illustrates in detail how to use the model and assets in compliance with the Directive.
The model, named ESPD-EDM (standing for European Single Procurement Document - Exchange Data Model) defines two electronic (XML) documents:
The ESPD Request, a document providing information about the contracting authority, the procurement procedure and the exclusion and selection criteria established for the procurement procedure.
The ESPD Response, the document that is filled-in by the Economic Operators stating whether they fulfill or not the criteria required in the ESPDRequest, and providing the sources where evidences can be obtained to prove that the criteria are met.
This guide is intended to facilitate the understanding of the model underlying the implementation of the ESPD Request and ESPD Response XML documents. With that objective in mind the reader is provided with examples and rules relating to how the content of ESPD XML document should look like and be processed.
The content of the guide is mainly addressed to the development teams from the Member States, economic operators, information providers or any other party interested in understanding how the ESPD Exchange Data Model works and how to use it to produce XML instances of ESPD Request and ESPD Response documents.
I.1.2 Contracts above the threshold and below the threshold
The Directive (namely Article 4) regulates in detail those public procurement procedures which values of contract exceed certain amounts. These amounts, also known as 'thresholds', vary depending on the type of the contract and of the administration level of the contracting authority.
Those contracts that fall under this article 4 of the Directive are called contracts 'above the threshold', and the rest are known as contracts 'below the threshold'.
The ESPD-EDM is rich and flexible enough so as to allow ESPD instances for contracts above and below the threshold. However this document is oriented exclusively to illustrate how to create ESPD electronic documents for contracts above the threshold.
I.2 ESPD conformant solutions
The main objective of the ESPD documents is to reduce the administrative burden and lead to considerable simplification of participation in public procurement procedures for buyers and suppliers. In order to make full use of the ESPD concept, Member States (MS) and private sector companies (service providers) are developing software and on-line services to help contracting authorities and economic operators draft interoperable ESPD electronic documents. These solutions will reduce that burden by removing the need to produce a substantial number of certificates and documentation related to exclusion and selection criteria. This will answer to obstacles reported by many suppliers and especially SMEs.
For these software solutions to be interoperable they will have to conform to the indications set in this guide.
The ESPD International Knowledge Base (ESPDint) is a consortium formed by Member States, Universities and private organisations the objectives of which are to develop (i) a formal specification for the CEN BII profile 56 and ESPD requirements by DG GROW; and (ii) a software solution for the edition and exchange of ESPD electronic documents.The software solutions provided by the ESPDInt initiative refers to this XML instantiation guide. In turn, this ESPD-EDM XML implementation guide is aligned with the specification produced by the ESPDint initiative. Thus:
-
Formal requirements introduced in this guide are taken from (and point at) the requirements specified in the document BIS 41 - European Single Procurement Document; whereas
-
Formal definitions are taken from the ESPD-VCD Domain Vocabulary.
I.3 The ESPD Profile
The ESPD profile realises the ESPD process, which is is part of the qualification process in the pre-awarding process area. This is represented in the diagram below:
The roles that participate as business partners in this process are mainly:
-
The Buyer (or ESDP requester) normally a governmental organisation like a contracting authority who prepares the procurement procedure requirements in a ESPD Request (electronic document
QualificationApplicationRequest); and -
The Supplier (i.e. economic operators), or ESPD Providers acting on behalf of them, who answer in an ESPD Response (electronic document
QualificationApplicationResponse).
This other figure below shows the choreography of the business process implemented by the profile. The choreography of business collaborations defines the sequence of interactions when the profile is run within its context.
I.4 Basic and Extended ESPDs
REQUIREMENT |
The CA must be able to select the type of ESPD (basic or extended) |
This version of the eESPD makes the difference between “basic” and “extended” ESPD, introduced in the previous v2.1.0.:
Basic ESPDs are those XML document instances the structure and content of which are strictly adjusted to the terms expressed in the Annex 2 of the Commission Implementing Regulation (EU) 2016/7: Standard form for the European Single Procurement document (ESPD).
A Basic ESPD usually refers to documents and information that are external; i.e. it uses sentences like "mentioned in the Contract Notice published or the Contract Documents". The criteria of a Basic ESPD are all defined in eCertis and their structure never changes.
In a Extended ESPD all the information needed for an ESPD Request is either contained in other parts of the document or the document refers to the authentic online source from where to obtain it. Thus the criteria and requirements that are particular to the MS or to the contracting authority, generic to all Procurement Procedures or particular of the Procurement Procedure, are explicitly mentioned or defined in the ESPD Request document.
Additionally, in a Extended ESPD the Member State and the contracting authority are able to introduce requirements that are particular to the national legislation or the procurement procedure. Extended eESPDs confer the contracting authorities a greater flexibility when preparing their eESPD Request documents.
Thus, in the case of exclusion grounds, the Member States can define in eCertis national exclusion criteria and link them to the corresponding European criteria defined in the Directives.
In the case of selection criteria, the contracting authority may introduce requirements for certain requirements (e.g. regarding turnovers, financial ratios, or references) to specify expected minimum amounts, specific types of ratios, minimum number of references, or other requirements).
This document provides descriptions about some of these situations, mock-ups and XML examples to illustrate the differences between Basic and Extended ESPDs and to clarify when and how to use them.
See also section "III. The ESPD Request document" for details on how to specify the type of ESPD in an XML instance of an ESPD Request document.
Mock-up
Software applications need to be aware of this feature introduced by the V2.1.0 of the ESPD-EDM. Depending on whether the ESPD Request document that is being prepared is Basic or Extended, a software application should behave in different ways; e.g. for Extended ESPD documents, the application should allow the contracting body to define requirements for some selection criteria that are specific to the procurement procedure.
One suggestion for a Graphical User Interface (GUI) aimed at editing ESPD Request documents is to facilitate the contracting body the selection of the type of ESPD Request in an initial page:
