Clarify Contract description

[jpmckinney]

Background

contracts:

Information from the contract creation phase of the procurement process.

Contract:

Information regarding the signed contract between the buyer and supplier(s).

The eProcurement Ontology (ePO) has a class for Contract:

A voluntary, deliberate, and legally binding agreement between two or more competent parties.

The ePO has a class for Purchase Contract, which is synonymous with: specific contract, call-off contract, draw-down contract (Ireland) and contract under a framework agreement. This concept also applies to "dynamic purchasing systems", which UNCITRAL considers synonymous with "open framework agreement".

Discussion

None of these definitions clearly indicate which contracts between buyer and suppliers belong in the contracts array, which can include:

• A contract establishing the relationship, like the set-up of a framework agreement
• A contract within the relationship, like a call-off contract under a framework agreement
• Purchase orders (the acceptance of a purchase order forms a legal contract)
• Catalog purchases

Framework agreements

The most important difference between the set-up contract and call-off contracts is that no goods or services are delivered directly under the set-up contract. The framework agreement has a maximum value, but no value in the same sense as a call-off contract. It might specify items to be delivered by call-off contracts, but these are not delivered directly under the set-up contract and might not have specific quantities.

The present guidance puts call-off contracts in the contracts array, and leaves the set-up contract in the awards array. This avoids confusion of the differences above, but it isn't perfect, as the set-up contract is indeed a contract itself. Some facts about the set-up contract might be better understood in the context of a contract than in the context of an award decision.

TED and eForms can inform this discussion.

Purchase orders

In a contract with definite quantities of items, purchase orders are more of an implementation detail, describing the specific timing, quantities, deliveries, etc. of the items in the contract.

In this first case, purchase orders seem appropriate under contracts.implementation.

