Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BT-681, BT-682: Foreign Subsidies mapping #219

Closed
odscjen opened this issue Jul 31, 2024 · 9 comments · Fixed by #224
Closed

BT-681, BT-682: Foreign Subsidies mapping #219

odscjen opened this issue Jul 31, 2024 · 9 comments · Fixed by #224
Assignees

Comments

@odscjen
Copy link
Contributor

odscjen commented Jul 31, 2024

New fields added as part of SDK 1.12.0 (see #215)

BT-681-Lot Foreign Subsidies Regulation

"The Foreign Subsidies Regulation (FSR) (EU) 2022/2560, in line with Article 28 thereof, is applicable to this procurement procedure."

This is a boolean in the cac:TenderingTerms block that says whether or not the procurement falls under “Foreign Subsidies Regulation (EU) 2022/2560 in line with Article 28 “. Suggesting that if true map this to legalBasis, otherwise discard. We'll need to update the Legal Basis extension as it currently only adds to tender and this refers to a specific lot.

{
  "tender":{
    "lots": [
      {
        "id": "LOT-0001",
        "legalBasis": {
          "id": "https://eur-lex.europa.eu/eli/reg/2022/2560/oj",
          "scheme": "ELI"
        }
      }
    ]
  }
}

BT-682-Tender Foreign Subsidies Measures

"Measures applied under the Foreign Subsidies Regulation (EU) 2022/2560."

This is a codelist field that appears in the efac:NoticeResult/efac:LotResult block the efac:NoticeResult/efac:LotTender [EDIT: made a mistake in the initial typing up of this issue]. This block refers to a submitted bid. The regulation this BT references lays out rules to avoid foreign subsidies distorting the internal EU market. The codes in the codelist refer to the judgment or outcome of any review or investigation undertaken (or not) with respect to the particular bid. The outcomes fall into 2 basic categories, the buyer can award to this tenderer or they can’t. The key thing in this first category is that they can award, not that they have or have too, just that awarding to this tenderer isn’t forbidden. So it’s a judgment on the bid, which has obviously happened post-submission of the bid but it's not an award decision in itself. This should be mapped to bids.details but there’s currently no suitable field for it.

Suggest a new bids.details.foreignSubsidiesMeasure classification object (singular as this is a non-repeatable field so there should only be a single value for any one bid):

{
 "bids": {
   "details": [
     {
       "id": "TEN-0001",
       "foreignSubsidiesMeasure": {
         "id": "fsr-irregul",
         "scheme": "eu-foreign-subsidy-measure-conclusion",
         "description": "Notification submitted, decision on irregular tender or request to participate",
         "uri": "https://op.europa.eu/en/web/eu-vocabularies/concept/-/resource?uri=http://publications.europa.eu/resource/authority/foreign-subsidy-measure-conclusion/fsr-irregul"
       }
     }
   ]
 }
}

where the label is mapped to the .description rather than the full description. I think this would be most appropriate to add to the EU extension rather than adding to the Bids extension as I'm not aware of any similar legislation in other jurisdictions (although there could well be).

@jpmckinney
Copy link
Member

I think BT-681 has more the semantics of coveredBy (like GPA). The legal basis for a procedure to which the FSR is applicable is still probably 2014/24/EU, etc.

@jpmckinney
Copy link
Member

jpmckinney commented Jul 31, 2024

This is a codelist field that appears in the efac:NoticeResult/efac:LotResult block. This block refers to a submitted bid.

Isn't a LotResult an award? https://standard.open-contracting.org/profiles/eforms/latest/en/primer/#lotresult-award Among LotResult fields, we currently put only the winning bid's value on the Bid object.


Whether BT-682-Tender goes on the award or bid depends on the processes around FSR. If all bids are evaluated, then it goes on the bid. If only the best bid is evaluated, maybe it makes more sense on the award?

Based on my very quick reading of https://competition-policy.ec.europa.eu/foreign-subsidies-regulation/about_en, I think the measures are applied when an award is imminent.

A notification-based procedure to investigate bids in public procurement procedures involving financial contributions by non-EU governments, where the estimated contract value is at least €250 million and the bid involves a foreign financial contribution of at least €4 million per third country in the last three years

Above the relevant thresholds ..., the parties must notify financial contributions received from non-EU public authorities prior to concluding ... a public procurement award. The Commission can also request ad-hoc notifications for ... public procurement procedures below the thresholds, if it suspects the existence of distortive foreign subsidies. Pending the Commission’s review, ... the investigated bidder cannot be awarded the contract.

With respect to the redressive measures and commitments, the Regulation includes a non-exhaustive and illustrative list of structural or non-structural remedies, such as the divestment of certain assets or providing access to infrastructure. In case of notified transactions and if the notifying parties do not propose effective remedy to fully remove the distortion, the Commission can also prohibit ... the award of the public procurement contract to the subsidised bidder.

These are the codelist values where the award is not made to the described bid:

  • fsr-irregul: Notification submitted, decision on irregular tender or request to participate. The Commission conducted a preliminary review and found that the notification was incomplete, and requested more information from the economic operator who did not comply. The Commission declared the tender or request to participate irregular and requests the Buyer to reject the tender or request to participate.
  • fsr-proh: Notification submitted, decision prohibiting the award. The Commission conducted its in-depth investigation and concluded that there are distortive foreign subsidies. Therefore, it issued a decision to the Buyer prohibiting the award to the tenderer that was under in-depth investigation.
  • fsr-meat: Declaration submitted, standard MEAT award. The Commission has started an in-depth investigation on the tenderer. However, this tenderer did not submit the most economically advantageous tender (MEAT). There was another tenderer who submitted a declaration and MEAT. The Commission did not open an in-depth investigation against that tenderer. Therefore, the Buyer can award the contract to that tenderer with the MEAT.

I assume that if one bid can't be awarded, then another bid can still be awarded – perhaps there will be one notice about the prohibition and another about the award. (I assume eForms structure doesn't prevent this?)

