Public API

---

The public API is the only interface to use the Central Business Process Engine that is the core unit of infrastructure. The API is a CQRS interface that provides programmatic access to BPE. It provides predictable URLs for accessing resources, and uses built-in HTTP features to receive commands and return responses. This makes it easy to communicate with. The API accepts JSON or form-encoded content in requests. It returns JSON content in all of its responses, including errors.

CQRS approach

In traditional architectures, the same data model is used to query and update a database. That's simple and works well for basic CRUD operations. In more complex applications, however, this approach can become unwieldy. For example, on the read side, the application may perform many different queries, returning data transfer objects (Data Transfer Objects or DTOs) with different shapes. Object mapping can become complicated. On the write side, the model may implement complex validation and business logic. As a result, you can end up with an overly complex model that does too much. Another potential problem is that read and write workloads are often asymmetrical, with very different performance and scale requirements.

Command and Query Responsibility Segregation (CQRS) - an architecture which addresses these problems by separating reads and writes into separate models, using commands to update data, and queries to read data.

• Commands should be task based, rather than data centric. Commands may be placed on a queue for asynchronous processing, rather than being processed synchronously.
• Queries never modify the database. A query returns a DTO that does not encapsulate any knowledge.

Compared to the single data model used in CRUD-based systems, the use of separate query and update models for the data in CQRS-based systems simplifies design and implementation.

For greater isolation, the read and the write data could be physically separated. In that case, the read database can use its own data schema that is optimized for queries. For example, it can store a materialized view of the data, in order to avoid complex joins or mappings. It might even use a different type of data store. If separate read and write databases are used, they must be kept in sync. Typically this is accomplished by having the write model publish an event whenever it updates the DB.

Command API

This section explain how the interfaces to the provided services are called.

Request example

All requests for Form Service are use POST-method (same as for parent Operation Service)

Specific Params

Set of specific parameters required in particular case. Described below.

Response examples

For all valid queries, the response will have a common structure:

For all invalid queries, the response will have a common structure:

Activities

This section describes the array of activities that can be performed through the API in each of the processes stages.

Budgeting

Budgeting is a stage where CA should assess and define the scope of his needs as well as disclose and describe existing fundings for each defined need. With this description CA will allow system to validate all future contracting processes from assessed needs and available funding perspective as well as control and disclose the progress of execution of this or that expenditure item, analyzing planned and announced procedures, conducted and executed or/and terminated contracts and made transactions.

