Multiple buyers and contract or item-level buyer information

[timgdavies]

This is being considered for the 1.1 OCDS upgrade via core and extension updates.

This builds on discussions in #352

The issue

At present the buyer property of a release is a single object rather than an array of objects.

This means each contracting process has a single buyer associated with it.

Some publishers run single contracting processes (particularly frameworks) with multiple buyers. This gives rise the following scenarios:

• The process may result in multiple contracts with each contract signed by a different buyer
• The process may result in a single contract with individual line items for each buyer

  The proposal

The proposed update to organisation handling will allow multiple buyers to be specified in the entities array at the top level of a contracting process, along a single lead buyer will still be required.

Where the contracting process results in multiple contracts with each contract signed by a different buyer we propose introducing an extension with a contract.buyer field to capture the buyer each contract relates to.

Where the contracting process results in a single contract with individual line items for each buyer, we propose an extension to provide an item.buyer field to explicitly capture the buyer each item relates to.

contract.buyer and item.buyer should follow our proposed approach to organization references (#368).

Questions

• Do any information systems capture buyer information at the line-item level?

  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.

[andrewlorien]

NSW eTendering has a field (in various objects) called "Multi Agency Access" (MAA) or "Piggyback", which allows other agencies to share a procurement. The publication of this field is significant, because it signals to suppliers that there might be a bigger market than the tender initially presents. A plan with MAA will only "potentially" result in a tender with MAA, a tender with MAA does not always result in contracts with MAA, and a tender without MAA may result in a contract with MAA. There is always a lead agency (the publisher of the tender/contract).

[duncandewhurst]

@andrewlorien thanks for this

For reference when we look at modelling for this issue here is the ProcurePoint NSW page on multi-agency access

[andrewlorien]

Yes, that's the thing. None of those arrangements are visible to the eTendering application. So when an agency advertises that a tender may be shared with other agencies, apart from the text in the tender/contract description we don't know what that arrangement is or whether it has borne fruit. If two contracts from different agencies list the same tender as being "related", it's a fair guess that it was a prior arrangement between those agencies. But we don't have data to reflect that, so for us there is nothing further we can add to the schema.

[timgdavies]

@duncandewhurst I did some work to tweak the descriptions of the proposed extension for this, and it's entries in the extension registry, to:

• Rename it to ocds_multiple_buyers_extension as this will remain an extension, rather than part of core;
• Update the descriptive text to reflect this;

I'm not sure whether we should include the buyer per-item elements into the same extension, or a separate one. My leaning is towards a separate one, as this will be easier to integrate into the documentation.

[duncandewhurst]

@timgdavies agreed - separate extensions was the approach I was going for, as it will avoid confusion for those who want to use just one or the other.

[JachymHercher]

My comment from the 1.1 peer review:

Adding a buyer to the contract level sounds like a very good idea. For 2.0., it could be considered to leave a buyer only in the contract section, while the contractingEntity would stay in the buyer section, essentially being responsible for the "procurement process".

[jpmckinney]

As this is the only issue that mentions a "lead buyer" (at least in those words), noting that eForms adds a "Buyers Group Lead Indicator" (note: this is not in the regulation, but is an invention of the concrete XML implementation). This has been mapped to a 'leadBuyer' code in the eForms profile.