Hilma draft API changes procurementProjectLot identifier

[ScRistinen]

Describe the bugHilma draft API changes procurementProjectLot identifier. Procurement project lot data cannot be synchronized between applications because identifier does not match.

To Reproduce Steps to reproduce the behavior:

1. Create notice draft
   • API endpoint that the request was sent to: https://test-api.hankintailmoitukset.fi/eforms/external-write/v1/procedure/{procedureId}/notice/{etsIdentifier}/draft[?parentEtsIdentifier][&isCorrigendum]
   • sample request payload: eFormsExampleSend.json
2. Read notice draft
   • API endpoint that the request was sent to: https://test-api.hankintailmoitukset.fi/eforms/external-write/v1/notice/{etsIdentifier}/eform
   • sample reponse payload: eFormsExampleRead.json

Actual behavior Procurement project lot with identifier "LOT-0001" is sent. Procurement project lot with identifier "LOT-0000" is read.

Expected behavior Procurement project lot with identifier "LOT-0001" is sent. Procurement project lot with identifier "LOT-0001" is read.

Additional context Add any other context about the problem here. eFormsExampleRead.json eFormsExampleSend.json

[Havunen]

If there is only one ProcurementProjectLot the ID must be "LOT-0000", if there are more than one lot the ID must start LOT-0001 and increment for each lot. This is requirement in eForms SDK

[ScRistinen]

Ok. Hilma draft API didn't have this requirement before. This is breaking change and I haven't seen any notice about this change.

[Havunen]

this is requirement from TED since the implementation of eForms

[ScRistinen]

Well, I'm using Hilma draft API and it's behavior has changed without any notice. Originally, when the draft API was implemented, it was agreed that the draft API will do any necessary data mappings and cleaning so that we can always use the same data set. Now this is changed, without notice.

[Havunen]

This logic has been there since the implementation of Draft API. It tries to simplify the draft API usage. Lot ID "LOT-0001" is not valid if there is only one lot. This is requirement by TED. Also the identifier needs to be PART-xxxx for prior information notices.

Originally, when the draft API was implemented, it was agreed that the draft API will do any necessary data mappings and cleaning so that we can always use the same data set

Yes this is what it is and has been trying to do. The logic will also transform LOT id to PART id if the notice type is prior information notice. If you don't want the content to change you can send the data in the SDK format.

LOT-0001 is not valid identifier for a procurement lot if there is only one lot. Would you prefer bad request response instead?

[ScRistinen]

No need to change response.