Auctions (information about the phases of the auction)

[jpmckinney]

Context

There is another issue about the information that is communicated to potential bidders prior to the auction (#793). This issue is about publishing information about the phases of the auction itself, in which tenderers make submissions, e.g. reducing prices in each phase in the case of a reverse auction.

Discussion

In an auction, a tenderer can make multiple submissions (for the same lot). An original proposal was to model each submission as a 'bid'. A tenderer's newest bid/submission would have a status of 'valid' (assuming only tenderers that have submitted an initial admissible bid are invited to the auction), and its older bids/submissions would have a status of 'withdrawn'.

However, this might be incorrect, semantically. An alternative model is for bids to only contain the initial bids that the buyer uses to determine which tenderers to invite to the auction. The submissions within the auction would be modelled in another way, and can be organized by phase of the auction, with additional fields to e.g. communicate relative ranking in each phase. Each submission can be linked back to its initial bid. For reference, here is how electronic auctions are described in the EU Directive 2014/24/EU.

In many auctions, the only difference between a tenderer's submissions is the price. In other auctions, differences might also include "new values of the features of the tenders".

Proposal

I haven't prepared a specific proposal yet, but I think it makes more sense to model auction submissions separately from bids.

cc @yolile @PaulBoroday

[PaulBoroday]

That's a good point to not keep everything in one single array (bids). We have been working on eAuction extension for a long time and we came to the same conclusions. Our approach so far based on the distinction between initial bids, auction progress (from the bids' substance change perspective) and eAuction results. Its everywhere bids, but these arrays are different and serve for different purposes. Its really complex schema and i don't want to duplicate everything here but if you are curious about what we have - please take a look and i will be happy to discuss it

[jpmckinney]

Thanks, I hadn't seen that extension before (the last time I looked for new extensions to review was in March, so I should do another round soon).

It looks like a fairly comprehensive approach, though I have some initial feedback, that I'll need to take more time to organize and write up.

In the meantime, @yolile, can you have a look at the linked extension and see if it informs Paraguay's modelling for auctions?

[jpmckinney]

Also related: #440 (comment)

[yolile]

I hadn't seen that extension neither. I think that we can reuse some things but there are things that I dont understand well, as AuctionRoundsGroup, AuctionRound, ValueDifference, AuctionRoundProgress.

In Paraguay, an auction has a competition for the lowest price for each lot in the tender, and each auction can have four stages: submissions, bid, random and tie break periods.
To participate in the auction the tenderer must provide: A single guarantee to preserve the price of all the bids in case he wins
For each item the tender must provide: A proposal with the item’s specifications and an initial price for it

Available data:

• Guarantees presented by each tenderer (one for the whole bids)
  • Number
  • Type
  • Entity
  • Period
  • Issue date
• For each item and tenderer:
  • Requested Item id
  • Item attributes (as brand, procedence country, etc)
  • initial amount
• Auction period per each competition (lot):
  • Submissions period start and end date
  • Bid period start and end date
  • Random period start and end date
  • Tie break period start and end date
• Bids
  • Hash
  • date
  • amount
  • Tenderer

So, maybe we can use a model like:

• Auction
  • Period
  • Competitions []
  • Proposals []
• Proposal
  • Id
  • Tenderer
  • Guarantee -> requirementResponse
  • items
    • id
    • amount
    • atributtes
• Competition
  • relatedLot
  • Id
  • Period
  • stages []
  • result
• Stage
  • Id
  • Period
  • Bids []
• Result
  • Winner
  • amount

[duncandewhurst]

Thanks @yolile and @PaulBoroday - I reviewed your proposed extensions and models and it looks possible to find a model that works for both cases. It would be helpful to see some more examples first and I have a few questions I need to clarify:

• @yolile - Can you share an example of the auctions data that is currently published in PDF which shows an auction with more than one lot and with more than one item per lot? I want to see what is common between the different competitions that make up an auction, to determine if they can be modelled as separate auctions without too much repetition.

• @yolile - is the item information which appears in the PDFs already available in Paraguay's OCDS data (for example, in the tender, or relatedLot, for the auction)? e.g.

• @yolile - can the data about the proposals that each supplier submits in order to participate in the auction differ from the data about the bid they submitted in the tender stage preceding the auction, either in the values of the fields, or the number of fields disclosed? e.g.

• @PaulBoroday - I want to understand more about the contracting processes you are modelling, to understand how they relate to Paraguay's processes. Can you share an example (in whatever format) of a contracting process, or processes, with:

  • Many auctions per process (if I understood correctly, this should be any contracting process with multiple lots)
  • Many stages per auction (AuctionRoundsGroups in your model)
  • Many rounds per stage (AuctionRounds in your model)

• @PaulBoroday - where are the initial bids in your proposed model, are these already disclosed in the bids array?

[yolile]

Thanks @duncandewhurst !

@yolile - Can you share an example of the auctions data that is currently published in PDF which shows an auction with more than one lot and with more than one item per lot? I want to see what is common between the different competitions that make up an auction, to determine if they can be modelled as separate auctions without too much repetition.

