BT-806, BT-821: exclusion grounds and selection criteria sources

[odscjen]

New fields added as part of SDK 1.12.0 (see https://github.com/open-contracting/european-union-support/issues/215)

BT-806-Procedure Exclusion Grounds Source: Where the exclusions grounds are defined, for example, the procurement documents or in ESPD.

BT-821-Lot Selection Criteria Source: Where the selection criteria are defined, for example, the procurement documents or in ESPD

These are very similar in that they are both just saying where the details of the grounds/criteria are taken from. There's already a Sources extension which defines a sources array but I don't think it's appropriate for use here as it defines sources as

The information systems from which the data originates.

And for these BT's it's not an information system that's being referenced but a document. (maybe a document could be considered an information system??)

The other ways these BT's are similar are:

1. they're both repeatable
2. they're not associated with any one specific ground/criteria but instead appear in a separate block before the block that lists all the grounds/criteria
3. their codelists also use the same 3 codes, although the codelists only seem to exist as bullet points in the docs rather than as .gc files which is frustrating. The three possible codes are:
   • the Procurement Documents (epo-procurement-document),
   • the Notice (epo-notice),
   • the ESPD (epo-sub-espd).

So I think it makes sense to model them both in the same way within exclusionGrounds and selectionCriteria respectively. This could either be an array of Classification objects with the code as id, the scheme as "eu-exclusion-grounds-source" or "eu-selection-criteria-source" and the titles in the above bullet list as the description.

E.g.

{
  "tender": {
    "exclusionGrounds": {
      "sources": [
        {
          "id": "epo-procurement-document",
          "scheme": "eu-exclusion-grounds-source",
          "description": "Procurement documents"
        }
      ]
    }
  }
}

Or this is possibly over complicating it and it would maybe be simpler to just use the titles as entries in an array of strings. E.g.

{
  "tender": {
    "exclusionGrounds": {
      "sources": [
        "Procurement documents"
      ]
    }
  }
}

But the issue there is that without actual codelists to refer to how to ensure people always use the same title?

@jpmckinney @duncandewhurst thoughts?

[jpmckinney]

I think the annex spreadsheet here https://ec.europa.eu/docsroom/documents/52697 hasn't been updated with the new BTs mentioned at https://eur-lex.europa.eu/eli/reg_impl/2023/2884/oj (Both of those are linked from https://single-market-economy.ec.europa.eu/single-market/public-procurement/digital-procurement/eforms_en). I added a check to the lint command, so we are reminded to manually copy over the missing Description and Business groups. I've added them now.

[jpmckinney]

I think the gc files are:

https://github.com/OP-TED/eForms-SDK/blob/develop/codelists/document-used-in-public-procurement_exclusion-grounds-source.gc

https://github.com/OP-TED/eForms-SDK/blob/develop/codelists/document-used-in-public-procurement_selection-criteria-source.gc

[jpmckinney]

Let's do a simple array of strings in the EU extension, constraining that array with a codelist (using the same codes as in eForms). I don't expect this field will be relevant outside the EU.

[jpmckinney]

I just remembered that this seems similar to the "Selection criteria as stated in the procurement documents" field from the old forms: https://standard.open-contracting.org/profiles/eu/latest/en/forms/F02/#section-iii

The description of BT-806 from the legislation is "Where the exclusions grounds are defined, for example, the procurement documents or in ESPD." I'm not sure if the words "Source" and "where [they] are defined" implies:

• "this is where to find them (and they are not in the present XML)", in which case maybe using documents is better, or
• "this is where they come from (and they are in the present XML)", in which case sources is still best, or
• "this is where to find more information (and brief information is in the present XML)", in which case maybe seeAlso is a better name, depending on what the differences between the two are

Without more clarity, we can keep the word sources for the field name, and reuse the same wording (minus the "for example") in the field description.