All needs could be divided into separate expenditure items - groups of needs united under common classification and procuring period for each specific buyer. For example: buyer needs to procure 25 different kinds of furniture (on this stage - doesn't matter which exactly) during next year - all these needs are expenditure item «Furniture» under CPV-code 391. Thus, from technical point of view such groups, expenditure items, are aggregated data-sets, based on common CPV-code and budget period (most often - year). Each defined expenditure item, on a annual financial plans’ level, has available fundings. Thus, next step of budgeting is description of such available fundings. The ‘amount’ available under this expenditure item for this period is the sum of all sources of funding and its amounts, identified for this expenditure item.

Expenditure Item (EI)

Create ei

country

Identifier of country of jurisdiction according to ‘country’ codelist

Update ei

ocid	OCID of EI to be updated

Funding Source (FS)

Create fs

ocid	OCID of parent EI

Update fs

ocid	OCID of parent EI
fs-ocid	OCID of FS to be updated

Planning

Once the EI and its FSs defined and described, CA is able to plan and schedule needed procurements - contracting processes for this subject classification - CPV group. Particular EI should be indicated as a ground (meta-parent) of future contracting process. Then, depending of CAs procurement strategy, Periodic Notice or Prior Information Notice could be prepared and published. Within this notice (PN or PIN) allocated by CA himself budget must be specified as a set of identified from the list of available under used EI funding sources together with allocated amounts - separate for each selected FS. The sum of all specified amounts of all indicated funding sources is a budget of future contract that will be conducted under this contracting process.

Planning Notice (PN)

Create pn

country	Identifier of country of jurisdiction according to ‘country’ codelist
pmd	Identifier procurementMethodDetails according to ‘pmd’ codelist

Update pn

ocid	OCID of parent Contracting Process
pn-ocid	OCID of PN to be updated

Announcement

Depending on type of procedure, method of procurement, geography and the legal basis, the attribute composition of the model can be adjusted, but its general logic remains unchanged for all types of procedures. The contracting process based on competitive procedure is commonly carried out in the following sequence:

Business Process Diagram

Creating a tender, CA determines key fields of the yet-to-be announced procurement, uploads tender documentation, with the requirements to the procurement object indicated as that which determines winner evaluation criteria.

Contract Notice (CN)

Create cn

country	Identifier of country of jurisdiction according to ‘country’ codelist
pmd	Identifier procurementMethodDetails according to ‘pmd’ codelist

Create cn based on pn

ocid	OCID of parent Contracting Process
pn-ocid	OCID of PN to be updated

Update cn

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated

Clarification

Clarification period is separately distinguished in the procurement procedure during which participants can ask questions regarding the procurement requirements, demand issue resolution, and submit a claims, while CA can provide answers to questions and introduce changes into the procurement conditions. The duration of the clarification period and offer submission is determined by CA but in any case can not be less than those, prescribed by Law.

Create enquiry

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated

Create answer

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
enquiry-id	ID of parent enquiry

Submission

Once the clarification period is over the CA can no longer introduce changes into the Contract Notice. Economic Operators submit offers that are confidential.

Create bid

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated

Update bid

An Economic Operator may modify its electronic bid by submitting online within submission deadlines a new information regarding previously submitted offer in accordance to the electronic submission procedures.

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
bid-id	ID of the bid

Update winning bid

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
bid-id	ID of the bid

Withdraw bid

An Economic Operator may withdraw his electronic bid by submitting online within submission deadlines a request for cancellation of previously submitted offer.

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
bid-id	ID of the bid

Awarding

Once the submission period is over and participants can not longer submit or update their bids, system will disclose all submitted bids, generate set of qualification envelopes (awards) and launch the awarding period for this contracting process. System will automatically verify eligibility (based on available via external bus data) of each tenderer whose bid was disclosed according to rules of dispatch under current procurement method.

Those bids that have been passed eligibility check, will go to the technical qualification. All the other that failed go to automatic exclusion. In case if after submission period end there is nothing to disclose (no bids were submitted) or all submitted bids failed, system will automatically change this specific lot of this contracting process to status “unsuccessful”.

Create award

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated

Update award

CA sequentially reviews bids that are eligible considering its technical compliance, beginning with first, suggested by the system. Depending on award criteria (priceOnly/costOnly/MEAT) system will rank eligible bids and suggest them in order of admissibility: from the most to the least acceptable by applicable criteria. If the most acceptable bid is in compliance with the CA’s technical requirements, CA determines this offer as a qualified and goes to next step - financial evaluation. If it is not, CA confirms his decision to disqualify the participant, and declines such an offer. Then the system suggests to qualify the next offer from the acceptance perspective.

If qualified offer is in compliance with the CA’s financial requirements, CA determines this offer as a winner. If it is not in compliance, CA confirms his decision to disqualify the offer on this (evaluation) stage, and declines such an offer. Then the systems suggests to qualify the next offer  from the acceptance perspective.

If all the offers were declined by CA either on qualification step or on evaluation one and upon the completion of complaining process (review period) this specific lot of this contracting process automatically changes to ‘unsuccessful’.

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
award-id	ID of award to be updated

Submit awarding protocol

Once winner is selected for each lot, CA submits the evaluation protocol which, in its turn, indicates the end of awarding process. As a result of submission of evaluation protocol, system will automatically generate a set of Submission for each awarded lot, change evaluation stage to ‘awarded’ and launch the complaining process - review period.

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
lot-id	ID of the parent lot

Update Contract Award Notice

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
can-id	ID of the CAN to be updated

Confirm Contract Award Notice

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
can-id	ID of the CAN to be updated

Cancel Contract Award Notice

ocid	OCID of parent Contracting Process
cn-ocid	OCID of CN to be updated
can-id	ID of the CAN to be updated

Contracting 

Create awarded contract

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be updated

Update awarded contract

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be updated

Issue contract to be approved

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be issued

Approve contract

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be approved
request-id	ID of initial

Activate approved contract

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be activated

Cancel awarded contract

ocid	OCID of parent Contracting Process
ac-ocid	OCID of the contract to be cancelled

Query API

Public Point is a service that displays records and data-sets in read-only mode. Only information allowed for publication by the current legislation is displayed (i.e. it does not show bids of the bidders until the opening session (disclosure) of the bids.

AccessPoint

All of the document uploading API endpoints follow the same set of rules and uses single access point.

Flow Description

Retrieving data

To retrieve a list of data or individual entity data-set use GET-request parameterized with one or more options sent to corresponding end-point.

• offset - timestamp of latest updates
• limit - quantity of elements per each package of data
• order - criteria for sorting results

Getting list of all data

By default all data returned from public point are sorted by modification time (from oldest to newest).

Limiting number of Tenders returned

You can control the number of data entries in the entity feed (batch size) with limit parameter. If not specified, data is being returned in batches of 100 elements.

Batching

The response contains ‘offset’ element. This is the parameter you have to add to the original request you made to get next page. If next page request returns no data (i.e. empty array) then there is little sense in fetching further pages.

Synchronizing

It is often necessary to be able to synchronize changes of Central Unit with local database. The default sorting “by modification date” together with Batching mechanism allows one to implement synchronization effectively. The synchronization process can go page by page until there is no new data returned. Then the synchronizer has to pause for a while to let Central Unit register some changes and attempt fetching subsequent page.

Getting individual entity information

To get a individual entity data set (as Record Package) provide your GET-request with unique ID of particular entity:

API for Competitive Procedures

Introduction

The public procurement process in Moldova includes both online and offline procedures.

In online procedures based on a selective method:

• 1. The Contracting Authority (CA) publishes a notice;
• 2. Interested Economic Operators (EOs) must submit a request to participate in response to this notice;
• 3. Only those EOs which are pre-selected by the CA may submit offers.

This report describes how the MTender (the System) may be used for a restricted procedure according to the European Union Public Procurement Directives .

This is a procedural use-case and no individual transactions are defined. Reference is made to other profiles, in which the transactions and the transaction information requirements are listed and defined.

At the system level, it is necessary to implement several online procedure based on a selective procurement method. These are:

• Procedure for utilities;
• Restricted tender.

Business processes

The following diagrams show the sequence of the business processes implemented under this profile and defines the sequence of interactions.

Common flow of an online selective procedure for utilities

The following Business Process Model Notation (BPMN) covers the common flow of the procurement procedure for utilities based on a selective method:

Common flow of restricted tender

The following BPMN covers the common flow of a restricted procurement procedure based on a selective method:

Technical design

In order to implement each use case in accordance with its’ BPMN in the System, the technical aspects described in this section should be taken into consideration.

Preparation of the Contract Notice

The general flow of an online procedure based on a selective method starts with a line in the annual procurement plan (Prior Information Notice or simplified Prior Notice - PAPI-1-1: Procurement initiation - prior notices) based on a described need (PAPI-0-1: Expenditure Item) and the sources of financing (PAPI-0-2: Funding Source) declared for such a need.

The preparation of a Call for Expressions of Interest (EoI) under an online procurement procedure based on a selective method consists of the preparation and publication of a Contract Notice (CN) based on a prior notice.

For the preparation of the CN, the following crucial parameters shall be determined as follows:

Command model attribute	Procurement for utilities	Restricted procedure
tender.procurementMethod	selective	selective
tender.procurementMethodDetails	gpa	rt

State-chart diagram

The life cycle of a cpPhase for the multi-stage non-repetitive procedure based on a selective method consists of the following states:

Pre-qualification

Along with the publication of a CN for an online procurement procedure based on a selective method, the time-frame for the submission of expressions of interest by EOs shall be established in the pre-qualification phase.

A separate preQualification block shall be included into a command model:

Submission of expressions of interest by interested EOs

EOs can submit an EoI during a certain period of time indicated in the tender documents. Each EoI shall fulfill all the requirements detailed through the qualification criteria stated by the CA.

Such requests must be based on the following submission schema:

4.2.2 Enquiries - requests and clarifications

EOs can send requests for clarification during a certain period of time indicated in the CN enquiryPeriod, according to PAPI-12-1: Clarification of conditions.

Initiation of pre-qualification

Disclosure of submissions

When enough EoI are received from EOs, the submitted EoI must be disclosed using the submissions array according to the following schema:

Establishment of a period for qualification by the CA

In order to indicate that the qualification phase of a procurement process has started, a separate qualificationPeriod.startDate shall be added into a preQualification:

Qualification of envelopes

Along with the initiation of the pre-qualification phase by the CA, a set of qualifications must be established against each EoI received in order to allow the CA to reflect the decision taken regarding the EoI.

Such objects are initially established with status:pending and statusDetails:awaiting. Since no order is stated for the pre-qualification sequence, the CA can qualify the received EoI randomly.

Declaration of non-conflict of interest

Before starting the qualification phase, all members of the evaluation panel (see Profile PAPI-11-6: Evaluation panel) shall provide a declaration of non-conflict of interest according to the common flow described in Profile PAPI-8-1: Declaration of absence of conflict of interest by CA.

Qualification of EoI

Once all declarations of non-conflict of interest against a specific EO which submitted an EoI are provided by the evaluation committee, the related qualification for this EoI may be switched into statusDetails: consideration.

Consideration

The CA shall update the qualification with all the required meta-data, being allowed to:

• Add qualification.documents if needed;
• add text qualification.description where any justification is needed;
• add qualification.internalID (if any).

Indication of a decision

Once the revision of a specific EoI is complete and the related qualification is fully updated with all relevant data, the CA shall switch this qualification into one of the following states, reflecting the decision taken:

• qualification.statusDetails: active means that the EoI is qualified (that is, that the EO will be invited to submit an offer);
• qualification.statusDetails: unsuccessful - means that the EoI is disqualified.

Qualification protocol

Once the CA has completed the revision of the received EoI and all the qualifications are updated with relevant meta-data, the CA must indicate the end of the pre-qualification phase by submitting a qualification protocol.

Completion of qualification

If no blockages arise during the stand-still period (out of system), the CA can initiate the end of the pre-qualification phase by initiating the second stage of the selective procedure, that is, the tendering phase. In order to do so, a tenderPeriod for this second stage needs to be defined by the CA:

The completion of the qualification period will have the consequences described in the following sections.

Completion of the qualification period

An indicator of the completion of the qualificationPeriod will be added into preQualification.qualificationPeriod:

Finalization of the pre-qualification phase

All qualifications shall be switched into final statuses:

• qualification.status: pending / statusDetails: active → qualification.status: active / statusDetails: none means that the related EoI is qualified and the EO is invited to submit a commercial offer;
• qualification.status: pending / statusDetails: unsuccessful → qualification.status: unsuccessful / statusDetails: none means that the related EoI is disqualified.

All related submitted EoI shall be switched into the following statuses:

• qualification.status: active → submission.status: valid;
• qualification.status: unsuccessful → submission.status: disqualified.

Completion of the pre-qualification phase

The result of the pre-qualification phase shall be reflected with:

• preQualification.status.complete, where a number enough of EOs who sent an EoI are invited to submit an offer;
• preQualification.status.unsuccessful, where the pre-qualification phase has been completed in a negative way due to the lack of EoI by EOs or because all the received EoI were disqualified.

Tendering

Invitations for qualified EOs

Once the pre-qualification phase and the following stand-still period are over, and when the tendering phase is initiated by the CA in order to disclose the offers by the short-list of invited EOs, a separate array invitations will be generated with a separate element for each invited EO (that is, those with qualification.status: active):

Only those EO that have been invited are allowed to submit a tender. Any tender submitted by EOs that have not been invited shall be refused automatically.

Submission of offers by invited EOs

Each invited EO is allowed to submit an offer within a given tender.tenderPeriod. Each offer shall fulfil all the requirements defined by the criteria related to every item or lot, providing an array of requirementResponses.

Each offer includes:

• A reference to the EO’s profile, previously sent with the EoI (in case of two-stage procedures);
• a set of documents of the offer, specifying the types of documents for their future splitting into different "envelopes";
• the financial value of the offer;
• a set of required responses according to the criteria specified by the CA (for example, related to the subject of procurement; related to the delivery and post-delivery, etc.).

Such requests are based on the bid schema:

All the received offers remain confidential and closed until the expiration of the tendering period tender.tenderPeriod.endDate. Once the tender.tenderPeriod.endDate is achieved, offers cannot be submitted, withdrawn or amended.

Electronic Auction

Electronic Auctions (eAuction) can be used as a part of the process, according to Profile PAPI-11-5: Electronic auctions.

Evaluation

Disclosure of proposals

When enough offers have been received, the disclosure of these offers shall be reflected in a bids array according to the following schema:

Establishment of a period for evaluation

A separate object awardPeriod must be added into a tender when the specific start date for awarding is automatically set:

Evaluation of offers

Along with the establishment of the tender.awardPeriod.startDate, a set of awards must be established for each offer received in order to allow the CA to reflect the decision taken for these offers. Such objects are based on the award schema and are initially defined with status:pending for all.

Initial ranking based on award criteria

Depending on tender.awardCriteria and tenderAwardCriteriaDetails, offers can or cannot be initially automatically ranked according to Profile PAPI-7-2: Initial ranking for evaluation.

Evaluation by the CA

Once an initial ranking is available (according to the awarding methodology applied), the CA can start the manual evaluation of offers according to either PAPI-7-1: Simple manual evaluation or PAPI-7-3: Scoring function - advanced evaluation.

Completion of the procedure

The evaluation process ends with the submission of a protocol that reflects the results of the tendering procedure. Once evaluation is completed and each received offer’s state is updated, the CA submits the evaluation protocol which indicates the publication of the Contract Award Notice (CAN) according to Profile PAPI-9-1: Award decision - contract award notice. This protocol has to be submitted for each lot separately.

Initiation of a contract

See PAPI-10-1: Initiation of a contract

Cancellation of a procedure

See PAPI-3-3: Termination of a procedure

Tutorial

This tutorial explains step-by-step how to use both the (Central Database Unit) CDUs’ command and query APIs in order to fulfil all the aforementioned requirements and perform all the functionality covered in this Profile

Pre-conditions

The procurement process for online procedures based on a selective method begins the same way as for any other procurement method: from the line in the annual procurement plan (Prior Information Notice (PIN) or simplified Prior Notice (PN) - PAPI-1-1: Procurement initiation - prior notices) based on the need described (PAPI-0-1: Expenditure Item) and the sources of financing (PAPI-0-2: Funding Source) declared for this need.

5.2 Getting started

This tutorial shows step-by-step a sequence of all actions and requests a contributor (NEPP) needs to conduct throughout the entire process covered by the use-cases.

Create a CN on a PN

To prepare a CN for a procurement procedure based on a limited method previously created cpPhase.PN to be updated with all data according to a relevant command model.

Get X-OPERATION-ID

According to CDUI-2-1: X-OPERATION-ID, for the identification of an operation before starting and, in particular, for the preparation of a CN, a unique operations’ identified, X-OPERATION-ID, shall be requested:

Registration of documentation

According to CDUI-3-1: Registration of a document, the CA can register document for the future cpPhase.CN before it is created:

Send a request for the creation of a CN based on a PN

To introduce a new CN for a procurement procedure based on the limited method createCNonPN.selective-online command, a model should be used for the preparation of POST-request for BPE with the following parameters:

/do/cn/cpid/ocid?country=...&pmd=...

Where:

• cpid - OCID of parent Contracting Process (cProcess)
• ocid - OCID of a prior notice under this contracting process
• country - Identifier of country of jurisdiction according to ‘country’ codelis
• pmd - Identifier procurementMethodDetails according to ‘pmd’ codelist

Important! Find below the main differences of a command model between a selective procedure and an open procedure:

Pre-qualification

A separate preQualification block shall be included into the CN in order to initiate a call for EoIs:

No tender period

Since there is no period for the submission of offers at the first stage of the selective procedure, tenderPeriod is supposed to be excluded from the request.

Second-stage parameters

The CA is allowed to limit the number of candidates to be invited to submit an offer in the second stage of the procedure. In this case, pre-selection instead of pre-qualification will be applied in order to evaluate the EOs which submit an EoI. In order to limit the number of candidates, secondStage building block shall be included within the tender:

Other criteria

Technique for the reduction of the number of candidates according to the limits of the secondStage:

Together with the request, information needed for future automated evaluation can be expressed:

PAPI-2-5: Evaluation panel

A set of CA evaluation panel could be announced.

PAPI-11-1: Award criteria

The set of criteria may include different types of requirements, used in different ways and for different reasons.

PAPI-11-4: Conversions

When a scoring function is used, a set of verifiable conversions might be needed for future ranking and evaluation of offers.

Feed Point Response

As a result of the command execution, a separate ocds-record is formed in the system describing the Contract Notice created. The system will inform the contributor (according to the CDUI-5-1: Backward notification) with the following message:

Upload documentation

Having both the documents registered and the cpPhase.CN created, the CA can upload documents according to CDUI-3-2: Upload of a document. Document uploading is an iterative process.

Request full result

Once all previous actions are finalised, the newly created CN is now available in a Public Point:

Amend a CN

Once a CN is published, only non-significant changes and amendments are available according to PAPI-3-1: Corrigendum notice - amendment of initial conditions.

Get X-OPERATION-ID

According to CDUI-2-1: X-OPERATION-ID, the identification of an operation before it starts is required and, in particular, for the preparation of an amendment, a unique operations’ identifier X-OPERATION-ID shall be requested:

Registration of documentation

According to a CDUI-3-1: Registration of a document, the CA can register documents related to an amendment.

Send a request for the amendment of a CN

To amend a CN using an amendPhase command, a model should be used for the preparation of a POST-request for BPE with the following parameters:

/do/cn/cpid/ocid

Where:

• cpid - OCID of parent Contracting Process (cProcess)
• ocid - OCID of a phase of contracting process to be amended

Feed Point Response

As a result of the command execution a separate ocds-release is formed in the system describing the CN together with amendment. The System will inform the contributor (according to CDUI-5-1: Backward notification) with the following message:

Upload documentation

Now the CA can upload new documents related to the CN, according to CDUI-3-2: Upload of a document.

Request full result

Once all previous actions are finalised, the amended CN is now available in a Public Point:

Clarification

The clarification activities conducted during the enquiryPeriod must be performed according to common Profile PAPI-12-1: Clarification of conditions.

Submission of an EoI

In order to submit a new EoI for pre-qualification, the actions described in the following sections must be performed.

Get X-OPERATION-ID

According to CDUI-2-1: X-OPERATION-ID, the identification of an operation before it starts is required and, in particular, for the preparation of the submission of an EoI, a unique operations’ identifier X-OPERATION-ID shall be requested:

Registration of documentation

According to a CDUI-3-1: Registration of a document, the EO can register documents related to the submission of an EoI.

Send a request for the submission of an EoI

To submit an EoI within an online procedure based on a selective method using a createSubmission command, a model should be used for the preparation of a POST-request for BPE with the following parameters:

/do/submission/cpid/ocid

Where:

• cpid - OCID of parent Contracting Process (cProcess)
• ocid - OCID of a phase of contracting process

Requirement Responses

An EoI shall include relevant requirementResponse for each requirement expressed through criteria, where criterion.source: tenderer

Feed Point Response

As a result of the command execution, a separate ocds-release is formed in the system describing the submitted EoI. The System will inform the contributor (according to a CDUI-5-1: Backward notification) with a following message:

Upload documentation

Now, having both the documents registered and the EoI submitted, the EO can upload documents according to CDUI-3-2: Upload of a document. Document uploading is an iterative process.

Note that there will be no updated information in a Public Point after the submission of an offer since all the offers remain confidential until the deadline for submission (tender.tenderPeriod.endDate) .

Withdrawal of an EoI

In order to withdraw an EoI, the actions described in the following sections must be performed.

Get X-OPERATION-ID

According to CDUI-2-1: X-OPERATION-ID, the identification of an operation before it starts is required and, in particular, for the preparation of the withdrawal of an EoI, a unique operations’ identifier X-OPERATION-ID shall be requested:

Send a request for the submission of an EoI

To withdraw an EoI, a request shall be send to BPE with the following parameters:

/cancel/submission/cpid/ocid/id

Where:

• cpid - OCID of parent Contracting Process (cProcess)
• ocid - OCID of a phase of contracting process
• id - an identifier of submission to be withdrawn

Feed Point Response

As a result of the command execution, the System will inform the contributor (according to CDUI-5-1: Backward notification) with a relevant message.

Establishment of a Framework Agreement

Business processes

The following diagrams show the choreography of the business processes implemented by the Profile. The choreography defines the sequence of interactions when the Profile is run within its context.

Pre-conditions

The process for the establishment of a framework agreement begins from a cameral demand analysis (based on detailed expenditure items of the Buyers) and aggregated planning as a multi-relation with a number of periodic indicative notices (Prior Information Notice or simplified Prior Notice - PAPI-1-1: Procurement initiation - prior notices), based on described need (PAPI-0-1: Expenditure Item) and the sources of financing (PAPI-0-2: Funding Source) declared for such a need by the other Buyers who intend to become a party of further framework agreement by CPB.

Initiation of a framework agreement

Initiation of a framework agreement is an offline process by CPB. It is based on analysis of a buyer's demand described by publishing the lists of expenditure items as a part of the budgeting process. Having all the needs described by both obligatory and voluntary Buyers, CPB can evaluate such demand against overall value, geographical distribution, homogeneity, timing and so on, as well as compare it with a market proposition. Main goal of this stage is to decide on a provisional procurement strategy and inform Buyers about CPBs intention to establish a framework agreement for a specific category. All the following action related to scoping of a future aggregated demand and budget.

BPMN for a process of initiation of a framework agreement

Common flow of planning an aggregated

A principle business-process of an aggregation of a Buyers indicative notices looks like following:

BPMN for common online selective procedure for utilities

Common flow of a design of a framework agreement

The high-level of a design of a framework agreement expressed in a following diagram:

Common process of a framework agreement establishment

The Profile covers a common flow of procurement procedure for utilities based on a selective method:

BPMN for common process of a framework agreement establishment

Technical design

In order to implement a Profile in a MTender system the following technical design is applied:

Preparation of framework agreement establishment

As it is stated above, contracting process for an establishment of a framework agreement based on an online selective procurement method and begins from a cameral demand analysis (based on detailed expenditure items of the Buyers) and aggregated planning as a multi-relation with a number of periodic indicative notices by the Buyers who intend to become a party of further framework agreement by CPB. Thus, an establishment of a framework agreement on a technical layer begins from an initiation of a relevant contracting process and publication of a draft of a future aggregated plan where all the relations with the periodic notices aggregated by CPB as a common scope of a framework agreement to be established.

Initiation of a contracting process for a framework agreement

Initiation of a contracting process in case of framework agreement goes in the same way as for any other procurement methods - with a publication of a planning notice (PN) which in this case is a draft of a future aggregated plan (AP). Thus, the relevant request for initiation of a contracting process based on createPN.ap command-model to be sent to a BPE:

/do/ap?country=...&pmd=...

Request parameters

country: Identifier of country of jurisdiction according to country codelist

pmd: Identifier procurementMethodDetails according to pmd codelist

As a result, a new contracting process for a farther framework agreement (FA) with a relevant attributes will be initiated in the system as well as draft of a future aggregated plan (AP).

4.1.2 Collection of demand and aggregated planning

The Aggregated Plan (AP) contains information about multiple individual procurement plans. Through the aggregation of demand CPBs could significantly diminish costs of procedures. Procurement techniques that involve aggregation usually take longer to award than non-aggregated procurement processes, but they are associated with lower cost than running "standard“ restricted or negotiated procedures. CPBs are more professional and aggregation may permit greater strategic buying power Repetitive purchasing and issues of aggregation are inevitably evoked in the context of CPBs since the reason to establish them is usually to provide smaller contracting authorities with the benefits of economies of scale.

On a data-level, aggregation means setting up a relationship between different data-sets and inheritance of specific data in order to reflect aggregation and its scope.

The logic illustrated with the following component diagram consist of a sequence of relations set based on the business process performed.

Component diagram of a collection and aggregation of a periodic notices as a aggregated plan

4.1.2.1. Collection of a needs to be included into a aggregated plan

According to a business process above, once a potential Buyer becomes aware of CPBs intention to establish a framework agreement for a specific category of goods or services, he can request from CPB an inclusion of his relevant demand and related budget into a scope of such FA. To do so, Buyer needs to describe his demand first by initiating a separate contracting process against previously declared annual needs (expenditure item classified with a certain CPV code) and publication of a relevant periodic notice, describes provisional schedule, budget allocated and, at least common definition of a subject of procurement. Once such data is ready on Buyers' side, the inclusion of a demand can be requested from CPB through establishing a relation between periodic notice of contracting process and the framework agreement. Such a relation serves as a data-hook of inclusion requests recorded.

/do/outsourcing/cpid/ocid?FA=...&AP=...

Request parameters

cpid: Identifier of a contracting process whichs PN is to be requested for inclusion into aggregated plan

ocid: Identifier of a PN which is to be requested for inclusion into aggregated plan

FA: Identifier of a FA where a received PN is to be included as a request for aggregation

AP: Identifier of a aggregated plan under targeted framework agreement

As a result, a relevant relation will be established in FA to PN received as follows:

And the reverse relation in PN to FA as follows:

Thus, all the requests by the Buyers interested in their needs to be covered by further framework agreement will be collected in an AP drafted by CPB as the related processes with a relevant

relationship: x_demand.

4.1.2.2. Aggregation of requested demands

On a CPB side, each requested inclusion to be reviewed by CPB and decided on whether this request is a subject of this framework from classification, geography, volume and etc perspectives. If compliant and CPB decides to include this demand into a scope of future framework agreement, such demand is to be aggregated through establishing a relevant relation:

/do/relation/cpid/ocid?CP=...&PN=...

Request parameters

cpid: Identifier of a contracting process whichs PN is to be requested for inclusion into aggregated plan

ocid: Identifier of a PN which is to be requested for inclusion into aggregated plan

FA: Identifier of a FA where a received PN is to be included as a request for aggregation

AP: Identifier of a aggregated plan under targeted framework agreement

As a result, a relevant relation will be established in AP to PN received as follows:

In the same way CPB proceeds with all the requests collected during a certain determined period of time and, having the final aggregated scope, CPB can complete a scoping period and start with a design of framework, preparation of a pre-qualification phase and a framework establishment itself.

4.1.2.3. Description of a scope of an aggregated plan

Since aggregation of a subject of procurement from multiple sources (periodic notices by Buyers) into single common scope (AP) doesn't seem a linear process and often requires a human-analysis, at this stage a subject aggregation together with a “lots” strategy goes to CPB as a manual process.

In order to reflect a summary of an aggregation - subject of matter of this contracting process as a set of items and lots, CPB supposes to update AP with a relevant substance. To do this, relevant request for an update of a AP based on updatePN.ap command-model to be sent to a BPE:

/do/ap/cpid/ocid

Request parameters

cpid: Identifier of a FA where a received PN is to be included as a request for aggregation

ocid: Identifier of a aggregated plan under targeted framework agreement

In the same way CPB proceeds with all the updates up to all the demand collected via the aggregated plan is reflected in its scope. Once done, CPB can start with collection of expressions of interest from a market.

4.1.2.3.1. Determining product categories and products

The subject matter of framework agreements is works/goods/services. However, as framework agreements are established for repeating needs and usually include a form of aggregated purchasing, challenges regarding the subject matter often occur. The issues relate to the uncertainties of how detailed the subject matter must be identified and described, and question whether substitution of subject is allowed, and if yes, to what extent. These uncertainties are particularly important within framework contracts, where all terms and conditions for awarding call-offs are established at the stage of concluding a framework - framework establishment. As a scope for change is limited in comparison with framework agreements, where a mini-competition or further specification of terms will be applicable.

Technically, determining of a product categories is a determination of a relevant list of items with aggregated classification according to CPV and decomposed place of performance (delivery).

Simplest case when the only category of goods scoped for relatively same (or even same) geography:

More complex case when a common volume in a category of goods is divided through geography:

4.1.2.3.2. Determining the legal type of FA Fixed and non-fixed terms

When it comes to framework agreements that do not include all terms and conditions, it is required that these are further specified and substituted when necessary at the stage of awarding call-offs.

Indication whether options are used and other information about options

A buyer may have a right – but not an obligation – to additional purchases from a supplier while the contract is valid. For example, a contract may concern a thousand uniforms, and the buyer may have the option to request an additional hundred uniforms. This may be useful if, when initiating the contracting process, the buyer doesn't yet know whether a planned increase in staff will take place.

The options.hasOptions field can be set to true, and the options.description field can describe the options for additional purchases. hasOptions and options.description can also be set on lot objects in the tender.lots array:

Information on the recurrence of the contracting process

Such information needed if, for example, another procurement procedure or qualification system for the same contract matter is likely to be re-launched, or re-established, in the foreseeable future. Note that this does not mean awarding multiple contracts within a single qualification system, framework agreement, or dynamic purchasing system; in these cases, these fields should not be used. This information can be useful, for example, to companies deciding whether to invest into machinery necessary for a particular contract. With this information, they know that there will likely be an opportunity to win similar contracts in future years, which may make the investment more worthwhile.

Description of the options for the renewal of contracts Information about variants 4.1.2.3.3. Duration of a future framework agreement by each defined category

The duration of a framework agreement may generally not exceed four years and may be shorter.

4.2 Call for expressions of interest

Preparation of Call for expressions of interest under a contracting process based on an online selective procurement method is made by preparation and publication of a contract notice based on a prior notice. In case of framework agreement such prior notice is an AP. To introduce a new Contract Notice as a call for expressions of interest for procedure based on a selective method createCNonPN.selective-online command-model should be used for preparation of POST-request for BPE:

/do/fe/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where a call for EoI is to be published

ocid: Identifier of a aggregated plan under targeted framework agreement

As a result of the command execution a separate ocds-record based on cpPhase.FE is formed in the system describing the Contract Notice created.

4.2.1 Specific information

Together with all the common information applicable for any of contract notices for other procurement methods, the following additional information is specifically applied in case of an announce of establishment of a framework agreement:

4.2.1.1. Applied techniques

4.2.1.1.1. Pre-qualification

Separate preQualification block shall be included into Contract Notice in order to initiate a call for EoI:

4.2.1.1.2. Second-stage parameters

A separate technique according to PAPI-11-8: Second-stage: PE allowed to limit a number of candidates to be invited to submit financial offers later on. Where this is a case, pre-selection instead of pre-qualification will be applied in order to evaluate candidates. To limit number of candidates, secondStage building block to be included inside:

4.2.1.1.3. Other criteria

A separate technique according to PAPI-11-3: Other criteria - reduction of the number of candidates according to a limits by secondStage:

4.2.1.1.4. Award criteria

Set of criteria may include different types of requirements based on PAPI-11-2: Qualification criteria, used in different ways and for different reasons.

4.2.1.1.5. Conversions

Where scoring function to be applied, a set of verifiable conversions needed for future ranking and evaluation as described in a PAPI-11-5: Scoring function and conversions

4.2.1.1.6. Requirement of an electronic catalogue to be submitted

If all the further financial offers to be expressed with a pre-award catalogue

4.2.1.2. Evaluation panel

A set of Procuring Entities’ evaluation panel could be announced based on PAPI-11-7: Evaluation panel

4.2.2 State-chart diagram

The life cycle of a cpPhase.FE for an establishment of a framework agreement based on selective method consists of the following states:

State-chart diagram for an establishment of a framework agreement based on selective method

4.3 Submission of expressions of interest by interested EOs

Along with publication of a contract notice for a framework establishment, the pre-qualification phase shall be launched in order to indicate a time-frame for submission of expressions of interest based on either PAPI-4-1: Submission - expression of interest or PAPI-4-2: Advanced submission - expression of interest based on ESPD dependign on PEs’ strategy. Separate preQualification block of a query-model expresses such time-frame:

Submission of EoIs is available for any interested economic operator during a certain period determined by tender documents. Each EoI shall fulfill all the requirements prescribed by the qualification criteria related to tenderers with a relevant list of the responses by EO. To send a submission for procedure based on a selective method a createSubmission command-model should be used for preparation of POST-request for BPE with an indication of the following parameters:

/do/submission/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where a EoI is to be submitted

ocid: Identifier of a framework establishment under targeted framework agreement

4.4 Enquiries - requests and clarifications

Within prescribed by a contract notice enquiryPeriod any interested EO allowed to send a request for clarification according to PAPI-12-1: Clarification of conditions.

4.5 Pre-qualification by CPB

4.5.1 Initiation of pre-qualification

4.5.1.1. Disclosure of submissions

Where enough submissions is a case, all the submissions to be disclosed as submissions array according to the relevant schema:

4.5.1.2. Establishment of a period for qualification by PE

In order to indicate a start of the qualification phase of a contracting process a separate qualificationPeriod.startDate will be added into a preQualification:

4.5.1.3. Qualification envelopes

Along with initiation of a prequalification by CA, a set of qualifications to be established against each submission received in order to allow CA to reflect its decision against each such submission.

Such objects are initially established with status:pending and statusDetails:awaiting. Since no order is prescribed for the prequalification sequence - CA can qualify submissions received randomly.

4.5.2 Initial ranking of submissions according to qualification criteria

Depending on tender.awardCriteria and tenderAwardCriteriaDetails initial automated ranking can or can not be done automatically according to PAPI-5-3: Initial ranking - simple pre-selection, PAPI-5-4: Scoring - advanced pre-selection or PAPI-5-2: Automated pass/fail - advanced qualification.

4.5.3 Declaration of non-conflict of interest

Before starting qualification, each declared member of the evaluation panel (see PAPI-11-6: Evaluation panel) shall respond against each candidate from each submission received according to a common flow prescribed by a Profile PAPI-8-1: Declaration of absence of conflict of interest by CA.

4.5.4 Qualification of a submissions

Once all the declarations of non-conflict of interest against specific candidates are submitted by evaluation committee, related qualification may be switched into statusDetails: consideration

/do/consideration/qualification/cpid/ocid/qualificationId

Request parameters

cpid: Identifier of a framework agreement where qualification is taking place

ocid: Identifier of a framework establishment under targeted framework agreement

qualificationId: Identifier of a qualification to be updated

4.5.4.1. Consideration

In order to evaluate a submission against qualification criteria and reflect CPBs’ decision on considered submission one of the following profiles shall be applied (depending on procurement strategy under specific procurement process): PAPI-5-1: Pass/fail - simple qualification or PAPI-5-5: Distributed qualification - conditions-driven decision making

CPB shall update qualification with all the required meta-data. Under such updates PE allowed to:

• add any qualification.documents if needed
• add text qualification.description where any justification is needed
• add qualification.internalID if any

4.5.4.2. Indication of a decision

Once consideration of specific submission is completed and related qualification is fully updated with all the relevant data, CPB shall switch such a qualification in a one of the states, reflecting positive or negative decision in its regard:

• qualification.statusDetails: active - means related submission is qualified
• qualification.statusDetails: unsuccessful - means related submission is disqualified

In order to implement both consideration and indication of a decision, a targeted qualification shall be updated according with an updateQualification command-model with a following request to a BPE:

/do/qualification/cpid/ocid/qualificationId

Request parameters

cpid: Identifier of a framework agreement where qualification is taking place

ocid: Identifier of a framework establishment under targeted framework agreement

qualificationId: Identifier of a qualification to be updated

4.5.5 Qualification protocol

As soon as CA has completed qualification and all the qualifications are updated with relevant meta-data and statuses details, CA indicates the end of pre-qualification by submitting a protocol:

/do/protocol/qualification/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where qualification is taking place

ocid: Identifier of a framework establishment under targeted framework agreement

qualificationId: Identifier of a qualification to be updated

4.5.6 Withdraw qualification protocol

If there are some blockers raised up during stand-still period (out of system), CPB can withdraw a previously submitted qualification protocol and step back to a qualification in order to address blockers:

/cancel/protocol/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where qualification is taking place

ocid: Identifier of a framework establishment under targeted framework agreement

qualificationId: Identifier of a qualification to be updated

4.5.7 Completion of qualification

If no blockers indicated during stand-still period (out of system), CPB can initiate the end of qualification:

/confirm/qualification/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where qualification is taking place

ocid: Identifier of a framework establishment under targeted framework agreement

qualificationId: Identifier of a qualification to be updated

Such completion of a qualification period will cause a also following consequences:

4.5.7.1. Completion of qualification period

Additional value will be added into preQualification.qualificationPeriod as an indication of a completion of qualificationPeriod

4.5.7.2. Finalization of pre-qualification

All the qualifications shall be moved into relevant final statuses:

• qualification.status: pending / statusDetails: active → qualification.status: active / statusDetails: none - means related submission is qualified and a candidate(s) is invited to submit a commercial offer
• qualification.status: pending / statusDetails: unsuccessful → qualification.status: unsuccessful / statusDetails: none - means related submission is disqualified)

And all the related submissions to relevant statuses:

• where related qualification.status: active → submission.status: valid
• where related qualification.status: unsuccessful → submission.status: disqualified

4.5.7.3. Completion of pre-qualification

Character of a result of the pre-qualification to be reflected with:

• preQualification.status.complete where enough number of candidates were selected for future invitation to submit an offer
• preQualification.status.unsuccessful where pre-qualification completed in a negative way due to lack of submissions or because all the submissions were disqualified

4.6 Pre-award catalogue request

Once pre-qualification and a following stand-still period are over, a sourcing phase shall be initiated by CPB by a publication of a number of pre-award catalogue requests according to a design of a framework agreement and a distinction of a subject matter.

In order to initiate a collection of indicative offers and competition on it by all the qualified suppliers, CPB shall publish a separate pre-award catalogue request for each separate part of a subject matter.

To start a new Pre-award catalogue request, a createPCRonFE command-model to be used for preparation of POST-request for BPE with an indication of the following parameters:

/do/pcr/cpid/ocid

Request parameters

cpid: Identifier of a framework agreement where PCR is needed

ocid: Identifier of a framework establishment under targeted framework agreement

4.6.1 Specific information

Together with all the common information applicable for any of contract notices for other procurement methods, the following additional information is specifically applied in case of an announcement of pre-award catalogue request:

4.6.1.1. Measurable targets

Set of sepcific targets describes an expected verifiable measures and values to be achieved within this pre-award catalogue request can be included according to PAPI-11-1: Targets and metrics.

4.6.1.2. Applied techniques

4.6.1.2.1. Electronic auction

An eAuction can be included as a part of process according to a Profile PAPI-11-5: Electronic auctions.

4.6.1.2.2. Award criteria

Set of criteria may include different types of requirements based on PAPI-11-2: Qualification criteria, used in different ways and for different reasons.

4.6.1.2.3. Conversions

Where scoring function to be applied, a set of verifiable conversions needed for future ranking and evaluation as described in a PAPI-11-5: Scoring function and conversions.

4.7 Submission of pre-award catalogues by qualified candidates

According to PAPI-6-1: Bid - simple tendering or PAPI-6-2: Structured Bid - advanced tendering each invited candidate allowed to submit his bid within the given tender.tenderPeriod. Each bid shall fulfill all the requirements prescribed by the criteria related to item or lot with a relevant list of the responses by EO by providing an array of requirementResponses.

According to PAPI-6-1: Bid - simple tendering or PAPI-6-2: Structured Bid - advanced tendering each invited candidate allowed to submit his bid within the given tender.tenderPeriod. Each bid shall fulfill all the requirements prescribed by the criteria related to item or lot with a relevant list of the responses by EO by providing an array of requirementResponses.

• a reference on organization profile sent previously while submitting an expression of interest, in case of two-stage procedures)
• set of documents of the offer, specified with relevant types of documents for their future splitting into the different "envelopes"
• absolute financial value of an offer
• set of required responses according to criteria specified by Contract Notice related to financial part of the offer:
• reflections on requirements characterise the nature of the subject of procurement
• reflections on requirements characterise the nature of the delivery and post-delivery