Anyway, this kind of veers into bid assessment: open-contracting/standard#1546 But, instead of taking that direction...


The role of the Commission as the "sole enforcer of the FSR" might also matter, for the modelling. We presently have an 'unsuccessful' code for award finalStatus that reads:

The award failed (for example, a review body cancelled the process during the standstill period) after the bid submission deadline, but before the award was made or before the standstill period, if any, had ended.

And a 'cancelled' code:

The award was cancelled by the buyer or the procuring entity (for example, because of a change in needs, insufficient funds, or technical or procedural errors) after the bid submission deadline, but before the award was made or before the standstill period, if any, had ended.

In the scenario where the Commission prohibits the award (fsr-proh), this sounds like a similar scenario to a review body, so perhaps it is best to model as an 'unsuccessful' award.

The Commission can also "request the Buyer to reject the [bid]", which sounds softer than a prohibition. In practice, I don't know if there is any difference; without reading the legislation, I'm not sure if the buyer actually has discretion here. In any case, if that code is used in the data, it is presumably because the buyer did follow the instruction to reject the bid. This sounds like it's also an 'unsuccessful' award.

In the scenario where the Commission noticed that, essentially, the buyer had made an error in determining the correct winner (fsr-meat), that sounds like it could be a scenario where the award was "cancelled", i.e. the buyer used its discretion to award a different supplier, after a "procedural error". To me, it doesn't seem relevant whether the buyer recognized the error themselves or not.

As such, this BT is maybe more about finalStatus and finalStatusDetails and/or some rationale for the award, similar to direct award justifications (though, those are in tender, where the 'direct' procurementMethod is indicated). I think we can maybe stick with finalStatusDetails unless there is competition for that field.

(The rest of the codes would map to final status ‘complete’ with details in final status details.)

If that's the way to go, we can add those fields to https://github.com/open-contracting-extensions/ocds_1_2_draft_extension


We can consider a foreignSubsidyMeasureConclusion field on the award if we wish to preserve the code and not use the free text finalStatusDetails field, but I think the value of easy discovery of information by using common fields is more valuable that a closer concordance with eForms’ structure.

@odscjen
Copy link
Contributor Author

odscjen commented Oct 8, 2024

Isn't a LotResult an award? https://standard.open-contracting.org/profiles/eforms/latest/en/primer/#lotresult-award

sorry, yes you're completely right but unfortunately I made a mistake in typing up this issue and BT-682-Tender actually is in the LotTender section.

