III. The ESPD Request document
III.1 ESPD Request Business Requirements
The ESPD-EDM V2.1.1 models the business and information requirements in alignment with the works developed by e-Sens, which uses the identifier Trdm070 to refer to the business requirements regarding the ESPD Request transaction. See formal information requirements related to the ESPD Request transaction in the document Business Requirements: ESPD request transaction (Trdm070), by e-Sens.
III.2 ESPD Request XSD Schema
The ESPD-EDM V2.1.1 uses the UBL-2.2 document named QualificationApplicationRequest.xsd XSD Schema. This schema can be found under the folder dist/xsdrt/maindoc (or the equivalent documented xsd folder).
The figure below shows the XSD Schema defined by UBL-2.2 for the document “Qualification Application Request”. This schema replaces the Schema for the “ESPD Request” document used in the previous versions of the ESPD-EDM.
The figure below shows a diagram representing the UBL-2.2 XSD Schema. Only the first level components of the schema are shown. The inner sub-elements and sub-classes are covered in detail in the following sub-sections of this document.
LEGEND: The figure below enumerates the four different types of optionality and cardinality for the elements of the UBL-2.2 Schema:
III.3 ESPD Request cardinalities
As you can see the UBL-2.2 Schema is quite flexible as, except for a few cases practically all the elements are optional.
The ESPD-EDM model, however, adds a few more restrictions regarding the cardinalities of some elements. These can be seen in the diagram below, which presents the ESPD-EDM V2.1.1 structure for the ESPD Request with its own cardinality restrictions. Notice that ESPD-EDM does not change anything else from the UBL-2.2 Schema.
If you compare both figures you will observe that:
-
The cardinalities of the root common basic components, such as
cbc:ID,cbc:UUID,ProcedureCode, andcbc:QualificationApplicationTypeCodeare different for the ESPD than for UBL-2.2; -
Similarly, the cardinalities of aggregate components like
cac:ContractingParty,cac:ProcurementProjectLotandcac:TenderingCriterionare different to the UBL-2.2 ones.
The cardinality constraints added by the ESPD are not defined in the XSD Schema. In order to control these constraints the ESPD-EDM uses ISO Schematron assertions. The ESPD-EDM V2.1.1 distribution package provides Schematron schemata and CVA files [1] for the validation of the XML instances (folder dist/val).
III.4 Root elements
The table below lists the elements that are expected in the ESPD Response V2.1.1 and provides details on the cardinalities and usage of those elements.
|
A note about the Business Rules identifiers
From this point on in the document, the tables defining classes and its properties refer frequently to business rules. As stated in the e-Sens BIS document, "[..] business rules are sets of rules that clarify the content of instances by stating mandatory fields, fixed values (like code lists), dependency between fields in the same object and dependency between different objects". If you need to well understand where the business rules come from and how they are implemented and executed you should read the following content in the order indicated:
Beware that all theses documents do share the same business rule identifiers (e.g. tbrxx-yyy for Business Requirement Identifiers in ESPDInt, and BR-Type-Id#n for the Test Cases technical rules). |
| Document name: | QualificationApplicationRequest |
|---|---|
Definition 1: |
"A structured electronic business document for requesting qualification information through an ESPD (conform to an ESPD template). Directive 2014/24/EU, Art. 59." (source: ESPD Request transaction (Trdm070)). Document provided by a buyer defining the exclusion and selection criteria for a given procurement procedure. |
Business rule(s): |
None |
File: |
dist/xsdrt/maindoc/UBL-QualificationApplicationRequest-2.2.xsd |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:UBLVersionID |
Identifier |
1 |
Identifies the earliest version of the UBL 2 schema for this document type that defines all of the elements that might be encountered in the current instance. |
Information Requirement: tbr070-002. Rule: Use the value "2.2". Use also "OASIS-UBL-TC" for the schemeAgencyID attribute. Rule scope: Common (BR-OTH-05, 2.BR-OTH-02) |
cbc:CustomizationID |
Identifier |
1 |
Identifies a user-defined customization of UBL for a specific use. tbr070-001. |
Information Requirement: Rule: For the ESPD we use the value “urn:www.cenbii.eu:transaction:biitrdm070:ver3.0”. Compulsory use of the value "CEN-BII" for the schemeAgencyID attribute. Rule scope: Common (BR-OTH-02, BR-OTH-06) |
cbc:ProfileID |
Identifier |
0..1 |
An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. The identification may include the version of the specification as well as any customizations applied. |
Information Requirement: tbr070-002. Rule: Use the value "41". Use also "CEN-BII" for the scheme AgencyID attribute. Rule scope: Common (BR-OTH-07, BR-OTH-02) |
cbc:ProfileExecutionID |
Identifier |
1 |
The identification and version of the ESPD Exchange Data Model used to create the to XML instance. The identification may include the exact version of the specification. |
Information Requirement: tbr070-002. Rule: Compulsory use of the CodeList Rule scope: Common (BR-OTH-01, BR-OTH-01#13, BR-OTH-03) |
cbc:ID |
Identifier |
1 |
An identifier for this document, normally generated by the system that creates the ESPD document, or the organisation responsible for the document (e.g. the buyer, e.g. a contracting authority, or the supplier, e.g. an economic operator). An identifier for this document, normally generated by the system that creates the ESPD document, or the organisation responsible for the document (e.g. the buyer, e.g. a contracting authority, or the supplier, e.g. an economic operator). The identifier enables positive referencing the document instance for various purposes including referencing between transactions that are part of the same process. |
Information Requirement: tbr070-002. Rule: Compulsory use of schemeAgencyID attribute. Use it to identify the organisation responsible for the document. Rule scope: Common (BR-OTH-02) |
cbc:CopyIndicator |
Indicator |
0..1 |
Indicates whether this document is a copy (true) or not (false). |
Information Requirement: tbr070-002. Rule: It is a good practice to use the CopyIndicator component if the same document is forwarded several times to the same or to different destinations. Use it in combination with the UUID identifier: copies of an ESPD document should be identified with distinct UUIDs. |
cbc:UUID |
Identifier |
1 |
A universally unique identifier that can be used to reference this ESPD document instance. |
Information Requirement: tbr070-002. Rule: This UUID will be used to link the ESPD Response to its corresponding ESPD Request (thus its compulsoriness). Copies of a document must be identified with a different UUID. Compulsory use of schemeAgencyID attribute. Rule scope: EXTENDED (BR-OTH-02) |
cbc:ContractFolderID |
Identifier |
1 |
An identifier that is specified by the buyer and used as a reference number for all documents in the procurement process. It is also known as procurement project identifier, procurement reference number or contract folder identifier. A reference to the procurement procedure to which a Qualification request document and the delivered response documents are associated. |
Information Requirement: tbr070-007. Rule: Try always to use the reference number issued by the contracting authority. This number in combination with a registered contracting authority ID (e.g. the VAT number) results in a universally unique identifier of the procurement procedure. Rule scope: BASIC (BR-REG-10), EXTENDED (BR-SC-10) |
cbc:IssueDate |
Date |
1 |
Date when the document was issued by the contracting authority. |
Information Requirement: tbr070-002. Rule: Format "YYYY-MM-DD". |
cbc:IssueTime |
Time |
0..1 |
Time when the document was issued by the contracting authority. |
Information Requirement: tbr070-002. Rule: Format "hh:mm:ss". |
cbc:VersionID |
Identifier |
0..1 |
The version identifying the content of this document. |
Information Requirement: tbr070-014. Rule: Changes in content should entail the modification of the version identifier and a reference to the previous version. |
cbc:PreviousVersionID |
Identifier |
0..1 |
The version identifying the previous modification of the content of this document. |
Information Requirement: tbr070-014. Rule: None |
cbc:ProcedureCode |
Code |
0..1 |
The type of the procurement administrative procedure according to the EU Directives. |
Information Requirement: tbr070-007. Rule: Rule: Compulsory use of attributes listID, listAgencyName and listVersionID. Compulsory use of the code list ProcedureType (values: Rule scope: EXTENDED (BR-SC-10#2, BR-OTH-03, BR-OTH-01, BR-OTH-01#1) |
cbc:QualificationApplicationTypeCode |
Code |
1 |
The type of European Single Procurement Document (ESPD). |
Information Requirement: tbr070-02. Rule: Compulsory use of the code list Rule scope: EXTENDED (BR-OTH-01, BR-OTH-01#2, BR-OTH-03) |
cbc:WeightScoringMethodologyNote |
Text |
0..n |
Free-form text to describing information about Weight Scoring Methodology. |
Information Requirement: tbr070-016 Rule: Used for transparency motives. Provide a text explaining clearly the method that will be used to select those selection criteria that will be weighted. Rule scope: Common (BR-2P-10) |
cbc:WeightingTypeCode |
Code |
0..1 |
A code specifying the type of the Weighting. |
Information Requirement: tbr070-016 Rule: Compulsory use of the code list Rule scope: Common (BR-2P-10) |
cac:ContractingParty |
Associated class |
1 |
The contracting authority or contracting entity who is buying supplies, services or public works using a tendering procedure as described in the applicable directive (Directives 2014/24/EU, 2014/25/EU). |
Information Requirement: tbr070-01. Rule: UBL-2.2 defines multiple cardinality ContractingParties presumably to allow joint procurements. However the ESPD only expects data about one buyer. The decision was made that in case of joint procurement the data collected in the ESPD would be about the leader of the joint procurement procedure. |
cac:ProcurementProject |
Associated class |
0..1 |
An overall definition of the procurement procedure. |
Information Requirement: tbr70-002. Rules: Use this component to identify and describe the procurement administrative procedure.
The BASIC version should not contain a Use this component in case the ESPD is EXTENDED and the procedure is divided into lots. In this case use the |
cac:ProcurementProjectLot |
Associated class |
0..1 |
One of the procurement project lots into which this contract can be divided. |
Information Requirement: tbr70-008. Rule: If there is only one single procurement project lot specified, the ESPD refers then to a procurement procedure without lots. |
cac:TenderingCriterion |
Associated class |
1..n |
A tendering criterion describes a rule or a condition that is used by the contracting body to evaluate and compare tenders by economic operators and which will be used for the exclusion and the selection of candidates to the award decision. |
Information Requirement: tbr70-003, tbr70-009. Rule: (see examples further below in this document) |
cac:AdditionalDocumentReference |
Associated class |
0..n |
A reference to an additional document associated with this document. |
Information Requirement: tbr70-007. Rule: For procurement procedures above the threshold it is compulsory to make reference to the Contract Notice of the procedure published in TED. See section "Reference to the Contract Notice" for a complete example. |
The figure below shows a global view of an ESPD Request XML instance (all nodes have been 'collapsed' to simplify the view):
XML example
The XML snippet below shows how the beginning of an ESPD Request XML instance looks like
<?xml version="1.0" encoding="UTF-8"?>
<QualificationApplicationRequest xmlns="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:espd="urn:com:grow:espd:2.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2 ../xsdrt/maindoc/UBL-QualificationApplicationRequest-2.2.xsd">
<cbc:UBLVersionID schemeAgencyID="OASIS-UBL-TC">2.2</cbc:UBLVersionID>
<cbc:CustomizationID schemeAgencyID="CEN-BII" schemeVersionID="3.0">urn:www.cenbii.eu:transaction:biitrdm070:ver3.0</cbc:CustomizationID>
<!-- The transactional profile where the ESPD is used. ESPD-EDM-V2.1.1 refers to the CEN profile -->
<cbc:ProfileID schemeAgencyID="CEN-BII">41</cbc:ProfileID>
<!-- The identifier of this document provided by the contracing authority system -->
<cbc:ID schemeAgencyID="DGPE">ESPDREQ-DGPE-3b5755dfb8</cbc:ID>
<!-- Indicator of whether this document is an original or a copy. In this case the document is the original -->
<cbc:CopyIndicator>false</cbc:CopyIndicator>
<cbc:UUID schemeID="ISO/IEC 9834-8:2008" schemeAgencyID="EU-COM-GROW" schemeVersionID="4">0fddbf2d-1e33-4267-b04f-52b59b72ccb6</cbc:UUID>
<cbc:ContractFolderID schemeAgencyID="DGPE">PP.20170419.1024-9</cbc:ContractFolderID>
<cbc:IssueDate>2019-11-27</cbc:IssueDate>
<cbc:IssueTime>10:09:11</cbc:IssueTime>
<cbc:VersionID schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">1.0</cbc:VersionID>
<cbc:ProcedureCode listID="ProcedureType" listAgencyName="EU-COM-GROW" listVersionID="2.1.1">OPEN</cbc:ProcedureCode>
<cbc:QualificationApplicationTypeCode listID="QualificationApplicationType" listAgencyName="EU-COM-GROW" listVersionID="2.1.1">EXTENDED</cbc:QualificationApplicationTypeCode>
...III.5 EU and national publications
REQUIREMENT tbr070-007 |
The CA must be able to provide information about official journals or gazettes where the procurement procedure is announced. For procurement projects above the threshold it is compulsory to refer to the Contract Notice published in TED. |
ESPD conformant software applications will have to provide the means for the user to supply references to EU and national publications about the procurement procedure, and notably about the Notices to which the ESPD is related.
Mock-up
The Figure below is a mock-up representation of how to collect the data expected to reference publications on official gazettes or journals. This mechanism can also be used for contracts below the threshold, obviously.
XSD Schema
The ESPD EDM uses the UBL component cac:AdditionalReferenceDocument to allow the inclusion of references to documents that they might consider relevant, and amongst them the reference to the Contract Notice on the TED (for above-the-threshold contracts) and to possible Notices on national journals and boards.
The class used for this, cac:AdditionalDocumentReference ''is a'' cac:DocumentReference class defined in the UBL-2.2 Common Aggregate Components library).
The class cac:AdditionalDocumentReference aggregates a subclass cac:Attachment that is used by ESPD to place the URI, name of the document and descriptions.
Expected elements
As you can see from the XSD Schema the cac:DocumentReference class has a rich data structure. However, to refer to publications such as the TED and national publications, the ESPD most expects at most the following data:
Class name: |
cac:AdditionalDocumentReference |
Definition: |
A reference to an additional document associated with this document. |
Business rule(s): |
Common (BR-COM-10) |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:AdditionalReferenceDocument |
Context of Use: |
In this case this reference points at a document published on the Supplement of the European Official Journal or on a national journal. |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:ID |
Identifier |
1 |
The identifier for the referenced document, generally issued by the entity responsible for the document. |
Information Requirement: tbr070-007. Rule: If the document referenced is a Contract Notice published on TED the ID must follow the scheme defined by the Publications Office: [][][][]/S [][][]-[][][][][][] (e.g. 2015/S 252-461137). If at the time of drafting the ESPD document the Publication Office has not published yet the Contract Notice the value 0000/S 000-000000 value must be used to indicate that a temporary identifier is being used. Rule scope: Common (BR-COM-10#1, BR-OTH-02) |
cbc:UUID |
Identifier |
0..1 |
A universally unique identifier that can be used to reference this ESPD document instance. |
Information Requirement: tbr92-013. Rule: If the referenced document has a UUID to identify its particular instance refer to that UUID here. |
cbc:DocumentTypeCode |
Code |
1 |
The type of document being referenced, expressed as a code. |
Information Requirement: tbr070-007. Rule: For the ESDP-EDM it is compulsory use of the Code List Rule scope: Common (BR-OTH-01, BR-OTH-01#3, BR-OTH-03) |
cbc:DocumentType |
Text |
0..1 |
The type of document being referenced, expressed as text. |
Information Requirement: tbr070-007. Rule: Optionally use the attribute languageID to indicate the language of the text. Use the Code List Rule scope: Common (BR-OTH-01, BR-OTH-01#4, BR-OTH-03) |
cbc:IssueDate |
Date |
0..1 |
Date when the document was issued by the contracting authority. |
Information Requirement: tbr92-013. Rule: Format "YYYY-MM-DD". If available in the referenced document place here the data of publication by the contracting authority. |
cbc:IssueTime |
Time |
0..1 |
Time when the document was issued by the contracting authority. |
Information Requirement: tbr92-013. Rule: If available in the referenced document place here the time of publication by the contracting authority. |
Beware that the ESPD document do not embed the content of referenced documents but instead make a reference to its source. Thus the class DocumentReference aggregates a `cac:Attachment`class that allows for embedding the content or making reference to an external source of the content, which is the preferred way in ESPD (see XSD schema above):
Component name: |
cac:ExternalReference |
Definition: |
A reference to the authentic source of content of this document. |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:AdditionalReferenceDocument/cac:Attachment/cac:ExternalReference |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:URI |
Identifier |
0..1 |
The Uniform Resource Identifier (URI) that identifies where the document is located. |
Information Requirement: tbr070-007. Rule: None. |
cbc:FileName |
Text |
0..1 |
The title of the document. |
Information Requirement: tbr070-007. Rule: Originally this field is the placeholder for the name of the file (e.g. |
cbc:Description |
Text |
0..n |
Short description of the document. |
Information Requirement: tbr070-007. Rule: If the document being referenced is a Notice being published on TED, use two description lines. Use the second description line to place therein the temporary number received from TED. See example and comments below. Rule scope: Common (BR-COM-10#2, BR-COM-10-S10, BR-COM-10-S20, BR-COM-10-S30) |
XML Example
The XML snippet below illustrates how to use the cac:AdditionalDocumentReference in the ESPDRequest XML document to refer to a Contract Notice published in TED and on a national procurement board:
<!--- Root elements eliminated for the sake of brevity -->
<!-- Reference to the Contract Notice published on TED -->
<cac:AdditionalDocumentReference>
<cbc:ID schemeAgencyID="EU-COM-OP">2017/S 142-293520</cbc:ID> (1)
<cbc:DocumentTypeCode listID="DocRefContentType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">TED_CN</cbc:DocumentTypeCode> (2)
<cac:Attachment>
<cac:ExternalReference>
<!-- Beware XML URI fields may require encoded URLs -->
<cbc:URI schemeAgencyID="EU-COM-OP">http://ted.europa.eu/udl?uri%3DTED:NOTICE:293520-2017:TEXT:EN:HTML%026src%3D0</cbc:URI> (3)
<cbc:FileName>Spain-Zamora: Repair and maintenance services</cbc:FileName>
<cbc:Description>Repair and maintenance services. Real estate services.</cbc:Description> (4)
<cbc:Description>293520-2017</cbc:Description> (5)
</cac:ExternalReference>
</cac:Attachment>
</cac:AdditionalDocumentReference>
<!-- Reference to the Contract Notice published on the Spanish Central Government eTendering Platform -->
<cac:AdditionalDocumentReference>
<!-- Contract Notice publishied on the Spanish Central eTendering Platform "PLACE" Plataforma de Contratación del Sector Público -->
<cbc:ID schemeAgencyID="PLACE">3.17/20830.0160</cbc:ID> (6)
<!-- Contract Notice (CN) published on a National Government Official Journal -->
<cbc:DocumentTypeCode listID="DocRefContentType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">NOJCN</cbc:DocumentTypeCode> (7)
<cac:Attachment>
<cac:ExternalReference>
<!-- Beware XML URI fields may require encoded URLs -->
<cbc:URI schemeAgencyID="PLACE">https://contrataciondelestado.es/wps/portal/!ut/p/b1/pY_LDoIwEEW_hQ8wM5S2wJKH5REUVEDbjenCGI3Axvj9gmFrMXF2Nzkncy8okDahHD2XMAYnUL1-3a76eRt6_Ziy4me6LqNIpAS9gxMjKeKm4ekUyQhIA5AQo5-w2WdORNu8rfghSxCzVMRFY7NR57_5-OUC_K-_t9j_CMqMkBkwTfwAhg3bdOguIEfMPQfthedkvoNluB8f5dWmrhJiI3KoQYbhEkYnLA-hUw8hhJ_dqV7pwLLeHJySpA!!/</cbc:URI>
<cbc:FileName>Suministro y transporte de balasto</cbc:FileName>
<cbc:Description>Suministro y transporte de balasto para el tramo Zamora — Pedralba de la Línea de Alta Velocidad Olmedo — Lubián — Ourense. Subtramo 8.</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
</cac:AdditionalDocumentReference>
</QualificationApplicationRequest>| 1 | For TED Notices you must use the Publications Office Official Journal Supplement number in its original format [][][][]/S [][][]-[][][][][][], e.g. 2017/S 142-293520. Notice that the schemeAgencyID is EU-COM-OP (OP standing for 'Publications Office'). |
| 2 | The jurisdiction scope of this document is typified in the Code List DocRefContentType (see file dist/cl/ESPD-CodeLists-V2.1.1 in the distribution package). Beware that the name and content of this Code List has changed from the previous ESPD-EDM version 1.0.2. The code `TED_CEN`means 'Contract Notice published in TeD (Official Journal of the European Publications Office)'. |
| 3 | The ESPD documents never embed the actual content. Rather the content is always referenced from its original source (alignment to the Once-Only-Principle). |
| 4 | The title of the CN has to be placed in the FileName field of the attachment. UBL does not provide a placeholder fo the title of the document. |
| 5 | In the case of publication on the TED, at ESPD Request preparation time, the procurer does not have yet the OJS number, but can receive a temporary CN identifier (Received Notice Number). To save this number in the DocumentReference component create two cbc:Description elements and use the second one to place this Received Notice Number. If you do not have a description for the CN then use a 'dummy' content for the first description, e.g. <cbc:Description>_</cbc:/Description>. |
| 6 | Notice how the schemeAgencyID is used in this example to specify that the national Agency that created this reference to the national publication (e.g. "PLACE" to refer to the ID of the national electronic board where the CN was published). The pattern of the ID is the one created by the Spanish contracting authority. |
| 7 | In this case the code NOJCN means 'Contract Notice (CN) published on a National Government Official Journal' (see file ESPD-CodeLists-V2.1.1) in the distribution package. |
III.6 Contracting Body
Related information requirements
See formal requirements related to the contracting authorities in the e-Sens site: tbr070-001*
Mock-up
In principle, the ESPD-EDM asks for a few data about the procurer (i.e. the contracting authority, body or entity). The essential (compulsory) data for the contracting body are namely the one aimed to identify it, i.e. its official name and the country. The figure below represents a possible GUI interface for these two data. However the UBL specification provides many other data elements some of which may be interesting to include in the ESPD, notably data about the means to contact the contracting body (see below the list of elements possible in the ESPD).
Therefore software applications may take leverage of the richness of UBL-2.2 to collect also data about the contracting authority contact, end-point, and other data possible in the ESPD.
XSD Schema
The UBL-2.2 model provides a component that fits the purpose of holding data about the procurer: the common aggregate component cac:ContractingParty.
The cac:ContractingParty class is a specialisation of cac:Party. Hence, the main data about the procurer is in this associated cac:Party component:
The cac:Party class in turn associates a very rich class that holds the data about the Party address, including the country (see the UBL-2.2 specification for the complete list of fields):
Notice also that the class associated to cac:Party to place the data about how to contact the contracting body:
Expected elements
Class name: |
cac:ContractParty |
Definition: |
The contracting authority or contracting entity who is buying supplies, services or public works using a tendering procedure as described in the applicable directive (e.g. Directives 2014/24/EU, 2014/25/EU). |
Business rule(s): |
Common (BR-REQ-20#1) |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ContractingParty |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:BuyerProfileURI |
Identifier |
0..1 |
URL of the web section, in the contracting body web site, that contains information about the contracting body, the norms it applies when contracting, published calls for tenders, Prior Information Notices and Contract Notices as well as the related procurement documents, contract award notices, etc. |
Information Requirement: tbr070-006. Rule: Notices published at national level shall not contain information other than that contained in the notices dispatched to the Publications Office of the European Union or published on a buyer profile, but shall indicate the date of dispatch of the notice to the Publications Office of the European Union or its publication on the buyer profile (Directive 2014/24/EU, Art. 52.2). |
Class name: |
cac:Party |
Definition: |
Main data placeholder structure for, in this case, the contracting body. |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ContractingParty/cac:Party |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cac:PartyIdentification/cbc:Identifier |
Identifier |
0..1 |
The national identifier of a contracting body as it is legally registered (e.g. VAT identification). |
Information Requirement: tbr070-001. Rule: More than one identifier can be specified. When possible use the VAT identification of the contracting body (see the VIES platform for a EU cross-border national VAT number verification system).
The code list EOIDType
may be used to indicate the type of identifier used as a value of the Rule scope: Common (BR-REQ-20#4, BR-OTH-02) |
cbc:WebsiteURI |
Identifier |
0..1 |
The website of the contracting body. |
Information Requirement: tbr070-006. Rule: For online services (e.g. Web Services, REST services, etc. use the component |
cbc:EndPointID |
Identifier |
0..1 |
Electronic address of the contracting body. |
Information Requirement: tbr070-001. Rule: Use it for online services (e.g. Web Services, REST services, Delivery ID, ftp, etc. For the official web site of the Party use always the |
cac:PartyName/cbc:Name |
Text |
1 |
The name of the contracting body as it is registered. |
Information Requirement: tbr070-001. Rule: Mandatory. Use the official name of the contracting body. The PartyName class has an associated basic element "cbc:Name". See XML example below. Rule scope: Common (BR-REQ-20#2) |
Class name: |
cac:PostalAddress |
Definition: |
Contractinng body address information. |
Business rule(s): |
None |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ContractingParty/cac:Party/cac:PostalAddress |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:StreetName |
Text |
0..1 |
The main address line in an address. Usually the street name and number or post office box. |
Information Requirement: tbr070-006. Rule: None. |
cbc:CityName |
Text |
0..1 |
The common name of a city where the address is located. |
Information Requirement: tbr070-006. Rule: None. |
cbc:PostalZone |
Text |
0..1 |
The identifier for an addressable group of properties according to the relevant postal service, such as a ZIP code or Post Code. |
Information Requirement: tbr070-006. Rule: None. |
cac:Country/cbc:IdentificationCode |
Code |
1 |
A code that identifies the country. The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". It is recommended to use the Country Code ISO 3166-1 2A:2006 representation. |
Information Requirement: tbr070-006. Rule: The country of the contracting body must always be specified. Compulsory use of the code list CountryCodeIdentifier (ISO 3166-1 2A:2006). Rule scope: Common (BR-REQ-20#3, BR-OTH-01, BR-OTH-01#5, BR-OTH-03) |
cac:Country/cbc:Name |
Text |
0..1 |
The name of the country. |
Information Requirement: tbr070-006. Rule: None. |
Class name: |
cac:Contact |
Definition: |
Used to provide contacting information for a party in general or a person. |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ContractingParty/cac:Party/cac:Contact |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:Name |
Text |
0..1 |
The name of the contact point. |
Information Requirement: tbr070-006. Rule: None. |
cbc:Telephone |
Text |
0..1 |
A phone number for the contact point. |
Information Requirement: tbr070-006. Rule: None. |
cbc:Telefax |
Text |
0..1 |
A fax number for the contact point. |
Information Requirement: tbr070-006. Rule: None. |
cbc:ElectronicMail |
Text |
0..1 |
An e-mail address for the contact point. |
Information Requirement: tbr070-006. Rule: None. |
XML example
The XML snippet below shows how an example of how to supply the expected data for the contracting body.
...
<!--- Root elements eliminated for the sake of brevity -->
<cac:ContractingParty>
<cac:Party>
<cbc:WebsiteURI>www.defensa.gob.es</cbc:WebsiteURI>
<cbc:EndpointID>www.defensa.gob.es/?p=3404</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeAgencyID="VIES-AEAT">B82387770</cbc:ID> (1)
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Ministerio de Defensa</cbc:Name> (2)
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Paseo de la Castellana, 109</cbc:StreetName>
<cbc:CityName>Madrid</cbc:CityName>
<cbc:PostalZone>28071</cbc:PostalZone>
<cac:Country><cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="ISO" listVersionID="2.1.1">ES</cbc:IdentificationCode></cac:Country> (3)
</cac:PostalAddress>
<cac:Contact>
<cbc:Name>Responsable de la compra pública</cbc:Name> (4)
<cbc:Telephone>913955000</cbc:Telephone>
<cbc:ElectronicMail>comprapublica@defensa.gob.es</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:ContractingParty>
...| 1 | The contracting body VAT number. The issuer Agency is the Spanish Tax Agency (AEAT). You can use the VIES platform to verify that the VAT number exists and is correct for Spain. |
| 2 | In the ESPD the official name of the contracting body is mandatory. |
| 3 | In the ESPD the country code (ES, in this example) is compulsory. You will need to use this code (ES) to verify the VAT number in the VIES service. |
| 4 | In this example the contracting body specifies a role, instead of the name of a person. |
III.7 Service Provider
REQUIREMENT tbr070-011 |
The ESPD request may contain information of identification regarding an ESPD service provider: Name, Party Identification, Endpoint ID. |
Service providers are officially recognised organisations that can supply ESPD Request documents (on behalf of the contracting body) with pre-filled information about the contracting body and additional information (e.g. liability statements, see tbr070-012)
The ESPD allows the provision of data about the service provider who produced the ESPD Request document (and equally for the ESPD Response document, on behalf of the economic operator).
Since the 2.1.0 version, and unlike to the previous version 1.0.2, the ESPD-EDM, including the current version 2.1.1 does not include the cac:ServiceProvider as a 'document root component'. Instead, it uses the UBL-2.2 cac:ContractingParty/cac:Party associated class cac:ServiceProviderParty.
XSD Schema
Notice that:
-
The
cac:Partyclass aggregates the classcac:ServiceProviderParty; and -
The
cac:ServiceProviderPartyclass 'is a' Party. Hence it aggregates acac:Partyclass too, and uses it to place the main data about the service provider (like name, address, end-point, etc.).
Expected elements
Class name: |
cac:Party |
Definition: |
Main information about the service provider. |
Business rule(s): |
None |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ContractingParty/cac:Party/cac:ServiceProviderParty/cac:Party |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:WebsiteURI |
Identifier |
0..1 |
The website of the service provider. |
Information Requirement: tbr070-011. Rule: Use it for the official web site of the service provider. Reserve the |
cbc:EndpointID |
Identifier |
0..1 |
Electronic address of the service provider. |
Information Requirement: tbr070-011. Rule: Use it for online services (e.g. Web Services, REST services, Delivery ID, ftp, etc. For the official web site of the Party use always the |
cac:PartyIdentification/cbc:ID |
Identifier |
1 |
The national identifier of a service provider as it is legally registered (e.g. VAT identification). |
Information Requirement: tbr070-011. Rule: An identifier for the service provider must always be provided. Compulsory use of the attribute Rule scope: Common (BR-REQ-20#5, BR-OTH-02") |
cac:PartyName/cbc:Name |
Text |
1 |
The name of the service provider. |
Information Requirement: tbr070-011. Rule: The name of the service provider must always be specified. Supply the official registered name of the service provider. Rule scope: Common (BR-REQ-20#6) |
cac:PostalAddress/cac:Country/cbc:IdentificationCode |
Identifier |
1 |
The code that identifies the country of the service provider. |
Information Requirement: tbr070-011. Rule: The country of the service provider must always be specified. Compulsory use of the code list CountryCodeIdentifier (ISO 3166-1 2A:2006). Rule scope: EXTENDED (BR-REQ-20#7, BR-OTH-01, BR-OTH-01#5, BR-OTH-03) |
XML example
The XML snippet below shows how an example of how to supply the expected data for the service provider.
...
<!--- Root elements eliminated for the sake of brevity -->
<cac:ContractingParty>
<cac:Party> (1)
<cac:PartyIdentification><cbc:ID schemeAgencyID="VIES">B82387770</cbc:ID> </cac:PartyIdentification>
<cac:PartyName><cbc:Name>Ministerio de Defensa</cbc:Name></cac:PartyName>
<cac:PostalAddress><cac:Country><cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="ISO" listVersionID="2.1.1">ES</cbc:IdentificationCode></cac:Country></cac:PostalAddress>
<cac:ServiceProviderParty>
<cac:Party>
<cbc:WebsiteURI>http://www.minhafp.gob.es/es-ES/Areas%20Tematicas/Patrimonio%20del%20Estado/Contratacion%20del%20Sector%20Publico/Paginas/ROLECE.aspx</cbc:WebsiteURI>
<cbc:EndpointID>http://www.minhafp.gob.es/ESPD/endpoint</cbc:EndpointID>
<cac:PartyIdentification> (2)
<cbc:ID schemeAgencyID="AEAT">B36699932</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName> (3)
<cbc:Name>Registro Oficial de Licitadores y Empresas Clasificadas (ROLECE)</cbc:Name></cac:PartyName>
<cac:PostalAddress> (4)
<cac:Country><cbc:IdentificationCode listID="CountryCodeIdentifier" listAgencyID="ISO" listVersionID="2.1.1">ES</cbc:IdentificationCode></cac:Country>
</cac:PostalAddress>
</cac:Party>
</cac:ServiceProviderParty>
</cac:Party>
</cac:ContractingParty>
...| 1 | ContractingParty non-compulsory elements have been omitted for the sake of brevity. |
| 2 | The service provider VAT number. The issuer Agency is the Spanish Tax Agency (AEAT). You can use the VIES platform to verify that the VAT number exists and is correct for Spain. |
| 3 | The registered name of the service provider is mandatory. |
| 4 | The country code of the service provider (ES, in this example) is compulsory. You will need to use this code (ES) to verify the VAT number in the VIES service. |
III.8 Procurement Procedure: Basic ESPD
REQUIREMENT |
The contracting authority must be able to provide basic data about the Procurement Procedure |
There are some important differences between the data collected for a Basic ESPD Request and the data that can be required in a Extended ESPD Request.
Mock-up
For the Basic ESDP Request only three basic data are required: the title, a short description and the file (i.e. case) reference number attributed by the Contracting Authority to the procurement procedure.
The mock-up below shows a possible way of collecting this data:
XSD Schema
The figure below is a fragment of the QualificationApplicationRequest XSD Schema. The placeholders for the data expected in the Basic ESPD Request have been highlighted (cbc:ContractFolderID and cac:ProcuementProject).
Expected elements
As already explained when describing the root elements of the QualificationApplicationRequest document, the identification of the procurement procedure is compulsory for the ESPD documents. This is done by specifying the reference number that the contracting authority assigned to the procedure in the element cbc:ContracFolderID.
Class name: |
QualificationApplicationRequest |
Definition: |
"A structured electronic business document for requesting qualification information through an ESPD (conform to an ESPD template). Directive 2014/24/EU, Art. 59." (ESPD Request transaction (Trdm070)) |
Business rule(s): |
None |
File: |
dist/main/xsdrt/UBL-QualificationApplicationRequest-2.2.xsd |
Components |
Type |
Card |
Description |
Requirements |
cbc:ContractFolderID |
Identifier |
1 |
An identifier that is specified by the buyer and used as a reference number for all documents in the procurement process. It is also known as procurement project identifier, procurement reference number or contract folder identifier. A reference to the procurement procedure to which this Qualification document is delivered as a response. |
Information Requirement: tbr070-007. Rule: Compulsory use of schemeAgencyID attribute. Although not mandatory, it is a good practice to identify the document wiht a UUID. Copies of a document should be identified with a different UUID. Rule scope: BASIC (BR-REG-10), EXTENDED (BR-SC-10) |
The rest of the data related to the Basic ESPD Request go in the cac:ProcurementProject class:
Class name: |
cac:ProcurementProject |
Definition: |
An overall description of the procurement procedure. |
Business rule(s): |
None |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:Name |
Text |
0..1 |
A title for the procurement procedure. |
Information Requirement: tbr070-007. Rule: Use the same name that will be used for the Contract Notice. Rule scope: EXTENDED (BR-SC-10#1) |
cbc:Description |
Text |
0..1 |
A descriptive text for the procurement procedure. |
Information Requirement: tbr070-007. Rule: Use the same description that will be used for the Contract Notice. |
XML example
The XML snippet below shows how an example of how to supply the expected data for the service provider.
...
<!--- Root elements eliminated for the sake of brevity -->
<cac:ContractingParty><cac:Party>...</cac:Party></cac:ContractingParty>
<cac:ProcurementProject>
<cbc:Name>Spain-Aljaraque: Repair and maintenance services</cbc:Name>
<cbc:Description>Repair and maintenance services. Real estate services.</cbc:Description>
</cac:ProcurementProject>
...III.9 Procurement Procedure: Extended ESPD
REQUIREMENT |
The CA must be able to provide the CPV codes to which the Procurement Procedure relates in the ESPDRequest |
REQUIREMENT |
The CA must be able to provide the object of the contract and the type of procedure |
The Extended ESPD adds the possibility for the contracting authority to specify a few more data relevant at evaluation time and for the economic operator:
-
The CPV (Common Procurement Vocabulary) codes for the procurement procedure so the contracting authority can assess the classification of the economic operator; and for the economic operator to confirm that the procedure falls under its competences, skills or experience.
-
The 'Object of the contract' (i.e. the type of procurement project: execution of works, supply of products, provision of services). Software applications may use this information to, in a dynamic way, show or hide certain objects from the GUI; or to control the coherence of the XML content. Thus for example, if the object of the contract is 'works' it does not make sense to ask for references related to supplies of goods or services.
-
The 'Type of procedure' (e.g. Open procedure, Restricted procedure, Competitive procedure with negotiation, Competitive dialogue, Innovation partnership). The type of procedure can be used to control how to treat certain selection criteria. Thus for example, the weighting of technical and professional ability criteria is only used in two stages procedures.
Mock-up
The mock-up below show how this could be implemented in an GUI. Notice that more than one CPV code can be supplied by the contracting authority.
XSD Schema
For the Extended ESPD Request, the 'Object of the contract' needs to be expressed as a code. This code is located in the cac:ProcurementProject class. As a matter of fact, the class provides two codes that allow to further refine the object of the contract: the cbc:ProcurementTypeCode and the cbc:ProcurementSubTypeCode. Thus you can specify things like 'Services' and 'Maintenance and repair services, or Land transport services, including armoured car services, and courier services, except transport of mail, or other', for example (see Code List ServicesProjectSubType in the Code Lists file).
The figure below shows the elements that can be used in a Extended ESPD. In blue those elements that are expected. See the UBL-2.2 XSD Schema for more elements in the cac:ProcurementProject class (e.g. the cac:AdditionalCommodityClassification class for other classifications beyond the CPV).
Expected elements
Class name: |
QualificationApplicationRequest |
Definition: |
"A structured electronic business document for requesting qualification information through an ESPD (conform to an ESPD template). Directive 2014/24/EU, Art. 59." (ESPD Request transaction (Trdm070)) |
Business rule(s): |
None |
File: |
dist/main/xsdrt/UBL-QualificationApplicationRequest-2.2.xsd |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:ContractFolderID |
Identifier |
1 |
An identifier that is specified by the buyer and used as a reference number for all documents in the procurement process. It is also known as procurement project identifier, procurement reference number or contract folder identifier. A reference to the procurement procedure to which this Qualification document is delivered as a response. |
Information Requirement: tbr070-007. Rule: Compulsory use of schemeAgencyID attribute. Although not mandatory, it is a good practice to identify the document with a UUID. Copies of a document should be identified with a different UUID. Rule scope: BASIC (BR-REG-10), EXTENDED (BR-SC-10) |
cbc:ProcedureCode |
Identifier |
1 |
The type of the procurement administrative procedure according to the EU Directives. |
Information Requirement: tbr070-007. Rule: Compulsory use of the Code List Rule scope: EXTENDED (BR-SC-10#2, BR-OTH-03, BR-OTH-01, BR-OTH-01#1) |
The rest of the data related to the Extended ESPD Request go in the cac:ProcurementProject class:
Class name: |
cac:ProcurementProject |
Definition: |
An overall description of the procurement procedure. |
Business rule(s): |
None |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:Name |
Text |
0..1 |
A title for the procurement procedure. |
Information Requirement: tbr070-007. Rule: Use the same name that will be used for the Contract Notice. Rule scope: EXTENDED (BR-SC-10#1) |
cbc:Description |
Text |
0..1 |
A descriptive text for the procurement procedure. |
Information Requirement: tbr070-007. Rule: Use the same description that will be used for the Contract Notice. |
cbc:ProcurementTypeCode |
Code |
0..1 |
A code to describe the object of the project (e.g. works, supplies, services, public work concessions, service concessions, other). |
Information Requirement: tbr070-007. Rule: Compulsory use of the Code List Rule scope: EXTENDED (BR-OTH-01, BR-OTH-01#6, BR-OTH-03) |
cbc:MainCommodityClassification |
Class |
0..n |
A class to classify the works, services or supplies. The Extended ESPD uses it to assign CPV codes to works and services. |
Information Requirement: tbr070-007. Rule: Use the element Rule scope: EXTENDED (BR-SC-10#1, BR-OTH-01) |
III.10 Lots - Basic ESPD
REQUIREMENT |
At least one Lot must be always instantiated in the Basic ESPD XML document. If the procurement procedure is not divided into Lots the only lot present in the Basic ESPD XML document represents the procedure, and its Identifier value must be '0'. |
If the procedure is divided into Lots you can create multiple instances of the element ProcurementProjectLot and use it to identify and describe the Lots.
Expected elements
Class name: |
cac:ProcurementProjectLot |
Definition: |
A sub-project into which a procurement procedure can be divided. A procurement project lot has its specific characteristics (e.g. different objectives and different selection criteria) and usually generates its own contract. |
Business rule(s): |
EXTENDED (BR-LOT-30) |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ProcurementProjectLot |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:ID |
Identifier |
1 |
A reference to one or more lots the economic operator is applying for. The original lot definition is part of the call for tender document. The Qualification instance only references the corresponding IDs in order to establish the connection to the call for tender information. |
Information Requirement: tbr070-008. Rule: Compulsory use of schemeAgencyID attribute. Check that the type of the Rule scope: EXTENDED (BR-LOT-10, BR-LOT-30-S10, BR-OTH-02) |
XML Example
In the example below the contracting authority has selected "No Lots", hence the Lot '0'.
<?xml version="1.0" encoding="UTF-8"?>
<QualificationApplicationRequest xmlns="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:espd="urn:com:grow:espd:2.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2 ../xsdrt/maindoc/UBL-QualificationApplicationRequest-2.2.xsd">
<cbc:UBLVersionID schemeAgencyID="OASIS-UBL-TC">2.2</cbc:UBLVersionID>
<cbc:CustomizationID schemeAgencyID="CEN-BII" schemeVersionID="3.0">urn:www.cenbii.eu:transaction:biitrdm070:ver3.0</cbc:CustomizationID>
<cbc:ProfileID schemeAgencyID="CEN-BII">41</cbc:ProfileID>
<cbc:ID schemeAgencyID="DGPE">ESPDREQ-DGPE-3b5755dfb8</cbc:ID>
<cbc:CopyIndicator>false</cbc:CopyIndicator>
<cbc:UUID schemeID="ISO/IEC 9834-8:2008" schemeAgencyID="EU-COM-GROW" schemeVersionID="4">0fddbf2d-1e33-4267-b04f-52b59b72ccb6</cbc:UUID>
<cbc:ContractFolderID schemeAgencyID="DGPE">PP.20170419.1024-9</cbc:ContractFolderID>
<cbc:IssueDate>2019-11-29</cbc:IssueDate>
<cbc:ProcedureCode listID="ProcedureType" listAgencyName="EU-COM-OP" listVersionID="1.0">OPEN</cbc:ProcedureCode>
<cbc:QualificationApplicationTypeCode listID="QualificationApplicationType" listAgencyName="EU-COM-GROW" listVersionID="2.1.1">BASIC</cbc:QualificationApplicationTypeCode> (1)
<!-- Contracting body data left empty for the sake of brevity -->
<cac:ContractingParty>
<cbc:BuyerProfileURI>http://www.defensa.gob.es/isfas/perfilcontr/</cbc:BuyerProfileURI>
<cac:Party/>
</cac:ContractingParty>
<!-- Mandatory Lot of a Basic ESPD -->
<cac:ProcurementProjectLot>
<cbc:ID schemeAgencyID="EU-COM-GROW">0</cbc:ID> (2)
</cac:ProcurementProjectLot>
</QualificationApplicationRequest>| 1 | The type of ESPD is "BASIC". If EXTENDED was specified the presence of more than one lot should be checked and a non-fatal warning should be thrown. |
| 2 | The Basic ESPD requires the presence of one Lot, identified with a '0' to indicate that the procedure is not divided into Lots. Additional Lots may be specified, in which case each Lot needs to be identified differently. |
III.11 Lots - Extended ESPD
REQUIREMENT |
The contracting authority needs to be able to specify the following information: (i) The Lots into which the procedure is divided; (ii) To which lots the tenders may be submitted (all lots, maximum number of lots, only one lot); and (iii) The maximum number of lots that may be awarded to one tenderer. |
XSD Schema
BASIC and EXTENDED ESPD documents share the same UBL-2.2 XSD Schemas (there are not two different sets of XSD Schemas). Thus, for the identification of the Lots, the Extended ESPD uses the same component than for the Basic ESPD:
The rest of information about the lots (“tenders must be submitted for…”, “maximum number of lots”, “maximum number of lots that may be awarded”) is treated as the elements (or properties) of a “Criterion” (component cac:TenderingCriterion) named “Additional information about the Lots”.
As you will see in section IV.5 Mock-ups, IV.6 Data Structures, IV.7 XML examples and tools and further on, this guide uses a spread-sheet-based method to represent the structures of the criteria (and to generate XML template instances of the criteria). The figure below shows the structure that "generates" the XML instance. One important thing to observe in this structure and in the XML example is the use of the Publications Office Code List "BidType" to specify to which Lots the economic operator may bid.
Expected elements
Class name: |
cac:ProcurementProjectLot |
Definition: |
A sub-project into which a procurement procedure can be divided. A procurement project lot has its specific characteristics (e.g. different objectives and different selection criteria) and usually generates its own contract. |
Business rule(s): |
EXTENDED (BR-LOT-30) |
File: |
dist/common/xsdrt/UBL-CommonAggregateComponents-2.2.xsd |
Path: |
/QualificationApplicationRequest/cac:ProcurementProjectLot |
| Components | Type | Card | Description | Requirements |
|---|---|---|---|---|
cbc:ID |
Identifier |
1 |
A reference to one or more lots the economic operator is applying for. The original lot definition is part of the call for tender document. The Qualification instance only references the corresponding IDs in order to establish the connection to the call for tender information. |
Information Requirement: tbr070-008. Rule: Compulsory use of schemeAgencyID attribute. Check that the type of the Rule scope: EXTENDED (BR-LOT-10, BR-LOT-30-S10, BR-OTH-02) |
XML Example
In the example below the contracting authority has specified seven Lots, hence the seven instances of ProcurementProjectLot component.
|
Convention: Lots should always be identified with a sequential number, as in the examples: Lot1, Lot2, … Lot7. |
<?xml version="1.0" encoding="UTF-8"?>
<QualificationApplicationRequest xmlns="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:espd="urn:com:grow:espd:2.1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:specification:ubl:schema:xsd:QualificationApplicationRequest-2 ../xsdrt/maindoc/UBL-QualificationApplicationRequest-2.2.xsd">
<cbc:UBLVersionID schemeAgencyID="OASIS-UBL-TC">2.2</cbc:UBLVersionID>
<cbc:CustomizationID schemeAgencyID="CEN-BII" schemeVersionID="3.0">urn:www.cenbii.eu:transaction:biitrdm070:ver3.0</cbc:CustomizationID>
<cbc:ProfileID schemeAgencyID="CEN-BII">41</cbc:ProfileID>
<cbc:ID schemeAgencyID="DGPE">ESPDREQ-DGPE-3b5755dfb8</cbc:ID>
<cbc:CopyIndicator>false</cbc:CopyIndicator>
<cbc:UUID schemeID="ISO/IEC 9834-8:2008" schemeAgencyID="EU-COM-GROW" schemeVersionID="4">0fddbf2d-1e33-4267-b04f-52b59b72ccb6</cbc:UUID>
<cbc:ContractFolderID schemeAgencyID="DGPE">PP.20170419.1024-9</cbc:ContractFolderID>
<cbc:IssueDate>2019-11-29</cbc:IssueDate>
<cbc:ProcedureCode listID="ProcedureType" listAgencyName="EU-COM-OP" listVersionID="1.0">OPEN</cbc:ProcedureCode>
<cbc:QualificationApplicationTypeCode listID="QualificationApplicationType" listAgencyName="EU-COM-GROW" listVersionID="2.1.1">EXTENDED</cbc:QualificationApplicationTypeCode>
<!-- Contracting body data left empty for the sake of brevity -->
<cac:ContractingParty> <cac:Party/></cac:ContractingParty>
(1)
<!--- This procurement procedure is divided into 7 Lots -->
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot1</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot2</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot3</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot4</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot5</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot6</cbc:ID></cac:ProcurementProjectLot>
<cac:ProcurementProjectLot><cbc:ID schemeAgencyID="EU-COM-GROW">Lot7</cbc:ID></cac:ProcurementProjectLot>
(2)
<!-- Additional information about the Lots supplied by the contracting authority -->
<!-- Criterion:CA Lots -->
<cac:TenderingCriterion>
<cbc:ID schemeID="CriteriaTaxonomy" schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">6a21c421-5c1e-46f4-9762-116fbcd33097</cbc:ID>
<cbc:CriterionTypeCode listID="CriteriaTypeCode" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">CRITERION.OTHER.CA_DATA.LOTS_SUBMISSION</cbc:CriterionTypeCode>
<cbc:Name>CA Lots</cbc:Name>
<cbc:Description>Please take into account the following requirements regarding the lots of this procurement procedure:</cbc:Description>
<cac:TenderingCriterionPropertyGroup>
<cbc:ID schemeID="CriteriaTaxonomy" schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">03cff8d1-4d22-4435-82fa-d6361af84be6</cbc:ID>
<cbc:PropertyGroupTypeCode listID="PropertyGroupType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">ON*</cbc:PropertyGroupTypeCode>
<cac:TenderingCriterionProperty>
<cbc:ID schemeID="CriteriaTaxonomy" schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">847829aa-e70a-45e1-b4d3-e11c3ffaf7a0</cbc:ID>
<cbc:Description>Tenders may be submitted for</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">REQUIREMENT</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">CODE</cbc:ValueDataTypeCode>(3)
<!-- Compulsory use of the Publications Office Code List BidType -->
<cbc:ExpectedCode listID="BidType" listAgencyID="EU-COM-OP" listVersionID="1.0">LOT_ALL</cbc:ExpectedCode> (4)
</cac:TenderingCriterionProperty>
<cac:TenderingCriterionProperty>
<cbc:ID schemeID="CriteriaTaxonomy" schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">dceddc28-0ac8-471b-b954-c376a862ea30</cbc:ID>
<cbc:Description>Maximum number of lots</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">REQUIREMENT</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">QUANTITY_INTEGER</cbc:ValueDataTypeCode>
<cbc:ExpectedValueNumeric>5</cbc:ExpectedValueNumeric>
</cac:TenderingCriterionProperty>
<cac:TenderingCriterionProperty>
<cbc:ID schemeID="CriteriaTaxonomy" schemeAgencyID="EU-COM-GROW" schemeVersionID="2.1.1">4b710530-abea-4ed0-b3fb-f324919c2d62</cbc:ID>
<cbc:Description>Maximum number of lots that may be awarded to one tenderer</cbc:Description>
<cbc:TypeCode listID="CriterionElementType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">REQUIREMENT</cbc:TypeCode>
<cbc:ValueDataTypeCode listID="ResponseDataType" listAgencyID="EU-COM-GROW" listVersionID="2.1.1">QUANTITY_INTEGER</cbc:ValueDataTypeCode>
<cbc:ExpectedValueNumeric>1</cbc:ExpectedValueNumeric>
</cac:TenderingCriterionProperty>
</cac:TenderingCriterionPropertyGroup>
</cac:TenderingCriterion>
</QualificationApplicationRequest>| 1 | This procedure is divided into 7 lots. Hence their automatic identification from Lot1 to Lot7. |
| 2 | This Criterion has one group of properties containing a sub-group where the three requirements about the lots are actually specified: (i) The tenderers may submit tenders for the maximum number of lots; (ii) The Contracting Authority specifies a maximum number of 5 lots; and (iii) one tenderer can not win more than one lot. Notice that each element inside a criterion has a Universally Unique Identifier (UUID): these UUIDs are 'constant', meaning that they are maintained by DG GROW and need to be used compulsory as they were issued by DG GROW. |
| 3 | A code has to be provided to specify whether the economic operator is allowed to submit a tender covering one lot only, more than one but not all, or all of them. |
| 4 | The value for the expected code (see bullet number 3) needs to be chosen amongst the values of the Code List BidType. |
