Clarify that "bundled" notices require different OCIDs (e.g. reporting the award of the same lot multiple times over the last 30 days)
Closed this issue · 14 comments
In a framework agreement or dynamic purchasing system with mini-competitions, a single lot can have multiple awards, each with a different number of bids.
The mapping in V2.2 loses the link between the number of bids and the award, so a single lot can have multiple conflicting bids statistics.
This is a gap in the bids extension. Its only field between bids and awards is Award.relatedBid (string), which is for the single winning bid. https://extensions.open-contracting.org/en/extensions/bids/master/schema/
Since the bids extension is versioned with the standard, we can, in the meantime, add BidsStatistic.relatedAward in the EU extension, and update the mapping accordingly.
@JachymHercher Is it correct that a single lot can be awarded multiple times, at different times? I think we performed the EU mapping assuming that a new lot would be created for each mini-competition.
Here's one of the examples from CRM-7416 with this issue:
https://www.find-tender.service.gov.uk/Notice/002763-2021
https://www.find-tender.service.gov.uk/api/1.0/ocdsReleasePackages/ocds-h6vhtk-029232
@JachymHercher Is it correct that a single lot can be awarded multiple times, at different times? I think we performed the EU mapping assuming that a new lot would be created for each mini-competition.
Yes, it is correct - in framework agreements (including DPS) this can happen.
In OCDS, wouldn't each round of competition be modelled as a separate process though, so there wouldn't be a conflict?
(Multiple awards, possibly with multiple bid statistics, could also happen in other cases where you have multiple rounds of competitions - innovative partnerships and competitive dialogues.)
Ah, yes, you're right. The publishers must not have implemented this part of the profile correctly: https://standard.open-contracting.org/profiles/eu/latest/en/operations/#create-a-release
So, FTS should be using new OCIDs for each call-off, in which case there would indeed be no conflict.
So, for CRM-7416, if the publisher can't fix this part of the implementation, then we can write up guidance on a local extension that adds relatedAward, but this field is not necessary in OCDS typically, where BidsStatistic.relatedLot is sufficient.
Hmm, I think the issue in the example shared in #94 (comment) is that the procuring entity is reporting awards for 3 different call-offs on the same award notice. So the publisher has implemented the profile correctly by creating a release for the notice and an award object for each 'Section V. Award of contract'. I'm not clear if using the award notice like this is permissible in TED?
I think EU legislation allows "bundling" of award notices to reduce administrative overhead.
I think the solution is still to edit the EU profile to clarify that such notices (awarding the same lot multiple times across a wide time span) should be modelled as separate OCIDs. Otherwise, we're contradicting our framework guidance.
Sounds good as long as there is a way to programmatically identify those notices in the TED XML?
Yes, the notice's data will have multiple awards for the same lot, with different dates.
Great. In that case, clarifying the profile sounds good. Can we do that soon then I can share the updated guidance with the publisher? If not, I can write them a message and explain the profile will be updated later.
I'm not sure how soon @ColinMaudry can update the profile, so probably best to write to the publisher first.
I think EU legislation allows "bundling" of award notices to reduce administrative overhead.
Yep. The general rule is that you can bundle awards within a 30-day window. Furthermore, for contracts within framework agreements and dynamic purchasing systems, this may be extended to a quarterly window instead (the details are in Art. 50 of Directive 2014/24/EU).
The guidance for the 2015 regulation is not expected to be implemented further.
I copied this issue over to open-contracting/standard#1624