search

open-contracting / european-union-support

Support scripts for TED mapping
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

eForms SDK 1.11.0 #204

Closed jpmckinney closed 2 months ago

jpmckinney commented 2 months ago

https://github.com/OP-TED/eForms-SDK/releases/tag/1.11.0

1.10 was https://github.com/open-contracting/european-union-support/issues/196

Relevant

New fields

     eForms guidance: Discard. The notice and sections that were modified can be determined by comparing previous releases with the current release.
     eForms example: <efac:ContractModification><efac:Change><efbc:ChangedSectionIdentifier>CON-0001</efbc:ChangedSectionIdentifier></efac:Change></efac:ContractModification>
     OCDS example: ''
     sdk: https://docs.ted.europa.eu/eforms/latest/schema/contract-modification-notice.html

Now using country instead of eforms-country codelist. Our guidance has a special case for Kosovo. It looks like it's no longer needed.

Maybe relevant

Now optional

Now mandatory

Not relevant

Changed pattern validation

odscjen commented 2 months ago

OPT-093 in the eForms changelog has the following

This field is currently not used, and is intended for the new "Contract completion" notices that will be added in a future version.

So suggest we repeat this in the eForms guidance field and deal with the potential mapping once the Contract completion notices are launched?

odscjen commented 2 months ago

BT-119 now mandatory

current guidance has

If "true", get the lot for the LotResult, and set the lot's .techniques.dynamicPurchasingSystem.status to 'terminated'. Otherwise, discard.

As this is now a mandatory field we maybe shouldn't discard it. However the other options are 'active', 'pending' and 'cancelled'. This BT is the only one in eforms that indicates what the status of the DPS is so there's no way of determining which of the other 3 OCDS statuses may be the correct one if BT-119 = false. So the guidance probably has to stand but noting that there's this slight disconnect

odscjen commented 2 months ago

BT-661-Lot (Maximum Candidates Indicator) is now mandatory but we have it mapped as "Discard". In this case I think this can stay as Discard as the number of candidates (BT-51-Lot) is also now mandatory so whether this is true or false can be inferred from the OCDS mapping of BT-51.

We could add an explanatory sentence about how to infer this information from the OCDS mapping though?

odscjen commented 2 months ago

The following are now mandatory but with guidance to discard:

BT-730-Tender (Subcontracting value known)

Discard. If the award's .subcontracting.value is not empty, the buyer knows the estimated value of the part of the contract that the contractor will subcontract to third parties.

BT-731-Tender (Subcontracing percentage known)

Discard. If the award's .subcontracting.minimumPercentage and .subcontracting.maximumPercentage are not empty, the buyer knows the estimated value of the part of the contract that the contractor will subcontract to third parties.

OPT-210-Tenderer (Tendering party ID)

Discard. Each tenderer in the tendering party is covered by OPT-310-Tenderer.

OPT-300-Tenderer (Tenderer ID reference)

Discard. This field is mapped as part of OPT-310-Tender.

Think it's fine to leave the guidance for these as is because of the explanatory sentences of how to infer this information from the other mappings

odscjen commented 2 months ago

OPT-170-Tenderer (Tendering party leader) is now mandatory, current OCDS guidance has

Get the organization for the tenderer. If "true", add ''leadTenderer'' to its .roles.

so nothing about what to do if the field = false. The sdk says the following

Only required when at least two Tenderers are listed. For a given Tendering Party with multiple tenderers, there should be one and only one leader.

we could update the OCDS mapping guidance to say something about how if there are 2 or more parties with roles = 'tenderer' then one must also have 'leadTenderer'? e.g.

Get the organization for the tenderer. If "true", add ''leadTenderer'' to its .roles. If "false" and there is more than one efac:Tenderer in ancestor:efac:TenderingParty ensure one organization in parties has "leadTenderer" in its .roles.

odscjen commented 2 months ago

Where fields are now mandatory and they are binary, have updated guidance from "set XXX to 'true" to "map toXXX`". This applies to fields:

odscjen commented 2 months ago

OPT-070 is now mandatory but mapped as

Discard. OPT-070 may only be used in some circumstances for a Call for Expression of Interest, which is not covered by the eForms regulation.

which was a result of this question https://github.com/OP-TED/eForms-SDK/discussions/254

if it's now mandatory should this be changed?

jpmckinney commented 2 months ago

I just noticed eForms' fields.json has some new "conditional mandatory" logic that was not there before. I'll update the code and cross out those that didn't actually change.

jpmckinney commented 2 months ago

OPT-093-Review

Agree with suggestion

BT-119-LotResult

Agree to do nothing. I don't know what it implies for this to be false.

BT-661-Lot

Agree about explaining how to infer

BT-730-Tender BT-731-Tender OPT-210-Tenderer OPT-300-Tenderer

Agree to do nothing, as existing inferences are sufficient.

OPT-170-Tenderer

I propose to leave as is. If the input eForms data is invalid, we don't need to make it more correct in OCDS. Ideally all mappings should be automatable – choosing a lead tenderer seems manual (or random).

BT-120-Lot BT-193-Tender BT-40-Lot BT-52-Lot

👍

OPT-070-Lot

It is only mandatory on CEI (Call for Expression of Interest), so we can leave it.

jpmckinney commented 2 months ago

I just noticed eForms' fields.json has some new "conditional mandatory" logic that was not there before. I'll update the code and cross out those that didn't actually change.

Okay, I think it was there before, but now I've made it more clear in guidance.yaml

If it's not mandatory, there is no mandatory field.

If it's mandatory, it lists the notices on which it's required, with "(conditional)" if there's a condition in fields.json

odscjen commented 2 months ago

all changes now made, I think this can be closed now?

jpmckinney commented 2 months ago

Thank you!