Contracting process type

[duncandewhurst]

(From open-contracting-extensions/public-private-partnerships#237 (comment)) 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]

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]

As noted in open-contracting/infrastructure#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:

• Concession
• Lease
• Concession to lease transformation

Also, as noted in open-contracting-extensions/public-private-partnerships#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]

A much older issue: #20

[JachymHercher]

Also linked / identical to #927.

[JachymHercher]

Some general thoughts:

• In the OCDS 1.2 schema's description we currently say "OCDS is used for contracts in public procurement (including design contests), concessions, public-private partnerships, government asset sales and other contexts."

• eForms' list of notices is in Table 1 of the Regulation. I'm afraid it's logic can't be described better than "there's a specific notice for every time the law says your supposed to publish a specific type of notice". It is a result of combining several dimensions:

  • What you want to do (e.g. planning / competition / result)
  • Under which Directive do you fall (i.e. general, defence, concessions)
  • Under which special regime, which are orthogonal to the directives, do you fall (i.e. none, design contests, light - also called social - regime)
  • Which legal instrument will you choose? (e.g. competition via a contract notice, a qualification system, a prior information notice)

  These dimensions are based on a mix of perspectives with which you can look at procurement: who buys, what do they buy, what type of contract is it, how expensive is it. Regrettably, the perspectives don't fit perfectly with the dimensions. For example procuring under the "utility directive" is a combination of "who buys" (utility companies) and "what do they buy" (pipes for gas, not paper); while procuring under the defence directive (as well as design contests and social regime) is "what do they buy" (military stuff / designs / social stuff); under the concessions directive it is just "what type of contract" (concession); choosing a prior information notice for competition depends on who you are (subcentral authority); and all of the above is then also about how expensive the purchase is (below/above threshold, different for each directive and some regimes).

• As far as I'm concerned, PPP is a different dimension altogether. In the EU, PPPs don't have their own category, they typically fall under concessions, but I think that some would fall under other directives.

• All of this is distinct from "how you meet your need", see the definition of a "public supply contract" in the classical directive:

  ‘public supply contracts’ means public contracts having as their object the purchase, lease, rental or hire-purchase, with or without an option to buy, of products.

  (This distinction was in TED forms between 2011 and ~2016, but was then removed because of low use.)

---

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]

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]

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 #1144 (comment) 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]

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]

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]

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]

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