-
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
Bids: Add support for disclosing notified suppliers #1245
Comments
So, globally, suppliers can be invited in a few ways:
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). |
In Paraguay, the invitation doesnt implies that:
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. |
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. |
I agree with notifiedSuppliers ! |
Great! In that case, the proposal sounds good to me. |
Drafted extension here: https://gitlab.com/dncp-opendata/ocds_tender_notifiedsuppliers_extension |
@yolile Something I had never noticed before is that the bids extension allows the creation of mostly empty Bid objects with a |
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. |
For what it's worth, we've used the 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. |
"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.
(I'm interested in the context of the EU profile, and the mapping for "selected participants" to design contests in F12) |
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 |
What about something along the lines of 'interested' organization? Would that be different than using bid status of 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. |
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.
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):
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. |
I'll move this issue to the standard repository, since we might solve this with a |
Noting comments in this PR: #1225 (comment) |
@jpmckinney @yolile Are you ok to solve this with an 'invitedToParticipate' partyRole code? I think it covers the following use cases:
I don't think it necessary to add a If adopted, this role should be mentioned in several places (at least in the EU profile instead of 'selectedParticipant'). |
I think having a code without a field is fine. Is the choice of term 'invitedToParticipate' based on something? |
"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. |
Roles tend to be noun phrases (procuring entity), not verb phrases (invited to participate), so maybe 'invitedParticipant'? |
I think that 'invitedParticipant' is fine |
This issue was originally about non-exclusive invitations to participate. The research in #1245 (comment) concludes that:
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.
The 'interestedParty' code can be used to represent organizations that have downloaded or accessed the tender documents. |
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... |
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. |
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. |
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. |
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. |
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:
The text was updated successfully, but these errors were encountered: