Remove note from mapping for BT-157-LotsGroup once new SDK is released

[odscjen]

The upgrade to 1.3.0 has introduced BT-1118, the OverallApproximateFrameworkContractsAmount. This now sits in the same parent field as BT-118, the OverallMaximumFrameworkContractAmount. Based on the example xml can_24_maximal.xml both of these values can exist in the same notice and can be different values.

We'd mapped BT-118 to techniques.frameworkAgreement.value. The definition of value in this extension is "The total upper estimated value of the framework agreement.". The use of "upper" here could be read as a synonym for "Maximum", but the use of "estimated" can be read as a synonym for "Approximate".

Regardless if we want both values to be retained in OCDS we'll need a new field. Either .estimatedValue which BT-1118 will map to leaving .value for BT-118. Or .maximumValue which BT-118 will map to leaving .value for BT-1118. @jpmckinney any preference?

[odscjen]

The same will apply to BT-156: GroupFrameworkMaximumValueAmount and BT-1561: GroupFrameworkReestimatedValueAmount the former of which is currently mapped to lotGroups.techniques.frameworkAgreement.value

[jpmckinney]

In OCDS 1.2 we resolved these issues by introducing maximumValue at tender, awards and contracts, and estimatedValue at awards and contracts. tender/value is for estimated. Awards and contracts value is for actual value. open-contracting/standard#1208

[odscjen]

Great, so as these will be in tender.techniques.frameworkAgreement and tender.lotGroups.techniques.frameworkAgreement BT-118 and BT-156 will be maximumValue and BT-1118 and BT-1561 will be value.

Looking at this again these fields all appear in the Notice Result section so they only appear once an award has happened. The pre-award/tender version of BT-156 is BT-157 (Group Framework Estimated Maximum Value) and for BT-118 it's BT-271 (Framework Maximum Value). So BT-157 and BT-271 should have the tender values.

• BT-157 -> tender.LotGroups.techniques.frameworkAgreement.value.
• BT-271-Lot -> tender.lot.techniques.frameworkAgreement.maximumValue.
• BT-271-LotGroups -> tender.lotGroups.techniques.frameworkAgreement.maximumValue.
• BT-271-Procedure -> tender.techniques.frameworkAgreement.maximumValue.

The 4 that appear in Notice Result are another example of aggregated values, like BT-161 which we've discarded, so should these 4 just be discarded too?

A complication is that the Framework values (BT-118, BT-1118, BT-156, BT-1561) that appear in the Notice Result can all be withheld from publication, which the Framework Values (BT-157, BT-271) in cac:TenderingProcess can't.

[jpmckinney]

It looks like these (plus BT-161-NoticeResult and some currency and ID fields) are the only NoticeResult fields (along with their withheld publication fields). I'm not entirely sure why they exist in eForms. Let's assume for now that they can be derived from BT-660-LotResult and BT-709-LotResult.

[odscjen]

guidance.yaml has been updated so I'm closing this issue

[jpmckinney]

Moving discussion from https://github.com/open-contracting-extensions/ocds_techniques_extension/pull/8/files#r1213391693

Ok, so I think:

• BT-27-LotsGroup: Is fine as-is. (LotGroup doesn't have a value field, and in any case the eForms field uses the words "over its whole duration, including options and renewals", which implies "maximum", per its note on BT-157 "Maximum value means a value covering all contracts to be awarded within a framework agreement over its whole duration, including options and renewals.").

• All 3 BT-271: Should map to techniques.frameworkAgreement.value, not techniques.frameworkAgreement.maximumValue. (The value field already has the semantics "The total upper estimated value of the framework agreement", and is otherwise not mapped to.)

• BT-157-LotsGroup: Honestly, I don't see how these two things differ:

  BT-271-LotsGroup: The maximum value of the framework agreement for the procurement procedure or lot, over its whole duration, including options and renewals. This value covers all contracts to be awarded within the framework agreement.

  BT-157-LotsGroup: The maximum value which may be spent in a framework agreement within a group of lots. This information can be provided when the maximum value of a group of lots is lower than the sum of maximum values of individual lots in this group (e.g. when the same budget is shared for several lots). Maximum value means a value covering all contracts to be awarded within a framework agreement over its whole duration, including options and renewals.

  In the regulation, there is no decomposition of BT-271 into Procedure, Lot, LotGroup. As such, I think the decomposition by the eForms schema authors has caused a duplication with BT-157. So, I recommend changing the guidance to:

  The authors of the eForms SDK decomposed the BT-271 business term into fields for the [procedure](#BT-271-Procedure), [lot](#BT-271-Lot) and [lot group]((#BT-271-LotsGroup). However, the authors of the eForms regulation had already anticipated the need to specialize the BT-271 business term for lot groups, creating this business term (BT-157).
  
  As such, this data element is duplicated in the eForms SDK. The OCDS mapping therefore discards BT-157-LotsGroup. If your data has different values for BT-271-LotsGroup and BT-157-LotsGroup, please contact the [OCDS Data Support Team](mailto:data@open-contracting.org).

[jpmckinney]

I created this issue on the eForms SDK: OP-TED/eForms-SDK#523

[odscjen]

That all sounds good, I've updated the guidance.yaml accordingly. So this means that we don't need to add maximumValue to the techniques extension afterall @duncandewhurst

[jpmckinney]

The linked eForms-SDK issue has been updated, and the issue we identified will be addressed in 1.10 (currently were 1.7).

[duncandewhurst]

I've updated the title to reflect what remains to be done here. Obviously, we'll check that the issue is actually addressed in SDK 1.10!

[jpmckinney]

Just a note that it is not in 1.10. Edit: Or 1.11.