-
Notifications
You must be signed in to change notification settings - Fork 40
Notice type 16: BT-33-Procedure is both mandatory and forbidden when there is only one lot #1360
SDK version
We are currently using eForms-SDK 1.13.2.
Summary
While validating a notice of type 16 with only one lot, we found an apparent inconsistency in fields/fields.json for:
BT-31-ProcedureBT-33-Procedure
The issue is especially visible for BT-33-Procedure.
What we observed
For a notice type 16 with exactly 1 lot:
- our local field-based validation reports
BT-31-ProcedureandBT-33-Procedureas missing; - if we populate them with value
1, TED Schematron validation fails because those fields are not allowed when there are not multiple lots.
Relevant rules in fields.json
For BT-33-Procedure:
- it is marked as
mandatoryfor notice type16; - it is also marked as
forbiddenwhencount(/BT-137-Lot) < 2.
This seems to create a contradiction for single-lot notice type 16.
For BT-31-Procedure, the metadata appears more conditional, because mandatory depends on count(/BT-137-Lot) > 1, so the main concern is really BT-33-Procedure.
Why this looks inconsistent
For a single-lot notice:
BT-33-Procedureshould not be present according to the Schematron/business rule logic;- but in
fields.jsonit is still marked as mandatory for notice type16.
This makes it impossible to satisfy both interpretations at the same time.
Expected behavior
For notice type 16 with only one lot, BT-33-Procedure should probably be:
- not mandatory, or
- treated as not applicable / forbidden consistently across metadata and Schematron rules.
Question
Is this an issue in fields.json for notice type 16, or is this intentional and expected to be handled by consumers with additional conditional logic?
If it is already fixed in a newer SDK version, could you point us to the relevant change?
Thanks.
All reactions
Hi,
Following analysis, I've converted the issue into a discussion as this is not a SDK issue
The conclusion following which there would be some contradiction results from a misinterpretation of the JSON file content.
Following the documentation:
The value of the forbidden property must take precedence over the value the mandatory property. If a field is forbidden, then it should not be present in the notice regardless of the value of its mandatory property. You should always check first if a field is forbidden or not. Then, consider whether the field is mandatory or optional only if the field is not forbidden. (cf. https://docs.ted.europa.eu/eforms/latest/fields/index.html )
In the cas...
Replies: 1 comment 1 reply
Hi,
Following analysis, I've converted the issue into a discussion as this is not a SDK issue
The conclusion following which there would be some contradiction results from a misinterpretation of the JSON file content.
Following the documentation:
The value of the forbidden property must take precedence over the value the mandatory property. If a field is forbidden, then it should not be present in the notice regardless of the value of its mandatory property. You should always check first if a field is forbidden or not. Then, consider whether the field is mandatory or optional only if the field is not forbidden. (cf. https://docs.ted.europa.eu/eforms/latest/fields/index.html )
In the case of BT-33-Procedure the Mandatory rule which does not have any additional condition is only to be considered when the field is not forbidden and in this case, when not forbidden, it is mandatory. If the two rules would have to be expressed independently, then the mandatory rule should have an associated expression with a condition that would be the contraposition of the condition associated to the forbidden rule.
An additional way to see the interpretation, is to have a look at the schematron files. BT-33-Procedure existence rule only exist in the stage 4 file, there is no stage 2 rule for it. Please note that the schematron files and json files are generated from the same source and express the same things different ways.
KR
All reactions
Thanks