partyRole: Change definition of 'funder' and/or 'buyer'

JachymHercher commented 5 years ago

Considering the following Party Role's definitions,

buyer	Buyer	A buyer is an entity whose budget will be used to pay for goods, works or services related to a contract.
funder	Funder	The funder is an entity providing money or finance for this contracting process.

I'm struggling a bit to understand the difference. Isn't funder just a sub-category of buyer? Or is the important difference that the buyer pays for the "goods, works or services" while the funder pays for the "contracting process"? There may be some scope for clarification/alignment of terminology.

jpmckinney commented 5 years ago

The 'funder' code was added in this commit https://github.com/open-contracting/standard/commit/6989523e2d07d466a8a74a70cfd650284882a170 following from the discussion in #368 as part of the development of OCDS 1.1. However, a 'funder' role wasn't discussed in that issue, and has no precedent in OCDS – whereas the other roles at the time had a related field pointing to an organization in that role (and those field descriptions were re-used in the code descriptions).

I can actually find no discussion whatsoever about the 'funder' role, so it seems to have slipped in unnoticed without review.

While I have used it in the draft OCDS for EU work, it is not used in any other extensions, so one option is to deprecate it – and I can pursue an alternate modelling in OCDS for EU for EU-funded processes.

The other option is to improve the descriptions in order to disambiguate the two roles.

It's not clear to me that the definition of a buyer depends much on budgeting concerns; changing that will require changing the field description as well.

JachymHercher commented 5 years ago

Ok, thanks. For reference, I got into this subject when working on https://github.com/eForms/eForms/issues/85#issuecomment-475609662 (and https://github.com/eForms/eForms/issues/285#issuecomment-475553242).

(In eForms, we define "buyer" by referring to the legal terms such as "contracting authority". It is unavoidable, because notices have legal value and need to be 100% precise on this point, but doesn't really help with re-usability, because the definitions are very complex. Depending on the needs of other OCDS users, perhaps it might be useful to add something like "Party which is obliged to run public procurement procedures according to the local legislation." in one of the PartyRole descriptions.)

LindseyAM commented 5 years ago

Hi there, 'funder' may be relevant in cases where eg the World Bank is providing the funding for the contract (rather than government budget).

jpmckinney commented 5 years ago

We have other means of modelling various funding/financing relationships, none of which use this party role (the Financing extension has a financingParty field and Budget Breakdown has sourceParty).

Anyhow, we can keep the 'funder' role, but it requires changes to the 'buyer' role (and field).

ColinMaudry commented 4 years ago

perhaps it might be useful to add something like "Party which is obliged to run public procurement procedures according to the local legislation." in one of the PartyRole descriptions

That would be the buyer since it is a central role in OCDS, with its own field at the top of release and usually the only buying party.

ColinMaudry commented 4 years ago

We have used the 'funder' role in the EU guidance in a single case: to support the following form field (it's common across the forms):

II.2.13) Information about European Union funds (yes/no + id of the programme)

Its implementation requires no extension

ColinMaudry commented 4 years ago

This is the current (OCDS 1.1) description of buyer:

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.

It's not clear to me that the definition of a buyer depends much on budgeting concerns

If we remove the budgeting part, there isn't much remaining.

My feeling is that a buyer in OCDS is, by default, a combination of several roles, since it's the default role:

it provides the funds for the procured stuff (funder)
it manages the procurement process (procuring entity: "The entity managing the procurement. This can be different from the buyer who pays for, or uses, the items being procured.")
it is "obliged to run public procurement procedures according to the local legislation" quoting @JachymHercher (= procuring entity? I think it's the case in a French context)
it is responsible for the payment of the suppliers (payer) (not sure for this one: do publishers use the payer role when it's the same party as the buyer?)

Proposals

a) For maximum accuracy, we remove the empty (semantically) "buyer" role and force publishers to use specific roles ("procuring entity", "funder", "payer", "legally bound entity", etc.).

b) Alternatively, if we want to keep a default "buyer" role, it could be a compound role and its description should reflect its versatility:

A buyer is an entity that takes on the roles of procuring entity, funder and payer.

This option gives room to ambiguity (what if party A is buyer and party B is procuring entity?), but it clarifies the situation and is in line with current usage.

jpmckinney commented 4 years ago

@ColinMaudry See also https://github.com/open-contracting/standard/issues/903#issuecomment-517703361. Can you also have a look at the glossaries, etc. mentioned in #827? Since we will be doing a lot of lookups into these other glossaries, we might want to put together a comparison table.

jpmckinney commented 4 years ago

Regarding your proposals:

a) The concept of a 'buyer' is a commonly needed concept, even if the entity it references might have different other roles in different contexts. So, we shouldn't do this option. b) I'm hoping that after reviewing my above comment, we might find a better definition that is less ambiguous.

