Update guidance on contract suppliers and change contract signatories to additional signatories

[jpmckinney]

Contract suppliers was staged for OCDS 1.1 but rejected: open-contracting/standard#249 (comment)

Contract signatories seems to satisfy the same needs, but without the issues that contract suppliers has.

Are any publishers using the contract suppliers extension? From my perspective, it should be removed from the registry in favor of contract signatories.

If we keep it, the readme needs an example.

[yolile]

Are any publishers using the contract suppliers extension? From my perspective, it should be removed from the registry in favor of contract signatories.

Yes:

• Paraguay_dncp: but as they use the 1.0 version of the standard so they are not referencing this extension
• Buenos Aires City: But they are not publishing yet, so we can advice them to use signatories instead of suppliers
• Honduras ONCAE: same as Buenos Aires

And checking in Kingfisher:

• Ukraine: same as Paraguay_dncp

[yolile]

Should we also remove contract_buyer extension then?

[jpmckinney]

Good question. Who is using contract_buyer?

[yolile]

Buenos Aires, again. If I remember well, the extension was created for Mexico Federal, but they ended up not using it.

[duncandewhurst]

Noting that the contract signatories extension doesn't specify the role of the signatories, whereas using contract.suppliers or contract.buyer would make this explicit in the contract object, rather than through organization.role in the parties section.

This issue has come up in Scotland recently, regarding modelling frameworks with multiple buyers in one contracting process. Helpdesk feedback was to use contract signatories, based on the direction of this conversation. FYI @mrshll1001

[yolile]

I'm suggesting the same to Buenos Aires and Honduras. But, a question, the contract.signatories list should has the complete list of signatories or if, for example, the buyer is already declared in the buyer section it can be omited in the signatories list? (or the same for suppliers)

[jpmckinney]

I think the semantics are that it should include all signatories (even if one party is the same as the buyer). If buyer and awards.suppliers are the signatories, then the recommendation should be to omit contracts.signatories, as they are implicitly the signatories.

[jpmckinney]

Note: If we go with signatories, we probably also don't want to add https://github.com/transpresupuestaria/ocds_multiple_buyers_extension to the registry.

[jpmckinney]

The current situation of having extensions for contract suppliers, contract signatories, contract buyer and (not in registry) contract multiple buyers means that we no longer have a standard way of determining the buyers and suppliers for contracts, which is very bad.

In the general case, we should not use any of these extensions. There are exceptional cases in which they can be used, and we need to be clearer about that.

1. If a process has multiple buyers, and all those buyers are the same for all contracts, then there should simply be multiple parties with a 'buyer' role in the parties array. In the EU, for example, there is always a primary buyer (buyer in OCDS) and then additional buyers (parties in OCDS).
2. If a process has multiple buyers, but there are different buyers for different contracts (can we find a real example, to inform the discussion?), then we should use the "contract multiple buyers" extension, which is more flexible than the "contract buyer" extension.
3. If a system has one award to multiple suppliers and then one contract per supplier, then the system is most likely implementing the award notice. In OCDS, we model the award decision. When implementing OCDS, there should be multiple awards (award decisions) even if the system has only one "award" (award notice).
4. In some exceptional circumstances, supplier information must be disclosed on the contract. These are:
   1. The award and contract systems are separate and not linkable, i.e. the implementer has no robust way to identify which award goes with which contract. In this case, there is no choice but to duplicate the supplier information on the contract (their data will also be invalid because awardID will not be provided). (Belarus example)
   2. The award is made to a parent company, but the contract is made with different subsidiaries (e.g. because the subsidiaries have different capacities, delivery zones, etc.). (From my brief legal research, subsidiaries are not necessarily subcontractors; it depends on things like shared personnel, shared financial resources, control percentages, etc. and the relationship might only be determined after it goes to court.) If the subsidiary is not a subcontractor (which would be modelled differently), and if the parent company was named in the award and the subsidiaries were named in the contracts, then the contracts need a field for the suppliers (subsidiaries). (Belarus example)
   3. A system has a monetary value for only the award notice, not for each award decision, and the value of each contract is not available in the system until the contract stage. I don't know any system with this characteristic; @duncandewhurst can you provide an example? If this is a real case, then there is no choice but to have one award object for all the suppliers, and then a contract object for each supplier.
5. The "contract signatories" extension should only be used and the field should only be filled in if there are additional signatories beyond the buyers and suppliers (in the case of the PPP profile, beyond the public authority and preferred bidders). We should consider replacing this extension with an "additional signatories" extension, since buyers and suppliers should always be disclosed via other methods.

For this issue:

• Find the real-world examples mentioned above.

Extensions:

• Remove the "contract buyer" extension from the registry, and replace the README with a notice to use the "contract multiple buyers" extension.
• Add the "contract multiple buyers" extension to the registry, after making a pull request to update the README with additional guidance on when to use the extension.
• Add examples to the "contract suppliers" extension and provide additional guidance that the extension should only be used for the listed exceptional cases.
• Consider replacing the "contract signatories" extension with an "additional signatories" extension. If so, replace its README with a notice to use the "additional signatories" extension.
• In either case, improve the documentation for whichever signatories extension to mention real examples of additional signatories (e.g. financiers, or, in Red Compartida, the government agency responsible for the national fibre network also signed the contract). Clarify this is the only time the extension should be used.

