Requirements: add 'bid' to relatesTo codelist

[yolile]

In Paraguay, one requirement is that the bidders must provide a guarantee to kept their offers/bids at the same price if they win. So, the requirement is about the bid itself.
So, can we add the 'bid' code to the relatesTo codelist?

[jpmckinney]

Just to check, is the guarantee with respect to the bid as a whole, or with respect to an item? My understanding was that guarantees were typically tied to items.

[jpmckinney]

Related issue: open-contracting/standard#900 I hadn't seen the updates there yet – I'll read them now. Link to extension: https://github.com/open-contracting-extensions/ocds_requirements_extension

[yolile]

In Paraguay the guarantee is with respect to the bids as a whole. You have to present only one guarantee for all your bids in the tender.

[yolile]

So, should I put the requirementResponses inside the bid? As the guarantee is the same for all the bids for a given tenderer and because in an auction a bidder can have several bids, would'nt be this too much repetition?

[PaulBoroday]

You have to present only one guarantee for all your bids in the tender.

There are cases when this is not the case: multi-lot procedures where each lot can require different guarantees.

So, should I put the requirementResponses inside the bid

This is the only place I guess

would'nt be this too much repetition?

Well in each bid you have organizationReference and its absolutely right. So why you shouldn't have the same approach for requirementResonses ? The idea is to have a comprehensive model describing specific data-object. in our case - bid.

Especially in your case

an auction a bidder can have several bids

Those several will be different? So the value of requirementResponse related to guarantee could be different in cases where instead of having a fixed value for the guarantee, CA requires it as a percent of the value of bid

[yolile]

Yes, in an auction all the bids of the same tenderer are differents but, the guarantee is a fixed percentage that is fixed in the tender so the percentage will be the same in all bids.
Guarantees data in auctions is just the number, type, entity, period and issue date

[jpmckinney]

Although it can be the case that the guarantee is the same for all of a bidder's bids, like @PaulBoroday mentioned, if the procurement is divided into lots and if tenderers are allowed to bid on multiple lots, each lot can have different guarantee requirements, and therefore each bid would have different responses to the requirement.

This conversation is overlapping with how bids should be modelled in the context of auctions, for which I created a new issue: open-contracting/standard#904

In that issue, I propose that auction submissions shouldn't be modelled as bids, but as something else. In that case, the guarantee would be on the bid (I don't think guarantees are among the 'features' of a bid that are modified over the course of an auction). As such, with respect to this issue, we would avoid repetition by just having the guarantee once on the tenderer's initial bid.

---

Regarding other options to reduce repetition, see open-contracting/standard#893, though that is a significant change that would require an OCDS 2.0.

[jpmckinney]

In open-contracting/standard#900 it was discussed that each requirement is implicitly about the 'bid' (unless stated otherwise). In open-contracting/standard#900 (comment), I give the advantages/disadvantages of an explicit field. In short, being explicit reduces uncertainty. However, it could introduce inconsistency (if relatedItem or relatedLots is set) and is redundant with the implicit interpretation.

There don't seem to be strong feelings about reducing uncertainty, so I'll close this issue for now.