Yes, here it is: https://contrataciones.gov.py/documentos/download/acta/369241-adquisicion-montaje-estacion-terrena-equipos-informaticos-1
And all the other information about that process: https://contrataciones.gov.py/licitaciones/convocatoria/369241-adquisicion-montaje-estacion-terrena-equipos-informaticos-1.html

@yolile - is the item information which appears in the PDFs already available in Paraguay's OCDS data (for example, in the tender, or relatedLot, for the auction)? e.g.

Yes it is, you can see it here https://contrataciones.gov.py/licitaciones/convocatoria/369241-adquisicion-montaje-estacion-terrena-equipos-informaticos-1.html#itemSolicitados

@yolile - can the data about the proposals that each supplier submits in order to participate in the auction differ from the data about the bid they submitted in the tender stage preceding the auction, either in the values of the fields, or the number of fields disclosed? e.g.

No

[duncandewhurst]

Thanks @yolile. Please let me know your thoughts on the following model:

• Each competition is modelled as a separate entry in the auctions array
• Data on items is already provided in tender.items so does not need repeating in the auctions section
• Data on initial proposals should be provided in the top-level bids section, since it cannot differ from the supplier's bid submitted in the tender stage
• Data on the bid guarantees provided by each supplier should be provided in bids.details.requirementResponses
• The techniques extension is used, in place of putting 'electronicAuction' in tender.submissionMethod, which is planned to be deprecated

{
  "ocid": "",
  "tender": {
    "submissionMethod": ["electronicSubmission"],
    "techniques": {
      "hasElectronicAuction": true,
      "electronicAuction": {
        "url": "",
        "description": ""
      }
    },
    "items": [...]
  },
  "bids": {
    "details": [//starting bids (proposals)
      {
        "requirementResponses": [ //guarantee information
          {
            ...
          }
        ]
      }
    ]
  },
  "auctions": [
    {
      "id": "",
      "status": "successful | unsuccessful | cancelled", //UStudio specific
      "period": {
        "startDate": "",
        "endDate": ""
      },
      "relatedLot": "",
      "stages": [
        {
          "id": "",
          "title": "", //UStudio specific
          "description": "", //UStudio specific
          "relatedModalities": "", //UStudio specific
          "rounds": [ //array needed for UStudio model, Paraguay would just have one round per stage.
            {
              "id": "",
              "period": "",
              "minStep": { //UStudio specific
                "value": { //use `.value` if min step is a monetary value
                  "amount": 0,
                  "currency": ""
                },
                "quantity": 0, //use `.quantity` and `.unit` if min step is not a monetary value
                "unit": {
                  "scheme": "",
                  "id": "",
                  "name": "",
                  "value": {
                    "amount": "",
                    "currency": ""
                  },
                  "uri": ""
                }
              }
            }
          ],
          "bids": [
            {
              //re-use `Bid` object
              "id": "",
              "tenderers": {
                "name": "",
                "id": ""
              },
              "date": "",
              "value": "",
              "relatedRound": ""
            }
          ]
        }
      ],
      "winningBids": [
        { //re-use `Bid` object
          "id": "",
          "tenderers": [
            {
              "name": "",
              "id": ""
            }
          ],
          "value": {
            "amount": 0,
            "currency": ""
          }
        }
      ]
    }
  ]
}

Questions:

• In both the Paraguay and uStudio models, a single auction/competition can only have one relatedLot (auction.relatedLot is a string, not an array). Are there any cases where a single auction can be for multiple lots?

Since electronic auctions can be used for competitive call-offs from a framework agreement, we'll also need to check that this model is compatible with the approach to modelling frameworks agreements.

[yolile]

In both the Paraguay and uStudio models, a single auction/competition can only have one relatedLot (auction.relatedLot is a string, not an array). Are there any cases where a single auction can be for multiple lots?

No, at least in Paraguay.

Data on initial proposals should be provided in the top-level bids section, since it cannot differ from the supplier's bid submitted in the tender stage

Ok, but so we also need to add the items array inside the bid object. Because the proposal includes the specific characteristics and attributes of each bidded item.

[yolile]

Drafted extension here

[jpmckinney]

Noting that there is some background in CRM-5451 and a private document about ProZorro.Sale, which we can integrate here if still relevant and not already integrated.

[jpmckinney]

Adding some resources to review/consider:

• Books: Auctions: Theory and Practice, Putting Auction Theory to Work
• https://iclg.com/practice-areas/public-procurement-laws-and-regulations/brazil
• Paraguay DNCP https://docs.google.com/document/u/1/d/1DTvSlYz8IGTEywYTAE-sMmux7aAI0jggbcw1BjmdsTc/edit
• ProZorro.Sale CRM-4382

[jpmckinney]

UNCITRAL glossary defines:

ID	Term	Definition	Reference
39	Initial bids	Bids submitted for examination or evaluation before the electronic reverse auction as a stand-alone method of procurement is held. For the explanation of the terms “examination”, “evaluation” and “electronic reverse auction as a stand-alone method of procurement”, see ## 29, 27 and 25 above.	N/A