Skip to content
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

partyRole codelist: add wholesaleBuyer #1180

Closed
JachymHercher opened this issue Jan 23, 2021 · 13 comments · Fixed by #1652
Closed

partyRole codelist: add wholesaleBuyer #1180

JachymHercher opened this issue Jan 23, 2021 · 13 comments · Fixed by #1652
Assignees
Labels
Codelist: Codes Relating to adding or deprecating codes in codelists Codelist: Open Relating to an open codelist
Projects
Milestone

Comments

@JachymHercher
Copy link
Contributor

JachymHercher commented Jan 23, 2021

When discussing procuringEntity in #571, I noted that several roles in contracting processes that can be marked in the EU's eForms and that seem useful, but that cannot currently be expressed in OCDS.

Introductory analysis

(from #571 (comment) and #571 (comment) and #571 (comment))

Concerning 'procuringEntity', a good starting point is to review the definitions (OCDS and Art. 2 of Directive 2014/24/EU):

  • 'procuringEntity': "The entity managing the contracting process."
  • (17) ‘procurement service provider’ (PSP) means a public or private body which offers ancillary purchasing activities on the market;
  • (16) ‘central purchasing body’ (CPB) means a contracting authority providing centralised purchasing activities and, possibly, ancillary purchasing activities;
  • (15) ‘ancillary purchasing activities’ means activities consisting in the provision of support to purchasing activities, in particular in the following forms:
    • (a) technical infrastructure enabling contracting authorities to award public contracts or to conclude framework agreements for works, supplies or services;
    • (b) advice on the conduct or design of public procurement procedures;
    • (c) preparation and management of procurement procedures on behalf and for the account of the contracting authority concerned;
  • (14) ‘centralised purchasing activities’ means activities conducted on a permanent basis, in one of the following forms:
    • (a) the acquisition of supplies and/or services intended for contracting authorities,
    • (b) the award of public contracts or the conclusion of framework agreements for works, supplies or services intended for contracting authorities;

There might be some legal distinction between "on behalf and for the account of" (in 15) ) and "intended for" (in 14) ), but my non-legal reading would be that (14)(b) is a type (15)(c), and thus all (14)(b) CPBs are also PSPs (but not vice versa). (14)(a) CPBs stand on their own, they are simply a 'buyer' (that passes on its purchases later on). "Managing the contracting process" (in the definition of 'procuringEntity') is part of (15)(c), which implies that a (14)(b) CPB is always a 'procuringEntity', while a PSP is a 'procuringEntity' under (15)(c) but not under (15)(a) and (15)(b).

An example of a (15)(a) party is for example a data publisher; a example of a (15)(b) party is a law firm or an EU fund consultancy that reviews the buyer's procurement documents, but does not actually manage the process. Would you agree that these currently don't have a role in OCDS under which information about them could be published?

image

Note that it correctly describes the status quo, but once we change the definition of buyer in line with #825 (comment), OCDS buyer will cover both 14(a) and 14(b). In fact, 14(b) will be an OCDS buyer, OCDS procuring entity and a CPB, which explains some of the "second sentences" in the codes below.

Proposal

partyRole gets the following new codes:

  • 'wholesaler' with the description "buyer (e.g. a central purchasing body) buying goods, works or services to be given or sold to other buyers. Organisations with the wholesaler role should not be marked with the buyer role." (14a),
  • 'contract intermediary' with the description "buyer (e.g. a central purchasing body) concluding contracts (e.g. framework agreements) to be used by other buyers. Organisations with the contract intermediary role should not be marked with the buyer role nor the procuring entity role." (14b),
  • 'infrastructure provider' with the description "organisation providing technical infrastructure for the contracting process (e.g. an eprocurement provider, a data publisher). If an organisation is both a buyer and an infrastructure provider (as is typically the case in simple contracting processes), it should only be marked with the buyer role, not the infrastructure provider role." (15a),
  • 'advisor' with the description "organisation providing advice on setting up or running the contracting process (e.g. a procurement consultancy or law firm.)" (15b),
