questions concerning change notices

[gabrieledall]

Trying to handle change notices, I have two questions to which I could't find an answer in the current documentation:

1. Notice Identifiers and changed Notice-Version reference ids
   Change notices refer to the "changed notices" by referencing their Notice-Id (BT-701) and version ID (BT-757) in one single BT-758 (Changed Notice Version Identifier). Since the change notice will contain the complete new notice (with all changes) as a whole, it remains unclear so far, how the notice-Identifiers of the complete changed document are expected to look like: will they remain similar to the Notice-Id of the former Notice and will only the version-id be set up or is it expected to send a complete new version Id for the changed notice? The currently given examples present differnt notice Ids in BT 758 and in BT-701. Since we would perfer staying with the same notice-id in every change and only changing the version-id, we wonder, if there could be certain circumcances that would not allow this. Otherwise how would we / you able to manage more than one changes of a once changed notice - when each notice will get a new id and starts with version 1, especially when transmission errors lead to the situation that one change had not reached TED before another further change has arrived?

2. BT-13716: Change Previous Notice Section Identifier - will there be any standardized sections Identifiers and where will they be documented?
   Since some examples use e.g. "PROCEDURE" as reference to the "procedure"-section and LOT-0001 to refer to the first lot-section, I wonder if these section-identifiers are fixed and will be documented where this documentation will be accessible?

[YvesJo]

Hi Gabriele,
Please find the answers below:

1. Notice Identifiers and changed Notice-Version reference ids
A Change notice, is a notice on its own and requires its own Notice Identifier. The versioning is defined to allow for multiple successive editions until it gets published. Controls will be put in place to ensure, in the case of conflicts, that the latest version (i.e. the one with the highest version number) is considered. The association of a Change notice to its parent notice is performed using BT-758. There may be multiple changes applied in a single change notice (each change refers to the relevant section using BT-13716). When changes appear at different points in time, then successive Change notices have to be submitted, each referring to the previous one.

Changes may only be applied on published notices, therefore, the use case where a second change should be applied while the first one has not been published should be addressed either way:

• Complete and submit the first Change notice to have it published and then proceed with the second,
• integrate all changes in a single valid Change notice

When the non publication of the first Change is purely associated to non reliable transmission, then, if the first Change has to be published separately, use an alternate channel (e.g. eNotices2).

2. BT-13716: Change Previous Notice Section Identifier

The BT-13716: Change Previous Notice Section Identifier refers to sections of the published notice. These reference identifiers should match identifiers that exist in the change notice. The list of section identifiers is reported in table 3 of Referring to sections of a notice.

LOT-XXXX refers in fact to the technical identifier for the Lot in which a change is made, for example LOT-0012.

XXXX should not be understood as an order of occurrence and just seen as a univocal way to identify an object.

[YvesJo]

In the latest CAN it should only be made reference to awarded contracts for which contract information were not previously published and the amounts should only refer to these contracts.
Also when a procedure is ongoing and decision has not been made for some lots, these should also be identified at LotResult with the Winner selection status set to "open-nw"; of course there will be no contract for these.

[gabrieledall]

Let's say we have a procurement procedure with Lot 1 and Lot 2 and it's not a framework agreement. We have a just one contract notice CN (it can be only one per procedure). The procedure is finalized.

This is an interesting topic I found here: the expectation, that only one (valid) CN is allowed to exist in a procedure. To me, this restriction comes from the process-oriented perspective regarding (only one) procurement process. Although this would be the usual case, there might be some exceptions to the rule:

Considering a long lasting project that will in itself be cut into (time-related) segments - each of them will lead to a single procurement process: At the moment each procurement will be regarded on it's own.

To me, it seems that the data driven point of view in eForms would also allow the publication of serveral CNs (dealing with different needs at different times if all of these belong to the same - long lasting - project): it is not the notices that are relevant but the correct identification of all lots, contracts, etc. within the procedure that define the outcomes of the whole project.

Does my understanding fit to the underlying data concept in eForms or is this a kind of over-interpretation?

Kind Regards
Gabriele

[YvesJo]

Considering a long lasting project that will in itself be cut into (time-related) segments - each of them will lead to a single procurement process: At the moment each procurement will be regarded on it's own.

Yes and each of these procurement will be seen as a different procedure,

To me, it seems that the data driven point of view in eForms would also allow the publication of serveral CNs (dealing with different needs at different times if all of these belong to the same - long lasting - project): it is not the notices that are relevant but the correct identification of all lots, contracts, etc. within the procedure that define the outcomes of the whole project.

I agree with the statement and if I understand it properly it would start from a planning notice and lead to multiple competition notices. This is perfectly exact, as illustration we may also remind that not only Parts from PIN only notices may be combined to define a competition notice but a given Part may lead to multiple Competition notices. We shall also keep in mind that a Procedure actually starts with a competition notice (NB: there is no procedure ID associated to planning notices), planning notices are not stricto sensu part of the Procedure. So I think we agree and the overall process covers everything from Planning to Result with many interrelated notices possibilities and eventually covers multiple procedures, each starting with their respective Competition notices.

[EmilyBrasa]

I have some followup questions on this topic.

In the FAQ it says: “Each time a notice with the same notice identifier is submitted and accepted by the destination application (and publication is not stopped by the user), it must have a different version ID (starting at "01" and incrementing). “

1. If for whatever reason a version is missing in the chain (e.g. for A we post versionID A.01, A.02 and A.04) would TED accept the latest version A.04 or reject it because version A.03 is missing?

2. Would it even be possible to post the same noticeID we post A.01, A.04 and afterwards A.02? If yes, which version would then be published – the highest (A.04) or the most recently submitted (A.02)?

3. What about stopping then? If for the same noticeID we post A.01, A.02 and A.03, but the Stop A.03 – Do we have to send A.04 afterwards or would it be possible to send A.03 again replacing the stopped A.03?

Thanks in advance

[YvesJo]

Hi,
Your question has previously reached the Helpdesk and is under process. As a general rule, non-technical questions should be directly sent to the Helpdesk: [email protected]
Also for technical questions, preferably start a separate discussion instead of adding comments to answered ones as it would prevent it to not be detected.
Thanks for your understanding.