PEPPOL BIS ESPD (European Single Procurement document)

This document describes the data formats used when trading partners exchange procurement information electronically. It is prepared as part of the initiative taken by the Norwegian “Agency of Public Management and eGovernment” (Difi) within the standardization of electronic procurement.

1. Introduction

1.1. Context

The European Single Procurement Document (ESPD) is a self-declaration document intended for preliminary evidence in a public procurement procedure. The requirements are first set by the Contracting Authority (CA), in an ESPD request which is part of the call for competition.

The Economic Operator (EO) answers the requirements from the Contracting Authority in a corresponding ESPD Response, and sends this ESPD Response to the CA with the tendering documents.

1.1.1. The electronic and structured ESPD documents

This EHF is based on the work done by DG GROW. DG GROW has developed a data model, XSD schemas and validation artefacts (schematron) for the exchange of the ESPD between any Procurement stakeholder’s system. This document illustrates in detail how to use these artefacts in OpenPEPPOL.

This EHF describes two transactions:

ESPDRequest: Document that is sent by the Contracting Authorities to the Economic Operators
ESPDResponse: The document that is filled-in by the Economic Operators stating whether they fulfil or not the criteria required in the ESPD Request, and providing the sources where evidences can be obtained to prove that the criteria are met by this EO.

1.2. Scope of this document

