OPT-300-Contract-Signatory

[duncandewhurst]

This field belongs to SettledContract and is a reference to the legal person that signs the contract from the Buyer side (source).

In OCDS, the signatories to the contract are not explicitly declared in the contracts section. Instead, the signatories are implicitly assumed to be the buyer and the suppliers in the award associated to the contract.

In eForms, there can be multiple buyers per procedure, as shown in can_25_ENG_Buyers.xml. Presumably, although not shown in that example, OPT-300-Contract-Signatory is then used to indicate which buyer signed a contract.

The Signatories extension can be used to explicitly specify a contract's signatories, but it should be used only if the signatories to a contract differ from its related award's suppliers and the contracting process' buyer. In which case, all signatories (buyers and suppliers) should be listed.

To conform to the rules for the use of the signatories extension, the mapping for OPT-300-Contract-Signatory would need to include logic along the lines of (rough draft):

• If the procedure has exactly one buyer (/*/cac:ContractingParty), discard. Otherwise:
  • Add the buyer to Contract.signatories
  • Add the supplier for the contract (the /efac:TenderingParty​/cbc:ID of the LotTender referenced in the SettledContract) to the Contract.signatories

I have two concerns about this:

1. The location of the data in OPT-300-Contract-Signatory varies depending on the number of buyers, but I guess that's the cost of standardisation.
2. In OCDS the tendering party is explicitly declared as a contract signatory when that is not explicitly declared in eForms. I don't know if there can be a scenario where the signatory from the supplier's side might differ from the tendering party.

To address those concerns, and have a simpler mapping, we could always map OPT-300-Contract-Signatory to Contract.signatories. However, that wouldn't conform to the rules for the use of the signatories extension.

@jpmckinney what do you think?

[jpmckinney]

open-contracting/ocds-extensions#86 considers removing the signatories extension. It also suggests making contracts.buyer plural. open-contracting/ocds-extensions#131 then suggests moving the buyer to the award.

So, I would map this to awards.buyers, and ideally when drafting the extensions we can address the above issues.

[duncandewhurst]

Mapping to awards.buyers sounds good. I've updated guidance.yaml. I'll leave this issue open as a reminder of the issues that we need to address when drafting the extensions.

[odscjen]

It also suggests making contracts.buyer plural.

There doesn't appear to have been an agreement reached on whether or not contracts.buyer should become contracts.buyers in open-contracting/ocds-extensions#86. And in open-contracting/ocds-extensions#131 (comment) you say

We can keep buyer on Contract for backwards-compatibility and any niche use cases.

So my combined reading is that we're adding awards.buyers and leaving contracts.buyer as is.

Additionally the name of the extension "ocds_contract_buyer_extension" is now confusing as it is:
a) different from the extensions title, "Multiple buyers - contract level",
b) contract specific and
c) not in keeping with the OCDS camel case style guidance.

Is this just a legacy issue we have to live with or can these elements be changed too. So the repo would become "ocds_multipleBuyer_extension" and the extension title changed to simply "Multiple buyers".

@jpmckinney

[jpmckinney]

The extension title can change.

We can also rename the repository (GitHub will still respond without redirects at the old URL), but I'm less fussed as it's not something people look at frequently.

I think we're agreed on adding awards.buyers. I don't know if we need contracts.buyer, but we haven't done much work to check - which is why the current plan is to leave it. I'm open to removing it.

[odscjen]

okay, for now then I'll add in awards.buyers and attempt to change the extension title.

[duncandewhurst]

I think that this can be closed now that the extension is named 'Buyer per award or contract'