lots: No place to state the awarded value of the lot

[jpmckinney]

An award can be made for multiple lots (hence Award.relatedLots).

However, it is not possible to disclose the awarded value of individual lots.

[odscjen]

The new UK regulations mean they will need to disclose this at both the award and contract stages.

They also plan on publishing details of bids so in the situation where the awarded value of the lot is just the value of the successful bid this information is contained in bids.details with bids.details.relatedLots and awards.relatedBids providing the links. This however is a) a very convoluted way for a user to work out the value of the awarded lot and b) only works if the final awarded value is the same as the value of the bid (which is not always going to be the case).

Adding a new field to Award e.g. lotValue doesn't work as the linking to the lot is an array for all lots, so that would imply the same awarded value for all lots in relatedLots.

There could be a new object with both the lot value AND a reference to the lot id, e.g.

{
  "awards": [
    {
      "id": "1",
      "awardedLotValues": [
        {
          "lotID": "lot-1",
          "value": {
            "amount": 10,
            "currency": "USD"
          }
        }
      ],
      "relatedLots": [
        "lot-1"
      ]
    }
  ]
}

I considered a more general name for awardedLotValues, e.g. awardedLots but that then begs the question, why is it only the value that's being separately declared for each lot covered by the award? Is the user supposed to just assume that all other award fields are the same for every lot mentioned in relatedLots? On the other hand if we did use a more general name it would open up the possibility to separate that data out if it was useful?

Or as mentioned in open-contracting/standard#790 (comment) we could just add the entire lot object to Award making it clear that the lot.id must match a lot.id in tender.lots (similar to how the value of contracts.awardID must match a value in awards.id). If we went with this option then is there even a need for relatedLots` anymore? If there was no additional information to add or changes to the lot between tender and award then the publisher could still use the lot objects but only include the id, eg.

{
  "awards": [
    {
      "id": "1",
      "lots": [
        {
          "id": "lot-1"
        }
      ]
    }
  ]
}

TLDR: should we add lots to Award? If so should we deprecate relatedLots or would that be too complicated? @jpmckinney

fyi @Ben-Hickling

[jpmckinney]

@odscjen Remind me why we can't create one Award object for each awarded lot? I forget if this was discussed somewhere.

Edit: This might be the discussion I was thinking of (where we discuss whether we can have one bid per lot): #138

[jpmckinney]

only works if the final awarded value is the same as the value of the bid (which is not always going to be the case)

Is this known to be true in the UK?

a very convoluted way for a user to work out the value of the awarded lot

This is a single lookup, and it's not terribly difficult (compared to eForms, where a whole series of lookups is needed).

[odscjen]

Is this known to be true in the UK?

Unclear, I'll ask

This is a single lookup, and it's not terribly difficult (compared to eForms, where a whole series of lookups is needed).

Yes I was probably overstating the case there and thinking of the laziest possible analyst :)

Re a previous discussion about 1 award per lot I don't remember such a discussion other than the bids one you've linked to. The problem with having a single award per lot would come when linking the awards to contracts, and an award that was for multiple lots leading to just a single contract which would then be unmodellable in OCDS due to the 1:1 linkages between awards and contracts.

[jpmckinney]

Ah, yes, that brings up open-contracting/standard#790 (comment)

The most common unit of analysis for contracting data is "per lot". Aggregating multiple lot-awards into a single award makes that difficult. I think the appropriate model is to have one award per lot (this also matches the reality described in the linked issues), and then to allow a contract to relate to multiple awards – because we want to ease analysis, and because since we want the number of contracts in OCDS to match the number of contracts in the real world. (We are less fussed about counting the number of "awards", since awards aren't as concrete – there isn't a legal instrument like a contract document, etc.)

My recommendation for the UK would be to implement a contracts.awardIDs array as an extension. If there is a single related award, they should populate both awardID and awardIDs. If there are multiple related awards, they should populate only awardIDs. I'm not sure this change is doable in a minor release, as connecting stages of a contracting process is quite fundamental.