Top level complaints container

[myroslav]

Extension offers adding complaints both to Tender and to Award objects. Having seen the case of Bids extension and the fact that Complaint can relate to different procurement process stages (tendering, awarding, pre-qualification), top-level container can be desirable with attributes like relatedLots, relatedAwards, etc. to make elements of that collection to reference specific elements of procurement process.

[duncandewhurst]

Adding complaints at release level seems likely to be the option that will work for the broadest range of publishers (it is already used this way in Belarus draft data)

[sorenabell]

Could you give us an example of the complaints block in the structure of release? We didn't find this use case in Belarus sources.

[jpmckinney]

Here's an example of release-level complaints from a Belarus sample we received:

{
  "complaints": [
    {
      "id": "12-6449",
      "status": "resolved",
      "reviewPlace": "г.Минск, ул.Кирова, 8/1, каб. 403, зал коллегий",
      "resolution": "продолжить процедуру закупки в соответствии с законодательством о государственных закупках.",
      "reviewDate": "2016-01-14T12:00:00+03:00",
      "documents": [
        {
          "id": "0-complaint-resolved",
          "datePublished": "2016-01-14T12:00:00+03:00",
          "documentType": "complaintResolve",
          "title": "protokol-4-ot-14.01.2016(1453225626).pdf"
        },
        {
          "id": "0-complaint-received",
          "datePublished": "2016-01-06T17:11:41+03:00",
          "documentType": "complaintRequest",
          "title": "12-6449(1452004446).pdf"
        }
      ],
      "datePublished": "2015-12-31T00:00:00+03:00",
      "type": "complaint",
      "author": {
        "id": "BY-UNP-101213657",
        "name": "ЗАО \"БЕЛХАРД ГРУПП\""
      }
    }
  ]
}

[jpmckinney]

What things can the complaints be about? And can a single complaint be about different things at the same time?

If they can be about different things at the same time, then it definitely makes sense to be top-level, and for it to have fields to relate to each of the things it's about.

If, on the other hand, complaints tend to be about only one thing (e.g. an award), then it might make more sense for the complaints to appear in the context of that thing.

I haven't read it yet, but @JachymHercher shared a study of EU complaint data, which might help decide this issue: https://github.com/open-contracting/standard/issues/205#issuecomment-463744967

[duncandewhurst]

Feedback from Belarus was that complaints "could be about any stage of the contracting process" but that no structured data was available on which stage they related to, so they were associated with the contracting process as a whole, hence the top level complaints container.

From a flattening perspective, having a complaints array at the top level, rather than nesting in both tender and another array (awards) would result in fewer tables, as well as allowing flexibility for complaints which could relate to another stage.

[jpmckinney]

The Belarus case is informative, but it seems like it's motivated by data quality issues in their source systems. If such issues are common across publishers, then top-level would make sense; if other publishers can relate complaints to specific stages, then it might not.

We have documents, milestones, items, etc. repeated in different parts of OCDS. That's because it's a more common use case to want to get the tender documents, or one contract's documents, than to get all documents about everything. With complaints, I suspect that it's a more common use case to want to get all complaints about one award, for example, than to want to get all complaints about everything. We can do more research to confirm, but if that's the case, then complaints should be nested.

The number of tables that flattening produces is not a primary concern. The other concerns above would take priority.