@jpmckinney jpmckinney added Codelist: Open Relating to an open codelist Codelist: Codes Relating to adding or deprecating codes in codelists labels Jan 26, 2021
@jpmckinney jpmckinney added this to To do in OCDS 1.2 via automation Jan 26, 2021
@jpmckinney jpmckinney added this to the 1.2.0 milestone Jan 26, 2021
@jpmckinney jpmckinney moved this from To do to To do: Codes in OCDS 1.2 Jan 26, 2021
@jpmckinney
Copy link
Member

@jpmckinney
Copy link
Member

jpmckinney commented Apr 1, 2021

Copying discussion at #1225 (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.

@jpmckinney
Copy link
Member

@duncandewhurst and/or @odscjen From your work on OCDS for eForms, what do you think of this issue, and do you think it is worthwhile to add the codes to OCDS, rather than using the open codelist and/or defining new codes in extensions?

@odscjen
Copy link
Contributor

odscjen commented Jun 9, 2023

From the eForms work we identified the following new codes to add to the EU extension +partyRole.csv codelist.

new code organization role authority table eForms term mapping explanation Jachym codes?
eSender ted-esen OPT-030 direct code mapping 'infrastructure provider'
procurementServiceProvider serv-prov OPT-030 direct code mapping 'infrastructure provider'
leadBuyer -- OPP-050 binary indicator to code ?
awardingCentralPurchasingBody cpb-awa OPP-051 direct code mapping ?
acquiringCentralPurchasingBody cpb-acq OPP-052 direct code mapping ?
leadTenderer -- OPT-170 binary indicator to code ?
evaluationBody -- OPT-301 XML field to code ?
submissionReceiptBody -- OPT-301 XML field to code ?

Comparing these to the codes proposed by Jachym most of these new codes don't map to the proposed ones. So from the point of view of the eForms work I'm not sure they are necessary in either the core or the EU extension, if we keep 'partyRole.csv' as an open codelist then if one of these is needed it can be added by the publisher.

Whether or not any of the codes we've created as part of the eForms mapping should be included in the core 1.2 codelist is another question. My initial feeling is that with the exception of 'eSender' they are all general enough to have utility outside of the EU but that would likely require further research to confirm.

@jpmckinney
Copy link
Member

jpmckinney commented Jun 9, 2023

Thank you!

My understanding of the quoted part of Art. 2 of Directive 2014/24/EU in the issue description is that 'ted-esen' (TED eSender) is a kind of "procurement service provider" (17), i.e. one whose "ancillary purchasing activities" (15) is "technical infrastructure" (15a). I think it matches what Jachym calls a "data publisher".

In the draft extension:

  • 'acquiringCentralPurchasingBody' matches 14a for which Jachym proposed the code 'wholesaler'.
  • 'awardingCentralPurchasingBody' matches 14b for which Jachym proposed the code 'contract intermediary'.

@JachymHercher Apologies for pulling you back into standard development :) but what was your intention for sentences like "Organisations with the wholesaler role should not be marked with the buyer role" ? For example, if the buyer in a contracting process is a wholesaler CPB, I assume they would appear in the buyer field. If that's the case, then their entry in the parties array should have 'buyer' in its roles array.

Or, is it the case that, in contracting processes involving CPBs, there is usually a buyer (e.g. ministry of transport) occupying the buyer field, such that the CPB would only be mentioned in the parties array, and in this context it shouldn't be marked with a 'buyer' role? If that's the case, we can maybe rewrite it as "Organizations with the 'wholesaler' role must have the 'buyer' role only if referenced from the buyer field." ... assuming there isn't always a second buyer.

@jpmckinney
Copy link
Member

Noting that the EU legislation mentions "supplies and/or services" but not works. That said, I think okay to include works in our definition.

Jachym had used the phrase "to be given or sold to" instead of "intended for". I'm not sure if there is a significant distinction here. I prefer "intended" to avoid having to disambiguate all the ways a purchase can reach its intended buyer (e.g. IP can be "relicensed to", cleaning services can maybe simply be coordinated without there being any change in ownership, control, or relationships, etc.).

@jpmckinney
Copy link
Member

jpmckinney commented Jun 9, 2023

eForms adds 'serv-prov' for 17 (which covers all of 15), plus 'ted-esen' which is a special case of 15a.

