Publications Office of the EU
Minutes - TED eForms
TED Events Series Header

TED eSender workshops

Minutes - TED eSender annual seminar

 

 

Minutes of the TED eSender annual seminar (13 December 2023) 

 

These are the consolidated questions and answers, i.e. replies to questions posted live during the webinar have been reviewed and may have been regrouped or modified for this written version to allow for a more cohesive and complete response.

Please note that some answers may no longer be accurate, as the Publications Office (OP) has followed up on comments made and may have modified its approach accordingly.

The live sessions were recorded and are available in the agenda section along with the PowerPoint slides of each presentation.

 

Questions from the participants: 

  • Could you share the percentage of the notices rejected due to lawfulness check? What is the average delay time until a notice is published? 

Answer: To date (13.12.2023) 25 notices have been accepted and 1 was rejected, because a buyer from an EU member State used eNotices2 to submit a CEI form, which is reserved for EU institutions. So far, all lawfulness checks have been processed daily with little or no delay to publish. 

 

  • Recently we encountered a new Notice Status: ARCHIVED. Is there any further documentation on how to deal with this status? Which Use Cases are allowed in this status (change notice etc.)?

Answer: The "Archived" status is used by eNotices2 web User Interface (UI) to declutter the users’ list of procedures and notices and, therefore, should be of no use to eSenders who should be using exclusively the API. More information on the Archived status can be found on the Help page

 

  • Which status will the change notice have, if the original notice was ARCHIVED (will the change notices also be ARCHIVED)? Is there any other way how a notice can get into status besides setting it manually via eNotices2 (is there any automation)?  

Answer: There is no automation for this, it is a manual operation by eNotices2 web UI users. This status can only be queried via the API. Please refer to the answer to the previous question. 

 

  • Could you please provide an example of an Archived status. How to treat it? Does it mean always Published or not guaranteed? 

Answer: All procedures/notice groups can be archived by front-end web UI users only. The status “archived” can be queried via API and is displayed on queried notices (that have been manually archived by front-end users). A front-end user can archive a procedure that has notices in it in all possible statuses, e.g., draft, published etc. eSenders should refrain from performing manual actions in the UI.   

 

  • What is a reasonable waiting time for a notice to be published before assuming that something is wrong? We have been polling notices (for publication or rejection) for 14 days, not sure if we're covered or if we should poll for some more time. If more time is needed, what's the recommended time lapse?

Answer: It all depends on whether you have chosen a Preferred publication date that might be beyond the 14 days that you poll.  If you generally publish as soon as possible, you should get a Published status (or Not Published) within 5 days as per TED’s obligation. Once the Expected publication date is made available (as of 28 February 2024 and eNotices2 application version 1.13.2), you can use that to poll until that date. 

 

  • When will the fixes for version 1.10 also be applied to version 1.7, and what is the lead time? 

Answer: Applying changes to older SDK versions is a time consuming and delicate process, as we need to ensure they do not create a negative impact or introduce inconsistencies. There are some minor issues in 1.10.0 (missing translations) so, primarily, we would first want to correct those issues before applying those corrections to older SDK versions, thus avoiding having to go through the process twice. With the holidays coming up, there might be a longer delay than usual, probably in January. 

 

  • What are the possible consequences of displaying notices compiled with SDK version 1.7 using the 'View templates' found in SDK version 1.10? 

Answer: The Viewer application detects the version of the SDK declared in the notice and uses the appropriate View templates. If you use the View templates in your own applications, we recommend using the same version of View templates as declared in each of your notices. Otherwise, it is possible that some items would not display properly. In the specific example you give, of using View templates in SDK version 1.10 to display notices created using SDK version 1.7, the award criteria, procurement document languages and framework values might not be displayed properly. In addition to this always use the latest patch of the same SDK that was used to create the notice. This is because improvements in the view templates to older SDK versions take place via patch versions, e.g., SDK version 1.7.2 has significant improvements over version 1.7.1 and 1.7.0. 

 

  • Are you considering the possibility of allowing and displaying minimal text wrapping options (line breaks, lists etc.) in fields with hundreds or thousands of characters? The current run-on text complicates content monitoring and ultimately the work of the economic operators. 

Answer: Unfortunately, this possibility is not envisaged and although technically possible, it would be very complex to implement potentially leading to negative side-effects on the processing of notices. The UBL schema on which eForms was based does not allow any formatting in text fields. 

 

  • Would you consider the possibility that the visualization endpoint could be switched by a parameter to display negative or unfilled values? 

