Edit tender.procuringEntity description

[JachymHercher]

Since the definition of procuringEntity is "The entity managing the procurement", I would expect that every procurement process should have at least one such entity. I think there is currently no such requirement for an OCDS contracting process. Shouldn't there be?

I'm also wondering whether saying "procurement process" instead of "procurement" in the description ("The entity managing the procurement process") wouldn't be a more consistent use of terminology?

---

Editor's summary: Change the definition of procuringEntity to "The entity managing the procurement process"

[jpmckinney]

@JachymHercher Introducing a new required field would have to wait for version 2.0, as we aren't introducing backwards-incompatible changes before then. While there may always be a procuring entity, it may not always be known, e.g. if the dataset is being constructed by a civil society organization based on information that does not declare the procuring entity.

We can consider adding 'process' to the field definition. I'll change the issue title to reflect that.

[JachymHercher]

2.0 change - sure.

"Not being known" - this argument could probably be applied to any field, no? For example, just as well, the procuringEntity might be known (e.g. a central purchasing body), but the buyer is not. However, buyer is a required field, right? Why treat these differently? I'd argue both are basic information about the process.

[jpmckinney]

I don't believe buyer is required.

[JachymHercher]

Ah, ok, then I'm wrong, nevermind :).

[yolile]

Another issue with the procuring entity definition is that it says:

"The entity managing the procurement. This may be different from the buyer who pays for, or uses, the items being procured."

But the buyer's definition only says:

"A buyer is an entity whose budget will be used to pay for goods, works or services related to a contract. This may be different from the procuring entity who may be specified in the tender data."

So, the procuring entity definition suggest that the buyer can be the one who pays or the one who uses, but the buyer definition only says that the buyer is the one who pays, what is correct, so I think that we need to update the procuring entity definition to be consistent with the buyer one.

[jpmckinney]

Related: #825

[ColinMaudry]

All in all, for v1.2, this will be the new definition of procuringEntity:

The entity managing the procurement process. This may be different from the buyer who pays for , or uses, the items being procured.

[ColinMaudry]

The definition must also be edited in the party role codelist.

[jpmckinney]

@ColinMaudry Like #825, can you also have a look at the glossaries, etc. mentioned in #827? I would be more confident in the re-definition if we had a comparison table with other definitions.

[ColinMaudry]

OK, I hold it so that we can improve it further with the glossary crosswalk.

[JachymHercher]

Don't we want "The entity managing the contracting process", not "The entity managing the procurement process"? I think my initial comment was stuck in the EU :-).

More importantly, in a simple procurement procedure, should publishers be declaring an organisation as a 'buyer' and also as a 'procuringEntity', or do we want to have a 'procuringEntity' only if it is different from the buyer? This very much depends on the overall approach in https://github.com/open-contracting/standard/issues/825 and should be done the same way also in https://github.com/open-contracting/standard/issues/548#issuecomment-476377918.

[jpmckinney]

