Minutes of the TED eSender workshop (26 June 2025)
These consolidated questions and answers have been reviewed and may have been regrouped or modified to provide a more cohesive and complete response. Some answers might no longer be accurate, as the Publications Office (OP) has updated its approach based on feedback.
The presentation slides as well as the recording of the live session are available in the agenda section.
Questions from the participants:
- Why do you have two slightly different visualisations, one used by eNotices2 and one by TED?
Answer: The two different visualisations in eNotices2 and TED currently exist due to their parallel development timelines and differing user requirements. We plan to align them more closely over time by first transitioning to EFX-2 and upgrading the render API service. While this harmonisation is a long-term goal, we maintain both visualisations in parallel for now, ensuring content consistency while allowing for some differences in look and feel.
-
In SDK 1.13, the IPI fields have been released, but they can't be used now. When are the rules for these fields expected to be released? Will there be a patch version of SDK 1.13 that includes them, and if so, when is it expected? you show us the new complete TED API v3 endpoints (for Preview and Production)?
Answer: The IPI fields in SDK 1.13 have been released but are not yet usable because the first IPI measure was only recently adopted. We plan to address this with a patch, version 1.13.2, which is scheduled for release by the end of July. This patch will enable the use of IPI fields, and we aim to make it available swiftly. Although immediate use of IPI in procurements is not expected, the update will be ready in case it is needed.
-
If we have implemented SDK 1.13, do we have to do anything when the 1.13.2 patch is applied?
Answer: Installing the patch should be sufficient unless there are customisations to affected fields by the eSender. The patch will introduce changes in code lists, rules, and view templates, which might impact you depending on how you use these components. If you are not utilising the API or view templates extensively, there should be no immediate impact. However, if you need to incorporate the new functionalities provided by the patch, you may have to adjust your system accordingly. The Central Validation Service (CVS) checks only the SDK minor version, not patch versions, so SDK 1.13 remains recognised as 1.13.
-
When will SDK 1.13.2 be available? Can you guarantee full backward compatibility with 1.13.0?
Answer: Our target is to make SDK 1.13.2 available by the end of July. There should be no issues with backward compatibility between SDK 1.13.2 and 1.13.0. We'll conduct thorough testing to confirm this, but given the limited scope of changes, we're not anticipating any surprises. While SDK 1.14 may include adjustments related to validation rules, such as handling tender value removals in contract modifications, any updates will be carefully tested to ensure a smooth transition.
-
Are you going to provide examples for SDK 1.13.2 regarding IPI, SAFE, and EDIP changes?
Answer: We will not be providing example XML files for SDK 1.13.2 regarding IPI, SAFE, and EDIP changes. Our immediate priority is to release the patch to manage these changes. However, for SDK 1.14, we might consider including examples, especially for IPI. SAFE and EDIP changes involve adjustments in the justification text for contract modifications rather than structural changes, and the European Commission will offer guidelines on the appropriate text for these justifications. This ensures buyers can confidently declare their modifications in line with the regulations.
-
Did we also get a child codelist for IPI BT-685 depending on CPV Codes?
Answer: Currently, there are no plans to implement a child code list for IPI BT-685 associated with CPV codes. The IPI measure code list will initially have only one entry, designating the applicable measure. Future updates may include additional entries, and for each measure chosen, the CPV codes for the lot will be checked against a specified range to ensure compliance. As new measures are introduced, they will be added to the code list, allowing for appropriate CPV checks.
-
What does "short-term" option for subtype 38 contract modification for SAFE/EDIP mean? Please specify short-term.
Answer: Contrary to what was presented and said at the eSender workshop on 26 June, the only change in the SDK 1.13.2 patch will be the addition of defence directive 2009/81 as a valid legal basis for subtype 38 (used by directive 2014/24), to allow its use by eSenders who have not implemented subtype E6. There will be no change to the label/name of subtype E6. The same change in SDK 1.13.2 will also be carried out in SDK 1.14 and there is no short-term or recommended choice: either subtype 38 or E6 can be used for contract modifications under 2009/81, depending on the eSender's situation or choice. Any further or more significant changes would only be carried out under the 3rd amendment (e.g. if Member States decide to create subtype 41 exclusively for 2009/81).
- Why not create a new notice subtype 41 for contract modifications in defence and security to maintain the logical structure of the eForms regulation and simplify the process, even though reducing the number of forms is necessary? On a technical level, couldn't the new subtype be a copy of E6 or 38 to avoid additional burden for implementers?
Answer: Please see above – there are no plans for this year for a new subtype 41 and subtypes 38 or E6 can be used in SDK 1.13 and 1.14.
-
When are SDK 1.14 and SDK 2.0 going to be in use for production?
Answer: We are targeting the release of the first candidate for SDK 1.14 by the end of September, which will then undergo a couple of weeks of testing. The aim is to have it in production by mid to late October, assuming all goes smoothly. SDK 2.0 will follow closely, with an alpha version expected by October. The objective is for SDK 2.0 to maintain legal and business equivalency with SDK 1.14 while evolving to include dynamic rules that SDK 1.14 cannot support. If all criteria are met, SDK 2.0 will be released around the same period, ensuring consistency with SDK 1.14, alongside these additional dynamic rules.
-
Remove parts (PAR) is listed as a possible change for the 3rd amendment. Is it the intention to switch to lots for notices that currently use parts?
Answer: Yes, the proposal for the 3rd amendment is to replace "Parts" with "Lots" for the three Planning subtypes currently using Parts. This change aims to simplify the schema and improve data quality and granularity. However, there needs to be a clear understanding that the Lots mentioned in Planning notices are not necessarily the same as those used in Competitions. For example, a Planning notice might indicate five Lots, whereas the corresponding Competition could involve only two of those Lots or perhaps even multiple Competitions for the initial Lots. This approach aligns with the way it was handled in older forms and was generally understood. But this proposal still needs to be discussed and agreed with Member States, like all the other proposals for the 3rd amendment to the eForms regulation.
- In Preview environment, it seems that notices are put in a 'lawfulness' warning if they're not created in an official language of the member state. Could this rule be removed in Preview?
Answer: In Preview, the lawfulness warning is not triggered by the language of the notice. Instead, it checks the country of the buyer. If you're encountering a warning related to language, it might be due to other factors, such as listing a buyer in a country which is not in the EEA or not a candidate country, which would trigger the warning. Changing rules specifically for preview environments is challenging, as the aim is to keep them consistent with production for accurate testing. If you encounter any issues related to language warnings, please let us know, but as it stands, there is no language lawfulness warning in place.
-
Please be wary of activating too many lawfulness warnings in Preview, as we often use dummy data. Could these warnings be adjusted?
Answer: Currently, we don't differentiate lawfulness warning rules between Preview and Production, meaning test notices with dummy data like "Lorem ipsum" could trigger warnings if such checks were activated. We have no immediate plans to implement comprehensive checks in Preview this year. Our goal is to develop flexible algorithms that can be easily refined or switched off in certain environments without needing an SDK release, allowing for adaptable adjustments as needed.
-
Who is using EFX templates vs SDK metadata files? How many eSenders use EFX and the full SDK, and what percentage of the total?
Answer: From our side, EFX view templates are used through the TED Viewer 2022 render API, which facilitates rendering and previewing notices in applications like eNotices2. Many eSenders and other users also leverage this API. Additionally, a handful of eSenders directly utilise EFX to create their own viewers, interpreting the templates locally. Most users incorporate "fields.json" from SDK metadata for schema adherence, and notice types are commonly used for their screen layouts. Specific usage might vary, and detailed information was gathered from a survey of 22 eSenders out of 51. The results of this survey were presented during the “Business eForms Issues” presentation of the eSender Workshop Q1 2025.
-
EFX grammar is not well documented. Will EFX-2 include more comprehensive documentation?
Answer: Yes, there will be extensive documentation for EFX-2, which will be much more comprehensive than what is available for EFX-1.
- The talk about breaking apart fields.json in SDK-3 is concerning. Can you provide clarity on this plan?
Answer: We will not make changes to fields.json merely for the sake of change. Any modifications will be aimed at unblocking issues and improving progress. If a decision is made to break apart fields.json, it will not be enforced before 2027, by which time it will be a five-year-old design. The change will be made only if it brings significant benefits, allowing for better organisation and retrieval of information. We understand concerns about efficiency, but at some point, updating to a more effective design is necessary. The new setup will present information more effectively and could introduce new opportunities for data retrieval. Rest assured, there's no rush, and changes will be considered carefully.
-
My customer complains about the time zone information in TED. Should there be an option for users to choose their time zone? My concern isn't with ambiguity in the actual eForms; it's an issue my customer raised about supplier confusion on TED. Should I direct them to TED for clarity?
Answer: Your customer is correct that TED doesn't allow time zone selection directly. Time zone information is limited to the UTC offset provided in the XML, such as UTC+2, which remains the same globally. Recently, TED added labels like Central European Time (for UTC+2) to clarify the context. While European users generally know their local time zone, TED could enhance the user interface to interpret the UTC offset and display local time dynamically. The printed notices will still show UTC timestamps, but there's potential to improve user-friendliness in the system's display. Directing concerns to TED's user support is advisable as they can provide guidance tailored to TED's functionality and user interface.
-
Is it allowed to use BT-300 for IPI information?
Answer: Using BT-300 for IPI information is not directly allowed, as there is no BT-300 field designated for IPI information. However, you can use BT-300 at the procedure or lot level, even though it might not be directly related. Structurally, it's best to use the specific IPI fields provided, as these are designed for accurate reporting and assessment by the Commission. Using these designated fields ensures that the information is captured for evaluations of IPI procedures and exceptions. If you need to include IPI information, upgrading to SDK 1.13 would provide the necessary fields.
-
How can I register for the eForms workshop scheduled for July and August?
Answer: Registration for the eForms workshops in July and August is restricted to members of the EXEP, which comprises representatives from Member States. It is a closed group managed by the European Commission, and participation isn't open to the general public or eSenders. However, you can follow the agenda, minutes, and issues discussed during these workshops at https://code.europa.eu/eproc/eforms/workshops. This allows you to stay informed and contribute to the issues, even if the decision-making process is not accessible.
Remarks from the participants:
- With the slow-moving changes on the SDK, it finally feels like it has matured. Congrats.
-
Last update: 18 July 2025