(Also noting that signatories data is harder to use in flattened format, as the roles of the signatories are not identified. It is better to have the buyers and suppliers in separate fields.)

In OCDS 1.2, we should move these extensions into the standard, as otherwise I expect we'll continue to have extensions that model buyers, suppliers and additional signatories in conflicting ways.

Standard: Add guidance on (open-contracting/standard#249) to:

• Model multiple buyers
• Determine the buyers (The robust method is to check the parties array. The weaker method is to only check the buyer object.)
• Model award decisions (not award notices)
• Model multiple suppliers in exceptional circumstances
• Determine the suppliers (The robust method is to check contracts.suppliers and fallback to awards.suppliers. The weaker method is to only check awards.suppliers)
• Model additional signatories

cc @juanpane

[duncandewhurst]

2. If a process has multiple buyers, but there are different buyers for different contracts (can we find a real example, to inform the discussion?), then we should use the "contract multiple buyers" extension, which is more flexible than the "contract buyer" extension.

Other than the example from CDMX I'm not aware of one off the top of my head, but @transpresupuestaria may be able to provide one.

This would also be the case for a framework agreement with direct call-offs, which was modelled following the guidelines in the documentation.

iii. A system has a monetary value for only the award notice, not for each award decision, and the value of each contract is not available in the system until the contract stage. I don't know any system with this characteristic; @duncandewhurst can you provide an example? If this is a real case, then there is no choice but to have one award object for all the suppliers, and then a contract object for each supplier.

Awards for the set-up of framework agreements in Contracts Finder are modelled in this way (example and other UK procurement systems also use this model (example).

Neither of those systems support linking between the set-up of a framework and the contracts resulting from call-offs, though competitive call-offs from the framework are sometimes disclosed under separate award notices (at which point the actual value of the contract with a specific supplier would be known).

[jpmckinney]

Yeah, a framework agreement in which multiple buyers can participate is a good example. So my new question is with respect to the semantics of 'buyer' in the multiple buyers extension. From its readme:

In some contexts, including Mexican public procurement, it is very common that a contract is paid for by more than one buyer (institution).

My understanding is that the buyer is the entity that is a party to the contract (e.g. is named as such on the contract) and that has contractual obligations. How the contract is paid is a separate concern. So, is 'buyer' being used to mean 'funder' in the extension, or are there really multiple government agencies all named as parties on an actual contract?

Regarding the set-up of a framework agreement, I'd say that the monetary value (usually the maximum value of the FA) is of the award decision (the decision to include the suppliers in the FA). I'm looking for an example where there's an award notice making multiple decisions (e.g. awarding different lots to different suppliers), yet there is only one monetary value for the whole notice.

[duncandewhurst]

My understanding is that the buyer is the entity that is a party to the contract (e.g. is named as such on the contract) and that has contractual obligations. How the contract is paid is a separate concern.

The description of the buyer field (and role) in OCDS is about who pays, rather than who signs:

A buyer is an entity whose budget will be used to pay for goods, works or services related to a contract.

Regarding frameworks, I'm not quite sure I followed:

Regarding the set-up of a framework agreement, I'd say that the monetary value (usually the maximum value of the FA) is of the award decision (the decision to include the suppliers in the FA).

Are you proposing that the examples mentioned would be modelled as multiple awards in OCDS (one per supplier included in the award decision)?

[jpmckinney]

The description of the buyer field (and role) in OCDS is about who pays, rather than who signs

Good catch, thanks! The EU eProcurement Ontology also has "Organisation that manages the budget allocated for the procedure and pays for the items being procured." So, we'll add the multiple buyers extension to the registry. We might want to clarify how 'funder' is different from 'buyer' since "entity providing money" is not far from "entity whose budget will be used".

Are you proposing that the examples mentioned would be modelled as multiple awards in OCDS (one per supplier included in the award decision)?

No, there would be a single award (decision) for all suppliers on the same framework agreement. As with other award decisions, there can be multiple decisions on an award notice (not the case in the examples, but it's possible in the EU for one procedure to set-up multiple FAs).

[jpmckinney]

I see there's already an issue about buyer-funder confusion: open-contracting/standard#825

[jpmckinney]

eForms Policy Implementation Handbook mentions:

Buyer, procurement service provider and, hypothetically, central purchasing bodies may refer to one or more lots. This could be the case for joint procurement (incl. joint procurement of central purchasing bodies), where certain lots would be used only by certain buyers or central purchasing bodies or supported only by certain procurement service providers. Furthermore, all three above-mentioned roles could also differ per contract, in cases where notices are being published about contracts within framework agreements (e.g. certain buyers in a contract award notice will be signing certain contracts, other buyers other contracts).

[jpmckinney]

See also #131