Good catch – we should broaden the semantics to "contracting process" (the term procuringEntity is more narrow, but we can't change the term in 1.2).

For simple procedures, I would recommend populating buyer and not tender/procuringEntity, unless the local legislation or local authorities consider it appropriate and correct to populate both with the same organization.

[JachymHercher]

Should the latter be reflected in a normative "should" or a non-normative text somewhere?

[jpmckinney]

Yes, we can add a "should" statement to tender/procuringEntity.

[ColinMaudry]

Not sure it's ideal, but here are the terms mapped to tender.procuringEntity and partyRole/procuringEntity in the glossary crosswalk (direct link to the row)

MAPS definition (3)	UNCITRAL definition (17)	eForms term (46)	eForms definition (46)	eForms codelist (6)	eForms code label (6)	eForms code def (4)
A public entity (agency) conducting procurement in compliance with the applicable law. The terms “procuring agency” or “procurement body” are often used synonymously. Procuring entities can belong to any level of government (national, provincial or municipal level). They can represent different arms of government (branches, ministries, departments, etc.) or they could be constituted as state-owned enterprises or bodies.	Defined in the Model Law as: “Option I (i) Any governmental department, agency, organ or other unit, or any subdivision or multiplicity thereof, that engages in procurement, except ...; [and] Option II (i) Any department, agency, organ or other unit, or any subdivision or multiplicity thereof, of the [Government] [other term used to refer to the national Government of the enacting State] that engages in procurement, except ...; [and] (ii) [The enacting State may insert in this subparagraph and, if necessary, in subsequent subparagraphs other entities or enterprises, or categories thereof, to be included in the definition of ‘procuring entity’];” For the explanation of the term “procurement”, see # 58 above.	BT-740 Buyer Contracting Entity	The buyer is a contracting entity.	Organisation role	Central purchasing body awarding public contracts or concluding framework agreements for works, supplies or services intended for other buyers--Central purchasing body acquiring supplies and/or services intended for other buyers	Contracting authority procuring activities conducted on a permanent basis, in one of the following forms:... the award of public contracts or the conclusion of framework agreements for works, supplies or services intended for contracting authorities;--Contracting authority procuring activities conducted on a permanent basis, in one of the following forms:(a) the acquisition of supplies and/or services intended for contracting authorities.

[ColinMaudry]

All the definitions in other glossaries tend to boil down to:

A public entity that engages in procurement.

[jpmckinney]

I forgot this issue was open when I opened #1156. That issue's description was:

@JachymHercher wrote in #825

ProcuringEntity covers three codes from eForms' organisation role: CPB wholesaler, CPB intermediary and a procurement service provider. They could either be split as they are in eForms, or they could be dealt with by extending the "fullly accurate" approach mentioned above (e.g. by adding codes such as "party receiving the items", "party distributing the items", "party signing the contract for its own use", "party signing the contract for the use by another party", "party using the items").

Re: "fully accurate", this was described as:

We can group the "needs" / "use cases" into three levels:

• Basic: distinguishing the "buyer side", supplier, subcontractor, unsuccessful tenderers, review bodies, etc.
• Medium: within the "buyer side", distinguishing "buyers", "procuring entities", "central purchasing bodies", "contract implementors" (see https://github.com/open-contracting/standard/issues/548#issuecomment-727912060), etc.
• Fully accurate: knowing who exactly does what, i.e. organisation receiving tenders, org. processing tenders, org. signing the contract, org. whose budget is used to pay for the contract, org. sending the payment, etc.

The first two are based primarily on "who they are" (often based on legal definitions), the third is rather "what they do" (often based on real world actions). Judging from the EU, I think most systems work on the first two levels, because that's the way the legislation is written, people are used to it, and requirements it puts on manual data input. However, I think systems sometimes "dip" into the third level, but less for "analytical" purposes and more for "practical" purposes such as "who do I actually send my tender to", "who do I actually send my questions to", etc.

In eForms, we try to cover the first two levels by organisation role, while giving the possibility to go into the third level with organisation subrole.

I guess as a starting point: Is "procuring entity" a useful concept on its own? If so, then this issue is about adding subroles (see below quote). If not, then this issue is about replacing it with new options. Viz. subroles:

OCDS does not have an equivalent of eForms' organisation subrole. Since legal definitions differ but real world actions are univeral, I think this approach might be valuable for standardization.

[jpmckinney]

@JachymHercher then replied:

I guess as a starting point: Is "procuring entity" a useful concept on its own? If so, then this issue is about adding subroles (see below quote). If not, then this issue is about replacing it with new options. Viz. subroles:

I think both roles and subroles are useful - the former because they appear in legal discussions, the latter because they sometimes meet concrete communication (or analytical) needs.

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?

Possible solutions

Regardless of the option below, we should add two new roles: one for (14)(a) and (14)(b). (Same approach as eForms.)

Option 1

• 'procuringEntity' definition stays as it is, i.e. corresponds to (15)(c).
• We add two additional new roles: for (15)(a), (15)(b),

  Option 2

• 'procuringEntity' definition is broadened (or the term is replaced with something broader) to cover also (15)(a) and (15)(b), i.e. it becomes a PSP.

I would go for Option 1 if there is some demand for publishing about bodies defined along the lines of (15)(a) and (15)(b). If not, I would go for option 2, which is analogous to eForms.

[ColinMaudry]

I have illustrated your comment:

[ColinMaudry]

We could check the data, but I feel that procuringEntity has been used to complete buyer when the data publishers needed to name the organisation that manages the contracting process on behalf of the buyer. I'd consequently go for Option 1.

Having all 15(a), (b) and (c) under the same term makes it very broad (having law firms, consultancies and data publishers, private and public bodies), not intuitive and consequently harmful for data analysis.

At least 15(a), which definition includes buyer profiles (@JachymHercher?), deserves its own role.

I don't know much of the demand for 15(b) (law firms, consultancies).

[jpmckinney]

I'd also go for Option 1, though we can fine-tune the definition.

I agree that 15(a) shouldn't be under procuringEntity but can have its own role. There are distributed eGP systems like ProZorro, where private companies offer marketplaces that fulfill 15(a). In terms of a data user's expectations, I think they would expect ProZorro to be the procuring entity (as a CPB).

I also agree that 15(b) can have its own role, though I similarly don't think there is much demand or data available.

[JachymHercher]

Option 1 seems popular, so below are some concrete drafts (also reflecting the rest of this issue). The process of drafting revealed some new complexity though, mainly reflected in the second sentences of the definitions. (By splitting (15) into its three components, we are going one step closer towards the granularity of eForms' organisation subrole. But I think there's still space for both.)

• Changing the description of tender.procuringEntity and 'procuringEntity' in partyRole from "The entity managing the procurement. This can be different from the buyer who pays for, or uses, the items being procured." to "The organisation managing the contracting process. If an organisation is both a buyer and a procuring entity (as is typically the case in simple contracting processes), it should only be marked with the buyer role, not the procuring entity role."

  (I've redrafted the second sentence slightly more, so that we don't repeat the buyer definition and at the same time to make it clearer that the "should" refers to data publication, not reality.)

• 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),

The definitions are based on the EU's laws, but I tried replacing legal jargon with simpler (and more universal) concepts, as OCDS usually does. I propose keeping the CPBs only as examples, so that we do not have to define what exactly a CPB is.

I have illustrated your comment:

Great, very useful! :) Note that it correctly describes the status quo, but once we change the definition of buyer in line with https://github.com/open-contracting/standard/issues/825#issuecomment-754989395, 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 above.

