-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pre-qualification/pre-selection for single use #906
Comments
@yolile How does the above proposal sound for pre-qualification in Paraguay? There are a few decisions to make, in the bullet list. |
For the array field, it would have different objects depending on the procedure (eg competitive dialogue) and techniques (eg electronic auction) used. This is harder to use, implement and validate. Instead, we can have different fields depending on the type of second stage. Similar to The field name for the second stage after pre-qualification/pre-selection can be |
@yolile For Paraguay's current implementation, in the If the proposal sounds good to you, then what's left to do is to author the proposal as an extension (minus the deprecations and the changes to titles and descriptions of existing fields). |
Thanks for this @jpmckinney , your proposal looks good, but, the only problem that I see with Paraguay is that the prequalification and its tender are different processes so, they have differents ocids. The ocid for the second stage (tender) comes from the planning. And the ocid for the first stage (prequalification) comes from the prequalification itself. And the link between the tender and the prequalification is set when the tender is made, not before. So if we use, for example, the prequalification number as ocid, the planning data will not be disclosed until the tender is made. |
Should we use the relatedProcess to link both processes? If yes, should we add the "preQualification" code to the related process codelist? (what I was planning to do we the existing qualification extension) |
Hmm, I need to understand how Paraguay's system works:
If that's how it works (please confirm), then in OCDS, this must be modelled as one contracting process. A process that, by design, never results in awards or contracts is not what OCDS considers a 'contracting process'. In the UNCITRAL Model Law, in many other jurisdictions, and similarly in OCDS, pre-qualification is just the first stage of a two-stage process. The thing I don't understand is how it's possible that suppliers are pre-qualified without there being a plan to justify their qualification. If a government has a pre-qualification process to identify qualified suppliers of uniforms, surely there must first be a plan to procure uniforms? If they don't plan to procure uniforms, then they are wasting suppliers' time. Can you clarify? In any case, if it's impossible to know what invitation to tender the pre-qualification is for until after the pre-qualification is complete, then I suppose there can be one OCID for the pre-qualification + tender and then another OCID for just the planning (which, as it precedes the start of a contracting process, is an exception to the rule above), and using relatedProcesses to relate the two using the existing 'planning' code. The OCDS governance process decided against having a 'preQualification' code in #371, so using one would not be conforming to OCDS. |
Sometimes, it can be used for multiples tenders, for examples, when the tenders are too similars example: Or after an unsuccessful tender the same prequalification can be used for the new one.
Yes, it's impossible. |
I see there are two requests for tender about 7 months apart (first, second). The pre-qualification was completed not long before the first request for tender. It sounds like this process in Paraguay is more like a 'multi-use list' as defined in GPA:
This is more like a framework agreement in structure. The proposal above is more for a (typical) restricted procedure in structure. I'll create a separate issue for this distinct structure.
Can you describe or link to an example of this? In other jurisdictions, if a procedure with pre-qualification is unsuccessful, I can't think of an example where the next procedure uses the same list of qualified suppliers (for example, a common problem is that not enough qualified suppliers submitted requests to participate). |
New issue is #909. |
Thanks for this proposal @jpmckinney I'd like to clarify a few points. Firstly, should:
actually read:
Secondly, is something missing from the following part of the proposal? I didn't understand it.
Thirdly, I want to check I understood the overall model you are proposing: {
"ocid": "",
"tender": {
"method": "?"
},
"secondStage": {
"type": "?",
"candidates": [
{
"id": "",
"name": ""
}
],
"invitations": [
{
"id": ""
}
]
},
"awards": [
{
"id": "",
"invitationID": ""
}
]
} This threw up a couple of questions:
|
Separately, I note that some jurisdictions model pre-qualification as a separate process, though this doesn't match the desired semantics of OCDS (New South Wales: #371 (comment)). |
UNCITRAL glossary defines:
EBRD glossary lists:
|
Context
The proposal in this issue is for pre-qualification/pre-selection leading to a single request for tender (i.e. the pre-qualification stage produces a single-use list of qualified suppliers).
There is another issue for pre-qualification/pre-selection leading to a multi-use list or similar: #909
Background
This issue is to break up #440 into smaller issues. This comment #440 (comment) has a proposal for how to model two-stage procedures in OCDS without causing backwards-incompatible changes. This issue specifically focuses on procedures with a pre-qualification or pre-selection stage.
Broadly speaking, such procedures have a first stage in which potential suppliers submit requests to participate. Submitters are qualified/selected based on their submissions, according to qualification/selection criteria. If there is a limit to the number of qualified candidates, then this stage is known as pre-selection instead of pre-qualification, and involves score/rank criteria instead of pass-fail criteria. Qualified/selected candidates then submit tenders in a second stage. (See UNCITRAL Glossary)
Qualification/selection criteria can presently be expressed using the requirements extension.
Proposal
First stage model
Per #440 (comment), the first stage should be modelled using the
tender
block. Indeed, this is already the block to which the requirements extension adds acriteria
field to express qualification/selection criteria, which need to be known in the first stage. (Related: #590)The qualification extension – which will be deprecated per the linked comment – is the present solution for pre-qualification/pre-selection and has the same structure as the
tender
block, with one difference (mentioned later). Given that it has the same structure, most fields in thetender
block can be used without modification for the first stage of a procedure with pre-qualification/pre-selection, just as they were in that older solution.awardCriteria
,awardCriteriaDetails
andawardPeriod
will still refer to the award that occurs after the second stage.As for
tenderPeriod
,numberOfTenderers
andtenderers
, we need to make a decision. FortenderPeriod
, we can either, in order of preference:submissionPeriod
and deprecatetenderPeriod
. And then, either:tenderPeriod
is used, then it should be interpreted as 'submission period'.tenderPeriod
is used, then it should be interpreted as 'submission period for tenders'.tenderPeriod
to mean 'submission period'.participationPeriod
to mean 'submission period for requests to participate' and leavetenderPeriod
to mean 'submission period for tenders'.For
numberOfTenderers
andtenderers
, the options are similar. For option 1, the new fields would benumberOfSubmitters
andsubmitters
. For option 3, I don't presently have a proposal for field names. (Related: #903)The first two options are preferred to the third, because, for example, if potential suppliers are looking for opportunities, they care about the submission period for the first stage, not for the second stage. And the first option is preferred to the second, because
tenderPeriod
is a confusing term for 'submission period'.Sidebar: We can add
qualificationPeriod
(the one difference from the qualification extension) to mirrorawardPeriod
; however, I want to check the supply and demand for this field, as it's more relevant to know the expected date on which invitations to submit tenders will be sent, rather than the start/end date of an internal process. (That said, neither of these concepts is considered in this proposal.)In terms of party roles, the parties submitting requests to participate should have a 'submitter' party role, to distinguish them from a 'tenderer'.
There is presently no extension (in either the older or this solution) to disclose the requests to participate (i.e. there is no extension that mirrors what the bids extension does for tenders).
Second stage model
Now, to model the second stage, continuing from the linked comment, we'd have a
secondStage
object to describe the stage, and then an array for each part of the stage (e.g. in a competitive dialogue or an electronic auctoin, there can be many rounds). For this issue, the array would have a single object for the invitation to tender. This object would match the currenttender
block (though we can decide to update the field names as above), but with fewer fields, so that we're not disclosing theawardPeriod
, etc. in two places. What remains is to at minimum decide the name of the array field.Update: This array field might have different objects depending on the procedure (e.g. competitive dialogue rounds, framework agreement mini-competitions) and techniques (e.g. electronic auction rounds) used. Having different objects in an array is harder to use, implement and validate. Instead, we can have different fields depending on the type of second stage. Similar to
initiationType
(which is presently used to distinguish PPPs in the first stage), we can add asecondStage.type
field. In the case of pre-qualification/pre-selection, the array field can beinvitations
.In terms of party roles, the parties that are qualified can be given the 'qualifiedBidder' code from the qualification extension; however, if that extension is rarely used, we can use a more flexible 'candidate' code. There can be an
secondStage.candidates
field to refer to these parties. Any 'submitter' that is not a 'candidate' can, by implication, be determined to be not qualified; however, an explicit indication can be considered like the 'disqualifiedBidder' code. The parties submitting tenders should have a 'tenderer' party role, like in an open procedure.Award stage model
We will need to add an
invitationID
field to relate the Award to the Invitation insecondStage.invitations
.Next steps
tenderPeriod
,numberOfTenderers
andtenderers
intender
.secondStage
(which is a new object betweentender
andawards
).tender
block in the object for the invitation to tender under thesecondStage
block.tender
block. We can refer to "first stage" and/or to use constructions like "tenders or requests to participate", "invitations to tender or to participate", etc. like in the EU forms.partyRole.csv
codelist, as aboveawards.invitationID
field.Note: The
preQualificationStatus.csv
codelist has no new codes compared totenderStatus.csv
.The text was updated successfully, but these errors were encountered: