Minutes of the TED eSender workshop (20 June 2024) 

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. 

Recordings of the live sessions and presentation slides are available in the agenda section. 

Questions from the participants: 

• Is the end of lifespan for SDK 1.7 still 30 September 2024?

Answer: The new extended lifespan for SDK 1.7 is 28 February 2025; we have updated the documentation and TED API (CVS version range operation).

• If the legal deadline for SDK 1.10 is 28 February 2025, why does SDK 1.11 have more months? Are all legal requirements included in SDK 1.11? 

Answer: SDK 1.11 does not meet the legal requirements of the December 2023 amendment due to changes in exclusion/selection criteria and FSR, which are addressed in SDK 1.12. We recommend upgrading to SDK 1.12, as the transition to SDK 1.13 will then be minor. From there, you can gradually implement additional features from the amendment, such as IPI, voluntary forms, or using Review information. TED will not block submissions in SDK 1.11 until after 28 February 2025, as each SDK version remains active for at least 12 months. 

• Is SDK 2.0 still planned? If so, will it introduce breaking changes on the structure of form sub-types description, fields and validation (xsd and schematron) files? 

Answer: We plan to resume work later this year, with the aim of releasing SDK 2.0 in late 2024 or early 2025. The focus will be on EFX, though the XML structure will remain unchanged. While the EFX rules may evolve, the underlying logic will stay the same. For more details, visit the roadmap. You can also track the SDK 2.0 development on GitHub and find information in the EFX toolkit. We aim to avoid breaking changes, but some fields will become obsolete with the introduction of business entities and will need to be removed. Business entities were included in SDK 1.12 so there is enough time to adapt before SDK 2.0. 

• When will SDK 1.12 be available in preview and production environments? 

Answer: SDK 1.12 was released in July (Release eForms SDK 1.12.0 · OP-TED/eForms-SDK · GitHub) and was activated in Preview shortly after its release. We aim to activate SDK 1.12 in Production by the end of August when TED website is also ready with the corresponding changes. 

• Will SDK version 1.13 be available in October? We are supposed to have it on our platforms by early 2025 (28 February). 

Answer: We plan to release SDK 1.13 by the end of October. In the meantime, consider analysing or implementing SDK 1.12. The implementation of the Energy Efficiency Directive and IPI depends on other parts of the Commission and requires input from various countries. The process for Reviews also differs across regions. We need this input to finalise the codelists and other details. Our goal is to have the structures ready, but alignment from a policy perspective is essential. 

While we have defined the scope and know what needs to be done, we require stable business policy specifications to complete the work. We will share release candidates when they are ready. 

• Regarding the tooltip for OPT-100-Contract in the CAN subtypes, shouldn't the reference be to the contract notice that announced the framework agreement?  

Answer: For a contract within a Framework Agreement, the reference should be made to the Result Notice where the Framework Agreement was awarded. The Contract Framework Indicator (BT-768) distinguishes between a Framework Contract (BT-768 = false) and a contract within a Framework Agreement (BT-768 = true). 

If the notice concerns the Framework Agreement itself, BT-768 must be set to "false” and OPT-100-Contract is not permitted. If the notice concerns a contract within a Framework Agreement, BT-768 must be set to "true” and OPT-100-Contract should refer to the Result Notice that details the Framework Agreement. 

If both the Framework Contract and the first contract within that Framework Agreement are published in the same notice, each must be treated as separate contracts. The contract for the contract within the Framework Agreement should reference the same notice where the Framework Contract is found. 

See also the relevant GitHub discussion. 

• We are in contact with DOFFIN and Norwegian organizations. Norwegian translations should be added to eForms SDK at some stage as per international agreements. Is there any plan on when (in which SDK version) this will happen? 

Answer: There are no plans to add Norwegian translations in the SDK, as it is not an official EU language, nor do we have the translation capacity for it. OP will consult with DOFFIN to determine what is feasible, including from a technical standpoint in the SDK. 