Such requests based on bid schema:

All the proposals collected remain confidential and closed until expiration of a period for tendering - tender.tenderPeriod.endDate. Once tender.tenderPeriod.endDate achieved, no offers to be received, withdrawn or corrected.

4.8 Electronic auction

An eAuction can be included as a part of process according to a Profile PAPI-11-5: Electronic auctions

4.9 Evaluation by CPB

4.9.1 Initiation of an evaluation

4.9.1.1. Disclosure of the pre-award catalogues

Where enough offers is a case, all such offers to be disclosed as an bids array according to the relevant schema.

4.9.1.2. Establishment of a period for evaluation

Separate object awardPeriod to be added into a tender where the certain start date for awarding is determined automatically.

4.9.1.3. Evaluation envelopes

Along with establishment of tender.awardPeriod.startDate a set of awards to be established against each bid received in order to allow CA to reflect its decision against each such bid. Such objects are based on award schema and initially established with status:pending for all.

4.9.2 Initial ranking on evaluation criteria

Depending on tender.awardCriteria and tenderAwardCriteriaDetails initial automated ranking can or can not be done automatically according to a Profile PAPI-7-2: Initial ranking for evaluation

4.9.3 Evaluation by contracting authority

Once an initial ranking according to applied awarding methodology is done, CA can start with a manual evaluation according to either PAPI-7-1: Simple manual evaluation or PAPI-7-3: Scoring function - advanced evaluation

4.9.4 Conclusion of a post-award catalogue

The evaluation process ends by submission of a protocol that reflects the entire results of tendering. Once evaluation is completed and each considered offer is indicated with a relevant state, CA submits the evaluation protocol which, in its turn, indicates the publication of the contract award notices according to Profile PAPI-9-1: Award decision - contract award notice. Such protocol has to be submitted for each lot separately.

4.10 Conclusion of a framework agreement

4.11 Cancellation of a procedure

See PAPI-3-3: Termination of a procedure

5. Command models

The following command-models to be used to operate with a data-objects under offline procedure based on a limited method

5.1 updatePN.ap

5.2 createPN.ap

5.3 createCNonPN.selective-online

In order to describe and contribute a Contract Notice for a procedure based on a limited method, a following structure to be used:

Attribute

Description

tender.title

Title for this part of CP

tender.description

Description for this part of CP

tender.awardCriteria

Specify the award criteria for the procurement

tender.awardCriteriaDetails

Specify the award criteria details for the procurement

tender.lots

A tender process is divided into lots

tender.items

The goods and services to be purchased

tender.submissionMethod

Specify the method by which bids must be submitted

tender.submissionMethodRationale

A value that identifies the rationale where electronic submission method is not to be allowed

tender.submissionMethodDetails

Any detailed or further information on the submission method.

tender.documents

All documents and attachments related to the tender, including any notices.

5.4 createSubmission

5.5 updateQualification

5.6 createPCRonFE

Execution of a Framework Agreement

In the context of a transition to digital public procurement in the Republic of Moldova, a new electronic procurement system was developed and implemented with the European Bank for Reconstruction and Development (EBRD) support.

Phase 4 of the project is focused on electronic Framework Agreement (FA), covering both the conclusion of the FA and the subsequent purchases under a FA using the different types of contracts based on a FA (direct purchase, second-stage competition, etc.), and enabling the participation of Central Purchasing Bodies (CPB) with a specific role in the process.

The use of FA will:

• improve value for money and achieve cost savings by aggregating demand and getting better value for money through economies of scale;
• reduce the administrative burden by lowering the number of procedures a Contracting Authority (CA) has to run and, therefore, decreasing the time and costs linked to carrying out procurement. The diminished administrative burden also applies to Economic Operators (EO) that are either awarded a contract directly or are invited to participate in a simplified “Mini Competition” (MC) within the FA;
• enable CAs to effectively manage procurement when they cannot objectively foresee the exact type and/or amount of supplies, services and works for a forthcoming period.

Aim of the document

The main purpose of this document is to provide a detailed technical design in order for the Networking Electronic Procurement Platforms (NEPPs) to be able to implement all the necessary processes and functionalities related to the execution of FAs in their platforms.

When a FA has been concluded with more than one EO, that FA shall be performed in one of the following ways by the CA or the CPB:

• Following the terms and conditions of the FA, without the reopening competition, by awarding a contract directly to a specific EO applying the terms governing the provision of the works, services and supplies concerned and the objective conditions set in the FA;
• Where not all the terms governing the provision of the works, services and supplies are laid down in the FA, through reopening competition amongst the EOs parties to the FA;
• Partly without reopening of competition and partly with reopening of competition amongst the EOs parties to the FA, where this possibility has been stipulated in the procurement documents for the FA.

Conclusion of the FA is described in a separate document .

Alignment with regulation

This blueprint is aligned with the following regulation:

• Regulation on procurements conducted through framework agreements

Technical design

BPMN

The diagram below shows the general processes for the execution of a FA with the different types of contracts based on a FA:

Figure 1 – BPMN for the execution of a FA

State-chart diagrams

Direct purchase

The following diagram presents the sequence of stages applicable for the execution of a FA based on direct purchase following the terms and conditions of the FA, without reopening competition, by awarding a contract directly to a specific EO applying the terms governing the provision of the works, services and supplies concerned and the objective conditions set in the FA:

Figure 2 – State-chart diagram for direct purchase under a FA

Mini-competition

The following diagram presents the sequence of stages applicable for the execution of a FA based on reopening of competition (partially or completely) amongst the EOs parties to the FA:

Figure 3 – State-chart diagram for mini-competition under a FA

Further detail on the different statuses is provided in section “2.4 OCDS dataflow” of this document.

OCDS dataset

Issuing of a Direct purchase under a FA

This request shall be formed on the basis of the FA execution and include:

• Products category determined for this request;
• precise technical specification;
• lots (where applicable);
• specific nomenclature;
• terms and conditions which are non-fixed in the (if any);
• evaluation criteria.

Figure 4 – Code for issuing of a Direct purchase under a FA

Issuing of a Mini-competition under a FA

This request shall be formed on the basis of the FA execution and include:

• products category determined for this request;
7
• minimum technical specification (where applicable);
• lots (where applicable);
• specific nomenclature;
• terms and conditions which are non-fixed in the FA (if any);
• awarding methodology and evaluation criteria and techniques.

Figure 5 – Code for issuing a Mini-competition under a FA

OCDS dataflow

Direct purchase

State1 - Tendering (active.tendering)

Together with the publication of the Purchase Request (PR), the CA shall initiate a period for the response by a quoted party of the FA.

Purchase request

In order to indicate the initiation of the period for the quoted party of a FA to respond to a PR, the CA shall establish the start and end dates of such period. This shall be done by adding a separate tenderPeriod object into the tender building block, which will reflect the end date of the period for response prescribed by the CA and its start date, reflected as a system moment of initiation of the tendering phase:

Figure 6 – Code for establishing the period of a Purchase request

Response to the purchase request

The EO that is party to the FA is the only one allowed to submit a quotation within the given tender.tenderPeriod indicated in a PR:

• Quotation is based on Bids schema.
• Quotation shall fulfil all the requirements prescribed by Criteria related to items or to lots with a relevant list of the responses by the EO, providing an array of requirementResponses.

Having a set of requirements predefined by the CA and a number of values available, the EO preparing a submission includes values for each requirement, reflecting the substance of the quotation and fulfilling general corporate profiles’ data, as requested by the CA or required by the legal framework of a particular jurisdiction.

Each offer includes:

1. An organization profile according to the extended Organization model (or a reference to such a profile previously sent within the FA);

2. a set of documents of the tender, specified with relevant types of documents for their future splitting into the different "envelopes";

3. absolute financial value of the tender;

4. a set of required responses according to the criteria specified by the CA within the Contract Notice (CN) related to the financial part of the offer:

• reflections on requirements characterise the nature of the subject of procurement;
• reflections on requirements characterise the nature of the delivery and post-delivery.

Figure 7 – Code for information of a bid

The quotation received remains confidential and closed until expiration of the period for tendering (tender.tenderPeriod.endDate).

State1.1 - Unsuccessful completion of responding period

When the quoted EO does not respond within the given period, the evaluation phase will end in an unsuccessful way with no future actions by the CA. Procurement initiation shall be moved to a phase of preparation of a negative award notice.

Indication of the unsuccessful outcome of procurement initiation

When absence of the requested quotation is the case, the relevant unsuccessful character shall be reflected for lots or for the entire PR.

For lots

A negative character of procurement under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed unsuccessfully due to the lack of submission of a tender by the quoted EO, or when the received tender was rejected.

Figure 8 – Code for unsuccessful outcome of procurement initiation at lot level

For entire initiation (purchase request)

Where all the lots are unsuccessful, the entire procurement initiation goes to State8.3 (described in Section 2.4.1.3 of this document).

A negative character of a procurement under entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed unsuccessfully due to the lack of submission by the quoted EO or where the received tender was rejected. Details of a negative closure are reflected in tender.statusDetails.

Figure 9 – Code for unsuccessful outcome of procurement initiation at tender level

State8.3 - Unsuccessful completion of tendering

Where no tender was collected during the tendering period for all the announced lots, the evaluation phase will end unsuccessfully with no future actions by the CA. The procurement process shall be moved to a phase of preparation of a negative award notice.

State3 - Evaluation (active.evaluation)

Once the tenderPeriod.endDate is achieved, the quotation received under this request shall be fully disclosed and available for the evaluation of the CA.

Initiation of evaluation phase

For the evaluation of the quotation received, the following technical steps shall be performed on a system level:

Disclosure of quotation

When a quotation is provided by the quoted EO, it is disclosed as a bid according to the relevant schema. An author (bid.tenderers) is updated into parties as an Organization with a role: tenderer.

Figure 10 – Code for quotation information

Establishment of a period for evaluation

A separate object awardPeriod is added into tender block where the specific start date for awarding is determined automatically. Such block is based on Period schema.

Figure 11 – Code for period for evaluation

Evaluation envelopes

Along with the establishment of the tender.awardPeriod.startDate, the evaluation envelope – award is generated for the quotation received. This object is based on the Awards schema and is initially established with status:pending.

Figure 12 – Code for evaluation of envelopes

Consideration

Evaluation

In order to evaluate the award, the CA shall update it with all the required meta-data:

• add any documents, if needed;
• add requirementResponses if there are relevant requirements related to the CA within the evaluation phase prescribed by tender.criteria;
• add text descriptions where any justification is needed;
• add internalID, if any.

Indication of a decision

Once the evaluation of the specific bid is complete and the related award is fully updated with all relevant data, the CA shall switch the award to one of the following states, reflecting a positive or negative decision:

• award.statusDetails: active - means the related bid is selected as the winning tender to be awarded;
• award.statusDetails: unsuccessful - means the related bid is rejected.

Figure 13 – Code for award details

As soon as the CA has completed the evaluation, the CA indicates the end of the evaluation by publishing an intention to award a contract (award decision).

Award decision

To reflect a decision regarding a Purchase Contract (PC), the CA prepares a Notice on Award Decision. This data-entity is based on Contract schema and is included in contracts array.

Initially, this contract is established with status: pending and a statusDetails which reflects a decisions' character:

• statusDetails: active - the decision regarding quotation is positive (winner is identified);
• statusDetails: unsuccessful - the decision regarding quotation is negative (the quotation was rejected).

Figure 14 – Code for award decision

Cancellation of the award decision

To reflect the decision to cancel a specific award, taken previously for a particular quotation, the CA shall switch relevant contract object into contract.status: cancelled.

Figure 15 – Code for cancellation of the award decision

Confirmation of the award decision

If no blockers are indicated, the CA can initiate the contract preparation for the awarded quotation or the finalization of an unsuccessful output of a PR where the received quotation was rejected during the evaluation phase.

Confirmation of a negative award decision

Confirmation of a negative award decision requires to switch the relevant contract object into final status unsuccessful, with parallel indication of the reason for a negative outcome in statusDetails.

Figure 16 – Code negative award decision

Confirmation of a positive award decision

Confirmation of a positive decision requires reflecting the subsequent contract initiation into a relevant contract object by indicating statusDetails, provided that the object remains in an intermediate status: pending.

Figure 17 – Code for positive award decision

Contract initiation

To describe and reflect the scope of a PC to be concluded on a positive award decision, a parallel data-stream will be initiated. This stream is a separate OCDS-record where all the information related to the future contract is collected from the current procurement process. In order to establish the relation with this parallel stream, the relevant contract reflects the positive award decision and shall be extended with relatedProcess.relationship: [x_contracting].

Figure 18 – Code for contract initiation

Contract preparation and activation

According to the common flow of MTender, the preparation of a contract is concluded.

State3.1 - Unsuccessful completion of evaluation (unsuccessful.lackOfOffers)

If the received quotation was rejected, the evaluation phase will end in an unsuccessful way with no future actions by the CA.

Completion of the evaluation phase

The previously opened period for evaluation shall be closed by adding a separate endDate attribute for awardPeriod.

Figure 19 –Code for closure of the evaluation phase

Indication of the unsuccessful outcome of procurement initiation

When the quotation received is rejected, the unsuccessful result shall be reflected for lots or for the entire PR.

For lots

A negative character under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed in a negative way due to the lack of submission of quotation or where the received quotation was rejected.

Figure 20 – Code for unsuccessful lot

For entire initiation (tender)

A negative character under the entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed in a negative way due to the lack of submission of quotation or where the received quotation was rejected. The details of a negative closure are reflected in tender.statusDetails.

Figure 21 – Code for unsuccessful procurement initiation

State4 - Completion of procedure

Indication of the successful outcome of procurement initiation

When the PC was concluded under a relevant request, a positive character of a process shall be reflected for both the lot and the entire PR:

For lots

A positive character under a specific lot is reflected with lot.status: complete.

Figure 22 – Code for successful lot

For entire process

A positive character under an entire initiation (procurement process) is reflected with tender.status: complete.

Figure 23 – Code for successful procurement initiation

Mini-competition

State1 - Tendering (active.tendering)

Together with the publication of the PR, the CA shall initiate a period for submission of quotations by the EOs that are party of the FA.

Call for proposals

In order to indicate the start of the tendering phase of a procurement process, the CA shall establish a start date as a call for tendering of the commercial tenders. This indication shall be done by adding a separate tenderPeriod object into the tender building block, which will reflect an end date of the tendering phase prescribed by the CA, and its start date is reflected as a system moment of initiation of the tendering phase:

Figure 24 – Code for establishing the period for Call for proposals

2.4.2.1.2 Tendering

Each invited EO (party to the FA) is allowed to submit a tender - quotation within the given tender.tenderPeriod indicated in the PR.

• Each quotation is based on Bids schema.
• Each quotation shall fulfil all the requirements prescribed by Criteria related to items or lots with a relevant list of the responses by the EO, providing an array of requirementResponses.

Having a set of requirements predefined by the CA and a number of values available, EOs preparing a submission include values for each requirement, reflecting the substance of the submission and fulfilling general corporate profiles’ data, as requested by the CA or required by the Legal Framework of a particular jurisdiction.

Each tender includes:

5. An organization profile according to the extended Organization model (or a reference on such a profile previously sent within the FA);

6. a set of documents of the tender, specified with relevant types of documents for their future splitting into the different "envelopes";

7. absolute financial value of the tender;

8. a set of required responses according to the criteria specified by the CA within the PR:

• reflections on requirements characterise the nature of the subject of procurement;
• reflections on requirements characterise the nature of the delivery and post-delivery.

Figure 25 – Code for bid information

All the tenders collected remain confidential and closed until the expiration of the period for tendering (tender.tenderPeriod.endDate). Once the tender.tenderPeriod.endDate is achieved, no tenders can be received, withdrawn or corrected.

State1.1 - Unsuccessful completion of tendering (unsuccessful.lackOfOffers)

Where not enough tenders were collected during the tendering period for all the announced lots, the evaluation phase will end unsuccessfully with no future actions by the CA. The procurement process shall be moved to a phase of preparation of a negative award notice.

Indication of the unsuccessful outcome of procurement

When absence of tenders is the case, the relevant unsuccessful character shall be reflected for lots or for the entire PR.

For lots

A negative character under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed unsuccessfully due to the lack of submission of tenders by the EOs party to the FA, or when the received tenders were rejected.

Figure 26 – Code for unsuccessful lot

For entire initiation (purchase request)

When all the lots are unsuccessful, the entire procurement initiation goes to State8.3 (described in Section 2.4.1.3 of this document).

A negative character under the entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed unsuccessfully due to the lack of submission of tenders by the EOs party to the FA, or when the received tenders were rejected. Details of a negative closure are reflected in tender.statusDetails.

Figure 27 – Code for unsuccessful purchase request

State 2 - Auction (active.auction)

Where electronic auction as a technique for the awarding of the contract was prescribed in the PR, all the tenders received shall be partially disclosed in order to establish an auction.

State3 - Evaluation (active.evaluation)

Once the tenderPeriod.endDate is achieved (when electronic auction was not prescribed in the PR) or when the electronic auction is completed, all tenders received under this request shall be fully disclosed and available for the evaluation of the CA.

Initiation of evaluation phase

For the evaluation of the tenders received, the following technical steps shall be performed on a system level.

Disclosure of tenders

Tenders are disclosed in a bids array. Authors (bid.tenderers) are updated into parties as an Organization with a role: tenderer.

Figure 28 – Code for tender information

Establishment of a period for evaluation

A separate object awardPeriod is added into tender block where the specific start date for awarding is determined automatically. Such block is based on a Period schema.

Figure 29 – Code for evaluation period

Evaluation envelopes

Along with the establishment of the tender.awardPeriod.startDate, an evaluation envelope – award is generated for each tender received. These objects are based on the Awards schema and are initially established with status:pending.

Figure 30 – Code for evaluation of envelopes

Disclosure of enquirers

Together with the initiation of the evaluation phase, all enquirers (tender.enquiries[*].author) are reflected into parties array according to Organization block schema with role: enquirer.

Initial ranking on award criteria

Depending on tender.awardCriteria and tenderAwardCriteriaDetails, an initial automated ranking can or cannot be done:

awardCriteriaDetatils / awardCriteria	priceOnly	costOnly	qualityOnly	ratedCriteria
automated	bid.value	bid.requirementResponses * lot.value	bid.requirementResponses * 1	bid.requirementResponses * bid.value
manual	-	-	-	-/td>

Table 1 – Automated and manual award criteria depending on the ranking approach

As shown in the table, automated ranking can be undertaken automatically using a set of criteria and the relevant conversions applied by the CA for each available value of each applied requirement published in a CN, on one hand; and the bid.requirementResponses submitted by each EO party to the FA against published criteria on the other hand. These two data-sets allow the normalised value for each bid based on the same approach to be calculated.

Normalised price

Where normalised price must be calculated, the following formula is applied for each tender in order to identify which one is most suitable by normalised price:

Pn = P * C1 * C2 * ... Cn

where

• Pn - value of normalised price
• P - basic price taken from bid.value or lot.value or equal to '1' depending on awardCriteria
• C1 ... Cn - values of the coefficients to be applied (related with values of requirements, available for supplier and indicated in requirementResponses)

Ranking approach

• priceOnly

Where awardCriteria: priceOnly - only bid.value is compared in order to identify the most suitable tender. Cheapest goes first.

• costOnly

Where awardCriteria: costOnly – the assumption is that all the tenderers have the same bid.value equal to lot.value. It means that the normalised price needs to be calculated for each bid received based on lot.value as a basis. Cheapest goes first.

• qualityOnly

>

Where awardCriteria: qualityOnly – the assumption is that the price doesn't matter and the only valuable part of the tender is quality - meaning set of values of criteria, selected by the EO while submitting a bid. It means that the normalised price needs to be calculated for each bid received, based on '1'. Most qualified goes first.

• ratedCriteria

Where awardCriteria: ratedCriteria – the assumption is that both price and value matter. It means that the normalised price needs to be calculated for each bid received based on ‘bid.value'. Cheapest goes first.

Where automated ranking is the case, all the awards are ranked into order for evaluation and the first award (most suitable according to the prescribed evaluation function) will be switched to the next state ‘available for evaluation’ by the CA.

Consideration

Evaluation

In order to evaluate an award, the CA shall update it with all the required meta-data:

• Add any documents, if needed;
• add requirementResponses if there are relevant requirements related to the CA within the evaluation phase prescribed by tender.criteria;
• add text descriptions where any justification is needed;
• add date when the decision was taken;
• add internalID, if any.

Indication of a decision

Once the evaluation of a specific bid is complete and the related award is fully updated with all relevant data, the CA shall switch the award to one of the following states, reflecting a positive or negative decision:

• award.statusDetails: active - means the related bid is selected as a winning tender to be awarded;
• award.statusDetails: unsuccessful - means the related bid is rejected.

Figure 31 – Code for award information

As soon as the CA has completed the evaluation and the winning tender for each lot is identified or all the tenders for this lot are rejected, the CA indicates the end of the evaluation for the lot by publishing an intention to award a PC (award decision).

2.4.2.4.4 Award decision

To reflect the decision regarding each lot and the tender selected to be awarded a PC (award.statusDetails:active), the CA prepares a Notice on Award Decision. This data-entity is based on Contract schema and included in contracts array.

Initially, this contract is established with status: pending and statusDetails which reflect a decisions' character:

• statusDetails: active where the decision regarding the lot is positive (winner is identified);
• statusDetails: unsuccessful where the decision regarding the lot is negative (all tenders were rejected).

Figure 32 – Code for award decision

Cancellation of the award decision

To reflect a decision to cancel a specific award decision taken previously for a particular lot, the CA shall switch relevant contract object into contract.status: cancelled.

Figure 33 – Code for cancellation of award decision

Confirmation of the award decision

If no blockers are indicated, the CA can initiate the contract preparation for the awarded lot or the finalization of an unsuccessful output of the lot.

Confirmation of a negative award decision

Confirmation of negative award decision requires to switch the relevant contract object into final status unsuccessful, with a parallel indication of the reason for a negative outcome as statusDetails.

Figure 34 – Code for confirmation of award decision

Confirmation of a positive award decision

Confirmation of a positive decision requires reflecting the subsequent contract initiation into a relevant contract object by indicating statusDetails, provided that the object remains in an intermediate status: pending.

Figure 35 – Code for positive award decision

Contract initiation

To describe and reflect the scope of a PC to be concluded on a positive award decision, a parallel data-stream will be initiated. This stream is a separate OCDS-record where all the information related to the future PC is collected from the current procurement process.

In order to establish the relation with this parallel stream, the relevant contract reflects the positive award decision and shall be extended with relatedProcess.relationship: [x_contracting]

Figure 36 – Code for contract initiation

Contract preparation and activation