In a contract with indefinite quantities, and especially in a contract with multiple suppliers (e.g 'simultaneous supply' in Paraguay #888), a user will have to look at the purchase orders to determine the actual quantities delivered by which suppliers, and to determine the real value of the contract. This is closer, in form, to a framework agreement with call-off contracts.

In this second case, it seems, at first, more appropriate to follow the same model as framework agreements.

However, we might need to compromise on recommending just one model for all purchase orders, because it might be too difficult or confusing to try to explain these two scenarios, both of which use the term 'purchase order'. It might also be impossible for systems to distinguish which model is appropriate for a particular procurement.

If so, we should think through how to distinguish the two cases, where possible. For example, in the second case, perhaps the contract should have only a maxValue and not a value. This would be similar to how the set-up contract in a framework agreement would be modelled, if we developed guidance for how to do so in contracts.

Catalog purchases

TBD

Proposal

1. Update the definition of contracts and Contract to be more clear on the scope.
2. Review the properties of set-up contracts in TED and eForms and determine whether they make more sense on an Award or Contract in OCDS. If the latter, update the guidance. This can be done as part of Guidance: How to model awards and contract suppliers in different scenarios #249 and would resolve Distinguishing between framework agreements and other types of contract #784.
3. See Purchase orders #897

[duncandewhurst]

Regarding modelling purchase orders in general, I think the key thing we want to avoid is having both a contract (with definite quantities and values) and the purchase orders resulting from it, in the contracts array, which could easily lead to double counting.

Putting all purchase orders under contracts.implementation avoids that situation.

That said, in a situation where a dataset contains a mixture of 'traditional' contracts along with frameworks or open contracts I can see the benefits of defining the contracts array as something like:

Legally binding agreements to provide a definite quantity or value of items

So, it would be good to get some feedback on the following point and the questions posed in #897 before deciding on the preferred approach for the standard:

It might also be impossible for systems to distinguish which model is appropriate for a particular procurement.

[jpmckinney]

Regarding the simultaneous supply case, @yolile clarified the procedure in #888 (comment):

The supplier with the lowest price is the first awarded, and he has to provide a percentage of the number of item (this percentage is determined already in the tender specifications and conditions document), then the second should provide the rest and so on. This decision is made in the award and there is not a second stage, all is part of the award stage. so I think that in this case is not necessary to have a secondStage or similar, we dont have extra information or stages.

So, the quantities might not be known at the tender stage, but they are known at the award stage, so the contracts will be for definite quantities.

For the more general case of indefinite quantities, here's a US description, where purchase orders (called 'delivery orders' for goods and 'task orders' for services) are made against a 'basic contract', which specifies "minimum and maximum quantity limits … as either number of units (for supplies) or as dollar values (for services)."

I think this 'basic contract' belongs in the contracts array, with the purchase orders under contracts.implementation, even though it is not for a definite quantity. However, in this case, there is no mix of contracts in the contracts array, so it's fine.

For framework agreements, the best compromise might be to leave the set-up contract as an implicit contract described in the awards array.

As for the description of Contract, it can perhaps be 'Legally binding agreements between buyers and suppliers to provide items. This excludes agreements to set-up a structure through which contracts are later awarded to provide items, for example: a contract to set up or add suppliers to a framework agreement or dynamic purchasing system.'

This makes it very specific to procurement, but we can always add words like "In a public procurement context, …" to open it back up to a more general statement.

[jpmckinney]

Noting that indefinite-delivery/indefinite quantity (or task order) contracts in the US were considered to be two-stage procurement techniques (similar to framework agreements) in a 2006 UNCITRAL survey (from Law and Economics of Framework Agreements, chapter 2).

[JachymHercher]

General observations

• Legally speaking, a contract is a type of agreement. Framework agreements, purchase orders, etc. are all contracts.

• Reality (/economics) speaking, all contracts are incomplete. What differs is the extent of their incompleteness (e.g. does the contract omit details for quantity / price / time of delivery and/or place of delivery) and the level of legal formality for dealing with this incompleteness (e.g. does the contract set that the time/place of delivery must be agreed in writing or can it be done orally).

• Framework agreements (FA) vs. non-FA contracts is an attempt to classify contracts by their completeness. This distinction is not clear cut. In the EU, the FA definition is fuzzy: an "[agreement establishing] terms governing contracts to be awarded during a given period, in particular with regard to price and, where appropriate, the quantity envisaged."; while, as far as I am aware, the GPA does not define them at all and UNCITRAL only provides a (somewhat circular) description. I believe you could find plenty of contracts where some lawyers would tell you they are actually FA, while others would insist they are not.

• "Purchase orders" (PO) is an ambiguous expression. Using EU public procurement terminology and comparing with https://www.unleashedsoftware.com/blog/know-four-types-purchase-orders; other online resources (e.g. here and wikipedia); and https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/

  • POs can set up framework agreements ("Contract purchase orders", "blanket purchase orders")
  • PO can be framework agreement call offs ("planned purchase order", "standard purchase order") - with the difference that in a public procurement call off you probably wouldn't be able to negotiate the unit price.
  • PO can be simply contracts (e.g. "discrete/stand-alone purchase order").
  • POs as "implementation details1" (based on the guidance example), i.e. cases when they are used within contracts with definite quantities (as compared to indefinite quantites or estimated quantities) and seem to just play the role of invoices?
  • POs as "implementation details2" (loosely based on the description at the beginning of this thread), i.e. cases when they are used within contracts with definite quantities (as compared to indefinite quantites or estimated quantities) and they would just specify the time/place of delivery. I'm not sure this category exists and if yes, I would say it is just a written agreements that in other contexts would take place orally?

  Some purchase orders do not need to be signed by the other party, but this can be the case also for contracts (see Austrian example below), so this also is not a distinguishing feature.

• As discussed in Discussion: Electronic catalogues #396, catalogues do not introduce any special cases for this discusssion - they are just a format for tenders (that often goes hand in hand with FAs).

Proposal

3. See Purchase orders #897

Based on the discussion of purchase orders above, my takeway is that purchase orders, with the exception of the "implementation detail" category, are not a specific "instrument" with some special functionality (consisting of unique types of actions or leading to unique results), but rather a subset of contracts described by specific terminology. Consequently, I would treat them as other contracts and just make sure they fit in the definition.

The "implementation detail" category I'm not sure of. The examples in https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/ should go, in my opinion, to contracts.implementation. What about the just time/place case, does that exist, @jpmckinney?

2. Review the properties of set-up contracts in TED and eForms and determine whether they make more sense on an Award or Contract in OCDS. If the latter, update the guidance. This can be done as part of Guidance: How to model awards and contract suppliers in different scenarios #249 and would resolve Distinguishing between framework agreements and other types of contract #784.

The present guidance puts call-off contracts in the contracts array, and leaves the set-up contract in the awards array. This avoids confusion of the differences above, but it isn't perfect, as the set-up contract is indeed a contract itself. Some facts about the set-up contract might be better understood in the context of a contract than in the context of an award decision.

I think the FA set-up should be in Contract, same as any other contact. Placing it where it belongs is not just semantically correct, but - mainly - has practical benefits. The decision to let (or not let) someone into a FA can be appealed at a court, so it can happen that the FA is "awarded" but does not become a "contract". Treating it as any other contract allows us to model that (consistently).

With the same reasoning, I would put PO into Contract. (With the exception of "PO as an implementation detail", discussed above.)

If we have all contracts, both FA and PO, in Contract, it means we need a mechanism to distinguish FA set-ups and call-offs and their PO equivalents. In eForms, this distinction (esp. to be very sure we avoid double-counting) was one of the reasons to distinguish Estimated / Maximum FA values and actual values - which in OCDS are both in Value.

I think the best approach for OCDS would be to do this in a specific field, as discussed in #784 (essentially a broader version of eForms' BT-768 introduced in eForms/eForms#251 (comment)). I'm not sure where exactly this field should be and whether it is not already covered / shouldn't be merged with a field existing in core OCDS or one of the extensions. If possible, we should have validation rules to make sure this is used correctly (e.g. linked to related processes and techniques).

To cover both FA and purchase orders, the codes should be drafted generically, along the lines of:

• 'The contract establishes general conditions for future contracts (e.g. "framework agreement", "dynamic purchasing system", "blanket purchase order"). Typically, these contracts do not specify the exact quantity and value of the purchase (they may specify the maximum or estimated quantity/value, however).'
• 'The contract purchases specific quantities based on a previous general contract (e.g. specific contract within a framework agremeent, call-off contract, draw-down contract, a specific or planned purchase order). These contracts typically specify the exact quantity and value of the purchase.'

(Note: In eForms, there is no distinction between "The contract is awarded within a dynamic purchasing system (DPS)" and "This contract sets up a DPS", because there is no notice published upon the establishing of a DPS. I'm assuming that different jurisdictions in the world might have this differently (i.e. someone might want to publish which companies made it into the DPS), so I have also included the DPS in the previous paragraph.)

1. Update the definition of contracts and Contract to be more clear on the scope.
   Contract:
   Information regarding the signed contract between the buyer and supplier(s).

Proposal:
Information regarding the concluded contract, typically between the buyer and supplier. This includes contracts describing all the contractual conditions (e.g. item, quantity, price, payment terms, time and place of delivery), as well as contracts that only describe general conditions (e.g. a framework agreement) and those describing specific conditions (e.g. a contract within a framework agreement). Communication between contractual parties that consists of minor specifications of conditions agreed previously (e.g. specifying the time or place of delivery) is not considered a contract. Amendments are considered as part of the contract that is being amended.

This definition also takes into account:

• As mentioned above in the context of purchase orders, contracts do not need to be signed. Based on feedback from Austria, in eForms, we replaced "signed contract" by "concluded contract", with additional information specifying that "Typically, this is the date when the last contractual party signed the contract. However, if no contract is signed, then the date of contract conclusion may correspond to other dates (e.g. the date when the buyer notified the winning tenderer)." (If we go for this change, then we should also reflect it dateSigned and possibly other fields).

• We should be more open concerning the "between the buyer and supplier(s)". At least, there can be contracts signed between 'procuringEntity' and 'supplier' (e.g. in case of CPBs buying on behalf of someone) and between 'buyer'/'procuring entity' and 'tenderer' (e.g. in design contests and innovation partnerships, where tenders who didn't win the contract could still be receiving a monetary prize). I would suggest adding "typically".

contracts:
Information from the contract creation phase of the procurement process.

Can probably be kept the way it is?

[jpmckinney]

The "implementation detail" category I'm not sure of. The examples in https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/ should go, in my opinion, to contracts.implementation.

Re-reading that example, the scenario isn't realistic, because a highway bypass is not the sort of thing for which multiple purchase orders are issued (that said, at least it shows the problem of double-counting).

A more believable scenario might be: A buyer needs to install black boxes on its 10 helicopters, which might be distributed at different airfields at different times – plus on 2 new helicopters it is purchasing separately, with uncertain delivery dates.

The buyer ultimately signs a contract for 12 black boxes, including shipping. The contract is incomplete with respect to delivery location, because the buyer calculated that it will be more efficient and effective to ship the black boxes to wherever the helicopters are, rather than fly the helicopters back and forth to a single location. Because the locations are changing regularly, it didn't make sense to put those details in the contract. The contract is also incomplete with respect to delivery time, because the 2 new helicopters have uncertain delivery dates.

In this scenario, the idea is that the buyer issues "purchase orders" once it has definite locations and times – but to be honest I don't know for certain if any jurisdiction calls these "purchase orders".

At any rate, I think we're agreed that these things belong under contracts/implementation.

[jpmckinney]

What about the just time/place case, does that exist, @jpmckinney?

Did I cover that above, or can you clarify what case you mean?

To cover both FA and purchase orders, the codes should be drafted generically, along the lines of:

Which codes are you referring to?

Information from the contract creation phase of the procurement process.

Can probably be kept the way it is?

I think we should at least clarify that it also covers implementation. We might re-use language from #866.

---

Thank you for the general observations and research! I agree with the proposals. To keep track of what needs to be updated, building on the numbered list in the issue description:

Normative changes:

• Update the definition of Contract
• Update the definition of dateSigned and review other mentions of contract signature to use language of "concluded"
• Add/update definitions to distinguish set-up contracts from specific contracts (not necessarily using those terms)
  • Add a field if needed to support this distinction (see next comment)
• Make sure the changes to awards/Award in Clarify award description #895 are consistent with these changes
• Add a Value object under the Contract object for estimated/maximum value, cf. Distinguishing between framework agreements and other types of contract #784 (since OCDS 1.1 has a Value object with mixed semantics, we might need to consider the best way/place to introduce the new object)

Non-normative changes:

• Update https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/:
  • Use a more realistic example than a highway bypass
  • Add the scenario from the above comment, if there is a real context in which these are called "purchase orders"
• Review guidance to be sure it is consistent with the normative changes (e.g. the guidance authored for Guidance: How to model awards and contract suppliers in different scenarios #249)

[JachymHercher]

Did I cover that above, or can you clarify what case you mean?

Yes, you covered that above in #896 (comment), thank you.

Keeping track: Depending on whether the example you gave would be called "purchase orders" somewhere, we should / should not include this scenario in https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/.

Which codes are you referring to?

The codes for this field:

I think the best approach for OCDS would be to do this in a specific field, as discussed in #784 (essentially a broader version of eForms' BT-768 introduced in eForms/eForms#251 (comment)). I'm not sure where exactly this field should be and whether it is not already covered / shouldn't be merged with a field existing in core OCDS or one of the extensions. If possible, we should have validation rules to make sure this is used correctly (e.g. linked to related processes and techniques).

Keeping track: Adding this field is not on the list of updates above? You only mention "Add/update definitions to distinguish set-up contracts from specific contracts (not necessarily using those terms)" (Or do we just need to change definitions because the field already exists?)

I think we should at least clarify that it also covers implementation. We might re-use language from #866.

Good point.

Add a Value object under the Contract object for estimated/maximum value, cf. #784 (since OCDS 1.1 has a Value object with mixed semantics, we might need to consider the best way/place to introduce the new object)

In eForms, the estimated/maximum FA values are stored at the procedure/lot level, not the contract level. This is because a typical scenario in a FA with multiple participants (with or without reopening of competition) is that the maximum value of a lot is X, but, in principle, any of the participants has a shot at supplying everything, so the maximum value for each participant (/contract with a participant) is also X. Summing up the contracts, this would lead to a seeming maximum value of 3X, which is not desirable.

When working with the word "estimated", we should take care to distinguish between "Estimated refers to estimation at the time of launching the call for competition" and "Estimated refers to estimation at the time of concluding the framework agreement." (eForms does not do that too well, see eForms/eForms#329 (comment).)

[jpmckinney]

I've added the two tasks you mention to my comment above.

In eForms, the estimated/maximum FA values are stored at the procedure/lot level, not the contract level. This is because a typical scenario in a FA with multiple participants (with or without reopening of competition) is that the maximum value of a lot is X, but, in principle, any of the participants has a shot at supplying everything, so the maximum value for each participant (/contract with a participant) is also X. Summing up the contracts, this would lead to a seeming maximum value of 3X, which is not desirable.

Should we have the maximum value on the award object for the framework setup (in which all suppliers are listed)?

As I understand, after the award, individual contracts are concluded with each supplier under the framework, and indeed, each can have a maximum value equal to the value of the framework, and I agree we wouldn't want their sum to be a multiple of the frameworks' maximum value.

• If those contracts were disclosed in OCDS, I guess they would omit a value?
• Right now, the suppliers for a contract are structurally assumed to be the same as for the award. Do we change that, or do we have a single contract paired with the framework setup?

When working with the word "estimated", we should take care to distinguish between "Estimated refers to estimation at the time of launching the call for competition" and "Estimated refers to estimation at the time of concluding the framework agreement." (eForms does not do that too well, see eForms/eForms#329 (comment).)

For the former, we would use tender/value and for the latter, we would use awards/value (or whatever we agree). Would that work?

[JachymHercher]

Should we have the maximum value on the award object for the framework setup (in which all suppliers are listed)?

Sounds good.

As I understand, after the award, individual contracts are concluded with each supplier under the framework, and indeed, each can have a maximum value equal to the value of the framework, and I agree we wouldn't want their sum to be a multiple of the frameworks' maximum value.

If those contracts were disclosed in OCDS, I guess they would omit a value?

I'm not sure why both Award and Contract have a value. When can the two be different? (I understand that an award may not lead to a contract e.g. because of a complaint or one party refusing to sign a contract. However, I don't see how that could change the contract value, at least not without repeating the evaluation phase which should lead to a new award being published.)

Regardless of the above, since an FA is a contract, I think the publishers should publish the values in both blocks - and they should be identical. (Same approach as for any other contract.)

Right now, the suppliers for a contract are structurally assumed to be the same as for the award. Do we change that, or do we have a single contract paired with the framework setup?

The contract having the same suppliers as the award doesn't seem like a problem to me. If I conclude a framework agreement (FA) with multiple suppliers, both of the following are currently acceptable:

• Single Award informs about all suppliers in the FA. A single Contract links to the Award.
• Single Award informs about a single supplier in the FA, i.e. we have many Awards to cover the whole FA. A single Contract links to each Award.

In both cases, all values are maximum values and should be repeated everywhere. EDIT: The semantics may be more complicated, see #896 (comment).

For the former, we would use tender/value and for the latter, we would use awards/value (or whatever we agree). Would that work?

Sounds good, with the latter being in both award/value and contract/value.

[JachymHercher]

Given #903 (comment), I think we should add a sentence to the definition proposed in #896 (comment) clarifying that

"Contracts also cover prizes or other rewards (e.g. a follow-up contract) resulting from a design contest."

[jpmckinney]

I'm not sure why both Award and Contract have a value. When can the two be different? (I understand that an award may not lead to a contract e.g. because of a complaint or one party refusing to sign a contract. However, I don't see how that could change the contract value, at least not without repeating the evaluation phase which should lead to a new award being published.)

If the contract is modified, would that not create a scenario where the award value is different from the contract value?

[jpmckinney]

Regardless of the above, since an FA is a contract, I think the publishers should publish the values in both blocks - and they should be identical. (Same approach as for any other contract.)

In both cases, all values are maximum values and should be repeated everywhere.

To be sure I'm clear, do you mean, for the setup of a framework agreement, that awards and contracts would set a new maximumValue field (and omit the value field)? Otherwise, we end up with the problem we are trying to avoid:

Summing up the contracts, this would lead to a seeming maximum value of 3X, which is not desirable.

[JachymHercher]

If the contract is modified, would that not create a scenario where the award value is different from the contract value?

Currently it would, but does tracking this require a new field? The difference between the original contract value and the contract value after the amendment could be derived by comparing AwardValue in the two releases.

(Note: according to https://standard.open-contracting.org/latest/en/guidance/map/amendments/#example-2-contract-amendment amendments are currently done by only changing Contract, while I assumed they would be done by changing Award and Contract. Once confirm this is the route to take, we should clarify in #895 that amendments to contracts do not require changes to awards.)

(Note2: in eForms, we treat an amendment essentially as a separate contract, so the amendment value is just the "new" value, i.e. the difference, not the total after the amendment.)

To be sure I'm clear, do you mean, for the setup of a framework agreement, that awards and contracts would set a new maximumValue field (and omit the value field)? Otherwise, we end up with the problem we are trying to avoid:

Yes, MaximumValue and no Value. This avoids the double-counting problem because the semantics of MaximumValue imply that it is a maximum for the entire process or lot (i.e. for the same process/lot, you do not add up maxima). However, for the "single Award for each Supplier" option, this approach rests on the assumption that the MaximumValue is the same for all suppliers. If there can be supplier-specific maxima - which I have not met in practice, but for which I can imagine plausible examples (e.g. "A single supplier in this FA cannot win more than 80% contracts" or "20% of this FA is reserved for suppliers that are SMEs" or "20% of this FA is reserved for suppliers that are female-led") - then this becomes quite complicated / stops working. (As long as there was a supplier who could have access to 100% of the FA, then the highest MaximumValue would be the one applicable to the whole FA. However, if each supplier had a lower-than 100% access, then it might not be possible to deduce what is the actual MaximumValue of the FA.)

Practically, the above implies:

• That we should recommend/require a single Award that informs about all suppliers in the FA.
• Furthermore, if a publisher wants to inform about supplier-specific maxima, he could do it with a supplier-specific Award. (Presumably, this will be extremely rare.)
• (I'm wondering how Tender.Value comes into the picture. IMO, usually, it would be the same as the Award from the first bullet (assuming that Tender.Value can be updated on the basis of submitted tenders), but it would be different if a single process has an FA with multiple lots (= multiple FAs). Consequently, it doesn't really bring anything to this discussion.)

[JachymHercher]

contracts:
Information from the contract creation phase of the procurement process.

Can probably be kept the way it is?

Actually, "procurement process" should be changed to "Contracting process"

[jpmckinney]

If the contract is modified, would that not create a scenario where the award value is different from the contract value?

Currently it would, but does tracking this require a new field? The difference between the original contract value and the contract value after the amendment could be derived by comparing AwardValue in the two releases.

Yes, the releases can be compared. However, this information isn't preserved in the compiled release; it's only available by inspecting each release or using the versioned release. Where relevant, we define separate fields rather than overwriting information. Since contract value modification is a common use case, we prefer separate fields.

(Note: according to https://standard.open-contracting.org/latest/en/guidance/map/amendments/#example-2-contract-amendment amendments are currently done by only changing Contract, while I assumed they would be done by changing Award and Contract. Once confirm this is the route to take, we should clarify in #895 that amendments to contracts do not require changes to awards.)

I believe that approach is appropriate, yes.

(Note2: in eForms, we treat an amendment essentially as a separate contract, so the amendment value is just the "new" value, i.e. the difference, not the total after the amendment.)

If we included the value in the structured information for the amendment, we would similarly assign it the difference. However, since we're describing the value of the contract that was modified, we assign the total after amendment. I assume it is not really a separate contract in eForms, otherwise "modification" wouldn't be the correct word.

• That we should recommend/require a single Award that informs about all suppliers in the FA.

Sounds good.

• Furthermore, if a publisher wants to inform about supplier-specific maxima, he could do it with a supplier-specific Award. (Presumably, this will be extremely rare.)

That's an option. We can cross that bridge when we get there.

• (I'm wondering how Tender.Value comes into the picture. IMO, usually, it would be the same as the Award from the first bullet (assuming that Tender.Value can be updated on the basis of submitted tenders), but it would be different if a single process has an FA with multiple lots (= multiple FAs). Consequently, it doesn't really bring anything to this discussion.)

I don't think tender.value should be updated on the basis of submitted bids. Does TED change the "Total value of the procurement" in Section II when publishing a CAN? I would have assumed it just repeated the value from the CN.

[JachymHercher]

I've started working on a PR (#1208). Here is a summary of the discussion above and whether the issues, as listed in #896 (comment), are resolved in the draft PR.

Normative changes:

• Update the definition of Contract

Included in PR: "Information regarding the contract, typically between the buyer and supplier. This includes contracts describing all the contractual conditions (e.g. item, quantity, price, payment terms, time and place of delivery), as well as contracts only describing the general contractual conditions (such as a framework agreement) and those only describing the specific contractual conditions (such as a contract within a framework agreement). Communication between contractual parties that consists of minor specifications of conditions agreed previously (e.g. specifying the time or place of delivery) is not considered a contract. Amendments are considered as part of the contract that is being amended. Contracts also govern the granting of prizes or other rewards (e.g. a follow-up contract) resulting from a design contest.",

• Update the definition of dateSigned and review other mentions of contract signature to use language of "concluded"

Included in PR. I've changed "signed" to "concluded" throughout the schema, but given the double meaning of "concluded", I sometimes used "concluded (e.g. signed)". Furthermore, in the guidance, I offen leave "signed" as I think the understandability/precision trade-off can go slightly more towards understandability there.

• Add/update definitions to distinguish set-up contracts from specific contracts (not necessarily using those terms)

Not included in the PR. I've changed Contract and contracts above and value fields below, not sure what else to change.

• Add a field if needed to support this distinction (see next comment)

Looking at #784 (comment), I'm wondering whether the field should be added in a PR for this issue or for #784 and whether it should be part of the core or rather of the EU extension.

• Make sure the changes to awards/Award in Clarify award description #895 are consistent with these changes
• Add a Value object under the Contract object for estimated/maximum value, cf. Distinguishing between framework agreements and other types of contract #784 (since OCDS 1.1 has a Value object with mixed semantics, we might need to consider the best way/place to introduce the new object)

Included in PR:

• Modified: tender.value: "The total upper estimated value of the procurement, as estimated when publishing the tender information".
• New: tender.maximumValue: "The estimated maximum value of the framework agreement, as estimated when publishing the tender information.",
• New: award.maximumValue: "The estimated maximum value of the framework agreement, as estimated when making the award."
• New: award.estimatedValue: "The estimated value of the framework agreement, as estimated when making the award."
• New: contract.maximumValue: "The maximum value of the framework agreement."
• New: contract.estimatedValue: "The estimated value of the framework agreement, as estimated when the framework agreement is concluded (e.g. signed)."
• Modified: award.value and contract.value, by adding "This field should not contain the value of a framework agreement, those should be given in estimatedValue or maximumValue instead."

(I considered whether the field naming wouldn't be clearer as maximumValueFramework, but decided against it, as perhaps someone might want to use them for other use cases, e.g. dynamic purchasing systems or qualification systems. I doubt it, but if so, the description could be changed, the field name less so.)

(I've also opened #1207.)

Non-normative changes:

• Update https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/:
• Use a more realistic example than a highway bypass
• Add the scenario from the above comment, if there is a real context in which these are called "purchase orders"

Since the PO discussion in #896 (comment) was not really disputed, my conclusion was that PO is not much of a useful term. Consequently, I would have a tendency to remove it from https://standard.open-contracting.org/latest/en/guidance/map/awards_contracts_buyers_suppliers/.

• Review guidance to be sure it is consistent with the normative changes (e.g. the guidance authored for Guidance: How to model awards and contract suppliers in different scenarios #249)

Status quo: there is https://standard.open-contracting.org/latest/en/guidance/map/awards_contracts_buyers_suppliers/ which contains various examples (that should be better linked to the text), including https://standard.open-contracting.org/latest/en/guidance/map/related_processes/, https://standard.open-contracting.org/latest/en/guidance/map/frameworks/ and https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/. So, far I've proposed just minor changes in the PR.

I think the two major points we need to explain are how to model FAs and how to work with FA values (avoiding duplication; communicating maximum values through a single award for all suppliers, as explained in #896 (comment)). I think we should address both of these issues in one place and since #1123 changes https://standard.open-contracting.org/latest/en/guidance/map/frameworks/, I would wait with the drafting until it's reviewed and merged (potentially, it might be worth also waiting for the getting started section). Concerning https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders, I think the example could largely be reused, but I would replace "purchase orders" with "FA and contracts within FAs".

[duncandewhurst]

• Modified: tender.value: "The total upper estimated value of the procurement, as estimated when publishing the tender information".

Can we narrow the semantics of a field like this in a minor version? Currently, if tender.status is 'planning', then tender.value means 'cost estimate', the pre-tender estimated value of the contracting process (see #914).

[jpmckinney]

#866 disambiguates "contracting planning process" from "contracting process", as their conflation creates a lot of challenges, and we also know that if disclosure truly begins at the planning stage, then it is unlikely that the process continues through the other stages without potentially splitting into multiple procedures, being redefined, etc.

With that distinction, tender.value will have different semantics (as it does now) depending on whether it is used in a contracting planning process or a contracting process.

The mechanism for indicating the type of process is likely to just be tender.status, so I think the new definition just needs to provide both meanings, for each alternative.

[JachymHercher]

While the semantics of tender.value are slighly different depending on whether tender.status is 'planning'/'planned' or 'active', the current definition aims to be agnostic to it. "As estimated when publishing the tender information" refers only to the tender block, which will be present in any planning process or contracting process. The purpose of the addition is just to differentiate it from "As estimated when making the award" (mainly relevant for framework agreements). Since the semantics are just slightly different (discussed in #914 (comment)), should we really explain it in more detail?

[duncandewhurst]

While the semantics of tender.value are slighly different depending on whether tender.status is 'planning'/'planned' or 'active', the current definition aims to be agnostic to it.

Ah, I see. I missed the intentional ambiguity of 'publishing the tender information', which I interpreted as publishing a tender notice. It might be best to add the clarification to the description of tender rather than to its individual properties. I'll add a note to #1154.

[JachymHercher]

To be sure I'm clear, do you mean, for the setup of a framework agreement, that awards and contracts would set a new maximumValue field (and omit the value field)? Otherwise, we end up with the problem we are trying to avoid:

Yes, MaximumValue and no Value. This avoids the double-counting problem because the semantics of MaximumValue imply that it is a maximum for the entire process or lot (i.e. for the same process/lot, you do not add up maxima). However, for the "single Award for each Supplier" option, this approach rests on the assumption that the MaximumValue is the same for all suppliers. If there can be supplier-specific maxima - which I have not met in practice, but for which I can imagine plausible examples (e.g. "A single supplier in this FA cannot win more than 80% contracts" or "20% of this FA is reserved for suppliers that are SMEs" or "20% of this FA is reserved for suppliers that are female-led") - then this becomes quite complicated / stops working. (As long as there was a supplier who could have access to 100% of the FA, then the highest MaximumValue would be the one applicable to the whole FA. However, if each supplier had a lower-than 100% access, then it might not be possible to deduce what is the actual MaximumValue of the FA.)

Practically, the above implies:

That we should recommend/require a single Award that informs about all suppliers in the FA.
Sounds good.

On second thought, having a single award actually doesn't work:

1. FAs in OCDS are both closed and open. In case of open ones, the decision to add new suppliers can happen later on, so it needs a separate award with a separate date. Similarly, the later awards may have a different maximum value, because some of the money might have already been spent.
2. A similar, if smaller, issue also applies for closed FAs. I would guess that in some places, awards will be made on a per-supplier basis (i.e. I check the supplier's selection criteria, he/she passes, I make the award). In such cases, this can happen on different dates, again requiring separate awards.

I would suggest that to avoid double-counting of values, we simply rely on the semantics of MaximumValue - when there is a maximum, you don't sum up. Then we can be indifferent on whether a publisher chooses to have an award per supplier or an award for multiple suppliers. This approach only fails when no supplier in the FA had access to the whole maximum value of the FA, which I think is fairly rare. (In eForms, this is solved by Group Framework Value (BG-556). That solution is not elegant, but I'm not aware of a cleaner way. OCDS can go for this eventually, e.g. once the mapping to eForms is done.)

(This approach is also in line with the current version of https://standard.open-contracting.org/1.1/en/guidance/map/related_processes/.)

[JachymHercher]

The PR is ready for review. The outstanding issues have been resolved in the following way:

---

Review guidance to be sure it is consistent with the normative changes (e.g. the guidance authored for Guidance: How to model awards and contract suppliers in different scenarios #249)
Status quo: there is https://standard.open-contracting.org/latest/en/guidance/map/awards_contracts_buyers_suppliers/ which contains various examples (that should be better linked to the text), including https://standard.open-contracting.org/latest/en/guidance/map/related_processes/, https://standard.open-contracting.org/latest/en/guidance/map/frameworks/ and https://standard.open-contracting.org/latest/en/guidance/map/purchase_orders/. So, far I've proposed just minor changes in the PR.

I think the two major points we need to explain are how to model FAs

I think this is sufficiently covered by https://standard.open-contracting.org/latest/en/guidance/map/related_processes/.

---

and how to work with FA values (avoiding duplication; communicating maximum values through a single award for all suppliers, as explained in #896 (comment)).

I think the following changes should be made in https://standard.open-contracting.org/latest/en/guidance/map/related_processes/. They are not included in the PR, because I need help with some branching / PRing wizadry:

• In the "Invitation to participate in the first stage of a framework agreement procedure" section, after "In the tender section, set:" add a bullet with "tender.maximumValue to the maximum value of the framework agreement and / or tender.value to the estimated value of the framework agreement (the values may be different e.g. if the budget for the framework agreement contains a reserve in case of an unforseen situation, but the situation is unlikely to occur)".
• In a section on the "Award of a framework agreement" (proposed in point 10 of Improvements/fixes to the framework guidance #1301 (comment)) add
  • "in the award section, set award.maximumValue to the maximum value of the framework agreement and / or award.estimatedValue to the estimated value of the framework agreement".
  • "in the contract section, set contract.maximumValue to the maximum value of the framework agreement and / or contract.estimatedValue to the estimated value of the framework agreement".
• (Approach to award.value and contract.value is already covered by Improvements/fixes to the framework guidance #1301 (comment).)

---

#896 (comment) is being dealt with elsewhere.

---

New question: I'm wondering whether the estimated (and possibly also maximum) value fields mentioned in #896 (comment) require an extra sentence of clarification along the lines of "This value concerns the entire framework agreement, not just this supplier." This might be unnecessary, because the description does not mention the supplier, but since the fields are in Award / Contract, the users might already be thinking just about the concrete supplier. (What we want to avoid is, for example, that the estimated value fields get populated by something like "maximum value divided by three, because there are three suppliers in the framework agreement.") Currently not included in the PR.

---

(Since the issue is mainly about clarifying Contract, not contracts, I would suggest renaming it to Clarify contract.)

[jpmckinney]

This value concerns the entire framework agreement, not just this supplier.

I think in all cases when we say "value of the framework agreement" we mean "…, as a whole". I've added that in the PR.

[jpmckinney]

I have renamed the issue to use "Contract" – though GItHub issues have no normative weight.

[jpmckinney]

I believe this is closed by #1208. #1358 is opened as follow-up. Thank you for the great work!