open-contracting / standard

Documentation of the Open Contracting Data Standard (OCDS)
http://standard.open-contracting.org/
Other
139 stars 46 forks source link

Contracting process type #1144

Open duncandewhurst opened 3 years ago

duncandewhurst commented 3 years ago

(From https://github.com/open-contracting-extensions/public-private-partnerships/issues/237#issuecomment-744625885) SIF's SOURCE platform includes a boolean isPPP/Concession field, the semantics of which are:

Whether the project intended to be tendered as a PPP/Concession or as a traditional procurement

At present, there is no field for this "type" information in OCDS.

jpmckinney commented 3 years ago

From #237

For example, the EU's standard procurement forms include separate sets of forms for utilities, design contests, concessions, transport, and "social and other specific services", but this type isn't expressed in data fields (and thus is not expressed in the OCDS mapping) – except indirectly via the use of particular fields in OCDS (or in the notice type/form name in the EU). Note that, in eForms (the EU's future forms), the same forms are used for different types, and a notice type field is used instead.

In other systems, this type information is disclosed indirectly through procurementMethodDetails, since some procedures are exclusively used for specific types.

duncandewhurst commented 3 years ago

As noted in https://github.com/open-contracting/infrastructure/issues/251, the SOURCE platform also includes a Contractual Arrangement field which mixes information on the functions for which the supplier is responsible with the following values relevant to this issue:

Also, as noted in https://github.com/open-contracting-extensions/public-private-partnerships/issues/238, SISOCS APP includes a tipo de contrat field which similarly mixes information on the functions for which the supplier is responsible with information on whether the contract is a concession or not.

So, based on these examples there seems to be some demand to explicitly declare information about the contractual arrangement.

jpmckinney commented 3 years ago

A much older issue: #20

JachymHercher commented 3 years ago

Also linked / identical to #927.

JachymHercher commented 3 years ago

Some general thoughts:

In principle, I think the dimensions are idiosyncratic, but the perspectives could be standardisable. However, at least in the EU, reconstructing the legal regimes from the perspectives is a huge hassle and I don't think anyone wants to do it. For eForms, all you need is the Notice Type (or Form Type and Notice Type) field which corresponds to Table 1 mentioned above. It'll need to be there verbatim and to me it sounds like ideal extension material. My guess would be that other jurisdictions will also have their idiosyncracies that are too unwieldy to break apart into their component parts, but who knows. Starting with very concrete use cases - who wants what typology, why - is I think a must here.

jpmckinney commented 3 years ago

Having seen this in a few datasets, I agree that governments tend to refer to process types by mixing dimensions in idiosyncratic ways, and they tend to have very long lists, which they are rather unlikely to want to map to some taxonomy.

I also think preparing that taxonomy of perspectives is a long task, that will be difficult to build consensus around (per above, the consensus might be that it is not needed/wanted).

I think having a standard field in OCDS for publishers to declare the local name for their procedure would be fine. Right now we use procurementMethodDetails for this.

So, I guess this issue is about whether that field is sufficient, or if its responsibilities are too broad, in which case publishers might benefit from having another field that is always only the name of the procedure, so that procurementMethodDetails can be used for whatever other details they want to include.

I am happy to defer to what helpdesk analysts have witnessed in publishers' data to inform which option to pursue.

JachymHercher commented 3 years ago

I think having a standard field in OCDS for publishers to declare the local name for their procedure would be fine. Right now we use procurementMethodDetails for this.

For me, these dimensions/perspectives are something else than procedures. The different classifications mentioned in https://github.com/open-contracting/standard/issues/1144#issuecomment-907752037 are orthogonal to procurementMethod, e.g. you could run an 'open' or 'selective' procedure in any combination of them. So I'd use a different field for this.

jpmckinney commented 3 years ago

Yes, procurementMethod is already separate from procurementMethodDetails, whose semantics are very broad such that it could describe these dimensions/perspectives. Right now it's often used for the name of the procedure, which in many jurisdictions conflates dimensions, perspectives and a "strict" concept of procedure. My question is whether there is something other than the name that we want to track, in which case another field(s) is useful.

JachymHercher commented 3 years ago

I think I understand, but I find it quite surprising. My impression of the two fields was that they are both very narrow: procurementMethod is defined by its closed codelist and procurementMethodDetails are details on the closed codelist, which is essentially just the name of the procedure (e.g. in the EU, I choose 'direct' and write "Negotiated procedure without prior publication of a call for competititon"). I wouldn't put other information there.

But to answer your question - for the EU, one field would be enough.

jpmckinney commented 3 years ago

In the EU, the names of procedures are separated from the dimensions/perspectives like "utilities", "social regime", etc. but in some jurisdictions we've reviewed, the names of procedures integrate these. I guess that is surprising, but it is common.

yolile commented 3 years ago

In Colombia, the procurementMethodDetails field already distinguishes if the process is a PPP. Example https://apiocds.colombiacompra.gov.co/apiCCE2.0/rest/release/ocid/ocds-k50g02-16-20-1498 And the endpoint and value to use to filter them all https://apiocds.colombiacompra.gov.co/apiCCE2.0/rest/releases/filters/tender.procurementMethodDetails%2CIniciativa%20Privada