While working on this issue, we should also update the description of the buyer field in OCDS.

ColinMaudry commented 4 years ago

From the @eprocurementontology mailing list:

Role of buyer:

Originator ‘The agent that originally requested the ordered items/ the agent on whose behalf the purchase is made, I;e; the end-user’

DeliveredTo ‘The agent to whom the items are to be delivered’

Invoicee ‘the agent who should be invoiced for the order’

martinszy commented 4 years ago

Hello, we at PODER are mapping from a government source, so for buyer we are using the procuring entity (unidad compradora), with a memberOf field that expresses the bigger institution to which it belongs (such as a ministry). And while the money for all contracts in our dataset is from the federal government and some times the institutions are from state and city level governments, we don't fill funder for those cases. Funder is a field that is only filled if there's an international bank such as IDB involved in the contract.

An issue that has arisen from this structure is that it's sometimes hard to filter for parties. In the case of funders, the only place in which they appear is in the parties array, and the only way they can be filtered is from the roles array, this is not ideal because it forces the parser to grab the whole parties array and then filter it, instead of just grabbing one field, as one can do with the buyer.name field or the parties.memberOf.name field.

This is just an example of a bigger problem with storing JSON in databases, as we are doing, that is why we now have an alternate representation of OCDS in our database, that is still very close to the standard, but has a few advantages, such as that it's easier to find things while using Kibana and it's more easily flattened.

Here's an example document for a release: https://gist.github.com/martinszy/36f501806547e7bf14550f4fe3910568

As you can see, there's no object arrays, only string arrays, and there's a named field for funders. This is particular to our case, in which we don't have multiple awards or multiple contracts in a single document, but I still share it here because I think it may be useful to show the adaptations that we needed to do.

JachymHercher commented 4 years ago

General

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.

Proposal

To solve the main issue in this ticket, I think we should:

Deprecate 'funder'. https://github.com/open-contracting/standard/issues/825#issuecomment-475650606 mentions fine ways to deal with the source of the money and to me it seems that the distinction between 'buyer', 'procuringEntity' and 'payer' covers the "buying side" of things quite nicely. (Adding the 'contractImplementer' from https://github.com/open-contracting/standard/issues/548 shouldn't cause any trouble.)

However, I'm not sure why 'sourceParty' and 'financingParty' are not codes on their own. Is it because they are used in extensions? Since partyRole is an open codelists, shouldn't the extensions be adding codes in there?
Keep a fairly general definition of "buyer". For me, the main trickiness is making it distinct from other codes we already have (i.e. 'procuringEntity' and 'Payer') and making it distinct from other codes we could expect to have in the future (for examples see the discussion below, but I think the most important one is "CPB intermediary" (signs framework agreements, clients buy directly from suppliers), "CPB wholesaler" (buys items, sends them to clients), the "body on whose behalf the CPB is buying in the previous two scenarios", and "CPB buying for itself" - all of which are "buyers" in EU law).

Option 1