We haven't encountered datasets describing a 15a aka 'infrastructure provider' (except in the 'ted-esen' special case), a 15b aka 'advisor', or a 15c (except in the case of it being a 14b), so I'll leave them out of OCDS 1.2. Noting that there was no proposal in the issue description for a code matching 15c except in the case where the organization was also a 14b.

Since "Procurement service provider" can be divided into more specific roles, I'll also leave it out of OCDS 1.2, despite it being modelled in eForms, because the desired end-state is to have a set of minimally-overlapping roles.


I'm not sure about the term 'contract intermediary'. For a similar case, in #1187, we added 'contractImplementationManager' instead of 'contractManager' since the latter had multiple interpretations.

From the discussion in #548:

the word "contract" is important for emphasizing the distinction with the party that manages the "process"

As such, a new term for 'contract intermediary' might include the word "process" (or "contracting process") and an appropriate "action" word to take the role of "Implementation".


That said, the issue description elaborates how 14b organizations are always procuring entities. Until we find a reason to distinguish 14b and 15c procuring entities from each other, I'm wondering whether we can't just continue using 'procuringEntity' for this role.

In terms of distinguishing 'procuringEntity' from its specializations 14b and 15c – well, I'm not quite sure what procuring entities do that the specializations don't. There needs to be a use case for indicating that an organization is only concerned with awarding contracts/FAs (15c).

In terms of indicating that this organization does this on a permanent basis (14b) (i.e. is a CPB, not another type of procuring entity) – I'm just not sure what other procuring entities are out there that wouldn't be considered CPBs, in the case where the buyer and procuring entity are not the same organization.

So, I think, in the end, we're only adding 'wholesaler'.

@duncandewhurst
Copy link
Contributor

A quick thought on terminology: 'wholesaler' as defined in Jachym's proposal does make sense, but I think that using that term might be confusing because, on the face of it and based on how that term is used in common parlance, I would expect a wholesaler to be a supplier rather than buyer, e.g. a government agency buying supplies from a wholesaler, as opposed to a retailer.

@jpmckinney
Copy link
Member

I'm open to suggestions. We can't use 'central purchasing body' because some CPBs only handle the award (awardingCentralPurchasingBody). acquiringCentralPurchasingBody is a bit cumbersome, especially in the absence of another CPB specialization in OCDS 1.2.

@duncandewhurst
Copy link
Contributor

Since the proposed description for 'wholesaler' begins with "A buyer...", would 'central buyer' work?

@jpmckinney
Copy link
Member

Hmm, that sounds like a synonym of 'central purchasing body'.

For context, 'buyer' already covers both the awarding and acquiring aspects: "The organization aiming to conclude a contract with a supplier or to use the goods, services or works resulting from the contract." Hence the caveat on 'procuringEntity':

If an organization is both a buyer and a procuring entity (as can be the case in simple contracting processes), its roles should include 'buyer', but not 'procuringEntity'.

We want to avoid this for new codes. We're stuck with the caveats based on how the roles were defined in OCDS 1.1 .

I suppose 'wholesaleBuyer' could work.

@duncandewhurst
Copy link
Contributor

I suppose 'wholesaleBuyer' could work.

Sounds good to me!

@duncandewhurst duncandewhurst changed the title partyRole codelist: new codes for supporting and central purchasing partyRole codelist: add wholesaleBuyer Jun 18, 2023
@odscjen odscjen self-assigned this Oct 16, 2023
@odscjen odscjen moved this from To do: Codes to In progress in OCDS 1.2 Oct 16, 2023
@odscjen odscjen moved this from In progress to Review in progress in OCDS 1.2 Oct 16, 2023
@jpmckinney
Copy link
Member

If this issue is ever revisited in future to consider the other codes, the comment that describes the decision is #1180 (comment)

OCDS 1.2 automation moved this from Review in progress to Done Oct 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Codelist: Codes Relating to adding or deprecating codes in codelists Codelist: Open Relating to an open codelist
Projects
Status: Done
OCDS 1.2
  
Done
Development

Successfully merging a pull request may close this issue.

4 participants