Distinguishing between framework agreements and other types of contract

[duncandewhurst]

The EU contract award notice (form F03 in TED) includes a field to indicate whether an award relates to a supplier joining a framework (when the value of the award should be interpreted as total potential spend on the framework) or not (when the value of the award should be interpreted as the actual amount of a purchase from the supplier).

There isn't currently a mapping for this field in the EU profile (see open-contracting-extensions/european-union#31) however since this information is important for users to understand how to interpret award values and since frameworks are used outside the EU context we should consider including this as a core extension to OCDS.

[jpmckinney]

Related: #750

[duncandewhurst]

The French legislation which defines the format in which open contracting data should be published includes the following field relevant to this issue:

Field (FR)	Field (EN)	Codelist (FR)	Codelist (EN)
Nature du marché	Nature of contract	Marché, Marché de partenariat, Accord-cadre, Marché subséquent	Contract, Partnership contract, Framework agreement, Subsequent contract

Looking at definitions for the less familiar codelist terms:

Marché de partenariat / Partnership contract
According to wikipedia these are public private partnership contracts.

Marché subséquent / Subsequent contract
These appear to be purchases from framework contracts, which may involve a mini-competition between suppliers on the framework or may take the form of a purchase order for a specific supplier (source)

[jpmckinney]

In the EU, the proposal is to have a boolean to indicate that "The contract is awarded within a framework agreement". This would be for call-offs, mini-competitions, etc. It can also be used in the cases of:

• purchase orders (to distinguish actual delivery of goods from a contract setting up the relationship)
• dynamic purchasing systems / electronic catalogues Discussion: Electronic catalogues #396 (to distinguish actual purchases from the contract setting up the system / catalogue)

(At least according to Wikipedia, the acceptance of a purchase order forms a contract.)

In the EU, there is a contract award notice for the framework agreement, and then contract award notices for any contracts within the framework agreement. These are all considered to be part of the same contracting process (they have the same procedure identifier). In OCDS, with this boolean, we can include a Contract object for both the initial contract (setting up the framework agreement, DPS, etc.) in the contracts array, to disambiguate it from the contracts that follow from it (call-offs, catalog purchases, etc.).

[jpmckinney]

We now have a Techniques extension. It has a pattern of pairs of hasConcept and concept fields, as some procurements indicate the use of a technique without any detail on the technique.

In the current EU mapping, tender.techniques.hasFrameworkAgreement is set when the procurement involves the set up of a framework agreement. However, in a compiled release, there would be no way to distinguish the award that sets up the framework agreement from the call-offs. We'd need another field on the Award, either matching BT-768 Contract Framework Agreement ("The contract is awarded within a framework agreement") from eForms, or matching its inverse ("This establishes a framework agreement").

cc @ColinMaudry

Note that this issue intersects with #909, where the idea was not to model the establishment of a multi-use list as an award, if possible. Although I haven't confirmed with real TED data, it looks like the EU discloses the establishment of a framework agreement as an 'award' (with many details that are relevant to awards and/or contracts). For OCDS 1.1 anyway, we will continue that pattern.

[ColinMaudry]

We'd need another field on the Award, either matching BT-768 Contract Framework Agreement ("The contract is awarded within a framework agreement") from eForms, or matching its inverse ("This establishes a framework agreement").

I believe we would make the data analysis easier if we added both "The contract is awarded within a framework agreement" and its inverse "This establishes a framework agreement".

[jpmckinney]

Yes, even better.

[jpmckinney]

For OCDS 1.1, we don't have a mechanism to disclose the details of the competition at the second stage, so we'd need to (mixing a few other concerns not directly relevant to this issue):

1. To distinguish the setup from its call-offs, we use relatedProcesses with a 'framework' code as currently documented
2. To distinguish a process involving the setup of an FA from other processes, we can use the techniques extension
3. To distinguish a direct call-off from a mini-competition, the difference would be implicit based on the presence of tender.tenderers or tender.numberOfTenderers

[jpmckinney]

For (1), looking ahead to OCDS 2.0 (where the set-up contract and call-offs will be in the same procedure), we need to ensure that we can still model the lifecycle of the set-up contract.

[ColinMaudry]

Does (1) definitely solve

in a compiled release, there would be no way to distinguish the award that sets up the framework agreement from the call-offs.

?

[jpmckinney]

@ColinMaudry: In the contracting process that sets up the FA, there's be no object in the relatedProcesses array that has a relationship of 'framework'.

[yolile]

To distinguish a direct call-off from a mini-competition, the difference would be implicit based on the presence of tender.tenderers or tender.numberOfTenderers

As discussed in CRM-4122, if this data isn't available an explicit field to distinguish the direct call-off from a mini-competition would be better, an extension for that is drafted here https://github.com/open-contracting-extensions/ocds_competitive_extension

[yolile]

is this already covered by #1123 ?

[jpmckinney]

I still have to review #1123, but I think so.

I'll limit the scope of this issue to OCDS 1.1. We aren't solving this in OCDS 1.2, and in OCDS 1.3/2.0 we will remember to support the same use cases as OCDS 1.1, so the issue doesn't need to remain open once #1123 is closed.