Invalid validation for GR-Lot-PlannedDuration > BT-36-Lot, start date is marked as a required field when the duration is used

[Fynnyan]

Hello

Since SDK version 1.8 there is an error in the validation for the lot cac:PlannedPeriod (Estimated duration - GR-Lot-PlannedDuration) when one uses the cbc:DurationMeasure (Duration - BT-36-Lot) instead of the start / end date.
The validation throws an error, the StartDate is a mandatory field when only the duration fields is set.

assertion id: BR-BT-00536-0075 - assert: count(cbc:StartDate) > 0 or (not(cbc:DurationMeasure) and not(cbc:EndDate)) 
xml location: /cn:ContractNotice/cac:ProcurementProjectLot/cac:ProcurementProject/cac:PlannedPeriod
severity: ERROR 
ruleId: rule|text|BR-BT-00536-0075
BT-536-Lot is mandatory in notice type '16' except under following condition: 'Duration' (BT-36-Lot) and 'End date' (BT-537-Lot) are not filled in

According the documentation / specification the duration and dates fields for the cac:PlannedPeriod are exclusive

Multiple exclusive ways exist to report the Procurement duration:

• indicating a code (for the special cases where duration is "unknown" or "unlimited"),
• Specifying the duration, or
• using start & end dates,

see: https://docs.ted.europa.eu/eforms/latest/schema/procedure-lot-part-information.html#plannedPeriodSection

So this validation is not in line to the described specification. When the cbc:DurationMeasure is set the cbc:StartDate is not to be set.

This results in a false positive as, according to the documentation, the cac:PlannedPeriod only with the cbc:DurationMeasure is a valid choice.
Also in this case the cbc:StartDate / cbc:EndDate should not be set.

Notice XML:

<ContractNotice>
    ...
    <cac:ProcurementProjectLot>
    ...
        <cac:ProcurementProject>
            <cac:PlannedPeriod>
                <cbc:DurationMeasure unitCode="DAY">120</cbc:DurationMeasure>
            </cac:PlannedPeriod>
        </cac:ProcurementProject>
    </cac:ProcurementProjectLot>
</ContractNotice>

example_contract_notice_for_bug.txt

SVRL for that part:

<svrl:failed-assert id="BR-BT-00536-0075" location="/cn:ContractNotice/cac:ProcurementProjectLot/cac:ProcurementProject/cac:PlannedPeriod" test="count(cbc:StartDate) > 0 or (not(cbc:DurationMeasure) and not(cbc:EndDate))" role="ERROR">
    <svrl:text>rule|text|BR-BT-00536-0075</svrl:text>
    <svrl:diagnostic-reference diagnostic="BT-536-Lot" see="field:BT-536-Lot">
      <svrl:text>cbc:StartDate</svrl:text>
    </svrl:diagnostic-reference>
  </svrl:failed-assert>

[YvesJo]

Hi,
There is no issue in there.
Providing the duration does not prevent to provide the start or end date, so long both fields aren't specified. Planned period may go beyond the only duration. The rules in place are based on a general discussion that took place during the Member States consultation and has been simplified; it is however still too complex to be illustrated in few words in the schema documentation.
Also be aware that some internal discussion are ongoing on the business side and these rules may get further simplified.

[Fynnyan]

You focused mainly on my second point about the exclusivity of the values. I understand but that was not my main point.

The main issue is, the mentioned validation rule prevents one to set only the duration for the planned period.
It makes a start date always mandatory in the two cases.

I noticed it for forms/notice-type 16, 17, 29, 30 but a quick glance at the rules show this assertion is in place for most forms.

When I create the notice with only the duration:

<cac:PlannedPeriod>
    <cbc:DurationMeasure unitCode="DAY">120</cbc:DurationMeasure>
</cac:PlannedPeriod>

The assertion for field BT-536-Lot

test="count(cbc:StartDate) > 0 or (not(cbc:DurationMeasure) and not(cbc:EndDate))"

makes the start date a mandatory field when using a duration.

In my example, it's assertion id BR-BT-00536-0075

So the notice will be Invalid, the error states that the start date must be set.

One should be able to set a known estimated duration without setting the start date as this may be depending the signing date of a contract.

p.s:

even in the eNotice2 GUI that exclusion of the values is mentioned:

[YvesJo]

Hi Thomas,
All the issues were addressed in my short answer. Following the consultation available information, the start date was required in some cases in addition to the duration for competition notices. Also at competition this date may only be understood as expected start date and not more, especially because at this stage it is not even sure that there will be a winner. On the contrary, after contract signature, Buyers and Contractors are legally bound. eForms is also there to address limitations and issues of the current solutions. Business people are currently reviewing these rules and we will see, on a case by case, whether the Start Date will remain mandatory, become additionally optional only (for buyers who would like to increase the probability of selection of the best offers, especially when start date is key) or just be forbidden. This will be addressed soon.

[Fynnyan]

OK, so my takeaway is we will omit this information as expected / documented behavior is different as the actual implementation and still subject to change.

Can you point me in to the direction where we can find the documentation for these complex rules.

For the technical implementation I was following the "Ted Developer Docs" that contain the "eForms Schema Documentation" and I was under the assumption that this documentation was comprehensive and up to date.

Thank you for your help.

[YvesJo]

Hi Thomas,
I agree the documentation may not be as complete as needed and this will get fixed.
It is not always possible to have all possible cases covered by the documentation and some corner cases we consider not worth documenting (either because they appear to be related to some business logic or because they may seem obvious) may in fact require more attention and this is why your feedback is important to us as It helps detect the documentation sections that actually need to be further detailed.
Also note that some business rules may be stated in the documentation and not find their counterpart in the implementation as their implementation is dependent from the solution capabilities; the approach that consists on looking at the Developer and the schema documentation in addition to the artefacts of the SDK is a good way to get the widest overview.
The rules on Duration fields are currently exclusively documented in the schematron files. Documentation on Duration related fields will get more specific and rules will be updated as soon as the business Decision will be made.