At least 15(a), which definition includes buyer profiles (@JachymHercher?), deserves its own role.

I wouldn't say buyer profiles are an organisation. In eForms, we just treat is as a website with procurement related documents.

[jpmckinney]

I think the new codes might require longer discussion. Can we split that out into a new issue? I think we can resolve the procuringEntity description without necessarily adding the new codes at the same time.

[JachymHercher]

Makes sense, I've opened https://github.com/open-contracting/standard/issues/1180 to discuss new supporting and centralized purchasing roles for partyRole.

I didn't open a new ticket for an equivalent to eForms' organisation subrole, mentioned in https://github.com/open-contracting/standard/issues/571#issuecomment-758726382, as perhaps we can deal with it only once concrete demand comes (e.g. when mapping eForms to OCDS).

[ColinMaudry]

The organisation managing the contracting process. If an organisation is both a buyer and a procuring entity (as is typically the case in simple contracting processes), it should only be marked with the buyer role, not the procuring entity role.

This definition seems to take into account the requirements we have expressed in this issue. @jpmckinney does it fit the bill?

[ColinMaudry]

If I have one concern, it's with "be marked with the buyer role". I'm not sure this wording matches OCDS phraseology. What about

it should only have the buyer role, not the procuring entity role

only: the organization may still have other roles beside "buyer". have: I think it's more inline with OCDS phraseology, highlighting the fact an organization may have several roles

[jpmckinney]

Yes, good refinement. We should also use American English spelling. Changing the phrasing a bit (similar to phrasing in the OCDS for EU profile):

The organization managing the contracting process. 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'.

Earlier, I had written, to which there has been no disagreement (yet):

For simple procedures, I would recommend populating buyer and not tender/procuringEntity, unless the local legislation or local authorities consider it appropriate and correct to populate both with the same organization.

From my perspective, the use of "should" means exceptions can be made. Just logging this here in case a future reader wonders whether there is an inconsistency in the discussion.

[ColinMaudry]

