Bids: Add support for disclosing notified suppliers

[yolile]

In Paraguay, some tendering process require the Procuring Entity to send invitations to bid to certain suppliers. These invited suppliers can or not make a bid then and become a tenderer. An example can be found here: https://www.contrataciones.gov.py/licitaciones/convocatoria/362337-construccion-polideportivo-9no-etapa-1.html#invitados

To publish this information it is proposed to add an array of invitedSuppliers (organization reference) to tender and "invitedSupplier" role in the Organization roles codelist.

Example:

 {
 "parties": [
    {
         "id": "2340874-0",
         "name": "BERLINDA PARRA NUÑEZ",
         "roles": ["invitedSupplier"]
    } 
 ], 
  "tender": {
      "invitedSuppliers": [
            {
               "id": "2340874-0",
               "name": "BERLINDA PARRA NUÑEZ"
           }
       ]
  }
}

[jpmckinney]

So, globally, suppliers can be invited in a few ways:

• pre-qualification ('selective', where tenderers respond with a request to participate, are qualified, and then qualified tenderers are invited to bid, i.e. the ultimate test is pass/fail)
• pre-selection (also 'selective', but where qualified bidders are furthermore shortlisted, i.e. the ultimate test is a ranking with a cut-off)
• direct solicitation ('limited' – or 'direct' if only one supplier – where the procuring entity decides on its own who to invite to bid)

The proposed model wouldn't distinguish between these – which might be preferred. Presently, in OCDS for PPPs, and in the recent PR open-contracting-extensions/ocds_qualification_extension#28, we have 'qualifiedBidder' and 'disqualifiedBidder' codes, which are specific to pre-qualification.

If we go with 'invitedSupplier', we should change that PR as well (or perhaps add these codes to OCDS itself).

[yolile]

So, globally, suppliers can be invited in a few ways:

In Paraguay, the invitation doesnt implies that:

• the invited supplier must make a bid
• others suppliers cannot make a bid

So the process is an open procurement but, just to be sure that at least some publishers knows that there is a tender, the procuring entity sends an invitation to some suppliers, but any supplier can make a bid.

[jpmckinney]

Aha, I didn't realize that the invitation didn't imply that "other suppliers cannot make a bid". I was only familiar with cases where, if specific suppliers are being invited/solicited, it's because the procedure is selected or limited.

To avoid confusion, we can consider something like "notifiedSuppliers" which is more neutral, and captures the semantics of a procuring entity notifying potential suppliers, without the suggestion or implication that the procedure restricts tenderers.

[yolile]

I agree with notifiedSuppliers !

[jpmckinney]

Great! In that case, the proposal sounds good to me.

[yolile]

Drafted extension here: https://gitlab.com/dncp-opendata/ocds_tender_notifiedsuppliers_extension

[jpmckinney]

@yolile Something I had never noticed before is that the bids extension allows the creation of mostly empty Bid objects with a status of "invited" and one or more suppliers in a tenderers array. (There would be one Bid object for each invitation; tenderers is an array in the case of consortia, joint ventures, etc.).

[yolile]

Hmm.. maybe.. but we need to extend the extension to add a codelist to the parties's roles, because in this case we cannot use the "tenderer" role.

[dwasyl]

For what it's worth, we've used the bid/status of "invited" to show this sort of thing in the past (in Northwest Territories, Canada). Much like Paraguay, sometimes particular vendors are told about a tender, but it doesn't mean they will bid, and it doesn't exclude anyone else. There are other selective tenders where they only invite a few vendors to bid (and no one else is allowed to), but in those cases it is easier to tell who was invited.

Data wise, the only challenge here exists in that the source system generally includes invited vendors as part of the planholders log, rather than structured as potential bids.

[ColinMaudry]

"Notified" or "selected" potential tenderers would be added as parties with a specific role. Since these parties may not bid, calling them "supplier" (= tenderer who has been awarded a contract) or "tenderer" (= who has submitted a bid) may be confusing.

• "notifiedOrganization" may be safer, but I find it too broad. It doesn't suggest it's about bidding.
• "invitedToBid" is more explicit, but possibly too narrow. @yolile ? Does it necessarily overlap with "qualifiedBidder"? @jpmckinney

