Procurement Category (supplies, works and services)

[timgdavies]

This issue is under consideration for core as part of the 1.1 upgrade process.

It builds on discussions in #204

The issue

A number of forms of contract analysis rely on knowing whether a contract is for goods/supplies, works or services.

There is currently no field to indicate this in OCDS, although for some item classification codelists this information can be inferred.

The proposal

We propose to introduce a contractType field with a closed codelist of:

• supplies - including physical goods
• works
• services

Detailed definitions for each code need to be identified. This codelist may be extended to include concessions or other contract types by OCDS extensions.

Outstanding questions

What level of the OCDS structure should this exist at?

We currently propose including it at the top level, i.e. it would apply to a whole contracting process, rather than allowing different awards or contracts to have different contractType values.

Engagement

Please indicate support or opposition for this proposal using the +1 / -1 buttons or a comment. If opposing the proposal, please give clear justifications, and where possible, make an alternative proposals.

Pointers to sources of clear definition on the proposed codes are also invited.

[akuckartz]

A lot depends on the encoding and the set of allowed values. It should be open.

[timgdavies]

The rationale for a closed codelist here is that:

(a) Most classifications of contractType should be able to map to this codelist;
(b) Analytical tools can be more easily developed against a closed codelist.

We could follow the pattern we have for other closed codelists, and pairing the field with a 'Details' free text field. E.g.

contractType with one of supplies, works or services

and

contractTypeDetails which can be used either for an explanation, or for a more detailed code from national systems.

Thoughts?

[JachymHercher]

Concerning #204 question 2, works/supplies/services are just a high-level CPV code (supplies correspond to CPV where the first two digits fall in (0,44>, works to those starting with <45>, services with <48,98).

I think they are relevant mainly from a legal point of view, as they determine the applicable thresholds for following the procedures described in the EU-level procurement directives. Thus, I would agree it makes sense to collect them only at the level of the whole procurement process.