• If there is a new Change reason to suspend, what type of validations need to be applied? Is this treated as like any other change notice e.g regarding rules for referencing the previous notice using ChangedNoticeIdentifier?  

Answer: From a notice point of view, there is no suspension; the procedure can be ongoing or awarded with or without winners. There is a "cancel intention" change notice, which allows the buyer to indicate "we may want to cancel this procedure" but for all intents and purposes, the procedure remains ongoing. There will be no validation rules in CVS, leaving it to the buyer to decide how to use it, depending on national practices. 

When using the new "suspend" option in the change notice—i.e., "Procedure suspended due to a complaint, appeal, or any other action for review"—you will need to refer to the previous notice being changed and publish the change notice as usual. There are no specific rules limiting this to a particular type of notice. A change notice indicating suspension can be published, updating the procedure to show that it is currently suspended. The process can conclude with either awarding the notice or not, depending on the outcome. 

The "cancel intention" option is used when it is known that the procedure will not have winners. You might move from suspension to cancel intention before publishing a final result. The use of these options is at the buyer's discretion and may vary based on national practices. This feature was added to align with practices in Member States that use it nationally and sought the same level of transparency at the European level. 

• Will the eforms-notice-viewer support E1-E6 when they are implemented in SDK 1.13? 

Answer: Yes, SDK 1.13 will include view templates for the new forms, and all viewers using EFX templates will be able to display them. 

• Will SDK versions 1.12 or 1.13 include the EFX for the new voluntary forms E1-E6? 

Answer: The forms, along with some EFX and Schematron rules, will be included in the October release of SDK 1.13. While the rules will be less comprehensive due to the inability to apply certain directives, they will still ensure a degree of consistency. We will review existing practices, as some Member States are already using these forms at national level. 

• Will the voluntary forms have only basic schematron validation? Will there be fewer rules on the voluntary forms and thus a lot less schematrons? 

Answer: Our general intention is to limit the rules to what is needed for a coherent notice, without the need to comply with any particular directive, as well as keep them relatively flexible since we are not aware of national requirements you may have for below-threshold notices. We're discussing with some Member States that might have started implementing a version of the voluntary forms nationally, to see if they have any rules which are useful. 

• How will the voluntary forms be displayed in TED? Will there be a dedicated section and explanatory text for end users stating that this is voluntary publication not falling under EU Law? 

Answer: There will be individual views, and the template for viewing on TED or TED Viewer will differ. Though they serve the same function, the most significant difference will be the legal basis. End users can search by “Legal basis” on TED. Normally, you wouldn’t use legal bases like Directive 2014/24, 23, or 25 for voluntary competition notices. Instead, you should use "other" and possibly include a reference to your national law. 

We might need a rule to prevent publishing a voluntary notice under the wrong legal basis. Highlighting legal bases more clearly could help clarify these distinctions. 

• Are we close to having a stable release of the SDK so that maintenance is limited to updates in NUTS and CPVs? 

Answer: One of the key drivers of eForms amendments is sectoral legislation related to procurement notices for reporting and compliance, such as CVD, FSR, IPI, and EED. While amendments to the eForms regulation will continue, the Commission aims to keep future changes limited and simplify the annex. 

We are also seeing a slowdown in non-regulatory changes. SDK 1.11 was the last version to introduce Conditionally Mandatory/Forbidden rules, while SDK 1.12 focused primarily on regulatory changes like FSR and exclusion/selection criteria, along with optional enhancements like business entities. There will be ongoing improvements, such as simplifying how unpublished fields are handled, enhancing data quality, updating codelists (e.g., Croatia adopting the euro), refining screen/PDF layouts, rule logic, messages, translations, and more. 

Regarding NUTS 2024, they will be included in SDK 1.13, while CPV will remain unchanged for the foreseeable future. 