(I'm interested in the context of the EU profile, and the mapping for "selected participants" to design contests in F12)

[yolile]

"tenderer" (= who has submitted a bid) may be confusing.

Although the reference of the party is in Bids/tenderers

"invitedToBid" sounds good to me or it could be "invitedToParticipate" to make it less narrowed to submitting a bid

[dwasyl]

What about something along the lines of 'interested' organization?

Would that be different than using bid status of invited?

Related, and perhaps this needs a separate ticket, but one of the challenges we have is the lack of any specific point to hold a list of planholders (interested parties that have downloaded/accessed the tender documents). Often the 'invitation' process here comes from adding a potential bidder to the planholder list. In some ways the entire planholder list is a list of potential bidders, but that's not really how we handle the information.

[ColinMaudry]

Although the reference of the party is in Bids/tenderers

That leads me to think that the bid extension is not the right place to model invited/notified/interested organizations. I think adding a party with a specific role is enough, it doesn't need to be in an array.

To avoid confusion, we can consider something like "notifiedSuppliers" which is more neutral, and captures the semantics of a procuring entity notifying potential suppliers, without the suggestion or implication that the procedure restricts tenderers. https://github.com/open-contracting/ocds-extensions/issues/141#issuecomment-489138194

Regarding the code of the role, I understand that @jpmckinney preferred 'notified' because 'invited' sounded like the possibility to submit a bid was exclusive.

How "invitation" is used in our glossary crosswalk (invite/invitation in bold):

Reference organization	Concept	Definition
UNCITRAL	Single-source procurement	A method of procurement of last resort which main distinct feature is the absence of competition since the invitation to present a quotation or proposal is addressed only to one supplier or contractor. For the explanation of the term “method of procurement”, see # 44 above. For the explanation of the term “supplier or contractor”, see # 85 below.
MAPS	Public (open) tender	Refers to the process whereby a procuring entity invites bids that should be submitted within a finite deadline. It is often used for a bidding process that is open to all qualified bidders (open tender) and where sealed bids are opened in public for scrutiny and are chosen on the basis of stated award criteria. In the context of sub-indicator 1(g), the term “tender” is used interchangeably with “bids” or “proposals”.
MAPS	Procurement document	A document issued by the procuring entity that sets out the terms and conditions of the given procurement. Invitation to participate in procurement proceedings (e.g. invitation to tender, participate in request for proposal proceedings or an electronic reverse auction). Alternative terms: solicitation document or tender document.
OCP	Selective	Only qualified suppliers are invited to submit a tender.
OCP	Tender notice	The notice published by the procuring entity inviting interested suppliers to submit a request for participation, a bid, or both. This can be a link to a downloadable document, to a web page, or to an official gazette in which the notice is contained.
GPA	Selective tendering	A procurement method whereby only qualified suppliers are invited by the procuring entity to submit a tender;

Summary: the OCP and MAPS use "invitation" for any type of procedure, implying the invitations are not necessarily exclusive. GPA and UNCITRAL only use "invitation" for direct and selective procedure.

"Invitation" tend to be used when the possibility to submit is exclusive.

[jpmckinney]

I'll move this issue to the standard repository, since we might solve this with a partyRole code.

[jpmckinney]

Noting comments in this PR: #1225 (comment)

[ColinMaudry]

@jpmckinney @yolile Are you ok to solve this with an 'invitedToParticipate' partyRole code? I think it covers the following use cases:

• Second stage of framework agreement
• Design contests invitations
• Selective and direct procedures in general

I don't think it necessary to add a tender.invitedToParticipate field (like in https://gitlab.com/dncp-opendata/ocds_tender_notifiedsuppliers_extension), as it means repeating information. However, it would follow the pattern we use for tenderers ('tenderer' partyRole code + tender.tenderers).

If adopted, this role should be mentioned in several places (at least in the EU profile instead of 'selectedParticipant').

[jpmckinney]

I think having a code without a field is fine. Is the choice of term 'invitedToParticipate' based on something?

[ColinMaudry]

"invited" was found in MAPS (#1245 (comment)), although UNCITRAL and GPA use it meaning "exclusively invited". That's fine for the "FA 2nd stage" and "selective/limited procedures" scenarios, but is a bit of a stretch in the case of design contests.

"participate" is a broad terms that intends to cover many ways to join a contracting process. In our master glossary, it only appears in "request for participation".

If you find it too broad, we could add one code in core for exclusive invitations, and leave one code in eu extension for design contests.

[jpmckinney]

Roles tend to be noun phrases (procuring entity), not verb phrases (invited to participate), so maybe 'invitedParticipant'?

[yolile]

I think that 'invitedParticipant' is fine

[duncandewhurst]

This issue was originally about non-exclusive invitations to participate. The research in #1245 (comment) concludes that:

"Invitation" tend to be used when the possibility to submit is exclusive.

As such, I don't think we should use 'invitedParticipant' to describe non-exclusive invitations. I don't think 'notifiedParticipant' is too broad - implicitly, the notification is about the contracting process.

Related, and perhaps this needs a separate ticket, but one of the challenges we have is the lack of any specific point to hold a list of planholders (interested parties that have downloaded/accessed the tender documents). Often the 'invitation' process here comes from adding a potential bidder to the planholder list. In some ways the entire planholder list is a list of potential bidders, but that's not really how we handle the information.

The 'interestedParty' code can be used to represent organizations that have downloaded or accessed the tender documents.

[jpmckinney]

I'm not 100% sure on the term. "invited/notified participant" seems like it contains a contradiction, as an entity can't be participating if they have only just been notified. In the time since this issue was last discussed, the style guide was updated to prefer "potential supplier" for such entities. We could do "notifiedPotentialSupplier", which is long, but correct...

https://ocds-standard-development-handbook.readthedocs.io/en/latest/meta/style_guide.html#word-choice

[duncandewhurst]

Good point. The other alternative is 'notifiedOrganization', which would cover cases where other interested parties that are not potential suppliers are notified about a contracting process; for example, in the Red Compartida PPP, the planning stage included a feedback process for the draft tender documentation, in which organizations that were not potential suppliers submitted comments.

[jpmckinney]

If there's only a use case for the broad semantics, then we can use it (similar to Colin's comment here #1245 (comment)).

However, if there's a use case to pick out the organizations that were invited to participate as potential suppliers, then the narrower code is needed.

[duncandewhurst]

I checked back to Red Compartida and it looks like they only published a list of organizations and individuals that submitted an expression of interest and a list of organizations that submitted comments on the draft tender documentation, which are both covered by the existing 'interestedParty' role, as is @dwasyl's scenario in #1245 (comment).

So that leaves us with the original question from Paraguay, which is indeed about invitations to participate as potential suppliers, so I'm happy to go with 'notifiedPotentialSupplier, even if it is a bit long.

[jpmckinney]

In this issue, I think we only have evidence for Paraguay as a potential user of this new code. That said, I know in Canada (at all levels of government) it's common to put together supplier lists and to notify the vendors on those lists, so it's a common enough procurement concept that I figure it can be added without further evidence/demand.