Link the definition to the law, because that's why all / most buyers are buyers. This could be for example "Party which is obliged to run contracting processes according to the local legislation. Typically, this would be the party that manages the process, signs the contract, pays the suppliers and uses the works/goods/services, but in more complex processes, these actions are sometimes done by different parties."

The two shortcomings of this approach are that 1) we would need to clarify better that a party that is obliged to run contracting processes in general, but not for this one specific contract, is still a buyer (e.g. for below-national-threshold contracts); 2) the definition is very much public sector linked. If OCDS has a significant ambition to be voluntarily used by other bodies, e.g. private extractive companies, NGOs, then this probably doesn't work.

Option 2

Choose one or more concrete real world actions (see point 3) above) and decide that is we want buyer to mean. Roles of other parties could then be described via something like eForms' organisation subrole. For me, the main buyer actions are "sign contract" and "use what was bought through the contract". This would mean one of the following definitions:
- "The party aiming to conclude a contract with a supplier." Note: an OCDS buyer would not cover, in EU-speak, a contracting authority that is buying from a CPB wholesaler.
- "The party aiming to use the goods, works or services resulting from a concluded contract." Note: an OCDS buyer would not cover, in EU-speak, a CPB (neither intermediary nor wholesaler).
- "The party aiming to conclude a contract with a supplier or to use the goods, works or services resulting from the contract." This should more or less fit with the EU approach.
(Another alternative would be to concentrate on where the money is coming from, i.e. budget. I think it is not as good as above, as I expect budgeting to be more nationally idioscynratic. For example:
- "The party whose budget will be used." Note: an OCDS buyer would not cover an intermediary CPB, nor (sometimes?) a wholesaler CPB nor (sometimes?) a client of a wholesaler CPB.)

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").
OCDS partyRole currently does not cover: subcontractor, mediator, beneficial owner.
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.
I'm not sure the "member of" need mentioned in https://github.com/open-contracting/standard/issues/825#issuecomment-723170861 is currently addressed by OCDS. In eForms, we have Organisation Part Name (BT-16) as a simplistic solution, but having nested organisation blocks where one can be "memberOf" another would be a more accurate solution.

jpmckinney commented 3 years ago

0.2% of parties have the "funder" role when we last checked, so OK to deprecate.

However, I'm not sure why 'sourceParty' and 'financingParty' are not codes on their own. Is it because they are used in extensions? Since partyRole is an open codelists, shouldn't the extensions be adding codes in there?

I've opened https://github.com/open-contracting/ocds-extensions/issues/157 and https://github.com/open-contracting/ocds-extensions/issues/158

The party aiming to conclude a contract with a supplier or to use the goods, works or services resulting from the contract.

This seems fine to me.

I'll open new issues for some of the related concerns.

jpmckinney commented 3 years ago

I created #1156 for procuringEntity (which might be a use case for subroles). Re: memberOf, there is https://github.com/open-contracting/standard/issues/452.

OCDS partyRole currently does not cover: subcontractor, mediator, beneficial owner.

I didn't create issues for this, but issues can be opened if there is demand. For mediator, the OCDS for EU profile adds 'mediationBody', which can be promoted to the standard: https://github.com/open-contracting-extensions/ocds_eu_extension/blob/master/codelists/%2BpartyRole.csv

jpmckinney commented 3 years ago

From https://github.com/eprocurementontology/eprocurementontology/issues/279#issuecomment-781355624

Definitions used by Peppol:

Buyer (Business Role): Is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

Definitions used by UBL:

Buyer: The Party Role for a Party that purchases the goods or services on behalf of the Originator. Originator: The Party Role for a Party that had the original demand for the goods and/or services and therefore initiated the procurement transaction.

Ours:

The organization aiming to conclude a contract with a supplier or to use the goods, works or services resulting from the contract.

I prefer that ours refers to a contract, rather than the verbs "buys or purchases". Also the above make it seem like the buyer and customer/originator are necessarily different, whereas we know they can be the same.

open-contracting / standard