BT-142 Winner Chosen not in EF25, EF26, EF27 and EF28 but schematrons checks in these forms on this field

[kletersteegp]

BT-142 Winner Chosen not in EF25, EF26, EF27 and EF28 but schematrons checks in these forms on this field

There are a number of schematrons that check the framework agreement and the values of the framework agreement. These checks use also BT-142 (selec-w value). But BT-142 will never be in EF25, EF26, EF27 and EF28. Because BT-142 is not defined in the notice type of these forms.

These rules make it now impossible for us to publish VEAT forms for framework agreements.

Example schematron rules for EF25 (but there are also that kind of rules in EF26, EF27, EF28.

	<assert id="BR-BT-01118-0032" role="ERROR" diagnostics="BT-1118-NoticeResult" test="count(efbc:OverallApproximateFrameworkContractsAmount) = 0 or not(not(efac:LotResult/cbc:TenderResultCode[../efac:TenderLot/cbc:ID/normalize-space(text()) = ../../../../../../../cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID[../cac:TenderingProcess/cac:ContractingSystem[cbc:ContractingSystemTypeCode/@listName='framework-agreement']/cbc:ContractingSystemTypeCode/normalize-space(text()) = ('fa-mix','fa-w-rc','fa-wo-rc')]/normalize-space(text())]/normalize-space(text()) = 'selec-w') or (not(efac:LotResult/efac:FrameworkAgreementValues/efbc:ReestimatedValueAmount)))">rule|text|BR-BT-01118-0032</assert>

	<assert id="BR-BT-00660-0032" role="ERROR" diagnostics="BT-660-LotResult" test="count(efbc:ReestimatedValueAmount) = 0 or not((../efac:TenderLot/cbc:ID/normalize-space(text()) = ../../../../../../../cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID[not(../cac:TenderingProcess/cac:ContractingSystem[cbc:ContractingSystemTypeCode/@listName='framework-agreement']/cbc:ContractingSystemTypeCode/normalize-space(text()) = ('fa-mix','fa-w-rc','fa-wo-rc'))]/normalize-space(text())) or not(../cbc:TenderResultCode/normalize-space(text()) = 'selec-w'))">rule|text|BR-BT-00660-0032</assert>

	<assert id="BR-BT-00709-0032" role="ERROR" diagnostics="BT-709-LotResult" test="count(cbc:MaximumValueAmount) = 0 or not((../efac:TenderLot/cbc:ID/normalize-space(text()) = ../../../../../../../cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID[not(../cac:TenderingProcess/cac:ContractingSystem[cbc:ContractingSystemTypeCode/@listName='framework-agreement']/cbc:ContractingSystemTypeCode/normalize-space(text()) = ('fa-mix','fa-w-rc','fa-wo-rc'))]/normalize-space(text())) or not(../cbc:TenderResultCode/normalize-space(text()) = 'selec-w'))">rule|text|BR-BT-00709-0032</assert>

[YvesJo]

Hi,
Thanks for reporting that concern.
We will correct in SDK 1.11 these conditional rules that prevent reporting other fields.
This shall also get backported in previous versions

[kletersteegp]

Thanks for your answer. Will SDK1.11 be there soon? And when will it be backported to SDK1.10? Because this prevents us now to go live with SDK1.10?

[YvesJo]

Please get in touch with the helpdesk for foreseen release dates: [email protected]

[kletersteegp]

Hello, we are testing nog SDK1.10.2

Only the first of the trhee mentioned schematron rules was backported to SDK1.10.2. All 3 schematrons were fixed in SDK1.11.
But we are implementing SDK1.10.2

These 2 are still not correct in SDK1.10.2 because they are dependent on selec-w which is not a field in the VEAT forms (for example form 25).

	<assert id="BR-BT-00660-0032" role="ERROR" diagnostics="BT-660-LotResult" test="count(efbc:ReestimatedValueAmount) = 0 or not((../efac:TenderLot/cbc:ID/normalize-space(text()) = ../../../../../../../cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID[not(../cac:TenderingProcess/cac:ContractingSystem[cbc:ContractingSystemTypeCode/@listName='framework-agreement']/cbc:ContractingSystemTypeCode/normalize-space(text()) = ('fa-mix','fa-w-rc','fa-wo-rc'))]/normalize-space(text())) or not(../cbc:TenderResultCode/normalize-space(text()) = 'selec-w'))">rule|text|BR-BT-00660-0032</assert>

	<assert id="BR-BT-00709-0032" role="ERROR" diagnostics="BT-709-LotResult" test="count(cbc:MaximumValueAmount) = 0 or not((../efac:TenderLot/cbc:ID/normalize-space(text()) = ../../../../../../../cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cbc:ID[not(../cac:TenderingProcess/cac:ContractingSystem[cbc:ContractingSystemTypeCode/@listName='framework-agreement']/cbc:ContractingSystemTypeCode/normalize-space(text()) = ('fa-mix','fa-w-rc','fa-wo-rc'))]/normalize-space(text())) or not(../cbc:TenderResultCode/normalize-space(text()) = 'selec-w'))">rule|text|BR-BT-00709-0032</assert>

Is it possible to fix this in a 1.10 version?

[YvesJo]

Thanks for reporting this concern. We'll consider this.

[Colan71]

Hi,
We are experiencing the same issue and our users are getting stuck in the validation due to the incorrect rules. We expect you to fix this for version 1.10 as well.
Thank you!

[bertrand-lorentz]

From what I can see, the remaining problems mentionned here were corrected in SDK 1.10.3, released on 18/06/2024: https://github.com/OP-TED/eForms-SDK/releases/tag/1.10.3

This version is in place in the Central Validation Service since that date, so you should not encounter them anymore if you try to submit a notice using SDK 1.10.