Conditional mandatory fields

[skyazid]

Hello,

My question concerns specifically subtypes 16, 29 and 38.

By examining the fields.json file in the SDK, I found that the following fields are optional (neither mandatory nor forbidden):

• BT-01(c)-Procedure
• BT-01(e)-Procedure
• BT-09(a)-Procedure
• OPT-111-Lot-FiscalLegis
• OPT-112-Lot-EnvironLegis
• OPT-113-Lot-EmployLegis

However, based on your previous discussions, I understand that these fields can become conditionally mandatory if certain related fields are present. Here’s what I have identified so far:

• BT-01(d)-Procedure → if present, then BT-01(c)-Procedure becomes mandatory

• BT-01(f)-Procedure → if present, then BT-01(e)-Procedure becomes mandatory

• BT-09(b)-Procedure → if present, then BT-09(a)-Procedure becomes mandatory

  Source: Discussion #1202

• OPT-301-Lot-FiscalLegis or OPT-110-Lot-FiscalLegis → if present, OPT-111-Lot-FiscalLegis becomes mandatory
  Source: Discussion #903

• OPT-301-Lot-EnvironLegis or OPT-120-Lot-EnvironLegis → if present, OPT-112-Lot-EnvironLegis becomes mandatory

• OPT-301-Lot-EmployLegis or OPT-130-Lot-EmployLegis → if present, OPT-113-Lot-EmployLegis becomes mandatory

Could you please confirm these rules and let me know if there are any other fields with this type of “conditional mandatory” behavior that I should be aware of?

Thank you very much for your help!

[douret]

Can we have a feedback quickly?

[YvesJo]

Hi,
These are typically identifiers (cbc:ID elements) that are required as soon as their XML parent element exists to satisfy the UBL XSD requirement; these elements should then be included in the generated XML when information already exists under the XML parent.
For most cases, cbc:ID is associated to technical identifiers that are required and processed a bit differently, also I can't identify an additional field that would behave a same way the ones you've already listed.
KR

[YvesJo]

• BT-01(c)-Procedure
• BT-01(e)-Procedure
• BT-09(a)-Procedure

Are cbc:ID elements respectively associated with

• BT-01(d)-Procedure
• BT-01(f)-Procedure
• BT-09(b)-Procedure

Some illustrations may be found at https://docs.ted.europa.eu/eforms/latest/schema/all-in-one.html#crossBorderLawSection and following section.

In absence of the cbc:ID element in the XML, it would be impossible to differentiate between BT-01(d)-Procedure, BT-01(f)-Procedure and BT-09(b)-Procedure:

<cac:ProcurementLegislationDocumentReference>
    <cbc:DocumentDescription languageID="ENG">Directive XYZ applies ...</cbc:DocumentDescription>
    <cbc:DocumentDescription languageID="FRA">La directive XYZ ...</cbc:DocumentDescription>
</cac:ProcurementLegislationDocumentReference>

This is also obvious when looking at the predicate associated to the parent node:

BT-01(d)-Procedure	/*/cac:TenderingTerms/cac:ProcurementLegislationDocumentReference[not(cbc:ID/text()=('CrossBorderLaw','LocalLegalBasis'))]/cbc:DocumentDescription
BT-01(f)-Procedure	/*/cac:TenderingTerms/cac:ProcurementLegislationDocumentReference[cbc:ID/text()='LocalLegalBasis']/cbc:DocumentDescription
BT-09(b)-Procedure	/*/cac:TenderingTerms/cac:ProcurementLegislationDocumentReference[cbc:ID/text()='CrossBorderLaw']/cbc:DocumentDescription