Technically, the SDK itself has been stable since its introduction in August 2022 and will remain unchanged until 2025, with only content improvements made without altering definitions or concepts. 

• Will OP continue to extend SDK version lifespan or is this an exception? 

• Currently, I need to update twice within a 12-month rolling period, as each SDK is released with a 12-month expiration date. Although there is flexibility to update whenever needed, the constant deadlines can make it feel otherwise. Specifically, when deprecating an API, I provide customers with 12-month notice. However, the SDKs often come with deprecation notices already in place, which creates ongoing pressure. While I understand the need for frequent updates, extending the lifespan of SDK versions to 18-24 months would be beneficial. This extension would allow more time for planning and building necessary contingencies, reducing the urgency and pressure associated with updates. 

Answer: The lifespan extensions are an exception to allow eSenders time to upgrade (in most cases, their first upgrade since going live). We’d like to aim for standard 12-month lifespans in general, but the option of extended lifespans will be used if needed. In principle, each SDK is stable and eSenders should plan to upgrade once a year. 

When we release an SDK, it comes with a 12-month transition period, which aligns with what you would offer your users. No SDK has been deprecated in less than 12 months. The only change we make after this period is discontinuing patches, as maintaining patches for all active versions is not feasible. 

During an SDK’s standard lifespan, we provide updates and patches. After this period, we cease patching the SDKs due to resource constraints. However, the extended lifespan allows you to continue submitting notices for an additional six to twelve months beyond the standard lifespan, allowing for up to two years for implementation. 

The expiration dates help us manage our resources effectively, as maintaining multiple SDK versions is resource-intensive. In summary, the standard lifespan supports our resource management, while the extended lifespan gives you extra time to adapt and continue submissions. 

The SDKs remain available if they comply with current regulations. If regulations change and the SDK no longer meets legal requirements, it needs to be removed from use and deprecated. The 28 February 2025 deadline is due to a recent regulatory amendment with an unfortunately short transition period. 

The tight deadline was driven by political pressures and ongoing discussions about foreign subsidies, which resulted in unrealistic timelines. Moving forward, the goal is to extend the lifespan of SDKs if that is required to offer better stability and flexibility.  Future regulations will likely also feature more generous deadlines to prevent such difficulties. 

Your clients may also need to request a new SDK to comply with updates such as the Energy Efficiency Directive. While the old SDK will remain usable, the new version will be essential for meeting evolving regulatory requirements and user expectations. 

• How does one generic email address relate with best practices in identity management? How can one identify who did what? Providing one username/ password is against the ISO27001 Information security norm. That will be a problem in our yearly ISO27001 certification. Login should be able to be tracked to a natural person. Also, forcing multiple users to use one account is also forcing them to share one password, which is bad security practice. 

Answer: From OP’s point of view, each eSender exists as only one EU Login account, email address and API key; the eNotices2 user interface should not be used by eSenders. It’s up to the eSender to manage the identity on their side. We will see what could be changed but it’s unlikely to happen this year. 

• We got an email that we need to log in every 90 days or our eNorices2 account will be deleted. This is stressful, because usually we would only use the account to get the API key. How can this be changed? 

Answer: If you received this email, it means you are not recognised as an eSender in eNotices2 because you have not yet used the TED API with this user. Users marked as eSenders in eNotices2 have their accounts preserved even if inactive and do not receive these notifications. 

To be recognised and “flagged” as an eSender, you need to make at least one valid API request using the key generated from the TED Developer Portal. This key must match the EU Login accounts used in both the Portal and eNotices2. If you need further assistance, please contact us with your username. 

• What will change with v3 of TED API? Will there be new information? E.g. currently "expectedPublicationDate" gives the requested publication date instead of the date that actually matches the publication calendar of TED, which should be improved. 

Answer: The “expectedPublicationDate” is assigned by our internal system based on the OJS calendar; the preferred publication date can coincide with the one assigned by our system, but not necessarily. There are no issues about this and "expectedPublicationDate" functions as expected.  

The change in v3 of TED API consists of harmonisation of the endpoint URLs by using a single domain name and choosing better names for some parameters. There will be more information on this in due course. 

• When will the eSender changes be in production (e.g. receiving a copy of the email that is sent to the buyer?) 

Answer: Since 16 May 2024, the eSender is in copy of all emails, whereas the buyer (“noticeauthoremail” in the metadata that eSender is obligated to provide) is the main recipient. 

• How should we handle the submission of big notices (> 3 Mb) that time out? Do you have news about increasing the timeout (only one minute now)?  

Answer: OP will discuss and decide at a later stage whether there should be limits imposed on the number of lots and organisations. Regarding limits in general, based on our experience, the timeout is the first limit to be reached. There isn't a specific limit for the file size; the biggest notice we have published so far was over 20 MB. For any request to our APIs, we have a timeout of 3 minutes, and this will not/ cannot change to exceed the 3-minute limit. This applies for API requests made directly to CVS, requests to the publication/submission API, and also for TED Viewer 2022. 

The time spent validating and submitting a notice does depend on the number of lots and the number of organisations, but those are not the only factors. Other factors are: 
* The type of notice: a result notice has more information to validate than a competition notice with the same number of lots and organisations. 
* The number of other types of entities: buyers, tenders, tendering parties, contracts, etc. 
* The number of references to entities: we check that the identifier in each reference corresponds to an entity in the notice. 
 
We are constantly working on reducing the time required to process notices, which then allows us to process bigger notices before the timeout. This includes improvements in our applications, and changes in the content of the eForms SDK. For example, the restructuring of the Schematron files in SDK 1.10.0 significantly reduces the time needed to validate large notices. 
 
For larger Result notices, OP’s recommendation is to break them up into smaller notices; that may reduce the possibility of a timeout and also make the notice more legible for readers and end users. 

As there are many factors at play, should you get a timeout on a notice you wish to publish, please contact us on a case-by-case basis. 

See relevant FAQ. 

• Will there be sample code for using business entities? 

Answer: The only way we can provide sample code is by incorporating business entities into our Notice Editor sample application. Due to a lack of resources, it may take some time for these changes to be reflected in the sample code. There will be documentation released in due time for eSenders to start working on this.  

• When will business entities become mandatory, when the use of SDK 2.0 becomes mandatory? 

Answer: SDK 2 will become available (but not mandatory) in Q1 2025. SDK 2 will become mandatory after no version of SDK 1 remains active. This will give you enough time to update your systems. 

• The rid of IDs for SDK 2 – what OP considers redundant – generates a huge additional job for us to rewrite the summarised logic for our statistics module. Please consider it to keep the redundancy. We understand the need for maintenance and improvements, but the total amount of workload to stay up to date at this pace becomes massive.  

Answer: We cannot – and should not – keep redundant information in the next major version of the SDK. We will keep it in place for all versions of SDK 1, but in SDK 2 we will remove the redundant fields. eSenders can change at the pace they want. The metadata structure has remained stable since August 2022 and won't change until Q1 2025, so you have time to adapt. 

• Will the business entities included in SDK 1.12 be reflected on the UI of eNotices2 when this SDK version is also implemented on the application? 

Answer: No, we are at the very early stages. We expect to see the business entities in eNotices2 UI sometime in early 2025. 

• Today I implement the newest SDK version (1.11). It takes me 2 months (Jul & Aug) before go-live in early September. I must do the same in January, so that by April I am updated. And then the same again. This change frequency and the amount of rules is unique to eForms; TED legacy and UK's FTS are more manageable. Why? 

Answer: There are bound to be amendments to the eForms regulation as well as improvements and changes for better data quality, codelists, layouts, rule logic/ messages, translations etc. but the frequency of the SDK updates is also likely to be reduced as the SDK (and eSender systems alike) mature. TED legacy XML covered fewer forms and fields and had matured (and still required a schema change at least every year).  