According to the common flow of MTender, the preparation of a contract is concluded.

State3.2 - Unsuccessful completion of evaluation (unsuccessful.lackOfOffers)

When all the tenders collected during the period of tendering were rejected, the evaluation phase will end unsuccessfully with no future actions by the CA,

Completion of the evaluation phase

The previously opened period for evaluation shall be closed by adding a separate endDate attribute for awardPeriod:

Figure 37 – Code for closure of the evaluation phase

Indication of the unsuccessful outcome of procurement initiation

Where all received tenders are rejected, the unsuccessful character shall be reflected for lots or for the entire PR.

For lots

A negative character under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed in a negative way due to the lack of submission of tenders or where all the received tenders were rejected.

Figure 38 – Code for unsuccessful outcome of procurement initiation at lot level

For entire initiation (tender)

A negative character under the entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed in a negative way due to the lack of submission of tenders or where all the received tenders were rejected. The details of a negative closure are reflected in tender.statusDetails.

Figure 39 – Code for unsuccessful outcome of procurement initiation at tender level

State4 - Completion of procedure

Indication of the successful outcome of procurement initiation

Where PC was concluded under relevant request, a positive character of a process shall be reflected for both lot and entire PR:

For lots

A positive character under a specific lot is reflected with lot.status: complete.

Figure 40 – Code for successful outcome of procurement initiation at lot level

For entire process

A positive character under an entire initiation (procurement process) is reflected with tender.status: complete.

Figure 41 – Code for successful outcome of procurement initiation at tender level

Restricted Procedure

The MTender system is version 2.0 of the Automated Information System "State Register of Public Procurements", and is an information system compatible with cloud computing technology, which is hosted on the MCloud shared government platform.

The "MTender" system is a systematised pool of data on public procurement contracts concluded and processes related to public procurement contracts, such as the planning and conduct of public procurement procedures, the selection and designation of winners in these procedures. The information resource on public procurement contracts is formed through the operation/functioning of the automated information system "MTender".

Aim of the document

The main purpose of this document is to provide a detailed technical design in order for the Networking Electronic Procurement Platforms (NEPPs) to be able to implement all the necessary processes and functionalities related to the restricted procedure in their platforms.

Restricted procedure is a public procurement procedure regulated by the EU Directives on Public Procurement (EUPD), in which any interested Economic Operator (EO) can submit a request to participate in response to a call for competition (first stage of the procedure), but only those EOs invited to do so by the Contracting Authority (CA) following its assessment of the information provided may submit a tender (second stage of the procedure).

Alignment with regulation

This blueprint is aligned with:

• The regulation regarding Restricted Procedure: REGULATION on electronic tendering procedure for procurement of goods, services and works via restricted tender
• The following standard bidding document:

Technical design

Business process model

The following BPMN reflects the general process for a restricted procedure as prescribed by the EUPD, which has been taken as a regulatory basis for the local secondary legislation on which MTender system is based:

Figure 1 - BPMN for a general restricted procedure

State-chart diagram

The following image presents the sequence of stages applicable for a restricted procedure:

Figure 2 - State-chart diagram for a restricted procedure

More detail on the different statuses is provided in section “2.4 OCDS dataflow” of this document.

OCDS building blocks applied

Tender

With a tender block, all the data describing an aspect of the competitive part of the tendering process can be designed and structured. The general scope of data needed to publish a Contract Notice (CN) for this type of procurement method is the same as for a single stage procedure (e.g. open tender).

Along with all the common information prescribed by Open Contracting Data Standard (OCDS) 1.1 for a tender building block (https://standard.open-contracting.org/latest/en/schema/reference/#tender), some specifics can also be designed as follows:

Targets

Where a CA intends to achieve particular quantifiable results within the competitive part of the tendering process, such targets can be designed with a targets building block. The block is built according to ocds_metrics_extension .

Criteria

In order to prescribe a scope of qualification and conditions for participation (exclusion grounds, selection and qualification criteria), a criteria building block should be used inside tender. In the same way, qualification and evaluation check-points for the CA itself can be included in the criteria array: e.g. request for declaration of absence of the conflict of interests. The block is built according to an eOCDS_structuredAwardCriteria .

Conversions

Once quantitative criteria have to be included into the CN as well as applicable options and weights, a separate extension must be applied to allow the CA to include all the conversions needed for future qualification and evaluation. Conversions are built on eOCDS-conversions , which is a tool that enables the describing of the conversions used and their applicable coefficients.

SecondStage

Building block adds a secondStage object to the tender and lot objects, to describe the second stage of a two-stage procedure. More specifically, it adds two fields to describe the limits on the number of candidates to be invited. If there is an exact limit on the number of candidates, minimumCandidates and maximumCandidates are set to the same number. If maximumCandidates is set, the selectionCriteria is used to describe how the selection criteria will be used to select candidates to be invited for the second stage. The block is built according to ocds_secondStageDescription_extension .

Enquiries

The enquiries extension can be used to record questions raised by the CA during a tendering process, and the answers provided by the EO. The ocds_enquiry_extension adds an enquiries array to tender, consisting of one or more enquiry objects, each with fields for a question and an answer.

Pre-qualification

The pre-qualification phase can be designed using ocds_qualification_extension . This extension also extends the code list for party roles with qualifiedBidders and disqualifiedBidders.

Submission

In order to express their interest in participating in a specific procurement process, EOs can submit a request - submission. Such an expression of interest includes self-declaration on eligibility criteria (both exclusion grounds and selection criteria) expressed by the CA in accordance with a notation prescribed by a criteria building block (see above) in a CN:

State-chart diagram - requests to participate sent by interested parties

Figure 4 - State-chart diagram for a ‘submission’ object

2.3.4 Qualifications

In order to reflect the qualify/does not qualify conclusions or a result of automated eligibility checks (where applicable), CAs can form qualifications. Each such object includes a result of the pre-qualification/pre-selection for each submission received against the eligibility criteria (both exclusion grounds and selection criteria) expressed by the CA in the CN. Mentioned qualifications can be designed with the following OCDS-structure:

State-chart diagram - qualifications

Figure 6 - State-chart diagram for a ‘qualification’ object

Invitations

In order to invite those who passed the pre-qualification/pre-selection exercise to submit their technical and financial tenders, CAs publish invitations. These invitations can be designed with the following OCDS-structure:

Tenders

Information on bids submitted as part of a procurement process. An array of a submitted bids can be designed using the ocds_bid_extension

Awards

The award section is used to announce any awards issued for a tender. There can be multiple awards made. Releases can contain all or a subset of these awards.

Contracts

The contract section is used to provide details of contracts that have been entered into. Every contract must have a related award, linked via the awardID field.

Parties

Each of the parties (organisations or other participants) referenced in a release must be included in the parties section.

Organisations

The specific details prescribed by an Organisation Schema can be provided for each party.

Persons

Specific information related to a person, representing a particular organisation, can be also described according to eOCDS-persons .

Details

Additional details on a particular organisation can be expressed with ocds_organizationClassification_extension and ocds_partyDetails_scale_extension .

OCDS dataflow

State 0: Announcement of the initiation

Contract Notice

The general scope of data needed to publish a CN for this type of procurement method is the same as for a single-stage procedure (e.g. open tender).

Subject of procurement

The goods and services to be purchased, broken into line items and lots according to a CA strategy.

A tender process can be divided into lots, where EOs can submit for one or more lots. Details of each lot can be provided according to (ocds_lots_extension ). Items, documents and other features may then reference the lot they are related to, using relatedLot. Where no relatedLot identifier is given, the values ought to be interpreted as applicable to the whole tender.

Awarding methodology

The CA prescribes a methodology for the further qualification of submissions and evaluation of the tender based on the following techniques:

For a qualification process, the CA describes:

• Qualification method –how the qualification decision will be taken:
• manual - where the CA intends to undertake a qualification process involving an evaluation panel;
• automated - where the CA transfers the qualification process to a system based on all the qualification criteria prescribed by a CN.
• Reduction criteria – The CA prescribes criteria for the reduction of the number of candidates to be invited to submit a tender:
• scoring - where there is a limitation on the number of candidates to be invited
• o none - where there is no limit for the number of candidates to be invited to submit a tender

Both attributes are to be described and included in a structure of the CN in accordance with ocds_otherRequirements_extension.

For an evaluation process, the CA describes:

• Awarding criterion – a general indicator on which the award decision will be based:
• priceOnly - where awardCriteria: priceOnly - only bid.value to be compared in order to identify the most suitable tender – Cheapest goes first.
• costOnly - where awardCriteria: costOnly - assumption that all the tenderers have a same bid.value equal to lot.value. This means that the normalised price needs to be calculated for each tender received, based on lot.value. Cheapest goes first.
• qualityOnly - where awardCriteria: qualityOnly - assumption that the price doesn't matter and the only valuable part of the tender is the quality - meaning the set of values of criteria, selected by the EO while submitting a tender. This means that the normalised price needs to be calculated for each tender received, based on '1'. Most qualified goes first.
• ratedCriteria - where awardCriteria: ratedCriteria - assumption that both price and quality matter. This means that the normalised price needs to be calculated for each tender received, based on bid.value. Cheapest goes first.
• How awarding criterion is to be applied for initial scoring of the tenders received – using a separate tender.awardCriteriaDetails attribute, the CA prescribes how all the tenders received shall be scored (by a system) for further evaluation:
• automated - the awarding will be approached automatically based on ‘awardCriteria’ and a set of relevant requirementResponses received from the tenderers against `requirements` applied by the CA.
• manual - the awarding will be approached manually.

Criteria and requirements

A separate criteria array can be added into the tender building block schema to describe:

• Qualification and evaluation criteria and its minimum requirements;
• specific requirements related to a procurement subject;
• specific requirements related to delivery/performance;
• general and specific essential conditions of the future contract;
• requirements related to the CA;
• criteria for future advanced evaluation by the committee.

Conversions - weightings for a scoring function

A separate conversions array can be added into the tender building block:

• To describe conversions used and their applicable coefficients, either as a list of precise values or as a mathematical formula for calculation of the value of a particular coefficient in this particular case (depending on the value received within requirementResponse related to a specific requirement) to be applied;
• to relate each conversion used (together with coefficients) with used criteria or targets (where applicable);
• to include applicable options to used criteria or observations for targets.

Limit of number of participants

The CA is allowed to limit the number of candidates to be invited to submit financial and technical offers. Where this is a case, pre-selection instead of pre-qualification will be applied in order to evaluate candidates.

To limit the number of candidates, secondStage building block can be included in the tender or even a specific lot, as shown below.

For tender

For specific lot

Call for enquiries

In order to indicate the start of the explanatory phase of a procurement process, the CA shall establish a start date as an enquiry session.

Such an indication shall be done by adding a separate enquiryPeriod object into the tender building block, which will reflect an end date of the explanatory phase prescribed by the CA and its start date, reflected as a system moment of initiation of the explanatory phase:

Pre-qualification modality

Along with a start of initiation for the restricted procedure, a pre-qualification phase shall also be launched in order to receive requests for participations from EOs.

Pre-qualification establishment

A separate preQualification block shall be included in the CN, where preliminary qualification or selection of the candidates to be invited to submit a tender is needed.

Call for expression of interest

A call for expression of interest (EoI) is used in limited tendering to invite EOs to qualify themselves, e.g. by means of an ESPD or qualification. Submission of EoIs is only allowed during a specified period, determined by a stage of pre-qualification. In order to reflect such a period, a separate period object can be added into a preQualification block, where the specific timeframe for expressions is determined.

State1 - Submission phase (active.submission)

Enquiries - requests and clarifications

Within a call for clarifications tender.enquiryPeriod, any interested EO is allowed to send enquiries - requests for clarification. Such requests remain anonymous. Once tender.enquiryPeriod.endDate is achieved, no more enquiries can be received.

Enquires

All the enquiries received within tender.enquiryPeriod are disclosed immediately as enquiries array items. All the enquiries’ authors remain confidential until the start of the evaluation.

Answers

During the enquiryPeriod, the CA is able to submit an answer to a question received:

Submission - expression of interests

The submission of EoIs is only allowed during a specific period of time, determined by a pre-qualification stage. In order to reflect this period, a separate period object can be added into a preQualification block, where the specific timeframe for EoIs is determined. Thus, within a given preQualification.period, any interested EO is allowed to send a submissions - requests for participation or EoI. Each request shall fulfil all the requirements prescribed by the criteria related to tenderers, with a relevant list of the responses by the EO (confirmative or quantifiable), providing an array of requirementResponses.

Having a set of requirements predefined by the CA and a number of values available, tenderers preparing their submissions include values for each requirement and fulfil general corporate profiles’ data, as requested by the CA or required by the Legal Framework of a particular jurisdiction.

Thus, each submission includes:

1. An organisation profile according to the extended organization model;

2. A set of documents of the tender, specified with relevant types of documents for their future splitting into the different "envelopes";

3. A set of requirementResponses according to criteria specified by the CA within the CN:

• Commitment on exclusion grounds;
• commitment on selection criteria (including absolute values if required);
• commitment on minimum technical requirements (including absolute values if required).

All the submissions received remain confidential and closed until the end of the submissions period - preQualification.period.endDate. Once a deadline for submissions is reached, no submissions can be received, withdrawn or corrected.

State1.1 - Suspension due to non-clarification

Where initiation is suspended, a particular value for tender.statusDetails is used:

State8.1 - Unsuccessful completion of submission

Where not enough submissions were collected during the EoI period, the pre-qualification phase will end unsuccessfully, with no future actions by the CA. The procurement initiation shall be moved to a phase of preparation of a negative award notice.

Reflection of an unsuccessful submission period completion

The character of a result of the pre-qualification to be reflected with preQualification.status is:

• complete where enough candidates were selected for future invitation to submit a tender;
• unsuccessful where pre-qualification is unsuccessfully completed due to lack of submissions or because all the submissions were disqualified.

Indication of the unsuccessful outcome of a procurement initiation

For lots

A negative character of procurement under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected.

For entire initiation

A negative character of a procurement under an entire initiation (procurement process) is reflected with tender.status: unsuccessful, where initiation is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected. Details of a negative closure are reflected in tender.statusDetails.

• lackOfSubmissions
• allDisqualified
• lackOfOffers
• allRejected

State2 - Qualification phase (active.qualification)

Initiation of qualification phase

Disclosure of submissions

Where there are enough submissions, all the submissions are disclosed as a submissions array according to the relevant schema. All the submissions’ authors are added into parties as organizations with a role: candidate.

Establishment of a period for qualification by the CA

In order to indicate a start of the qualification phase of a procurement process, a start date must be established. Such an indication shall be done by adding a separate qualificationPeriod object into the preQualification building block, which will reflect a start date of the qualification phase as a system moment:

Qualification envelopes

Along with establishment of preQualification.qualificationPeriod.startDate, a set of qualifications is established against each submission received in order to allow the CA to reflect its decision on each submission. Such objects are initially established with status:pending and statusDetails:awaiting (State1 of a relevant state-chart diagram of a qualification object). Since no order is prescribed for the pre-qualification sequence, the CA can evaluate submissions received randomly.

Declaration of non-conflict of interest

Before starting qualification, each declared member of the evaluation panel shall respond with a confirmation of absence of conflict of interest against each candidate from each qualification by sending requirementResponses, following a common flow for declarations, as described in Conflict of interests - declaration by the CA

Qualification of submissions

Once all the non-conflict of interest declarations are submitted by evaluation committee members, the qualification for review is switched into qualification.statusDetails: consideration (State 2 of a relevant state-chart diagram of a qualification object).

Consideration

The CA shall update the qualifications with all the required meta-data. By updating, the CA reflects its decision on each submission received. The CA is allowed to:

• Add any qualification.documents if needed;
• add qualification.requirementResponses if any relevant requirements related to the CA within the pre-qualification phase prescribed by tender.criteria is applied;
• add text qualification.descriptions where any justification is needed;
• add qualification.date when any decision was taken;
• add qualification.internalID, if any.

Indication of a decision

Once consideration of a specific submission is complete and the related qualification is fully updated with all relevant data, the CA shall change the qualification state, reflecting a positive or negative decision in this regard:

• qualification.statusDetails: active - state 3 of a relevant state-chart diagram of a qualification object. This means the submission is qualified and a candidate(s) will be invited to submit a commercial tender.
• qualification.statusDetails: unsuccessful - state 4 of a relevant state-chart diagram of a qualification object. This means the submission is disqualified.

As soon as the CA has completed the qualification and all the submissions received are updated with the relevant meta-data, the CA indicates the end of qualification.

State3 - Standstill period for pre-qualification

In this state, no one can take any action except the CA to switch the process to State4 or back to State2. No other actions can be prescribed for the system - all review procedures go offline and the time tracking is up to the CA.

Completion of qualification period

If no blockers are indicated during the stand-still period, the CA can initiate the end of the qualificationPeriod and the entire pre-qualification phase. Additional values of the endDate can be added into the preQualification.qualificationPeriod as an indication of pre-qualification completion.

Finalisation of pre-qualification

Finalisation of the qualifications

All the qualifications shall be moved by a system into relevant final statuses:

• qualification.status: pending / statusDetails: active → qualification.status: active / statusDetails: none (State 3 to State 3.1 of a relevant state-chart diagram of a qualification object. Means that the submission is qualified and the candidate(s) is invited to submit a tender).
• qualification.status: pending / statusDetails: unsuccessful → qualification.status: unsuccessful / statusDetails: none (State4 to State4.1 of a relevant state-chart diagram of a qualification, see 3.3.4.1). Means the submission is disqualified).

