Bids: Allow individual bids to express the value per lot

[odscrachel]

It would be good to add a field to the bids object to allow values to be added that relate to individual bids on individual lots or bid details added to the lots extension. We have seen a publisher adding a lotValues field that sits under /records/releases/bids/details.

               "lotValues": [
                                    {
                                        "lotID": "lot-1",
                                        "value": {
                                            "amount": 16940.0,
                                            "currency": "JOD"
                                        }

[duncandewhurst]

Related issue: CRM-5973

Comment from @jpmckinney:

I think their model is essentially correct. We might just want to change the nesting and field names – and consider if there is other lot-specific information that publishers might want to disclose for each bid (which would change the model somewhat).

[duncandewhurst]

@jpmckinney in terms of nesting and field names, did you have any particular suggestions? I considered the following, but I'm unsure about lotBreakdown:

{
  "bids": {
    {
      "details": [
        {
          "lotBreakdown": [
            {
              "relatedLot": "1",
              "value": {
                "amount": 1000,
                "currency": "USD"
              }
            }
          ]
        }
      ]
    }
  }
}

In terms of other lot-specific information, asides from value the other candidates from Bid are date, status, tenderers and documents. I don't know whether these fields can vary per lot, but my sense is that if data, status and tenderers can vary per lot, then modelling a separate bid per lot would be preferable.

@JachymHercher might know more about what bid data can be lot-specific, or we might need to seek community input.

[duncandewhurst]

Noting that https://github.com/open-contracting/ocds-extensions/issues/126 discusses items per lot, which can be linked by Item.relatedLot.

[jpmckinney]

I think we need to collect more information on what these bids look like / what information is disclosed about them. I think from the CRM we only have evidence from one jurisdiction, which is not enough.

[JachymHercher]

In eForms, a bid (a "Tender" in EU terminology) is by default per lot. This has the major drawback of not corresponding to established use (which is to see a bid as a single document parts of which then apply to different lots), but on the other hand avoids a level of nesting.

In principle, any fields in Tender (BG-320) can differ per lot, see below. However, most of them are rather niche fields required by the EU legislation. The two fields that are important and universal are Tender Value and Tender Rank.

Level	ID	Name	Data type	Repeatable	Description
++	BG-320	Tender	-	Yes	Information about a tender. This information differs per lot. In cases such as design contests, some framework agreements and innovation partnerships, this information may also differ per organisation.
+++	BT-3201	Tender Identifier	Identifier	No	An identifier of a tender. The information in the tender section refers to this tender.
+++	BT-13714	Tender Lot Identifier	Identifier	No	An identifier of a lot or a group of lots for which the tender was submitted. The information in the tender section refers to this lot.
+++	BT-720	Tender Value	Value	No	The value of the tender or another result; including options and renewals. In case of the modification notice, the value of the modification.
+++	BT-171	Tender Rank	Number	No	The position of the tender (i.e. whether the tender ended up first, second, third, etc.) in a design contest, some framework agreements with multiple winners (e.g. cascades) a competitive dialogue or an innovation partnership.
+++	BT-162	Concession Revenue User	Value	No	The estimated revenue coming from the users of the concession (e.g. fees and fines).
+++	BT-160	Concession Revenue Buyer	Value	No	The estimated revenue coming from the buyer who granted the concession (e.g. prizes and payments).
+++	BT-163	Concession Value Description	Text	No	The description of the method used for calculating the estimated value of the concession and any other relevant information concerning the value of the concession.
+++	BT-193	Tender Variant	Indicator	No	The tender is a variant.
+++	BT-191	Country Origin	Code	Yes	A country of origin of the product or the service.
+++	BG-180	Subcontracting	-	No	Information regarding the parts of the contract that the contractor will subcontract to third parties.
++++	BT-773	Subcontracting	Code	No	Whether at least a part of the contract will be subcontracted.
++++	BT-730	Subcontracting Value Known	Indicator	No	The buyer knows at least the estimated value of the part of the contract that the contractor will subcontract to third parties.
++++	BT-553	Subcontracting Value	Value	No	The estimated value of the part of the contract that the contractor will subcontract to third parties.
++++	BT-731	Subcontracting Percentage Known	Indicator	No	The buyer knows at least the estimated percentage of the contract that the contractor will subcontract to third parties compared to the whole contract.
++++	BT-555	Subcontracting Percentage	Number	No	The estimated percentage of the contract that the contractor will subcontract to third parties compared to the whole contract.
++++	BT-554	Subcontracting Description	Text	No	The description of the part of the contract that the contractor will subcontract to third parties.

[duncandewhurst]

Thanks, @JachymHercher!

[duncandewhurst]

Noting that OCDS for eForms models each LotTender (the results of the decomposition of a received tender into fragments, each corresponding to a lot or group of lots) as a Bid object, rather than having a single Bid object with a breakdown by lot. We might want to document that approach in the bid extension's documentation.

[odscjen]

So this discussion seems to be leading to not making any changes to the Bids extension schema (quite a few have already been made since this issue was opened to account for eforms) but instead to just add some additional guidance to the extension documentation.

Suggested change to the Bids documentation, add a section under Guidance

Bids covering multiple lots

In some jurisdictions bidders can submit a single bid that covers multiple lots. Publishers should use the details.relatedLots field to record the identifier(s) of the lot(s) the bid relates to. If any of the bid details differ between lots a separate Bid object should be created for each lot. The details.identifiers field can be used to record the original bid identifier.

And add an additional example

Examples

A bidder submits a single bid for two individual lots in a contracting process. The value of the bid for each lot is different.

{
  "bids": [
    {
      "id": "1",
      "date": "2016-12-09T01:00:00+01:00",
      "identifiers": [
        {
          "id": "ABC-1350",
          "scheme": "internal"
        }
      ],
      "value": {
        "amount": 1000,
        "currency": "USD"
      },
      "relatedLots": [
        "LOT-0001"
      ]
    },
    {
      "id": "2",
      "date": "2016-12-09T01:00:00+01:00",
      "identifiers": [
        {
          "id": "ABC-1350",
          "scheme": "internal"
        }
      ],
      "value": {
        "amount": 500,
        "currency": "USD"
      },
      "relatedLots": [
        "LOT-0002"
      ]
    }
  ]
}

[odscjen]

@jpmckinney what do you think of the above suggested change to the Bid documentation?

[jpmckinney]

I think we should always favor dividing bids into lots, unless it's not possible.

---

Bids submitted for multiple lots

In some cases, potential suppliers can submit bids for multiple lots. Regardless of whether the bids take the form of a single document or multiple documents, OCDS models the "bid" for each lot as a separate object, to improve interoperability.

If a potential supplier submits a bid for multiple lots as a single document, for each lot, add a Bid object to the bids.details array. Set the object's .identifiers to the bid's identifier, and add the lot's identifier to the object's .relatedLots.

If the bid cannot be divided (for example, the data source describes only the total value of the bid, and not the individual value for each lot within the bid), create one Bid object, and add all lots' identifiers to the object's .relatedLots.

---

Just a sidenote that Bid.relatedLots (plural) has existed since the first commit to the Lots extension. With the benefit of this conversation, it would have made sense to make in singular. That said, if a system has metadata about a whole bid but not its decomposition into individual lot values, etc. then perhaps it's still useful to have it plural, to allow such cases to be published.

[odscjen]

OK great, yes I think it makes sense to leave .relatedLots as the plural to allow for the cases where decomposition might not be possible. I'll get started on a PR for this.