(Note that under the EU directives a procurement process may also be a "mixed-contract", in which case it may have multiple types of contract. However, one of them will still be the "main" one, so I'm not sure how relevant this is.)

[duncandewhurst]

Feedback from the codelists breakout at IODC suggested the following additional codes:

• Concessions
• Utilities (e.g. electricity, gas, water etc.)

[JachymHercher]

At least in the EU context, "concessions" and "utilities" are a different type of classification than supplies, works, and services. In the EU legal framework, "W/S/S" is about what is being bought, while "concessions" and "utilities" distinguish legal regimes. (Concessions and utilities have their own procurement directives, slightly different than the "general" procurement directive.)

For us, concessions are applicable on works and services, not on goods. Things like electricity have their CPV codes (e.g. 09310000) and thus fall into the works/goods/services category (e.g. services supplies because the first two digits are 09, in the case of electricity).

[duncandewhurst]

The World Bank's Public Procurement Indicators for monitoring e-GP adoption and performance includes several indicators based on the type of contract (goods, works or services)

[duncandewhurst]

The World Bank Procurement Regulations for IPF borrowers makes a distinction between consulting services, defined as:

Covers a range of services that are of an advisory or professional nature and are provided by Consultants. These Services typically involve providing expert or strategic advice e.g., management consultants, policy consultants or communications consultants. Advisory and project related Consulting Services include, for example: feasibility studies, project management, engineering services, finance and accounting services, training and development.

And non-consulting services, defined as:

Services which are not Consulting Services. Non-consulting Services are normally bid and contracted on the basis of performance of measurable outputs, and for which performance standards can be clearly identified and consistently applied. Examples include: drilling, aerial photography, satellite imagery, mapping, and similar operations.

The regulations also define goods as:

A category of procurement that includes: commodities, raw material, machinery, equipment, vehicles, Plant, and related services such as transportation, insurance, installation, commissioning, training, and initial maintenance

We should also note that our terminology of contractType could be ambiguous - the World Bank regulations use contract type to describe the payment conditions of a contract.

Thanks to Hunt La Cascia from the World Bank for the pointer to these definitions.

[duncandewhurst]

The regulations also define works as:

A category of procurement that refers to construction, repair, rehabilitation, demolition, restoration, maintenance of civil work structures, and related services such as transportation, insurance, installation, commissioning, and training.

[chrisalexsmith]

As many governments (and other MDBs)have modelled their own procurement laws and regulations on the WB procurement procedures there may already be some natural alignment with the OCDS if World Bank definitions are used.

[duncandewhurst]

Feedback from consultation with Marcela Rozo, Open Contracting Team Leader, World Bank:

Goods, Works, Services etc. are not types of contract but rather what the contract is about, would contract object be a better title for the field?

Contract type would typically mean:

• Concession
• PPP
• Framework Agreement

We should consider whether the initiationType codelist should be extended to include these codes or whether this information should be captured in a new field.

• Aggregated Purchasing, etc.

[duncandewhurst]

Feedback from consultation with Alexandre Borges de Oliveira, World Bank:

• The term "contract type" is ambiguous
• Alternative terms for this concept include "procurement type" and "procurement category"

[timgdavies]

In this staging extension I've added a procurementCategory item to tender, and proposed a procurementCategory codelist which is shown below.

Although the category might be set before the tender stage, the rationale for including this in tender, rather than at the top-level, is that it collects it alongside other properties like procurementMethod etc. which can also be set at earlier planning stages.

I considered whether this should be labelled as something other than procurementCategory, to future-proof for other contracting processes, but that feels premature for 1.1, and leads to very abstract terminology.

I looked at whether this should be an array, to handle cases where there is more than one category - but based on discussions in #204 of how existing practice is to classify according to largest goal, and request for a 'mixed' code rather than the codelist to express the nature of the mixture, I've opted for a single code.

Draft codelist

The procurement category codelist is used to indicate the primary focus of a contracting process. Where a contracting process covers more than one of the options below, publishers should either:

• (a) select the category that accounts for the greatest value; or
• (b) use the 'mixed' code;

depending on the available data in source systems.

Where a publisher is using the code 'consultingServices', then the 'services' code should be used only for non-consulting services. However, users should note that not all publishers are able to make this distinction from their source data.

Code	Title	Description
supplies	Goods and supplies	The primary object of this contracting process involves physical or electronic goods or supplies (such as electricity)
works	Works	The primary object of this contracting process involves construction, repair, rehabilitation, demolition, restoration or maintenance of some asset or infrastructure.
services	Services	The primary object of this contracting process involves professional services of some form, generally contracted for on the basis of measurable outputs or deliverables. When the consultingServices code is also available or in use for data from a particular dataset, the service code must only be used for non-consulting services.
consultingServices	Consulting Services	The primary object of this contracting process involves professional services provided on a consultancy basis.
mixed	Mixed	There is no identified primary object of this contracting process. The object of the contracting process involves two or more of supplies, works and services.

Mini example

{
	"releases": [{
		"tender": {
			"id": "123456",
			"procurementCategory": "works"
		}
	}]
}

[JachymHercher]

I find the addition of "mixed" an unnecessary loss of information. In particular, in #204 it's mentioned that "single procurement may include both goods/services.". However, in general, any combination of the basic three types can exist, and choosing "mixed" means we don't have any information about what the "main" element was - works/goods/or services? (An array, or a mainProcurementCategory and an additionalProcurementCategory would be better imo).

The addition of "consultingServices" to this top-level codelist is a not really a systematic approach - these types of specifications belong into the CPV code. If including in CPV is not doable for the WB, I understand you need to have it here though.

[timgdavies]

The suggestion of 'mixed' came from @joshuacpowell here based on data from Vietnam which didn't name the main object, but instead used the term 'mixed' (or equivalent).

Josh - any views on @JachymHercher's point above?

Would it be possible from Vietnam data, or other data you have seen, to provide code based on the 'main' element of the procurement (supplies/works/services)?

[timgdavies]

Feedback during the peer review has raised two major concerns:

• The inclusion of the mixed code was opposed by a number of reviewers;
• The inclusion of consultingServices was rejected by one reviewers;

One reviewer noted:

It would be great if applications could capture the breakdown of the 'mixed' label given to any procurement category (i.e. goods/services/etc.). At the moment, it's not clear how that would work.

Should the procurementCategory field be added at each contract stage rather than (or along with) a single tender?

Another reviewer commented that:

It should be an open codelist to adapt to each country.

Another reviewer stated:

ConsultancyServices are, by definition, part of services. Thus, they should not have their own procurementCategory. This level of detail can be covered by other classifications such as the CPV.

Mixed contract should not be a value in the codelist, as it represents a loss of information. If mixed is selected, it's no longer clear what is the main category, nor which category is excluded. Instead, there should be two procurementCategory fields: mainProcurementCategory and additionalProcurementCategory. This is also the way this is proposed in the future EU forms.

Another review stated:

I like the idea of having procurementCategory, my comment is more with the wording, in some cases the data is not broken down between Services and ConsultancyServices, so I would suggest adding more documentation around what would fall under the consultingServices, or just remove the consultingServices category. In Governmet of Canada (Federal) our categories are: Goods, Services, Services related to Goods, Construction. We don't have a specific category for consultingServices only, so might have trouble implementing this.

[timgdavies]

Based on the peer-review feedback, and discussions in the standard team, here's an updated proposal:

(1) We introduce mainProcurementCategory (singular, one value) with a closed codelist consisting of 'supplies', 'services' and 'works'.

(2) We introduce a additionalProcurementCategories (plural, array of values) field with an open codelist, with suggested codes, but the idea that publishers may extend this with local procurement categories. The suggested codelist for this will additionally include 'consultingServices' to accommodate the common requirement in World Bank and Latin American contexts to explicitly identify consulting contracts - as a category of contracts particularly prone to corruption.

This approach requires publishers using these fields to map their categories to a core three ('supplies', 'services' and 'works') and to identify the main procurement category for any 'mixed' procedure, whilst also providing a way to specify each of the other categories under additionalProcurementCategories.

This does not capture the 'share' of the procurement associated with each category (e.g. 70% services; 30% supplies). This information should be extracted from line-item level classifications and the categories associated with item classifications.

Quick worked example:

{
     "mainProcurementCategory":"services",
     "additionalProcurementCategories":["consultingServices","supplies"]
}

[LindseyAM]

very tiny request: can we use 'goods' instead of 'supplies' (its a shorter word and commonly used in this context)?

[timgdavies]

@LindseyAM This was discussed in #204 (comment) where the point made was that 'supplies' includes 'intangible goods' such as electricity - and so 'supplies', 'works' and 'services' provides a comprehensive list.

[chrisalexsmith]

UNCITRAL Model Law on Public Procurement uses the term Goods not Supplies and I agree with Lindsey

[LindseyAM]

Interestingly, @JachymHercher pointed out on Oct 20 that electricity is categorized as a service in Europe. In the US, it is sometimes categorized as a service and sometimes categorized as a good (http://faculty.law.miami.edu/rrosen/courses/documents/05kelectricityagood_000.pdf).

It seems that the EU directive uses the term 'supplies' (and in one instance 'goods') whereas 'goods' is the more used term elsewhere. So this might be one of those situations where Europe says supplies and other places say goods. I would still lean towards 'goods' but now I understand better where the term 'supplies' comes from :)

[timgdavies]

Based on weight of feedback - I'm staging 'goods' as code for 1.1 release candidate - for final review then.

[JachymHercher]

(I asked around whether there is a clear reason why "supplies" was preferred to "goods" in EU procurement terminology and it seems to be a linguistic choice more or less forgotten by history. The argument that it should cover things like electricity might have been where it started.

Which brings me to correcting my example from Oct 20 - electricity is indeed a supply, not a service, sorry.)