I think the proposed definition (https://github.com/open-contracting/standard/issues/571#issuecomment-767208811) works well for the code in the partyRole codelist, but not for the description of the procuringEntity field.

I suggest we use something like this:

The organization managing the contracting process. If an organization is both a buyer and a procuring entity (as can be the case in simple contracting processes), it should only be referenced in the buyer field, not in this field.

[jpmckinney]

Good catch, I got confused about which code/field we were working on.

Suggested change in bold:

The organization managing the contracting process. If an organization is both a buyer and a procuring entity (as can be the case in simple contracting processes), it should be disclosed using the buyer field, but not this field.

• Removed "only" since there might be other fields like informationService that also refer to the organization.
• Changed "be referenced" to "be disclosed", since the use of organization references is a structural detail, not a semantic detail. Also, this way, the description will work for both OCDS 1.0 data (where organizations are inline) and OCDS 1.1 data (where organizations are referenced).

[ColinMaudry]

Great. I'll update the PR (#1163).

[jpmckinney]

Noting that the 'limited' code in the method codelist is:

The procuring entity contacts a number of suppliers of its choice.

This is based on the GPA text:

a procurement method whereby the procuring entity contacts a supplier or suppliers of its choice

The GPA text for "selective tendering" uses the passive voice, e.g.:

a procurement method whereby only qualified suppliers are invited by the procuring entity to submit a tender

where we omit "by the procuring entity" for the 'selective' code:

Only qualified suppliers are invited to submit a tender.

So, for the 'limited' code, we could reword it in the passive voice, in order to omit "The procuring entity", since, per this issue, there might only be a buyer without a procuring entity (in OCDS terms).

[jpmckinney]

@ColinMaudry Can you suggest new wording for the 'limited' code and then, once agreed, edit the open PR?

[ColinMaudry]

I've also used the OCDS definition of selective ("Only qualified suppliers are invited to submit a tender."):

Only chosen suppliers are invited to submit a tender.

[jpmckinney]

Where does "chosen suppliers" come from?

[ColinMaudry]

supplier or suppliers of its choice

Both the current OCDS definition and the GPA definition describe limited tendering as a method whereby the buyer chooses (not "select") certain suppliers. I simply (naively?) translated "of choice" into a past participle.

[jpmckinney]

Ah, I got confused; in https://github.com/open-contracting/standard/issues/571#issuecomment-772636835 you referred to 'selective', not 'limited', but you meant using the definition of 'selective' as inspiration.

On second thought, it might not be clear who is doing the choosing, whereas people familiar with procurement processes understand that "qualified suppliers" is based on pre-qualification/selection criteria.

So, perhaps, after all, we should follow the GPA text more closely:

The buyer or the procuring entity contacts a supplier or suppliers of its choice.

cc @JachymHercher

[jpmckinney]

I'm not sure it's been clearly stated in this discussion, but the reasons for preferring only setting the buyer field in cases where the buyer and procuring entity are identical are:

1. There are more use cases related to the buyer. Publishers ought to be encouraged to publish this common field in preference to the procuringEntity field.
2. In many jurisdictions, for simple procedures, the buyer is disclosed and the procuring entity is understood to match. As such, it is already current practice to omit the procuring entity in such cases.
3. The procuring entity (when not identical to the buyer) is a central purchasing body or another organization that does the "preparation and management of procurement procedures on behalf and for the account of the [buyer] concerned". If a user wants to analyze such organizations, then setting the procuringEntity field to the buyer organization would "pollute" this field, and require data cleaning.
4. More broadly, the buyer organization by default takes multiple roles in a procurement procedure (the respondent to any enquiries, requests for documents, etc.) and it is unnecessarily verbose to disclose all these roles for every buyer.

[jpmckinney]

Closed by #1163

[JachymHercher]

In the worked example in https://standard.open-contracting.org/latest/en/guidance/map/organizational_units/#using-the-organization-building-block, the organization in the example has roles equal to 'buyer' and 'procuringEntity'. However, as exaplained in https://github.com/open-contracting/standard/issues/571#issuecomment-778510316, it should only have 'buyer'. https://github.com/open-contracting/standard/pull/1404 corrects it.

[jpmckinney]

Re-closing as the PR is a separate issue (related to this one).