Add the codes from EU extension #1225
Conversation
ColinMaudry
changed the title
ColinMaudry
changed the title
ColinMaudry
added
the
Codelist: Codes
schema/codelists/partyRole.csv
Outdated
| @@ -10,3 +10,9 @@ payee,Payee,A party in receipt of a payment from a transaction., | |||
| reviewBody,Review body,A party responsible for the review of this procurement process. This party often has a role in any challenges made to the contract award., | |||
| interestedParty,Interested party,"A party that has expressed an interest in the contracting process: for example, by purchasing tender documents or submitting clarification questions.", | |||
| contractImplementationManager,Contract implementation manager,The organization responsible for managing the implementation of the contract on behalf of the buyer. (This may be different from the procuring entity that manages the contracting process.), | |||
| mediationBody,Mediation body,The body responsible for mediation procedures., | |||
| centralPurchasingBody,Central purchasing body,"The procuring entity providing centralized purchasing activities and, possibly, ancillary purchasing activities.", | |||
There was a problem hiding this comment.
@JachymHercher This was added to the EU extension for I.2 "The contract is awarded by a central purchasing body" from the current EU forms. With respect to #1180, does it make sense to use this code? Does it match any of the 4 codes proposed in #1180?
There was a problem hiding this comment.
'centralPurchasingBody' covers both 'wholesaler' and 'contract intermediary' from #1180 (comment). In eForms, the codes only exist in their split form (see cpb-acq, cpb-awa), but in the TED 2.0.9 forms they only exist as one code. To be able to map to both, we would either need to include all three codes, or decide that for TED 2.0.9, a CPB should be marked by including both the 'wholesaler' and 'contract intermediary'. The latter option avoids clutter in OCDS, but might be less obvious to users (not sure how many there are for TED 2.0.9 though).
There was a problem hiding this comment.
What was the use case for splitting CPB into two codes? What need does it satisfy? Is it just to be maximally accurate from the publisher's perspective, or does it have analytical value?
There was a problem hiding this comment.
Noting that we can also leave/restore 'centralPurchasingBody' in the EU extension until we resolve #1180.
There was a problem hiding this comment.
I have removed 'centralPurchasingBody' from the PR.
There was a problem hiding this comment.
What was the use case for splitting CPB into two codes? What need does it satisfy? Is it just to be maximally accurate from the publisher's perspective, or does it have analytical value?
Primarily policymaking: wholesale and intermediary are two very different ways of doing/organizing central purchasing and being able to distinguish them is the first step to knowing how they are used and, ultimately, which one is better in which contexts (e.g. for which types of purchases). Speculatively, wholesale/intermediary might also turn out to be a "shorthand" way of communicating certain information to the market such as single/multiple place of delivery, single/multiple payments (and the related delays in payments), etc. These can always be specified in more detail elsewhere of course.
schema/codelists/partyRole.csv
Outdated
| centralPurchasingBody,Central purchasing body,"The procuring entity providing centralized purchasing activities and, possibly, ancillary purchasing activities.", | ||
| processContactPoint,Process contact point,A contact point dedicated to this contracting process., | ||
| reviewContactPoint,Review contact point,The service from which information about the review procedure can be obtained., | ||
| selectedParticipant,Selected participant,A party that has already been selected to participate in the design contest., |
There was a problem hiding this comment.
This was added to the EU extension for IV.1.7 "Names of participants already selected (in the case of a restricted contest)" from the current EU forms.
@ColinMaudry Should this instead be modelled as a Bid with a status of 'invited'? https://extensions.open-contracting.org/en/extensions/bids/master/codelists/#bidStatus.csv
There was a problem hiding this comment.
Good idea, but I see several issues:
- That would be a bid with only
statusandtenderers, nodateand novalue. - At the time of publication of this design contest notice, we don't know whether the selected/invited participant actually submitted a bid. They may be selected/invited but not participate. @JachymHercher Could you please confirm this point?
- Only the "selected participants" would appear in bids, as if they were the only bidders (F13 Results of design contest only discloses statistics about participants, not details)
There was a problem hiding this comment.
Yes, there are two issues: (1) how to model incomplete data, and (2) how to model invitations to bid.
(1) From this perspective, it's no problem for a bid to lack a date and value, and for bids to only contain invited applicants. A more complete dataset would add/update such values.
(2) However, maybe there should be no such status as 'invited', because an invitation to bid is not the same thing as a bid, and therefore they should be modelled separately.
We should move this to an issue to discuss.
There was a problem hiding this comment.
Actually, there is already an issue: https://github.com/open-contracting/ocds-extensions/issues/141
There was a problem hiding this comment.
For now 'selectedParticipant' remains in the EU extension.
There was a problem hiding this comment.
Co-authored-by: James McKinney <26463+jpmckinney@users.noreply.github.com>
|
Noting that we should restore 'selectedParticipant' to the EU extension until #1245 is resolved. |
jpmckinney
removed
Codelist: Codes
documentTypes:
milestoneType:
partyRole:
#1157