Minutes of the TED eSender workshop (28 March 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: 

• We received a notification regarding the release of TED API v3 and learned that TED API v2 will be supported until 30 September 2025. Could you provide clarity on whether there is a definitive cut-off date after which TED API v2 will be deprecated? Additionally, it was mentioned that version 2.0 would be supported until 4.0 is introduced to maintain only two versions. Could you update us on any developments related to version 4.0?

Answer: In general, we aim to support two versions of the TED API at a time. While we have no intention to deprecate a version unless necessary (see versioning policy), it's possible that by the end of the transition period, a new version may be introduced. The intention remains to support only two versions in parallel. Version 4.0 was initially considered but was ultimately deemed unnecessary. 

In line with the six-month transition period as previously announced, we will not deprecate TED API v2 before v4, however, we strongly encourage eSenders to be ready by 30 September 2025 in case a new version is introduced, e.g. due to breaking changes in the meantime. We consider that six months is ample time for the changes required.

• Can you show us the new complete TED API v3 endpoints (for Preview and Production)?

Answer: Please refer to the updated TED API documentation. 

• Regarding SDK lifespans, when can we expect the new SDK timeline information published?  

Answer: The formal details regarding SDK lifespan changes were covered in the relevant presentation: “Business eForms issues”. You can also refer to the updated list of active SDK versions in the documentation as well as the updated active version range via the TED API, which should always be consulted as the single source of truth. 

• Could you confirm whether the actual validity end date for SDK 1.10 is now 31 July 2025, or is it still 30 April 2025? Is the extension to July only available "on demand"? 

Answer: We can confirm that the validity end date for SDK 1.10, along with 1.11, has been extended to 31 July 2025. If you plan to use this extension and haven't already contacted us, please get in touch. We would also like to discuss certain conditions and rules that should be implemented before making the switch to these versions. 

• Will the go-live dates be published along with the schedule? We were surprised to see that SDK 1.13 was prepared but not yet available in production. 

Answer: There was indeed a time gap between SDK 1.13 being released and its availability in Production. This was due to a one-off change needed by the TED website. SDK versions are made available in Preview shortly after release so you can always get started with implementation and testing. We realise we cannot wait too long to activate SDK versions in Production given the speed at which some eSenders can upgrade. 

• Am I correct in understanding that SDK 2.0 will be available in August 2025? Could you share the specifications for this release, as it involves major changes? 

Answer: SDK 2.0 is anticipated for release at some point in 2025. While the full specifications are not yet documented, you can refer to the EFX2 branch in the SDK repository to view the updated grammar and related changes as we prepare for the release. The changes to the grammar and the toolkit updates are already available there. Comprehensive documentation and specifications will be provided upon the official release. For more details, please refer to the relevant presentation: “Technical eForms issues”. 

• How long will the transition period be for implementing the 3rd amendment from its entry into force, and will it provide ample time to implement SDK 2.1? 

Answer: The transition period for the 3rd amendment is intended to be sufficiently generous to accommodate the implementation of SDK 2.1. The plan is to ensure that SDK 2.1 becomes available at least 12 months before SDK 1.13 is deprecated. This timeline aims to provide enough time for users to make the necessary transitions without the rush experienced during the 2nd amendment, which had a very tight and challenging deadline. We are coordinating with the Commission to ensure the 3rd amendment reflects this ample transition period for a smooth and realistic implementation process. 

• We would appreciate it if there were a dedicated SDK version for regulatory amendments, separate from technical improvements. This separation would help eSenders implement regulatory changes more efficiently. 

Answer: This approach aligns with what we have been doing recently and plan to continue. For instance, SDK 1.12 introduced business entities, which are optional and can be disregarded, if necessary, while SDK 1.13 solely focused on implementing the 2nd amendment without any technical changes. This year, SDK 2.0 will bring significant technical updates, but without regulatory changes, whereas SDK 2.1 next year will handle the 3rd amendment. The strategy is to alternate between major regulatory and technical updates, ensuring minimal overlap and providing a clear focus for each SDK version. This approach appears to be beneficial for everyone involved, and we aim to maintain it going forward. 

• What is the advantage of moving fields, such as the main location, from lots to the procedure level? It seems this might obscure the purpose of lots.

Answer: The main advantage is that some fields, like the main location, rarely change between lots – showing a variance of less than 1% in a dataset of one million notices. By moving these fields to the procedure level, we minimise data repetition, offering a clearer view of the procurement without redundantly displaying the same information multiple times. This shift also lessens the administrative workload for buyers, as it reduces the number of fields they need to fill out, with minimal impact on the data's integrity. These decisions are made in consultation with member states, allowing them to accommodate specific national practices if necessary. 

• Revisiting field names and structures increases complexity on the technical side. Simplifying them may make things more complicated and expensive to build.

Answer: We're not removing existing field names; instead, we're adding more readable aliases. This allows you to switch between the field name and its alias without rewriting expressions, making them more understandable. Eventually, we hope everyone will adopt these aliases, but for now, it's a step towards making EFX expressions clearer. While it might initially seem complex, working together, we'll ensure the transition is as simple as possible, providing ample time before any field names are potentially changed.

• Is there any way to withdraw lots before demolition? 

Answer: The term "demolition" isn't entirely clear, but generally, you can't modify the number of lots once your procedure has been launched. Such changes are seen as substantial, so they're not typically allowed.  

• Are there any plans to move API authentication responsibilities to the Contracting Authorities? Currently, there’s no mechanism to verify that an eSender is posting on behalf of the CA in a notice. In comparison, the new UK portal assigns API authentication to the CAs, which streamlines the process for eSenders. 

Answer: We have no plans to shift API authentication to the Contracting Authority. eSenders are responsible for managing their clients, as they know their contracting authorities best. While the UK system centralises authentication due to its national setup, such an approach isn't feasible at the European level owing to diverse authorities. National portals may track authorities, but managing numerous API authentications broadly isn’t practical. We’re open to exploring other API improvements in the future. 

• Why was NUTS level 3 initially required beginning with SDK 1.10, and now, with SDK 2.1, only NUTS level 2 is necessary? 

Answer: NUTS level 3 has been required since the 2019 regulation, not just starting with SDK 1.10. The introduction of NUTS level 2 is aimed at simplifying data entry, especially for large, interregional projects like highways that span multiple areas. Instead of specifying numerous NUTS level 3 regions, using NUTS level 2 allows for broader regional categorisation, reducing the administrative burden. While the detailed granularity of NUTS level 3 can be beneficial, many procurements occur at a higher level, which this adjustment accommodates. This change represents a relaxation of the previous regulations, though it requires regulatory updates to implement fully. 

• Which of your sample applications use EFX?

Answer: Currently only the notice viewer uses EFX; the notice editor does not implement live validation.  

• Is it possible to provide an open-source implementation of eNotices2 that directly evaluates EFX expressions on a visual model using the visitor pattern? This would address limitations in the current method of converting EFX to XPath via XML and enhance project integration by offering a native solution. Additionally, an open-source tool for converting visual model JSON to physical model XML would be greatly beneficial. 

Answer: Making eNotices2 open source is not feasible due to its complexity and the effort required. However, we are considering developing a sample application that could be shared, offering similar functionality within a limited scope. We are exploring this option and hope to make progress over the summer. Collaboration with select eSenders could provide further insight into how we might address this need. We will provide an update during the next eSender workshop in June. While fully open-sourcing eNotices2 is unlikely, we're committed to finding ways to share valuable resources and support our community. 

Regarding the internal implementation that evaluates EFX expressions more directly, we recognise the limitations of the current method and are interested in exploring solutions. Part of this is already implemented in the notice editor sample application, allowing it to generate a physical model from the visual model. This feature enables users to create, fill in, and submit forms, resulting in the corresponding XML output. We acknowledge the need for comprehensive documentation to facilitate its use and are working on allocating resources to complete this solution. 

We encourage the individual who raised this concern to get in touch, as they may provide valuable context that could aid in resolving these issues. We are keen to rework certain aspects of eNotices2 and will be actively discussing potential improvements.  

[Relevant GitHub discussion: https://github.com/OP-TED/eForms-SDK/discussions/1073#discussioncomment-11408941] 

• Will dynamic validations be mandatory in SDK 2.0, and are they driven by data quality needs or regulatory requirements? With potential risks in migrating to SDK 2.0, what incentives exist for users to adopt it earlier?

Answer: Dynamic rules in SDK 2.0 are designed to enhance data quality by reducing errors, such as incorrect notice links. While there are no regulatory mandates for such improvements, the demand for high-quality data is strong. Our goal is to implement only a few dynamic rules to avoid creating barriers to adopting SDK 2.0. For example, a dynamic rule would help ensure correct notice linking, minimising common mistakes. While comprehensive dynamic validations add value, we’re cautious not to burden users with excessive requirements in the initial release, focusing instead on incremental improvements. 

• Are there plans to introduce more warn-type error messages in the future? 

Answer: Currently, this is an open issue for consideration. We aim to extend lawfulness checks using algorithms that would help identify notices needing manual review, acting as a form of warning, though not via Schematron. In the previous eSentool system, warnings showed limited impact on data quality, although some did help improve rules on the sender's side. In the past, new rules were introduced as warnings before becoming errors in subsequent releases to provide foresight. However, it remains unclear if these warnings are effective, as they often went unnoticed. To improve this, we could focus on providing more detailed consultations and advance notice of future rules, aiding users in preparation and compliance. 

• There is a warning in the official name field (BT-500-Organization-Company) indicating that it should not contain the word 'test.' The word 'test' has different meanings in various languages, which can cause problems. Why was this implemented? 

Answer: A new warning was introduced in SDK 1.13 to address the issue of eSenders or end users inadvertently publishing test notices in production, often with 'test' in the organisation name. This situation led to undesirable publications in the official journal. By flagging the word 'test,' we aim to identify and manually review these cases to prevent such occurrences. While we acknowledge that some legitimate organisations, like "testing.com," might be flagged, these incidents are infrequent. Our team can verify and approve genuine cases within one working day, ensuring minimal delay in publishing. In the future, we aim to enhance our system with algorithms that can more broadly identify suspicious entries, extending beyond basic keyword checks. 

• We have developed a partial solution to compare two versions of the SDK, specifically focusing on field.json files. We're currently testing it and plan to share it with the community. The goal is to reduce false change detections and allow results to be exported. Is this something that could be integrated into existing tools or systems? 

Answer: Your initiative to create a solution for comparing SDK versions is commendable. Collaboration on such tools could enhance our collective toolkit, leading to more efficient processes for all users. We are open to integrating such innovations into existing tools, where feasible and encourage you to get in touch and share your progress, as contributions like this are always welcome.

• The release notes indicate changes, such as "Update existence rules for fields related to Procedure Type (BT-105)," but don't explain why or how these changes were made. Could you link tickets or related documentation to help those working on systems that aren't 100% metadata-driven? 

Answer: Our internal tickets often contain extensive details and discussions, making them unwieldy for direct external reference. However, we recognise the need for more transparent communication of changes, especially for those updating systems manually. We are exploring ways to enhance the SDK Explorer to display detailed rule changes, including line-by-line differences in EFX, which are not captured in the high-level release notes. This approach would not rely on Schematron and could significantly ease the implementation process for developers. We invite any suggestions you might have on how to best implement this feature in the SDK Explorer, as it could benefit the entire community. 

• To your knowledge, has any eSender utilised Large Language Models (LLMs) or AI tools to expedite the SDK upgrade process? We would love to hear about any instances where these technologies have been beneficial. 

Answer: We are not aware of any instances where eSenders have used Large Language Models (LLMs) or AI tools to expedite the SDK upgrade process. No participants indicated otherwise during the event.

• We use the eNotice2 Preview to understand field structures. For IPI, this is restricted since the fields are hidden without "IPI=true." Could the IPI section be made visible by allowing "IPI=true," even if there is no Implementing Act and the section cannot be completed? 

Answer: Currently, we cannot enable the "IPI=true" option because it could lead to buyers mistakenly declaring IPI measures that don't exist, causing confusion and potentially incorrect information in the system. The IPI indicator must remain false until an actual IPI measure, such as the case for Chinese medical devices, is available. Once this occurs, we would patch SDK 1.13 to make the IPI fields visible in both preview and production and remove the rule enforcing the false IPI indicator. In the meantime, you might experiment locally with your SDK to explore how the fields might appear, but officially opening this option isn't feasible right now. 

• Many national stakeholders have reported challenges in generating and dispatching eForms on the same day. For organisational reasons, they would appreciate a longer validity period for these notices—such as generating the eForms notice today and scheduling its dispatch within three or four days. 

Answer: It is possible to manage the timing of eForms publications by using the "preferred publication date" feature. This allows you to generate the form and send it to us, requesting its publication on a later date. Additionally, in eNotices2, you can draft and complete a notice, submitting it only when it is ready or needed. The dispatch date (BT-05) should reflect when the buyer sends the notice for publication, as deadlines are calculated based on this date. It is advisable for eSenders not to hold onto notices before sending them to TED. If there are specific challenges or situations where difficulties arise, please let us know so we can address them appropriately. 

• IPI is in SDK1.13, but no measures are implemented. When will they be available? 

Answer: Currently, there are no IPI measures available in SDK 1.13 because there is no implementing act for IPI in place. The IPI code list exists as a placeholder. A report on medical devices from China, published in January, might eventually lead to an IPI measure. If this occurs, the IPI measure would likely be released as a patch to SDK 1.13. Although the framework is present in the SDK, the rules would need to be adjusted to activate and use these measures. As such, users with the existing data structures will be prepared once these adjustments are in place. We will share updates and links to relevant documents as they become available. 

• Currently, if we were to send a notice with IPI information, would it be rejected by the API/CVS? Will eSenders be notified once IPI data is accepted, and what is the expected duration between the IPI implementing act and the release of an SDK version with IPI enabled and use considered mandatory? 

Answer: Currently, SDK 1.13 has rules that prevent the submission of IPI information. If a notice is sent with the IPI indicator set to true, it will be rejected by the API/CVS. Once an implementing act for IPI is in place, we will add it to the IPI code list and remove the rules that currently block these submissions. This will involve releasing a patch to SDK 1.13, which we aim to complete within a few weeks after the implementing act is established. While there won't be a direct notification to eSenders, you will be able to see the changes via SDK patches on GitHub, indicating that the IPI measure has been added. Keeping up with the latest SDK patches is the best way to be informed when IPI data becomes accepted. 

-

Last update: 14 May 2025