From a policy side, the Commission (DG GROW) will aim to create a governance document to clarify how amendments and update-timelines are handled, making them more predictable for eSenders. We should have originally planned for a longer transition period, but this was overlooked as everyone focused on the initial eForms implementation. In the future, we will try to ensure transition periods are more generous to facilitate easier upgrades for service providers in Europe. We can also try to avoid having many amendments to add new concepts. The difference is that Member states and policymakers are increasingly interested in data, which affects the lifespan and frequency of updates in research forms. There are both regulatory and technical drivers behind these changes. 

We introduced business entities in SDK 1.12, even though it wasn't mandatory, because they offer added benefits. SDK 1.12 includes business entities for system improvement and regulatory changes for reporting, such as simplifying the exclusion and selection criteria. Users can now refer to procurement documents or ESPD without filling in all the exclusion or selection criteria. 

Without eForms, we would need multiple parallel systems for different regulations, which would require separate applications for reporting. By leveraging eForms, we consolidate efforts and costs. 

For non-regulatory aspects, the aim is to provide a better SDK that empowers users to build applications more efficiently. The reason we created the SDK to begin with and took this approach is so that you can optimise this process by using metadata-driven applications. The SDK offers more than just schemas and basic tools; it facilitates metadata-driven applications. While SDK 2 will introduce breaking changes for the first time, most updates are manageable and support ongoing improvements. The conversation around these changes will continue, and we acknowledge the challenges, but it's important to plan for change. 

Regarding the UK, we cannot comment on how third countries handle procurement notices. 

• We are looking for a more stable SDK version. The cost of implementation of different SDKs demands a huge amount of resources, not to mention this business field introduction, which is a structural modification to our analytic logic.  

• The problem is not that there are too many updates of the SDK, but that new concepts are introduced (and others are removed): if only the structure of the metadata were stable, that would be manageable, but introducing new concepts like Business Entities poses a problem. 

Answer: We know that SDK upgrades can involve a lot of effort, even if your systems are metadata driven. We don’t have much control about regulatory updates, but we do believe it’s useful to provide incrementally better SDKs (and in future, possibly also simpler SDKs). The eForms SDK also allows more options to upgrade to the active SDK version of your choice, which was impossible with the legacy TED XML schema. But we have noted the general demand to keep SDK versions active for longer. 

Business entities address a key issue—filling forms and linking pieces can be difficult, but this solution gives you ample time to adapt. The structure of the metadata hasn't changed since August 2022 and won't change until Q1 2025, so eSenders have three years of stability. The impact depends on how your system manages schema changes, but the schema's description remains consistent. To use precise language: the metadata structure is stable. 

• Is there a legal basis for adding business rules only for data quality improvement? For example, requiring zip code for touchpoints. It conflicts with our aim to reduce the administrative burden for publishing tenders. 

Answer: The requirement for good quality data is not explicitly stated in the procurement directives, however, the eForms regulation does specify mandatory and conditionally mandatory fields. The conditions themselves are not in the regulation, but the intention is to collect and publish complete datasets. The postcode field is a free text field that could hold any value if the buyer really doesn’t want to provide information that they probably have, though there are other required fields that will add a certain effort for buyers in exchange for better data. 

• How is the resource situation in your Helpdesk? Sometimes it takes several weeks to get an answer to our questions. What is an approximate timeline before getting an answer? 

Answer: The TED helpdesk has been very busy supporting users of eNotices2 web interface and the new TED website, so you might not have received a reply as quickly as we would have liked. As announced on various occasions, if you have technical questions about the SDK, you can reach the Publications Office teams (and other eSenders) via GitHub discussions: https://github.com/OP-TED/eForms-SDK/discussions. If you have an urgent operation issue, you can include OJS-ESENDERS@publications.europa.eu in copy of your email to the TED helpdesk. 