BT-682 has parentNodeId: ND-LotTender, looking for that in the guidance.yaml there's 9 other elements with the same parentNode:

element name OCDS mapping
BT-13714-Tender Tender Lot Identifier bids.details.id
BT-171-Tender Tender Rank bids.details.rank
BT-1711-Tender Tender Ranked bids.details.hasRank
BT-193-Tender Tender Variant bids.details.variant
BT-3201-Tender Tender Identifier bids.details.identifiers.id
BT-720-Tender Tender Value bids.details.value AND awards.value
OPP-080-Tender Kilometers Public Transport contracts.publicPassengerTransportServicesKilometers
OPT-310-Tender Tendering Party ID Reference bids.details.tenderers.id AND parties.id
OPT-321-Tender Tender Technical Identifier bids.details.id

OPP-080 is very specific and only features in T02 forms so I think we can ignore it for our purposes here. The value of the bid, BT-720-Tender, is mapped to awards but only after it was realised that eForms expects users to look up the value of the winning bids themselves (see #178). So discounting OPP-080 these elements are all mapped into bids. BUT what it unclear is whether or not publishers are only publishing winning bids? From looking through the examples it looks like only winning bids are included, but that might just be how the examples have been put together. From the SDK Competion Results guidance it says these notices contain

The tenders received for the lots about which a decision has been made and is shared with the notice

which I read as leaving open the possibility that publishers could include details of unsuccessful tenders as well as the winning ones as not awarding to a submitted tender is still a "decision".

In terms of the mapping, if we map this to awards there's a risk of losing some linking. The main way bids are linked to awards is using the relatedBids array, but different bids could have different FSR review decisions, i.e. one could be fsr-stand and another could be fsr-commit but by just putting this in finalStatusDetails it'd not be clear which result was for which bid.

I think we need to add this bids.details. It could be a simple string field named foreignSubsidyMeasureConclusion rather than a classification object I originally suggested, but I do think bids.details is the correct place for it rather than awards, @jpmckinney

@odscjen
Copy link
Contributor Author

odscjen commented Oct 8, 2024

Just found in the guidance for policy makers pg 24

3.3.4
eForms could be used to collect and publish information about all bids received (26), not just the winning bid.

  1. This is done by submitting multiple Tender (BG-320) sections, where only the winning one will be referred to by Contract Tender Identifier (BT-3202), others not.

So details of unsuccessful individual bids can be published

@jpmckinney
Copy link
Member

I think we need to add this bids.details. It could be a simple string field named foreignSubsidyMeasureConclusion rather than a classification object I originally suggested, but I do think bids.details is the correct place for it rather than awards, @jpmckinney

Hmm, but in my earlier comment I discuss how it is not all bids that are subject to FSR, but only those being considered for an award. If a bid fails the FSR, it should be modelled as an unsuccessful or cancelled award, depending on the reason.

The important distinction is the timing of the evaluation. If all bids were being evaluated (like for selection criteria, exclusion grounds and award criteria), that information would be "bid stage" (though we don't actually recognize that stage in OCDS). But it's only to-be-awarded bids being evaluated – similar to the work of a review body. That puts it in the award stage.

@odscjen
Copy link
Contributor Author

odscjen commented Oct 8, 2024

I assume that if one bid can't be awarded, then another bid can still be awarded

Yes I also assume this

– perhaps there will be one notice about the prohibition and another about the award. (I assume eForms structure doesn't prevent this?)

but I don't think it would be split into separate notices, it would all be included in the one CAN notice as this information sits in the block that gives info on (potentially) all the bids that were submitted for this procurement opportunity.

...I discuss how it is not all bids that are subject to FSR, but only those being considered for an award.

The important distinction is the timing of the evaluation. If all bids were being evaluated (like for selection criteria, exclusion grounds and award criteria), that information would be "bid stage" (though we don't actually recognize that stage in OCDS). But it's only to-be-awarded bids being evaluated – similar to the work of a review body. That puts it in the award stage.

I think I'm interpreting this all slightly differently. I agree with the interpretation that it's not all bids that meet the thresholds that will be evaluated, only those that make it to the final shortlist (which could be a shortlist of 1) after the other evaluation steps, where I'm considering this final shortlist to mean these are the bids being considered for an award. But I view that as still just being part of the evaluation procedure/bid stage. If you've a list of evaluation steps to go through one of them has to be done last and you may well order those steps so that the most onerous only get applied once some bids have already been discarded, but it's still just a part of whittling the list down. I don't read the summary in https://competition-policy.ec.europa.eu/foreign-subsidies-regulation/about_en as precluding the buyer from submitting say 2 bids for FSR review as a final check before they decide which bidder to make the award to, or submitting 1 but then deciding that actually they want to award the tender to a different bid anyway.

If a bid fails the FSR, it should be modelled as an unsuccessful or cancelled award, depending on the reason.

In the eForms structure if a bid fails the FSR that won't necessary lead to an unsuccessful award if another bid can be awarded instead. As we've modelled each eForms award as an OCDS award,i.e. we currently map efac:LotResult/cbc:ID to awards.id, if multiple bids, some of which have passed the FSR and some of which haven't are all in the same eForms notice (which they would be) then we'd need to entirely rethink how we create the OCDS awards from the eForms awards. I think it all comes back to the fact that the positive FSR outcomes only say that the buyer can award the tender to that bid, not that they have to. It allows for the fact that a bid can pass the FSR but still not win the award, which I don't think would be an unsuccessful award, just an unsuccessful bid.

@jpmckinney
Copy link
Member

jpmckinney commented Oct 8, 2024

Looking at the regulation to get a better understanding of how/when FSR procedures can arise:

Article 29 describes one scenario, where the bidder (economic operator) notifies the buyer (contracting authority/entity) of foreign financial contributions. The buyer transfers the notification to the Commission. The Commission then does its work. The steps in this scenario are mandatory. I expect these steps can occur as early as bid submission.

The bidder sends the initial notification on this condition 28(1):

a notifiable foreign financial contribution in a public procurement procedure shall be deemed to arise where:
(b) the economic operator [...] involved [...] in the public procurement procedure was granted aggregate financial contributions in the three years prior to notification […] equal to or greater than EUR 4 million per third country

In another scenario (below), the buyer has discretion about whether to notify the Commission, insofar as it has control of its own suspicions. However, it doesn't get to decide which of the suspicious bids it notifies about. I expect these steps occur during bid evaluation, once bids are opened – at which point the buyer has information on which to base suspicions.

Where the contracting authority or contracting entity examining tenders suspects the presence of foreign subsidies, although a declaration was submitted, it shall communicate such suspicions to the Commission without delay

Another way FSR can arise is if the Commission starts an "ex officio procedure" (that is, an investigation of its own initiative).

FSR is not exclusive to procurement. The Commission can start a procedure in other contexts.

So, without further information or research, it would seem decisions could be made at any time – e.g. the Commission could investigate: a supplier that later submits a bid; a supplier that has submitted a bid, but evaluation hasn't started; a supplier to whom an award is imminent. In general, FSR procedures have their own lifecycle independent of contracting processes; Article 29 describes one case where the FSR procedure is somewhat "contained" in the contracting lifecycle.


All this said, this discussion might be moot because, based on current eForms publisher patterns, we will never see FSR details with respect to a bid, unless that bid reaches the point of being awarded.

If the bid does reach the point of being awarded, I think it is relevant and appropriate to express the cancelled or unsuccessful award as an award – not as a bid. If the Commission blocks an award (like a review body can block an award), that is not the same as the Commission making a decision that causes the buyer to exclude the bid from consideration at an earlier stage of the process.

At this point, I think all we can be certain of is that eForms will contain information about awards that were cancelled or unsuccessful (or, awards that were successful and passed the FSR investigation).

If, in future, publishers start disclosing FSR information about bids that were excluded earlier in the process (or information about bids that passed FSR, but didn't win), then, I agree, it would be appropriate to model that on the bid. For now, though, I think we can save ourselves the trouble.

@jpmckinney
Copy link
Member

BT-682-Tender actually is in the LotTender section.

Actually, I take it back - let's just put it on the bid in the EU extension. I was still thinking there was some additional consideration for putting it on the award.

@jpmckinney
Copy link
Member

And we got clarification here as well: OP-TED/eForms-SDK#1050 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants