Open jpmckinney opened 5 years ago
Are any publishers using the contract suppliers extension? From my perspective, it should be removed from the registry in favor of contract signatories.
Yes:
And checking in Kingfisher:
Should we also remove contract_buyer extension then?
Good question. Who is using contract_buyer?
Buenos Aires, again. If I remember well, the extension was created for Mexico Federal, but they ended up not using it.
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
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)
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.
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.
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.
buyer
in OCDS) and then additional buyers (parties
in OCDS).awardID
will not be provided). (Belarus example)For this issue:
Extensions:
(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:
parties
array. The weaker method is to only check the buyer
object.)contracts.suppliers
and fallback to awards.suppliers
. The weaker method is to only check awards.suppliers
)cc @juanpane
- 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).
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.
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)?
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).
I see there's already an issue about buyer-funder confusion: https://github.com/open-contracting/standard/issues/825
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).
Contract suppliers was staged for OCDS 1.1 but rejected: https://github.com/open-contracting/standard/issues/249#issuecomment-261229685
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.