• For physical meetings we would appreciate having information as soon as possible so that we can plan ahead. 

Answer: We understand you need time to arrange approvals and travel. We aim to finalise the dates no later than September to allow for planning. We're already discussing it to meet both your needs and ours. 

• Why is there so much delay in SDK delivery? Planning seems out of control, it's a bit hard to deal with updates. 

Answer: Planning has been challenging, but we've tried to be clearer this year. After announcing changes in March, we combined two SDKs for regulatory updates and business entities, which delayed the release from May to June. The delay was mainly due to discussions on the foreign subsidies regulation and finalising the codelist. 

We're now planning for an October release. While last year was more hectic, we're striving for better clarity this year. You still have flexibility in when to adopt the SDK.  

• Since SDK version 1.11, when working with change forms, the sections have become mandatory to localize the changes. This means that if you modify a submission date, you need to specify the change for each individual lot. For example, if there are more than 50 lots, you must signify all the LOT-XXXX numbers. Why can't we have an enumerated list that says all the lots? 

Answer: In eForms, much information has been moved to the lot level, meaning elements like submission dates may appear multiple times (e.g., 50 instances). If you need to change one, you must update each instance individually. From an SDK and rules perspective, you don't have to link every change to each lot; there’s some flexibility depending on the buyer’s approach. 

In the future, this could be managed at the business entity level, enabling more streamlined changes. For instance, when updating submission dates for 50 lots, you could specify the procedure section as the area being changed and note in the description that all submission dates have been updated, without referencing each lot individually. However, each lot’s submission date still needs updating, as there’s no collective "lots" entity—only individual lots. Although this adds some overhead, your application might be able to automate the process. 

• Do you plan to introduce a delay in SDK deployment between Preview and Production environments? It would give us some time to implement and test our software. 

Answer: We generally aim to release both preview and production SDKs simultaneously, although it's more challenging on our side because the TED website isn't always able to keep up. Ideally, having Preview and Production aligned allows for smoother transitions. We understand the value of having something available in preview before it goes live in production, as it gives users a chance to test out the updates. However, once it's in Production, it doesn't immediately impact eSenders unless they are actively publishing in the new version.  

If your concern is from the perspective of a TED data reuser, the situation is different. For instance, once eNotices2 is updated, all notices in the system will switch to the latest SDK with little warning. Some countries might take longer to adapt, but the switch for eNotices2 happens immediately, which can be challenging for data reusers. The XML might change from one day to the next, leaving little time to adapt. While we strive to get SDKs out quickly to users, we understand that this can be awkward for reusers. There might be room to consider keeping Preview and Production releases slightly apart, perhaps by a week, to allow more time for adaptation. 

Suggestions from the participants: 