This document explains and illustrates how to implement XML documents based on the Data Model and XSD Schema from the European Commission, as well as any specific requirements for use in the Norwegian marked (EHF specific rules and restrictions). The ESPD data model (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.

1.2.1. Out-of-Scope

Many of the requirements and recommendations expressed in this document MAY NOT be valid for contracts below the threshold. However, from a purely technical point of view, this document MAY be used to understand how the ESPD data model works, and to create, in a normalized way, XML instances containing criteria for contracts below the threshold.

2. The ESPD Exchange Data Model

The ESPD Exchange Data Model (ESPD EDM) re-uses three other models, that were defined in parallel to the ESPD, the Core Criterion Data Model, the Core Evidence Data Model, and the OASIS UBL-2.1 common information components.

The figure below presents a high-level view of this data architecture for the entire ESPD-EDM. The blocks coloured in green represent libraries of components defined by the UBL-2.1 Technical Committee (TC), whilst the rest have been defined from scratch by the EU Commission (COM) ESPD development team. The blocks represented in the figure represents either a document (e.g. ESPDRequest and ESPDResponse) or a library (the rest of the blocks). Per each document or library one XSD Schema has been implemented. Each Schema has been assigned its own namespace and a specific prefix representing the namespace.

Figure 1. High-level view of the ESPD-EDM data architecture

2.1. Schemas used

The table below lists the file names corresponding to each block, schema, namespace and namespace-prefix.

Table 1. Schemas, namespaces and prefixes used by the **ESPDResponse**
Schema name	XSD file names	Namespace	Prefix
ESPDRequest	ESPDRequest-1.0.xsd	urn:grow:names:specification:ubl:schema:xsd:ESPDRequest-1	espd-req
ESPDResponse	ESPDResponse-1.0.xsd	urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1	espd
ESPD Aggregate Components	ESPD-CommonAggregateComponents-1.0.xsd	urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1	espd-cac
Core Criterion Vocabulary Aggregate Components	ESPD-CommonAggregateComponents-1.0.xsd	urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1	ccv-cac
Core Evidence Vocabulary Aggregate Components	CEV-CommonAggregateComponents-1.0.xsd	urn:isa:names:specification:ubl:schema:xsd:CEV-CommonAggregateComponents-1	cev-cac
UBL-2.1 CAC Common Aggregate Components	UBL-CommonAggregateComponents-2.1.xsd	urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2	cac:
ESPD Common Basic Components	ESPD-CommonBasicComponents-1.0.xsd	urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1	espd-cbc:
CCV-CBC Core Criterion Vocabulary Common Basic Components	CCV-CommonBasicComponents-1.0.xsd	urn:isa:names:specification:ubl:schema:xsd:CCV-CommonBasicComponents-1	ccv-cbc:
CEV-CBC Core Evidence Vocabulary Common Basic Components	CEV-CommonBasicComponents-1.0.xsd	urn:isa:names:specification:ubl:schema:xsd:CEV-CommonBasicComponents-1	cev-cbc:
UBL-2.1 Common Basic Components	UBL-CommonBasicComponents-2.1.xsd	urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2	cbc:

2.2. Namespaces

The example below shows how these namespaces and prefixes are specified in the ESPDResponse XSD Schema, as well as how the different layers of schemas specified in the ESPD-EDM data architecture are imported:

Namespaces and prefixes in the ESPDResponse-1.0.xsd Schema

<xsd:schema xmlns="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1" (1)
        xmlns:espd-cac="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1"(2)
        xmlns:espd-cbc="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1"(3)
        xmlns:ccv="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1"(4)
        xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"(5)
        xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"(6)
        xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"(7)
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1"(8)
        elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.2">(9)
        <xsd:import
                namespace="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1"
                schemaLocation="../common/ESPD-CommonAggregateComponents-1.0.xsd"/>
        <xsd:import namespace="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1"
                schemaLocation="../common/ESPD-CommonBasicComponents-1.0.xsd"/>
        <xsd:import
                namespace="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1"
                schemaLocation="../common/CCV-CommonAggregateComponents-1.0.xsd"/>
        <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
                schemaLocation="../common/UBL-CommonAggregateComponents-2.1.xsd"/>
        <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
                schemaLocation="../common/UBL-CommonBasicComponents-2.1.xsd"/>
        <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
                schemaLocation="../common/UBL-CommonExtensionComponents-2.1.xsd"/>
        <xsd:element name="ESPDResponse" type="ESPDResponseType"/>
        <xsd:complexType name="ESPDResponseType">
                <xsd:sequence>
                        <!-- Code ommited for clarity-->

1	Default namespace representing the document ESPDResponse
2	"espd-cac", prefix for the Common Aggregate Components defined by COM for the ESPD, e.g. "espd-cac:EconomicOperatorParty"
3	"espd-cbc", prefix for the Common Basic Components defined by COM for the ESPD, e.g. "espd-cbc:SMEIndicator"
4	"ccv", prefix for the Core Criterion Vocabulary elements, e.g. "ccv:Criterion" (elements belonging to the Core Evidence Vocabulary are used by
5	"cac", prefix for the Common Aggregate Components defined in UBL-2.1, e.g. "cac:ContractingParty"
6	"cbc", prefix for the Common Basic Component defined in UBL-2.1, e.g. "cbc:TypeCode"
7	"ext", default prefix defined in UBL-2.1 for non-standard extensions of the schema (Not used in EHF)
8	targetNamespace matching to the default schema namespace, aligned to UBL practice
9	use of "qualified", "unqualified" and "version" defaults aligned to the best practices, as in UBL

The example below illustrates the header of an ESPD Response XML document instance that implements the namespaces of the above schema:

Declaration of the namespaces and prefixes in the ESPD Response XML document instance

<espd:ESPDResponse

    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
    xmlns:ccv-cbc="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonBasicComponents-1"
    xmlns:cev-cbc="urn:isa:names:specification:ubl:schema:xsd:CEV-CommonBasicComponents-1"
    xmlns:cev="urn:isa:names:specification:ubl:schema:xsd:CEV-CommonAggregateComponents-1"
    xmlns:espd="urn:grow:names:specification:ubl:schema:xsd:ESPDResponse-1"
    xmlns:espd-cbc="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonBasicComponents-1"
    xmlns:ccv="urn:isa:names:specification:ubl:schema:xsd:CCV-CommonAggregateComponents-1"
    xmlns:espd-cac="urn:grow:names:specification:ubl:schema:xsd:ESPD-CommonAggregateComponents-1">

Example of use of the namespace prefixes in the ESPD Response XML document instance

<!-- code ommited for clarity -->

<ccv:Requirement responseDataType="EVIDENCE_URL">
    <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">f4313bb6-21b6-499e-bdff-debe10e11d2c</cbc:ID>
    <cbc:Description>URL</cbc:Description>
    <ccv:Response>
        <cev:Evidence>
            <cev:EvidenceDocumentReference>
                <cbc:ID schemeAgencyID="EU-COM-GROW">abf94e2d-f2cd-4d8f-8654-6d19d2892458</cbc:ID>(1)
                <cac:Attachment>
                    <cac:ExternalReference>
                        <cbc:URI>www.skatteetaten.no</cbc:URI>
                    </cac:ExternalReference>
                </cac:Attachment>
            </cev:EvidenceDocumentReference>
        </cev:Evidence>
    </ccv:Response>
</ccv:Requirement>

<!-- code ommited for clarity -->

1	Notice that in the XML instance namespaces that are not referred to in the XSD schema of the ESPDResponse document are needed as they instantiate elements from other inner schemata of the data architecture, e.g. "cev:Evidence"

2.3. The Core Criterion and Core Evidence Data Models and Vocabularies

When creating a new ESPD Request XML document, the Contracting Authority (CA) specifies the series of exclusion and selection ''criteria'' that the Economic Operator (EO) has to satisfy for a specific Procurement Project. In the ESPD Response, the Economic Operator (EO) MAY provide where to get evidences that prove it satisfies the criteria required by the CA.

Two new data models were defined from scratch by the European Commission (COM), the Core Criterion Data Model and the Core Evidence Data Model. Once implemented as XSD schemata these Data Models are named ''Core Criterion Vocabulary'' and ''Core Evidence Vocabulary''. Both Data Models (and therefore the vocabularies too) are interrelated.

From the modelling perspective the main difference between the ESPDRequest and the ESPDResponse is that the ESPDRequest does not use the Response element, and therefore neither the XML Core Evidence Vocabulary.

2.4. Detailed ESPD data model

Below is an overview of the ESPD data model, showing the business information content and cardinality. The classes marked in blue are not used by the ESPD Request, only by the ESPD Response transaction. The classes that are white, are used by both the ESPD Request and the ESPD Response.

3. Criterion

Criteria are at the core of the ESPD and is used to describe a condition that the economic operator has to fulfil in order to not be excluded and be selected as a candidate for awarding in a procurement procedure.

The two main groups of Criteria relevant for the ESPD are the ones required in the Directive, Exclusion and Selection criteria. This section gives a detailed view on how to specify each of those criteria. Its content is aligned to the Norwegian ESPD standard form establishing the standard form for the European Single Procurement Document.

3.1. Core Criterion Data Models and Vocabularies

The UML diagram below shows in detail the classes of the Core Criterion used in the ESPDRequest XML document.

Figure 2. UML diagram

The above UML diagram SHOULD be interpreted as follows:

One Criterion contains one or more Groups of Requirements
One Criterion MAY be linked to a specific Legislation
One Group of Requirements contains one or More Requirements

Example of criterion

<ccv:Criterion>
    <cbc:ID schemeID="CriteriaID" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0"
        >61874050-5130-4f1c-a174-720939c7b483</cbc:ID>(1)
    <cbc:TypeCode listID="CriteriaTypeCode" listAgencyID="EU-COM-GROW" listVersionID="1.0.2"
        >CRITERION.EXCLUSION.CONFLICT_OF_INTEREST.PROCEDURE_PREPARATION</cbc:TypeCode>
    <cbc:Name>Direct or indirect involvement in the preparation of this procurement
        procedure</cbc:Name>
    <cbc:Description>Has the economic operator or an undertaking related to it advised the
        contracting authority or contracting entity or otherwise been involved in the preparation
        of the procurement procedure?</cbc:Description>
    <ccv:LegislationReference>(2)
        <ccv-cbc:Title>DIRECTIVE 2014/24/EU OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 26
            February 2014 on public procurement and repealing Directive 2004/18/EC</ccv-cbc:Title>
        <cbc:Description>Directive 2014/24/EU</cbc:Description>
        <ccv-cbc:JurisdictionLevelCode listID="CriterionJurisdictionLevel"
            listAgencyID="EU-COM-GROW" listVersionID="1.0.2"
            >EU_DIRECTIVE</ccv-cbc:JurisdictionLevelCode>
        <ccv-cbc:Article>57(4)</ccv-cbc:Article>
        <cbc:URI>http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32014L0024</cbc:URI>
    </ccv:LegislationReference>
    <ccv:RequirementGroup>(3)
        <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0"
            >77ae3f29-7c5f-4afa-af97-24afec48c5bf</cbc:ID>
        <ccv:Requirement responseDataType="INDICATOR">(4)
            <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW"
                schemeVersionID="1.0">974c8196-9d1c-419c-9ca9-45bb9f5fd59a</cbc:ID>
            <cbc:Description>Your answer?</cbc:Description>
        </ccv:Requirement>
        <ccv:RequirementGroup pi="GROUP_FULFILLED.ON_TRUE">
            <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0"
                >73f0fe4c-4ed9-4343-8096-d898cf200146</cbc:ID>
            <ccv:Requirement responseDataType="DESCRIPTION">
                <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW"
                    schemeVersionID="1.0">e098da8e-4717-4500-965f-f882d5b4e1ad</cbc:ID>
                <cbc:Description>Please describe them</cbc:Description>
            </ccv:Requirement>
        </ccv:RequirementGroup>
    </ccv:RequirementGroup>
</ccv:Criterion>

1	UUID from Criteria Taxonomy
2	Legislation reference
3	Requirement group
4	Requirement with expected response type (INDICATOR)

3.2. Criterion structure and the taxonomy

This EHF ESPD is based on the ESDP datamodel from the EU commission, and its method of structuring the criterions. Each criterion has a defined set of requirement groups and requirements, all documented by the EU Commission in the Criteria Taxonomy.

Please note that a file with all criteria and their corresponding Norwegian translation are provided, to enable the Norwegian text in user interfaces.

Please note that requirement groups can be nested within other requirement groups.

The following "rules" has been established on how to build up a data structure:

3.2.1. Taxonomy

Respect the structure for each criterion in the Criteria Taxonomy

3.2.2. Indicator

The first requirement of a requirement group is reserved to ask a question where the response is an INDICATOR (boolean true or false).

Example of indicator in first requirement

<ccv:RequirementGroup>
    <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">7458d42a-e581-4640-9283-34ceb3ad4345</cbc:ID>
    <ccv:Requirement responseDataType="INDICATOR">(1)
        <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">c1347b74-1872-4060-a6db-f4044edcd7c4</cbc:ID>
        <cbc:Description>Is this information available electronically?</cbc:Description>
        <ccv:Response>
            <ccv-cbc:Indicator>false</ccv-cbc:Indicator>
        </ccv:Response>
    </ccv:Requirement>

    <!-- Code omitted for clarity -->

1	First requirement of the group has expected response type INDICATOR

3.2.3. Use of attribute `pi`

The attribute pi of the requirement group element is used to determine if the requirements and nested requirement groups must be answered expicitly or not.

The attribute has the following possible values:

GROUP_FULFILLED.ON_TRUE: If the INDICATOR is set to true, the group and nested sub-groups must be answered. This is the case for all the exclusion criteria.
GROUP_FULFILLED.ON_FALSE: If the INDICATOR is set to false, the group and nested sub-groups must be answered. Valid for some of the selection criteria.

Example of use of pi-attribute

<ccv:RequirementGroup>
    <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">7c637c0c-7703-4389-ba52-02997a055bd7</cbc:ID>
    <ccv:Requirement responseDataType="INDICATOR">
        <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">974c8196-9d1c-419c-9ca9-45bb9f5fd59a</cbc:ID>
        <cbc:Description>Your answer?</cbc:Description>
        <ccv:Response>
            <ccv-cbc:Indicator>false</ccv-cbc:Indicator>(2)
        </ccv:Response>
    </ccv:Requirement>
    <ccv:RequirementGroup pi="GROUP_FULFILLED.ON_TRUE">(1)
        <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">f5276600-a2b6-4ff6-a90e-b31fe19dae41</cbc:ID>
        <ccv:Requirement responseDataType="DATE">
            <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">ecf40999-7b64-4e10-b960-7f8ff8674cf6</cbc:ID>
            <cbc:Description>Date of conviction</cbc:Description>

        </ccv:Requirement>
        <ccv:Requirement responseDataType="DESCRIPTION">
            <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">7d35fb7c-da5b-4830-b598-4f347a04dceb</cbc:ID>
            <cbc:Description>Reason</cbc:Description>

            <!-- Code omitted for clarity -->

1	`ccv:RequirementGroup/@pi` set to GROUP_FULFILLED.ON_TRUE
2	The indicator is set to false, so explicit answer to this group must not be sent

Attribute `pi` not used

If the attribute pi is not used, the requirement group must be answered

Example of pi-attribute not used

<ccv:Criterion>
    <cbc:ID schemeID="CriteriaID" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">0d62c6ed-f074-4fcf-8e9f-f691351d52ad</cbc:ID>
    <cbc:TypeCode listID="CriteriaTypeCode" listAgencyID="EU-COM-GROW" listVersionID="1.0.2">CRITERION.OTHER.EO_DATA.RELIES_ON_OTHER_CAPACITIES</cbc:TypeCode>
    <cbc:Name>EO relies capacities</cbc:Name>
    <cbc:Description>Does the economic operator rely on the capacities of other entities in order
     to meet the selection criteria set out under Part IV and the criteria and rules (if any)
     set out under Part V below?</cbc:Description>
    <ccv:RequirementGroup>(1)
        <cbc:ID schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">e688f7d6-dcef-4726-bc61-052e63ead60f</cbc:ID>
        <ccv:Requirement responseDataType="INDICATOR">
            <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">7f18c64e-ae09-4646-9400-f3666d50af51</cbc:ID>
            <cbc:Description>Your answer</cbc:Description>
            <ccv:Response>
                <ccv-cbc:Indicator>false</ccv-cbc:Indicator>
            </ccv:Response>
        </ccv:Requirement>
    </ccv:RequirementGroup>
</ccv:Criterion>

1	`ccv:RequirementGroup/@pi` not present

3.3. Criteria structure

The flow-chart below illustrates the structure of the criteria

Legend

Figure 3. General data-structure design for criteria and requirements with a ''yes'' or ''no'' answer"

Interpretation

This criterion has two main groups of requirements (G1: Breach? and G2: Online Evidence);
The first group of requirements has one requirement and one sub-group or requirements;
If the response to the requirement is "Yes" (ON TRUE) the EO will have to provide the date of the conviction, the reason, who was convicted and for how long. If the response is "No", then the EO will proceed providing data about whether there’s online evidence or not regarding to the absence of conviction (if that is possible).
This behaviour repeats per each subgroup of requirements: the deepest subgroup of the structure for the group 1 will have to be filled by the EO in case a requirement has a "Yes" in the response to the requirement Self-Cleaning.

4. Evidence

Evidence is used by the economic operator to refer to a trusted source of proofs that supports the stated response to a criterion requirement.

In the ESPD Exchange Data Model (ESPD EDM) the Evidence class is part of the Response to a Requirement, as shown in the XSD diagram below

4.1. Core Evidence Data Models and Vocabularies

The UML diagram below shows in detail the classes of the Core Evidence used in the ESPD Response XML document.

Figure 4. UML diagram

Example of evidence

<ccv:Requirement responseDataType="EVIDENCE_URL">(1)
    <cbc:ID schemeID="CriterionRelatedIDs" schemeAgencyID="EU-COM-GROW" schemeVersionID="1.0">03bb1954-13ae-47d8-8ef8-b7fe0f22d700</cbc:ID>
    <cbc:Description>URL</cbc:Description>
    <ccv:Response>
        <cev:Evidence>
            <cev:EvidenceDocumentReference>
                <cbc:ID schemeAgencyID="EU-COM-GROW">a77cd875-3fc9-46eb-8792-b2ed8ad29638</cbc:ID>(2)
                <cac:Attachment>
                    <cac:ExternalReference>
                        <cbc:URI>www.brreg.no</cbc:URI>(3)
                    </cac:ExternalReference>
                </cac:Attachment>
            </cev:EvidenceDocumentReference>
        </cev:Evidence>
    </ccv:Response>
</ccv:Requirement>

1	Response fulfillment indicator
2	Evidence document identifier
3	Evidence document URI

5. Description of selected information blocks

This chapter describes selected blocks of information that is used in both the ESPD Request and Response transaction, providing valid snippets of xml code.

5.1. Contracting body

Definition

The contracting authority or contracting entity who is buying supplies, services or public works using a tendering procedure as described in the anskaffelsesforskriften and forsyningsforskriften.

The contracting body must be identified, hence information about the party is required, such as party name, identification, endpoint id, and country.

The ESPDRequest uses the aggregate element cac:ContractingParty to represent information on the contracting body, but uses only a reduced subset of its element. The XSD Schema however imports the entire aggregate element, but only the elements shown in the example below, is expected in the ESPD Request

Example of contracting body

<cac:ContractingParty>
    <cac:Party>
        <cbc:EndpointID schemeID="NO:ORGNR">991825827</cbc:EndpointID>
        <cac:PartyIdentification>
            <cbc:ID schemeID="NO:ORGNR">991825827</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>Name of CO</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
            <cac:Country>
                <cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="EU-COM-GROW" listName="CountryCodeIdentifier" listVersionID="1.0.2">NO</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
    </cac:Party>
</cac:ContractingParty>

5.2. Economic Operator

Definition

Economic operator means any natural or legal person or public entity or group of such persons and/or entities, including any temporary association of undertakings, which offers the execution of works and/or a work, the supply of products or the provision of services on the market

The ESPDResponse was explicitly designed to hold data about one single Economic Operator. Thus, the ESPDResponse Exchange Data Model associates a class EconomicOperatorParty as a placeholder for the data related to only one Economic Operator (EO) that tenders solely to a procurement project, to one of the EOs that tender as part of a group (e.g. a Consortium), or to one possible sub-contractor of the EO.

Consortia grouping more than one EO need to draft and submit as many ESPDResponses as Economic Operators and sub-contractors participate in the tender.

Example of economic operator

<espd-cac:EconomicOperatorParty>
    <espd-cbc:SMEIndicator>false</espd-cbc:SMEIndicator>
    <espd-cac:RepresentativeNaturalPerson>
        <espd-cbc:NaturalPersonRoleDescription>Daglig leder</espd-cbc:NaturalPersonRoleDescription>
        <cac:PowerOfAttorney>
            <cac:AgentParty>
                <cac:Person>
                    <cbc:FirstName>Jens</cbc:FirstName>
                    <cbc:FamilyName>Jensen</cbc:FamilyName>
                    <cac:ResidenceAddress>
                        <cbc:CityName>Oslo</cbc:CityName>
                        <cac:Country>
                            <cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="EU-COM-GROW" listName="CountryCodeIdentifier" listVersionID="1.0.2">NO</cbc:IdentificationCode>
                        </cac:Country>
                    </cac:ResidenceAddress>
                </cac:Person>
            </cac:AgentParty>
        </cac:PowerOfAttorney>
    </espd-cac:RepresentativeNaturalPerson>
    <cac:Party>
        <cbc:EndpointID schemeID="NO:ORGNR">987654325</cbc:EndpointID>
        <cac:PartyIdentification>
            <cbc:ID schemeID="National_Number">987654325</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>Edisys</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
            <cbc:StreetName>Hovedgaten 32</cbc:StreetName>
            <cbc:CityName>Bergen</cbc:CityName>
            <cbc:PostalZone>1234</cbc:PostalZone>
            <cac:Country>
                <cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="EU-COM-GROW" listName="CountryCodeIdentifier" listVersionID="1.0.2">NO</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
    </cac:Party>
</espd-cac:EconomicOperatorParty>

5.3. Additional Document Reference

The ESPD reuses this UBL-2.1 component to allow both the contracting body (in the ESPDRequest) and the economic operator (in the ESPDResponse) to include references to documents that they might consider relevant including in the XML instances of both types of documents.

The ESPD uses the following data for referencing additional documents:

The document ID;
The issue date and time;
The document type code;
A title for the document; and
A description of its content and/or intended purpose; and
The URL where to access its content.

Example of additional document reference used in the ESPDRequest XML document.

<cac:AdditionalDocumentReference>
    <cbc:ID schemeAgencyID="EU-COM-GROW" schemeAgencyName="DG GROW (European Commission)" schemeVersionID="1.1">18/00001</cbc:ID>(1)
    <cbc:DocumentTypeCode listID="ReferencesTypeCodes" listAgencyID="EU-COM-GROW" listVersionID="1.0">NGOJ</cbc:DocumentTypeCode>(2)
</cac:AdditionalDocumentReference>

1	Doffin referanse
2	The code for this type of content

All ESPD Response instances MUST always include an Additional Document Reference indicating the TeD reference number of the Contract Notice the ESPD is related to. This reference number MUST be specified in the field cbc:ID of the element cac:AdditionalDocumentReference component, and MUST follow the scheme defined by the Publications Office: [][][][]/S [][][]-[][][][][][] (e.g. 2015/S 252-461137).

Example of additional document reference used in the ESPDResponse XML document.

<!-- Reference to the corresponding ESPD Request -->

<cac:AdditionalDocumentReference>
    <cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID" schemeAgencyID="EU-COM-GROW" schemeAgencyName="DG GROW (European Commission)" schemeVersionID="1.1">fd8b7a4f-9ecb-4605-b4b9-c011055a7767</cbc:ID>(1)
    <cbc:IssueDate>2018-01-09</cbc:IssueDate>(2)
    <cbc:IssueTime>09:08:23</cbc:IssueTime>(3)
    <cbc:DocumentTypeCode listID="ReferencesTypeCodes" listAgencyID="EU-COM-GROW" listVersionID="1.0">ESPD_REQUEST</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>

<!-- Reference to the Contracting notice in TED -->
<cac:AdditionalDocumentReference>
    <cbc:ID schemeID="ISO/IEC 9834-8:2008 - 4UUID" schemeAgencyID="EU-COM-GROW" schemeAgencyName="DG GROW (European Commission)" schemeVersionID="1.1">2018/S
     123-123456</cbc:ID>(4)
    <cbc:DocumentTypeCode listID="ReferencesTypeCodes" listAgencyID="EU-COM-GROW" listVersionID="1.0">TED_CN</cbc:DocumentTypeCode>(5)
    <cac:Attachment>
        <cac:ExternalReference>
            <cbc:Description>Test description</cbc:Description>
        </cac:ExternalReference>
    </cac:Attachment>
</cac:AdditionalDocumentReference>

1	UUID for the ESPD Request
2	Issue date of the ESPD Request
3	Issue time of the ESPD request
4	Ted reference number of the Contract Notice
5	Document type code