Finalisation of the submissions

All the related submissions are assigned the relevant statuses:

• submission.status: pending where relevant qualification.status: active → submission.status: valid (State1 to State3 of a relevant state-chart diagram of a submission).
• submission.status: pending where relevant qualification.status: unsuccessful → submission.status: disqualified (State1 to State4 of 2.3.3.1 state-chart diagram of a submission).

Completion of pre-qualification

The character of a result of the pre-qualification to be reflected with preQualification.status is:

• complete where enough candidates were selected for future invitation to submit a tender;
• unsuccessful where pre-qualification is unsuccessfully completed due to a lack of submissions or because all submissions were disqualified.

State8.2 - Unsuccessful completion of pre-qualification

Where all the submissions collected during the EoI period were disqualified, the pre-qualification phase will end unsuccessfully with no future actions by the CA. Procurement initiation shall be moved to a phase of preparation of a negative award notice.

Completion of qualification period

If no blockers are indicated during the stand-still period, the CA can initiate the end of the qualificationPeriod and the entire pre-qualification phase.

An additional value of endDate is added into preQualification.qualificationPeriod as an indication of pre-qualification completion.

Completion of pre-qualification

The character of a result of the pre-qualification is reflected with preQualification.status. It is:

• complete where enough candidates were selected for future invitation to submit a tender;
• unsuccessful where pre-qualification is unsuccessfully completed due to a lack of submissions or because all the submissions were disqualified.

Indication of the unsuccessful outcome of procurement initiation

For lots

A negative character of a procurement under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected.

For entire initiation

A negative character of a procurement under entire initiation (procurement process) is reflected with tender.status: unsuccessful, where initiation is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected. Details of a negative closure are reflected in tender.statusDetails.

• lackOfSubmissions
• allDisqualified
• lackOfOffers
• allRejected

State4 - Tendering (active.tendering)

Invitations for selected candidates

Once pre-qualification and the following stand-still period are over and the tendering session is initiated by the CA, in order to disclose a short-list of invited candidates, separate array invitations is generated with separate elements for each invited candidate (those whose submissions are affiliated with qualification.status: active).

The authors of valid submissions are reflected in the parties section with an additional role: invitedCandidate. Only those tenderers indicated in invitations are allowed to submit their financial and technical offers. All the others are refused automatically.

Call for proposals

In order to indicate the start of a tendering phase of a procurement process, the CA shall establish a start date as a call for tendering of the commercial tenders. This indication shall be done by adding a separate tenderPeriod object into the tender building block, which will reflect an end date of the tendering phase prescribed by the CA and its start date reflected as a system moment of initiation of the tendering phase:

Tendering

Each invited candidate is allowed to submit a financial and technical tender within the given tender.tenderPeriod indicated with any call for tenders. Each tender is based on a Bids schema. Each tender shall fulfil all the requirements prescribed by the criteria related to items or lots, with a relevant list of the responses by the EOs and providing an array of requirementResponses.

Having a set of requirements predefined by the CA and a number of values available, tenderers preparing their submissions include values for each requirement and fulfil the general corporate profiles data as requested by the CA or required by the Legal Framework of a particular jurisdiction.

Thus, each tenders includes:

• Reference on organization profile sent previously while submitting an expression of interest;
• set of documents of the tender, specified with relevant types of documents for their future splitting into the different "envelopes";
• absolute financial value of a tender- bids[*].value;
• decomposed array of unit prices (if requested by the CA) - bids[*].items.unit.value;
• set of requirementResponses according to criteria specified by the CA within the CN related to the financial part of the tender:
• reflections on requirements characterise the nature of the subject of procurement;
• reflections on requirements characterise the nature of the delivery and post-delivery.

All the tenders collected remain confidential and closed until the end of the period for tendering - tender.tenderPeriod.endDate. Once tender.tenderPeriod.endDate is reached, no tenders can be received, withdrawn or corrected.

State8.3 - Unsuccessful completion of tendering

Where not enough tenders were collected during the tendering period for all the announced lots, the evaluation phase will end unsuccessfully with no future actions by the CA. The procurement process shall be moved to a phase of preparation of a negative award notice.

Indication of the unsuccessful outcome of procurement process

For lots

A negative character of a procurement under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected.

For entire initiation (tender)

Where all the lots are unsuccessful, the entire procurement initiation goes to State8.3. A negative character of a procurement under entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed unsuccessfully due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected. Details of a negative closure are reflected in tender.statusDetails.

• lackOfSubmissions
• allDisqualified
• lackOfOffers
• allRejected

State5 - Evaluation (active.evaluation)

Initiation of the evaluation phase

Disclosure of the proposals

Where enough tenders are received, all the tenders are disclosed as a tenders array according to the relevant schema. All the authors (bid.tenderers) are updated into parties as an organizations with a role: tenderer.

Establishment of a period for evaluation

A separate object awardPeriod is added into a tender block where the specific startDate for awarding is determined automatically.

Evaluation envelopes

Such objects are based on an awards schema and initially established with status:pending with statusDetails:none for all.

Disclosure of the enquirers

Together with initiation of the evaluation phase, all the enquirers (tender.enquiries[*].author) are reflected into the parties with a role: enquirer once tender.enquiryPeriod.endDate is reached.

Initial ranking on award criteria

Depending on tender.awardCriteria and tender.AwardCriteriaDetails, initial automated ranking can or cannot be done, as described in Ranking for evaluation: Ranking for evaluation:

Depending on previously established or not established eligibility checks, the result state may be:

• award.statusDetails: consideration - where an eligibility check took place previously
• award.statusDetails: awaiting – where an eligibility check was not conducted by the CA previously

Evaluation

To evaluate the tender, the CA shall update the related award with all the required meta-data. In these updates, the CA is allowed to:

• Add any documents if needed;
• Add requirementResponses if there are any relevant requirements related to the CA within the evaluation phase prescribed by tender.criteria;
• Add text descriptions where any justification is needed;
• Add date when the decision was taken;
• Add internalID, if any.

Indication of a decision

Once the evaluation of a specific tender is complete and the related award is fully updated with all relevant data, the CA shall switch the award to one of the following states, reflecting a positive or negative decision:

• award.statusDetails: active - means the related tender is selected as a winning tender to be awarded;
• award.statusDetails: unsuccessful - means the related tender is rejected.

As soon as the CA has completed the evaluation and the winning candidates for a particular lot are identified or all the proposals under this lot are rejected, the CA indicates the end of evaluation for the lot by publishing an intention to award a contract (award decision).

Award decision

To reflect a decision regarding each specific lot and the proposal selected to be awarded with a contract (award.statusDetails:active), the CA prepares a Notice on Award Decision. This data-entity is based on a contract schema and included in a contracts array.

Since it a stand-still period for evaluation, initially these contracts are established with a status: pending and statusDetails, which reflects a decisions' character:

• contract.statusDetails: active where the decision regarding the lot is positive (winner is identified);
• contract.statusDetails: unsuccessful where the decision regarding the lot is negative (all the tenders were rejected).

Stand-still period

In this state, no one can take any actions except the CA, who switches the process to State4 or back to State2. No other actions can be prescribed for the system - all review procedures go offline, and the time tracking is up to the CA.

Cancellation of the award decision

To reflect a decision to cancel a specific award decision taken previously under a particular lot, the CA shall switch the relevant contract object into contract.status: cancelled.

Confirmation of the award decisions

If no blockers indicated during stand-still period, the CA can initiate contract preparation for the awarded lot or finalization of an unsuccessful output of a lot where all the proposals were rejected during the evaluation phase.

Confirmation of a negative award decision

Confirmation of a negative award decision requires switching the relevant contract object to final status: unsuccessful, with a parallel indication of the reason for a negative outcome as a statusDetails:

Confirmation of a positive award decision

Confirmation of a positive decision requires reflecting the subsequent contract initiation into a relevant contract object by indicating statusDetails, provided that the object remains intermediate status: pending:

Contract initiation

To describe and reflect the scope of a contract to be concluded on a positive award decision, a parallel data-stream will be initiated. This stream is a separate OCDS-record where all the information related to future contracts is collected from a current procurement process. In order to establish the relation with this parallel stream, the relevant contract reflects a positive award decision and shall be extended with a relatedProcess.relationship: [x_contracting]:

Contract preparation and activation

According to a common flow of MTender, the preparation of a contract is concluded.

State8.4 - Unsuccessful completion of evaluation

Where all the tenders collected during the period of tendering were rejected, the evaluation phase will end unsuccessfully with no future actions by the CA.

Indication of the unsuccessful outcome of procurement initiation

For lots

A negative character of a procurement under a specific lot is reflected with lot.status: unsuccessful, where the lot is closed in a negative way due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected.

For entire initiation (tender)

A negative character of a procurement under the entire initiation (procurement process) is reflected with tender.status: unsuccessful, where the initiation is closed in a negative way due to a lack of submissions for pre-qualification or tenders for evaluation, or where all the tenders were rejected. The details of a negative closure are reflected in tender.statusDetails.

• lackOfSubmissions
• allDisqualified
• lackOfOffers
• allRejected

State6 - Completion of procedure

Indication of a successful outcome of a procurement initiation

For lots

A positive character of a procurement under a specific lot is reflected with lot.status: complete

For entire initiation

A positive character of a procurement under an entire initiation (procurement process) is reflected with tender.status: complete.

State7 - Cancellation of procedure