• Some tips for OP to consider: 
  1. separate technical updates from regulation (functional) updates, 
  2. group multiple changes in one release (e.g. instead of having SDK 1.7. 1.8 1.9 etc., combine it all in one release. 
  Combining multiple changes into a single SDK release can simplify management and extend support periods. For example, merging changes from versions 1.7 to 1.11 into one release reduces the number of releases to manage, making the process more cost-effective and less complex. 
  In the Netherlands, we’re moving directly from version 1.7 to 1.11, as intermediate versions are not usable for us. This situation highlights the benefit of combined releases. 
  Separating technical upgrades from functional changes could also ease the transition. For instance, if you need to update to version 1.12 to comply with new regulations but also require  new technical features, the process can become overwhelming. 
  By distinguishing between regulatory updates and technical improvements, you can manage these changes more effectively. 

OP’s  comment: The size of the SDK release you adopt depends on your update strategy. You can opt for incremental updates by upgrading with each release—such as every three months for four releases a year, or every six months for two releases. Alternatively, you can choose to upgrade all at once for a major update. 

This year, we have fewer SDK releases compared to the five from last year, with three releases in total: 1.11, 1.12, and 1.13. In the future, there may be only one regulatory update per year, depending on political pressures. 

We are also considering the possibility of separating regulatory and technical updates into different releases, depending on timing and capacity. In March, we announced two SDK versions: 1.11, which included additional rules, and 1.12, which incorporated those rules along with business entities. Ideally, there would have been a clear separation between technical and business updates. However, due to overlapping developments, both types of updates were combined in the 1.12 release. 

Regarding bundling SDK releases into fewer, larger updates, this might seem simpler, but it comes with challenges. Limiting releases to one per year or every two years would mean implementing many changes at once, increasing complexity and pressure. 

Frequent, incremental updates allow for gradual adaptation, making the process more manageable despite the higher number of versions. Although it may seem overwhelming, this approach typically proves more practical. 

A "big-bang" approach could complicate transitions, as users would need to handle many changes simultaneously. Despite the perception that frequent updates are more complex, they often offer a more manageable solution. 

• Changes should be related to functional changes. Implementing an SDK is unpredictable for us even after studying the release notes. We're encountering significant challenges with automatic testing and integrating new SDK versions, especially when transitioning from version 1.7 to 1.12. Versions like 1.8 and 1.9 introduced critical issues for us that hindered successful implementation mainly due to the addition of complex schematron rules, such as requiring email addresses or phone numbers, which conflicted with local regulations or existing systems. 

OP’s comment: This situation highlights how SDKs often become the vehicle for expressing changes that were not communicated or described elsewhere before, leading to unexpected challenges. This issue reflects broader business and regulatory maturity and though not purely technical, there is a correlation between the number of SDKs and the complexity eSenders face. For example, eSenders may have to review multiple release notes to understand the changes when updating across several versions. This can be cumbersome, especially if jumping several versions at once. If there were fewer versions with consolidated release notes, it would simplify the process and reduce surprises. Ideally, after SDK 1.11, we hope to move past the initial wave of new rules. 

From a policy perspective, the timeline between November and the end of February was too short. Moving forward, DG GROW will develop a governance document to clarify how updates and amendments will be managed, potentially reducing the number of releases and focusing on more substantial changes. The number of releases has already decreased from last year, and we expect this trend to continue. 

Future amendments will affect current implementations. Long-term, we need to simplify eForms, as we currently have 46 forms (as from SDK 1.13) and some rarely are used. Reducing the number of forms will make the system more manageable and consistent. The variety of forms, stemming from minor directive differences, adds unnecessary complexity. If the procurement directives are revised under the new European Commission, they will impact the forms, but the goal should be to harmonise them effectively. 

Already for SDK 1.12, the Commission is taking a new approach by consulting on and sharing regulatory changes before implementation. This includes providing guides that detail new fields and their usage, such as the FSR update with two fields outlined in the 1.12 guide. This allows for discussion and review of rule changes prior to finalisation. Similarly, OP can explore a way to announce rule changes in advance, so you could review them before they are included in an SDK. This approach would allow us to consult on rule changes prior to their implementation, potentially improving the process and ensuring better preparation. 

• As an aspect to consider for the SDK lifespan/ timeline: some countries take an EU request and create a national version of it with additional local requirements, which takes time. Only then can the companies working with buyers implement the new version, so 12 months is tight. 

• New concepts (like Business Entities or future ones) should stay optional as much as possible technically (even for SDK 2), and current concepts should be maintained. I understand that current metadata have been "stable" since 2022 and until SDK 2 becomes the only supported SDK (despite the numerous bugs that we had to cope with until early 2024). However, I can't understand why we should be forced to adopt new concepts (since SDK 2 forces us by dropping "redundant" info) that should stay "nice to have". Apart from that, if concepts are not dropped, moving from one version to another is not that much a problem (although there still is some work to do on unexpected issues). 

-

Last update: 19 August 2024