Answer: With SDK version 1.11, we modified the display to represent some negative and empty values. These changes will subsequently be applied to earlier SDK versions. However, it’s important to note that this won’t apply to all negative or unfilled values. There are no plans to offer a parameter with different views of the same notice. 

 

  • What is the expected end date of SDK version 1.7? Is there a table for the end of validity of each SDK version? 

Answer: Please refer to the relevant page in the TED Developer Docs:  SDK Active versions :: TED Developer Documentation (europa.eu) . Regarding active versions of the SDK, you should always consult the information provided by the TED API version range as the single source of truth.

 

  • Do you know when the SDK version 2.0 will be made available?

  • When will the SDK version 2.0 be made available? It was supposed to be published by June 2023 and it's now mid-December. Is there a definitive release date? 

Answer: SDK version 2.0 should be available towards the end of 2024 or early 2025. Please also consult the SDK roadmap at https://docs.ted.europa.eu/eforms-common/roadmap/index.html.

 

  • Can you explain why http://www is a requirement for BT-505 and BT-508? Can this field not just begin with www. instead? 

Answer: The reason is that a URL must start with the protocol scheme (http:// or https://, etc.) for it to be valid. There is no requirement to also include www (e.g. https://ted.europa.eu is valid). 

 

  • In case of countries out of the European Economic Area, the country codes (e.g., US) were accepted in NUTS-code fields (e.g., BT-507). This seems to have changed due to CVS validation. However, the submit API still accepts them. What’s the reason for this difference? 

Answer: This situation shouldn’t occur as both the API and UI follow the same rules. A potential reason could be that the checking is done by CVS, which might explain why the submission API doesn’t halt the notice. Please note that there is no NUTS code for countries outside the EU or EEA and as such they will not be reintroduced; in fact the UK will be dropped in NUTS 2024. 

 

  • Several county codes have been removed from the NUTS-code list (e.g., US). Is it foreseen to reinclude them in the list? 

Answer: Please refer to the previous question. NUTS don’t exist for countries outside EU or EEA. They will not be reintroduced, but rules are adapted. If the country is not supposed to have a NUTS, then one is not expected to be filled in. Please note that the UK will be dropped in NUTS 2024 (planned for SDK v.1.11). 

 

  • The current display only refers to the GMT time zones as +01:00 or +02:00. Is there an option to include the standard GMT notation in the display or to issue some sort of legally binding announcement on the TED website regarding this matter? 

Answer: The W3C XML Schema standard only allows time zone offsets in date/time elements and therefore cannot change. It’s tricky to go from an offset to a time zone name like “CET” because of daylight savings, but we could see if we can have something in the display to refer to GMT, CET etc. 

 

  • Would it be possible for the HTML and PDF versions displayed by the visualization endpoint to include the BT identifiers? Or at least include an option added as a parameter to the endpoint, so this feature can be turned on? 

Answer: Unfortunately, this is currently not under consideration. 

 

  • Given the importance and oftentimes urgency (when it involves deadlines) of the problems we encounter and which we try to communicate with you, could you provide a platform where eSenders could expect prompter responses to questions like these?  

Answer: Helpdesk receives currently many requests, which may explain any delays. Notwithstanding, we are doing our very best to respond as fast as we can with regards to business or operational issues. Please note that for technical issues about the SDK, you could always use GitHub. 

 

  • Is there a possibility that a future SDK version will be good enough to be supported for longer than just 1 year? 

  • Is it possible to have a stable and final version of SDK which will last for several years? Current practice modes require us to change the version every 2 months. Also, if it happens that we skip a version, we must check all changes to field rules, translations, and final texts, which makes the whole process unbearable.  

  • Is it possible to extend the life cycle of an SDK version so that it can be used for a period of 12 months or longer in national environments? Since the setup time is usually a minimum of 3 months, the life cycle time of an SDK version at TED should be at least 15 months (or even longer). 

Answer: While each SDK version introduces enhancements, there are business or legal considerations that typically prevent an SDK from being active for several years. You can read more about the standard and extended SDK lifespans at https://docs.ted.europa.eu/eforms-common/active-versions/index.html.

 

  • Should mandatory but 'pointless business terms' be re-enabled or removed from the legislation to avoid eSenders and buyers violating the law? 

Answer: The business meaning of these BT fields is enforced by the eForms schema (the structure of the XML), so there is no requirement to implement these Fields in the XML notices. In other words, by using eForms to publish the procurement notices, the law requiring these BTs to be used is being followed. 

 

Answer: We can confirm that submissions of (TED-XML) notices via the legacy eNotices application will be closed on 31 January 2024. 

 

  • Once a notice is cancelled, it is marked as ‘cancelled’ but remains visible. The doc says, "In case of many clerical errors, it will be possible to cancel a notice, which will cancel the notice itself and make it null and void, but this will not cancel the procedure." Will this be corrected, so that cancelled notices will be removed from TED? 

Answer: No, a notice that has been published in the OJS remains published permanently (online on TED for 10 years, then offline).  A notice that is cancelled will exist twice: in the form of the original notice, plus as a Change notice that says it’s cancelled. So, this is another reason why “cancel” Change reason is not a recommended option. To cancel (end) a procedure or lot, the buyer must publish a Result notice with no winner chosen.

 

  • IDs should be unique within the notice. What happens within a family of notices? Do you check if a LOT is awarded and afterwards announced as unsuccessful? 

Answer: We are planning to introduce some checks to ensure that the change notice and continued procedures are consistent. Those will be kept to a minimum (at least initially). 

 

  • The following is a country-specific issue – in Italy, public authority employees mainly fall in the 50–59-year-old bracket and generally have little IT skills. Don’t you think that eForms are too complex and in their compilation too much importance is given to tech rules rather than law?  

Answer: While we understand that eForms were not designed with the end user in mind, this is what the Member States accepted during consultations and should have made provision for. While many rules appear to be too technical, there are other rules that are trying to enforce the directives or simply make common sense. 

 

  • Where can one find the published changes about rules between the different SDK versions? 

Answer: These can be found in the release note, since each release summarizes the rule changes in each SDK, which can also be seen in more technical detail by comparing the SDK components. For further information please follow this link: https://github.com/OP-TED/eForms-SDK/releases. Since the seminar, OP has also released a first version of the eForms SDK Explorer, which you can use at https://docs.ted.europa.eu/eforms-sdk-explorer

 

  • Doesn’t API v.3 necessitate more details? 

Answer: New endpoint URLs will be added in TED API v3., however the current URLs will remain functional during the transition. As always, we will keep you informed in advance of any changes, and we will make sure to plan a reasonable transition time. 

 

  • Are there any plans to improve the integration between eForms and ESPD? Particularly because the current approach does not fully support the variety of possible ESPD versions and use cases. 

Answer: Yes, the December 2024 eForms amendment is a first step towards the harmonisation of codes (criteria) across eCertis, ESPD, and eForms. This will already enhance the connection between these three services. Over the course of 2024, we’ll explore ways to further enhance this integration. As a result, this could also influence future amendments to eForms.

 

  • What kind of subtype is E6? 

Answer: This is the contract modification notice for the 2009 Defence Directive which can also be used for national purposes. 

 

  • Is it still permissible to use the "above threshold" eForms notices or national eForms  (eForms xx) notices for below threshold tenders? since E1-E6 are voluntary? 

Answer: Yes, but it would not make sense anymore and should be discouraged.  From a data perspective this would not be a welcome move and provides ambiguity. In such notices, the buyer needs to encode manually so that it does not fall under the EU Directives. 

 

  • How is it possible that a NUTS code validation gives an error by the Validation API, but not by the Submit API? One example is the code "TEN-0001 - id with whitespace” is marked as an error by the Submit API, but not by the Validation API? Isn't the same validation applicable for both APIs? TED Support does not give a clear answer about APIs.  

Answer: This is because the business rules validation is done by the Validation API, while the Submission API checks also the parsing of XML. We are working to harmonize the two. In this respect, we have opened a discussion on GitHub, where we kindly ask for your feedback: https://github.com/OP-TED/eForms-SDK/discussions/779. The rules for leading and trailing whitespace in identifiers have since been implemented in SDK 1.11. 

 

  • Will the voluntary forms, especially E2, E3 and E4 support all legal bases (2014/23-24-25/EU + 2009/81/EG) and not just "other"? On the national level, it would make perfect sense for e.g., to publish a simplified CN within the legal framework of the standard directive. 

Answer: While we check this out with our colleagues, we kindly ask you to provide us with more information about where to use a simplified CN that fits the EU framework? 

 

  • When we have questions or problems with APIs we are instructed to write to TED support. Very often, the answer provided does not give a direct answer to the questions posed. Moreover, the answers are provided with a delay of days and weeks. We have no information about API lifecycle, developments, and releases. Why isn’t the whole process more transparent?  

Answer: There are two issues highlighted in this question. In reference to the transparency issue, the reality is that the lack of communication is not a question of lack of transparency, but in the absence of significant changes or developments for APIs, we don’t see the necessity for communication. Please rest assured that any future API changes or developments will be communicated before their release. The current version of the API will be supported in parallel with the new version during the transition period.  

The second issue deals with the response delay from TED support and we would like to stress that it is usually not the norm that questions take weeks to be answered. There can be questions that justify a longer response period such as those that involve legal aspects of eForms. Should you notice a delay in response please highlight this delay in the email subject and we will give it our immediate attention. 

 

  • Which SDK version will make Exclusion and Selection criteria optional? 

Answer: The order of implementation of the 2023 amendment is still in its planning phase. The aim is to primarily focus on the IPI and FSR first for them to be available by June and the rest will follow – no later than November 2024. The eForms amendment does foresee rendering these criteria optional in the future, and it will be the buyer who must indicate where to find the exclusion grounds and selection criteria. 

Update: the Exclusion and Selection criteria will be updated in line with the December 2023 eForms amendment with SDK 1.12 in June 2024, along with FSR but without IPI. For more details, please see the SDK roadmap at https://docs.ted.europa.eu/eforms-common/roadmap/index.html.

 

  • When can we expect to receive improved descriptions of fields/BT? 

Answer: The eForms amendment should be published by the end of this year and it is envisaged that BT descriptions in an SDK version should be updated progressively after. 

 

  • According to the legislation, there are numerous BT fields that are mandatory, but which have been identified as 'pointless business terms' in the documentation and are specifically missing from the SDK versions. This practically forces eSenders and buyers to violate the law. In your opinion, which solution is most feasible: Will you re-enable these BTs or will they be removed from the legislation?  

Answer: The business meaning of these BT fields is enforced by the eForms schema (the structure of the XML), so there is no requirement to implement these Fields in the notices XML. In other words, by using eForms to publish the procurement notices, the law requiring these BTs to be used is being followed.  

 

  • For the eInvoicing question [BT-743-Lot] it seems the only acceptable answer that does not generate an error is "Required". When we enter "Allowed/Not Allowed" we receive an error. eInvoicing is not mandatory in Ireland so can "Allowed/Not Allowed" be enabled as correct answers for this question? 

Answer: The rule for eInvoicing was removed in SDK 1.9 (please refer to https://github.com/OP-TED/eForms-SDK/releases/tag/1.9.0). Please contact the Helpdesk with this issue and include an example XML of a notice which generates this error. 

 

  • When an eSender sends a notice, eNotices2 sends an email informing the buyer of the status of the notice. Will these emails change their format to one which is more like those sent by the previous system?  

Answer: Yes, the plan is to improve the emails sent to buyers (the noticeAuthorEmail that eSenders put in their API submission). We will add the Expected Publication Date, which is the date calculated by our back-end system that corresponds to an OJS publication date that considers the daily export and any preferred publication date. 

Update: As of eNotices2 application version 1.14.0, deployed in Preview on 15 May and in the Production environment on 16 May, we have improved the automated notifications regarding the various statuses of notices so that the eSender’s email address is also included in copy of these emails. As part of the improvement, the Publication notification email will include a link to the published notice on TED. 

If you have not done so already, you are reminded that mandatory property “noticeAuthorEmail” in the metadata must be a valid email address and is intended to identify the buyer, i.e. must correspond to the Contracting Authority, so that the Publications Office can notify them about the workflow of their notice, e.g. the publication/rejection of their notices. 

 

  • Regarding BT-765-Lot & BT-766-Lot, is there a layman's explanation of what is meant by the terms used in the drop-down selections? The descriptions for the drop downs in BT-765-Lot are especially confusing for our users and we cannot provide any guidance ourselves because we fail to understand the context. 

  • BT-765 is causing us a bit of confusion about how to support our buyers in answering the question effectively, a clearer description would be very beneficial.

Answer: BT-765 and BT-766 relate to the Framework Agreement Code and to the Dynamic Purchasing System Code respectively. This is ongoing; we will soon initiate the process to clarify the codelists and their respective meanings to provide clearer explanations to facilitate the users’ understanding.

 

  • Are there any plans to set up a change management board which will include representatives of the eSender implementers? 

Answer: The are no plans for a change management board. At the level of the implementation of eForms by the EU Publications Office we communicate and consult through the eSender workshops and GitHub discussions. You may be interested in following policy discussions between the European Commission and Member States at https://code.europa.eu/eproc/eforms.

 

  • Which rules regulate that a form needs to be checked manually? 

Answer: The only manual check that is done on any received notice is for the so-called "lawfulness authorisation". These checks are done following the business rules described here: https://docs.ted.europa.eu/eforms/latest/reference/business-rules/index.html#_lawfulness. If the rules are triggered, a member of TED team will manually check the document and allow or reject it for publication. 

 

  • During the seminar it was mentioned that the new TED web site will be made available at the end of January 2024. Will the old URL be redirected to a new site? What will happen if we point to a notice using the old URL? 

Answer: The new TED website went live on 29 January at the same URL as before. Link: https://ted.europa.eu. The old URLs of editorial pages and notices are redirected to the new URLs. 

 

  • If an error is detected or reported in the eForms implementation of TED what is the stipulated time frame for it to be fixed? 

Answer: If you see any problems with the new TED website, please contact the helpdesk at: https://ted.europa.eu/en/contact.  If there is a technical issue with the SDK, you can raise it via GitHub. 

 

  • To which email address does "Developer Portal email" refer to?  

Answer: If this question refers to the alert about an expiring API key, the email address used for this is the same as that used for the EU login account (same as used for the TED Developer portal sign up). Other email addresses are the additional ones that the developer can add for notifications from OP such as about downtimes, events and other important information.

 

  • In the future would it be forbidden to use PIN for market consultation? 

Answer: No, but it would not make sense anymore and it should be discouraged. OP/CVS doesn’t have the means to check if a PMC is somehow smuggled into the text of a PIN notice. From a data perspective this would not be a welcome move and provides ambiguity. SMEs will not be able to search for PMC specifically (or will not be able to see it all). We (EC/OP/MS/eSenders) can only advertise and encourage the use of the new PMC once it becomes available as voluntary form E1 in SDK 1.13 in October.

 

  • When will the Directives be renewed? Are there any plans to start the work? (as it is likely to take several years). I think that all these sectoral regulations make the Procurement Directives more and more ‘out of sync’. 

Answer: The responsibility of deciding whether to renew the Directives will rest with the new Commission.

 

  • An SDK explorer question: It would be nice to filter by set of given BT fields. This way I could check which fields used in Finland have changed. 

Answer: We agree this would be useful and will try to put this into action. Additionally, we are hopeful for contributions from eSenders in the implementation of new features in the SDK Explorer.

 

  • Will this app allow you to compare rule changes? 

Answer: We acknowledge the requirement in the SDK Explorer and understand that it’s the most challenging aspect to address. At present, though we have plans to tackle this issue, we haven’t yet developed a concrete design on how to effectively navigate through more than 40 000 rules.

 

  • Once the problem with the trailing comma in the URL to the documents is solved, will it be also extended to notices already published or will it be limited solved to future notices only? When will it be solved?  

Answer: The issue with the comma in the URL in TED Viewer 2022 will be rectified for all notices, both those previously issued and those that will be issued in the future.

 

 

Suggestions from the participants:

 

  • We suggest that all the bugs discovered and/or features explained (eg. BT-70, BT-77, BT-736, BT-761, BT-76-Lot - these are missing from the rendering for forms 38-40 due to a bug. This will be fixed with the release of SDK 1.10, and the fix will then be applied to previous SDK versions. These BTs will then appear for your notice in TED.”) would be communicated transparently on the dedicated site (https://simap.ted.europa.eu/web/simap/known-issues-with-the-display-of-eforms-notices), so that buyers could be informed about why the information they clearly provide fails to appear in the published notices. This would relieve eSenders from doing all the explanation and promote transparency on your side. 

 

  • Why not make SDK explorer available online through a URL? This would avoid the need to run it locally.   Update: this is now available at https://docs.ted.europa.eu/eforms-sdk-explorer/.

 

  • In the organizations section, is it possible to move the eSender’s name and address away from organizations list when the notice is published in TED. Suppliers may contact the eSender instead of the contracting authority. eSenders info could also be included as a footnote in the published notice. 

 

  • I would like to see one Directive that applies to all fields and just 5 or 6 notices in eForms - this would be possible without changing eForms…. 

 

  • I think the selection criteria would have to stay as mandatory. They are important to suppliers - much more important than exclusion grounds. On another note, exclusion grounds are missing a question on sanctions (the Russia/Ukraine situation) 

 

 

Last update: 23 May 2024