State7 is a cancellation of procedure. The cancellation flow is common to any procurement method and described in a separate document (the API guide for NEPPs:

https://mtendereprocurementsystem.github.io/MTender-Documentation/API/).

Annexes

Evaluation Committee

Background

The process of evaluation of tenders is generally carried out by a suitably competent evaluation panel. According to the Public Procurement Guidance for Practitioners by the European Commission, it is best practice to establish the Evaluation Committee as soon as the decision has been taken to proceed with the procurement to ensure that the procurement process is done in the most professional way by involving all the necessary staff qualifications from the start.

The Committee needs to have a permanent core of members. Procurement, financial and legal persons should be permanent members. Technical staff will be members depending on the type of contract. The committee should ideally comprise members experienced in each of the areas to be examined in the tender.

A chairperson is usually appointed to lead, co-ordinate, give guidance and control the process of evaluation of tenders. The chairperson is responsible, inter alia, for ensuring that the process of tender evaluation is carried out in accordance with the general law and Treaty principles as well as local requirements. A secretary to the evaluation panel, generally with non-voting powers, is often appointed for the purpose of providing support to the chairperson, carrying out the administrative tasks linked to the evaluation process, and keeping the minutes of each meeting.

The way in which the members of the evaluation panel operate - for example, whether they assess the tenders independently or jointly - depends on local legislation or local practice.

In principle, the evaluation panel normally has only the mandate to identify the best tender and to make a recommendation as to the award of the contract to the CA.

References

• Tender Evaluation and Contract Award by the Sigma Programme (OECD and EU)
• How will the tenders be evaluated? (page 18) by the Office for Infrastructure and Logistics of the European Commission
• Public Procurement Guidance for Practitioners by European Commission

Technical design

In order to declare an evaluation panel member, the CA while preparing a CN can add specific information about each person to be included in the evaluation panel by adding relevant information according to a `persones` block:

Structured criteria

Background

A set of criteria may include different types of requirements, used in different ways and for different reasons. Some of the criteria used may be prescribed on the legal basis “by default” (exclusion grounds of ESPD or particular chapters of selection grounds from ESPD, like ‘general yearly turnover’).

Types of criteria

Under each Tendering Process, the CA may define and apply various types of criteria:

Pre-qualification, pre-selection or the scoring function.

According to the ESPD, the structure of qualification criteria is as follows:

Exclusion grounds

These criteria are eligibility criteria put forward by the CA to the candidates. All of them are published in the CN and relate to the whole procedure.

Selection criteria

These criteria are also eligibility criteria, but they are optional for the CA to apply for the tender. The criteria allow determining the quantitative and qualitative criteria for candidates for participation in the procedure.

Allowances

These criteria are award criteria and should be taken into account by the CA in cases determined by the relevant law, which also defines a set of these criteria and their values. Examples include the following criteria:

• The proposal of the candidate-resident of the country of jurisdiction receives a reduction factor;
• The proposal of a candidate-resident of the country of jurisdiction if the candidate is an organisation in the category of SMEs receives a reduction factor of price.

Non-price criteria

These criteria are award criteria and can be applied by the CA in the case of the most economically advantageous tender (MEAT) strategy. MEAT is recognised as winning according to the following criteria:

• In case of contracts for public procurement of goods - the price, delivery time, payment terms, profitability, quality, aesthetic, functional and technical characteristics, capabilities and cost of technical assistance and maintenance.
• In the case of contracts for public procurement of works - the proposed quality, cost per unit of product of the tenderer by the end of the work, total price, experience of the tenderer, etc. The share of the price in the total evaluation of the tenders should not be more than 80%.
• In the case of contracts for public procurement of services - the proposed quality, cost per unit of the tenderer’s products, total price, experience of the tenderer, etc. The price share in the total evaluation of the tenders should not be more than 40%.

Therefore, depending on the category of procurement, the CA can determine a set of non-price criteria (quantitative and qualitative) in the range of 20-60%, which will be taken into account along with the price part of the tender and affect the absolute economic value of the entire tender proposal.

Guarantees

The CA may, if deemed appropriate and proportionate, on a case-by-case basis and subject to a risk analysis, require contractors to lodge a guarantee. For example, in the case of works contracts, a performance guarantee may be required to assure the Commission that the contract will be properly fulfilled after provisional approval and payment of the balance, pending final acceptance.

An example of this application is described by ocds_requirements_extension (example).

Bid bond / Performance guarantee

The guarantee is released after final acceptance of the deliverables, except where the contract has not been performed or has been performed incorrectly or completion is late. In these cases, a part of the guarantee is retained, in proportion to the seriousness of the damage suffered, at the first request of the Commission. If the value of the damage is greater than the sum of the guarantee, the whole guarantee will be retained.

Essential conditions - contract draft

The draft contract containing all the elements of the contract that will subsequently be signed is enclosed with the tender documents so that tenderers have all the information they need. The draft contract is divided into two parts:

General conditions

The terms that apply to all contracts of the same type, unless the special conditions derogate from them.

Specific conditions

They cover the subject and duration of the contract, the price, and arrangements for implementing the contract (deadlines for ordering, paying, etc.). They specify whether a performance guarantee must be provided by the future contractor to ensure proper implementation of the contract.

Technical design

Separate criteria array to be added into tender building block according to a criteria schema to describe:

• Qualification and evaluation criteria and their minimum requirements;
• Specific requirements related to a subject of procurement;
• Specific requirements related to delivery/performance;
• General and specific essential conditions of the future contract;
• Requirements related to the CA;
• Criteria for future advanced evaluation by the committee.

Examples

Below is an example of requirements specified against both an item and a tenderer:

Coefficients for conversion

Background

Pre-selection of the candidates and future evaluation of the tenders submitted by invited candidates is a critical part of the procurement process, and for this reason care must be taken to ensure that the outcome is the right one and that it has been decided in a fair and transparent manner.

The criteria for the awarding of contracts are either the lowest price only or the MEAT. If the MEAT method is used, either the CN itself or the tender documents must detail all criteria to be used . Best practice would be to disclose in the tender notice or tender documents the scoring matrix or weightings being used in addition to the evaluation methodology.

Pre-qualification questionnaire (PQQ)

If it is the intention to have a shortlist of tenderers, then this must be done by fair and transparent means giving equal treatment to all. Thus, CAs should indicate beforehand in the CN or tender documents a set of minimum requirements, in particular:

• The minimum requirements which characterise the nature of the procurement (which should not be changed in the negotiations or evaluation);
• Minimum eligibility and qualification requirements to be fulfilled by any tenderer.

along with

• The values available for each applied requirement;
• The relative weighting of each option available under each applied requirement.

Scoring matrix for evaluation

Tender evaluation should:

• Have award criteria that are weighted to reflect importance/priority and are focused on the requirements of the specification (judging on quality rather than price);
• Be relevant to the subject matter of the contract;
• Preferably be based on a model that takes into account a balance between price and quality where price is the dominant criteria in %. Care must be taken to ensure that the price/quality split reflects the requirements of the contract;
• Have approval for the award criteria and the evaluation model (including weightings of each criterion); and
• Use an Evaluation Committee made up of appropriate and relevant representation having the necessary experience, technical skills and knowledge.

Technical design

A separate conversions array is added into tender building block according to a Conversions schema ‘Conversions’ is a tool that allows describing used conversions and their applicable coefficients.

• To describe used conversions and their applicable coefficients, either as a list of precise values or as a mathematical formula for calculation of the value of a particular coefficient in this particular case (depending on the value received within requirementResponse related to a specific requirement) to be applied.
• To relate each conversion used (together with coefficients) with used criteria or targets (where applicable).
• To include applicable options to used criteria or observations for targets.

True/false requirement and its coefficients of conversion

This simple criterion that requires only a true/false answer can be used by the CA. For example, if the currently submitting EO is a domestic tenderer, his/her tender will get a ratio that increases the advantage of its price by 20%:

Using criteria, we can describe this criterion as such. But using conversions, we can also describe applicable coefficients:

Therefore, if the EO responds that his/her company is a domestic tenderer, using cross-reference through requirement.id we can extract an applicable coefficient - 0.8.

Requirement with a predefined set of coefficients of conversion for a specific criterion value

The criterion that requires a precise answer with digitalisation can be used by the CA. For example, when a minimum product warranty of 1 year is required for all tenders but warranties of 2 years receive a 15% advantage and warranties of 3 years or more receive a 30% advantage:

Using criteria, we can describe this criterion as such where the EO is required to confirm that s/he guarantees at least 1 year of product warranty (002-1-1) but also to specify a precise number of years for this guarantee for the proposed product (002-1-2). Using conversions, we can also describe applicable coefficients:

Depending on the EO’s response, we will have an applicable coefficient for future conversion.

Ranking for evaluation

Depending on tender.awardCriteria and tender.awardCriteriaDetails, initial automated ranking can or cannot be done:

awardCriteria	awardCriteriaDetails	formula
priceOnly	automated	bid value
	manual	-
costOnly	automated	bid.requirementResponses * lot.value
	manual	-
qualityOnly	automated	bid.requirementResponses * 1
	manual	-
ratedCriteria	automated	bid.requirementResponses * bid.value
	manual	-

As shown in the above table, automated ranking can be undertaken automatically using a set of criteria and the relevant conversions applied by the CA for each available value of each applied requirement and published in a CN, on one hand; and the bid.requirementResponses submitted by each EO against published criteria on the other hand. These two data-sets allow the normalised value for each bid based on the same approach to be calculated.

Normalised price

Where normalised price must be calculated, the following formula is applied for each tender in order to identify which one is most suitable by normalised price:

Pn = P * C1 * C2 * ... Cn

where

• Pn - value of normalised price
• P - basic price taken from bid.value or lot.value or equal to '1' depending on awardCriteria
• C1 ... Cn - values of the coefficients to be applied (related with a values of requirements, available for EO and indicated in requirementResponses)

Ranking approach

priceOnly

Where awardCriteria: priceOnly - only bid.value is compared in order to identify the most suitable tender. Cheapest goes first.

costOnly

Where awardCriteria: costOnly – the assumption is that all the tenderers have the same bid.value equal to lot.value. It means that the normalised price needs to be calculated for each bid received based on lot.value as a basis. Cheapest goes first.

qualityOnly

Where awardCriteria: qualityOnly – the assumption is that the price doesn't matter and the only valuable part of the tender is quality - meaning set of values of criteria, selected by the EO while submitting a bid. It means that the normalised price needs to be calculated for each bid received, based on '1'. Most qualified goes first.

ratedCriteria

Where awardCriteria: ratedCriteria – the assumption is that both price and value matter. It means that the normalised price needs to be calculated for each bid received based on ‘bid.value'. Cheapest goes first.

Where automated ranking is the case, all the awards are ranked into order for evaluation and the first award (most suitable according to the prescribed evaluation function) will be switched to the next state ‘available for evaluation’ by the CA.

Conflict of interests - declaration by the CA

“Member States shall ensure that contracting authorities take appropriate measures to effectively prevent, identify and remedy conflicts of interest arising in the conduct of procurement procedures so as to avoid any distortion of competition and to ensure equal treatment of all economic operators.

The concept of conflicts of interest shall at least cover any situation where staff members of the contracting authority or of a procurement service provider acting on behalf of the contracting authority who are involved in the conduct of the procurement procedure or may influence the outcome of that procedure have, directly or indirectly, a financial, economic or other personal interest which might be perceived to compromise their impartiality and independence in the context of the procurement procedure."

EU24/2014 Article 24. Conflicts of interest

Types of conflict

• "Conflict of interest" means any situation where an individual has an interest that may compromise or be reasonably perceived to compromise the individual’s capacity to act independently and in the public interest when providing advice to the Commission in relation to the subject of the work performed by the expert group or sub-group in question.
• "Immediate family member" means the individual’s spouse, children and parents.
• "Spouse" includes a partner with whom the individual has a registered non-marital regime.
• "Children" means the child(ren) the individual and the spouse have in common, the own child(ren) of the individual and the own child(ren) of the spouse.
• "Legal entity" means any commercial business, industry association, consultancy, research institution or other enterprise whose funding is significantly derived from commercial sources. It also includes independent own commercial businesses, law offices, consultancies or similar.
• "Body" means a governmental, international or non-profit organisation.
• "Meeting" includes a series or cycle of meetings.

References

• Standard declaration of interests (DI) form for individuals applying to be appointed as members of Scientific Committees' Working Groups in a personal capacity by the European Commission
• Template declaration of absence of conflict of interest and confidentiality by the European Commission (6.5)
• Identifying conflicts of interests in public procurement procedures for structural actions a group of Member States' experts coordinated by OLAF's unit D2- Fraud Prevention of the European Commission
• Conflicts of Interest under EU procurement law by Public Procurement Analysis (PPA).

Technical design

The issue of considering a "certificate" as a core extension was reviewed by the OCP helpdesk and the following conclusion was made: "There has been some discussion of approvals and certification in open-contracting/standard#403 and the work in the Requirements Extension can potentially be used to model a requirement that a supplier needs to be certified in a particular way.". Based on this, the following approach could be applied in the system to cover the DoI needs:

Request of Declaration

Since the declaration is the same for all the members of the evaluation panel (either single procurement officers or all the members), it can be designed as a common requirement under specific criteria, related to the organisation appointed as a CA:

Declaration

Now each declared member of the evaluation panel can respond with a confirmation of absence of conflict of interest against each tenderer from each award (in case of a combined evaluation under single-stage procurement) or each candidate from each qualification (in case of a multi-stage procurement with prior qualification) by sending the relevant requirementResponses.