Annual TED eSenders Seminar

 

The Annual TED eSenders Seminar took place online over two half-days from 12 to 13 December 2022.

These are the revised minutes, 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 OP has followed upon 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.

 

Day 1 – 12 December

Current status of eForms implementation – Karl Ferrand – Publications Office of the European Union 

The transition to eForms started on 14 November 2022. All the APIs (eNotices2, TED CVS, TED Viewer 2022 and TED Developer Portal) are available since then. There is a Preview environment for testing purposes.  

The SDK (Software Development Kit) is available on GitHub. It is a transparent, coherent, standardised and versioned technical specification, and it allows to better manage changes that are coming with eForms.  

The applications went live with SDK 1.3.2; the latest version available is 1.5.1 (it was 1.4.1 at the time of the Seminar). The SDK 1.3.x includes all the 2022 amendment’s fields and changes in the schema and rules. There will be more releases in the future (on average one per month) and more than one version can be valid at the same time, which will allow eSenders to plan when they choose to upgrade. The Publications Office will support each minor SDK version for at least one year and give at least 6 months warning before an SDK version is deprecated.  

There was a survey in November-December 2022 entitled ‘TED eSender: let us know your plans for eForms’. It showed that certain eSenders will develop their eForms systems and applications from scratch, whereas others will upgrade their existing systems. More information about the results of the survey can be viewed in the presentation ‘Current status of eForms implementation’.  

The Office will continue improving the documentation of all the applications. There will be new releases of SDK but it is important to remember that none of the new versions forces the eSenders to implement them immediately. 

 

eForms policy plans for 2023 – Marc Christopher SCHMIDT – DG GROW, European Commission  

eForms were designed to reduce administrative burdens, help businesses to find procurement opportunities, improve the quality and analysis of data (e.g. invoicing), increase transparency, add sustainable criteria and increase data-driven decisions about public spending.  

The Commission Implementing Regulation 2019/1780 was adopted on 25 October 2019. It was amended on 24 November 2022.  

Since 14 November 2022, it is possible to submit eForms notices for publication on TED. The last day of the transitional period towards mandatory use of eForms is 24 October 2023.  

The main improvements and changes in the 2022 amendment are related to: 

• Clean Vehicles Directive,  
• Green procurement criteria,  
• EU funds,  
• Notice Dispatch Date eSender,  
• descriptions and labels.  

There are also other new business terms in the 2022 amendment, i.e. non-disclosure agreement, tender ranked indicator and framework agreement amounts. 

Regarding eForms tailoring, DG GROW emphasised that the stakeholders must first meet with the public procurement decision-makers to define the national approach to the various aspects of eForms (e.g. to use or not the groups of lots). An example on how to implement the green procurement criteria in eForms can be found in the 'eForms policy plans for 2023' presentation.  

In 2023, there will be a second Amendment of the Commission Implementing Regulation 2019/1780. The changes will most likely involve:  

• Foreign Subsidy Regulation,  
• International Procurement Instrument,  
• Energy Efficiency Recast,  
• integration of the five voluntary forms (E1-E5), 
• simplification of annex 2, e.g. not to be forced to have a new amendment when a request comes from a Member State asking for an addition of a new field, 
• additional changes, e.g. improvements on GPP.  

 

Current status of eSentool and data quality – Karl Ferrand – Publications Office of the European Union 

eSentool is still available until 24 October 2023 when it will be replaced by the eNotices2 API. There will be no changes (i.e. improvements or releases) in relation to the TED-XML schema or eSentool until then. TED eSenders workspace will be available until the end of 2023. 

When it comes to the data quality of notices, the four most common validation rules triggered (i.e. warnings) in the period 1/1/2022 – 6/12/2022 in eSentool were: 

• R612 – information about tenders 
• R617 – number of tenders received 
• R609 – Lot numbers not listed 
• R995 – Attention, the schema version will be phased out (obsolete). 

The most common rules to reject notices were: R013 (duplicate No_DOC_EXT) and T001 and T002 (errors in the structure of XML). 

Missing or incoherent text is the main reason for low quality of notices. For more detailed information on the quality of data of notices, please consult the 'Current status of eSentool and data quality' presentation.  

When eSentool becomes obsolete and replaced by eNotices2, the validation (by CVS) will have only errors and no warnings, except for the warning about lawfulness check.  

The Publications Office will progressively set up reporting for eForms data quality based on CVS reports. 

 

Day 2 – 13 December

How to: Common problems, different solutions for traditional vs metadata-driven apps – Ioannis Rousochatzakis – Publications Office of the European Union  

The documentation is being constantly updated together with search improvements. Recent documentation updates include: 

• reorganised content, 
• equal weight on traditional and metadata-driven development, 
• new developer guide.  

When it comes to the creation of notice forms, there are two possible approaches. One is related to traditional applications and the other one to metadata-driven applications. Both have pros and cons and the choice depends on the user needs. More information can be found at: https://europa.eu/!G4q3Yp, and https://europa.eu/!qwfKnT. The summary is in the table below: 

Standard Features	Traditional Applications	Metadata-driven Applications
Fill-in a new notice form	*	SDK
Edit an older notice	*	SDK
Save as XML	*	SDK
Validate a notice (XML)	TED API / SDK	TED API / SDK
Submit a notice	TED API	TED API
Validate while filling-in the notice	*	SDK
Visualise a notice	TED API	TED API / SDK
Import a new SDK	N/A	eForms Core Library
Switch between SDK versions	N/A	eForms Core Library

* read the docs, design your own solution 

There will be certain changes in the future. The main reasons to change anything is the future amendments of the eForms regulation. The impact of implementing a change depends on the type of application that the user is building: traditional applications require manual interventions, metadata-driven applications can be updated automatically. 
SDK will develop further in 2023 but the version SDK 1 will continue being supported until October 2023. The Publications Office estimates that there will be approximately one minor release per month until June 2023. SDK 2 will likely be introduced in March 2023. The main improvements in SDK 2 are related to the EFX and field names. SDK 1 and SDK 2 will be running in parallel.  

 

Ms CRUZ announced that there will be a series of workshops next year, i.e. in February, March, May, September and December. The Office aims to help and might assist even more but it depends on the feedback from the eSenders and on the Office’s resources.  

Ms CRUZ reminded that the XML schema is available since December 2019. The Office decided to share the SDK because it thought it would be helpful to those building or adapting applications to deal with eForms. Whereas the Office advises to use the SDK, there is no obligation to do so. 

 

Questions from the participants: 

Amendments of eForms Regulation:  

• Where is the new eForms extended annex in Excel format with the optional fields? 

Answer: It can be found at: https://single-market-economy.ec.europa.eu/single-market/public-procurement/digital-procurement/eforms_en.

 

• A major customization in eForms is the topic of lots. Lots have been brought to the forefront and now have many more input fields that previously had to be specified across lots. This will tend not to be an improvement for the user as much more input is required. 

Answer: The main idea was to have more structured information about individual lots, e.g. the same IT training services with different locations. 

 

eNotices2:   

• Could you share the link to the eNotices2 application? 

Answer: The link to eNotices2 in the Preview environment is: https://enotices2.preview.ted.europa.eu/home.  
eNotices2 in Production: https://enotices2.ted.europa.eu/home. 
 

• Will the Preview environment always use the same SDK version as the production environment? Can you provide an environment that is always production-like? 

Answer: Currently, both Preview and Production environments are aligned. In the future, OP will aim to keep the Preview environment slightly ahead to Production. 

 

Sample eForms notice: 

• Is it possible to get the number of the eForms notice(s) in TED that Publications Office published as a test? In TED, it is not possible to filter to standard forms from eForms. 

Answer: There are 10 test eForms notices that were published in two OJS issues, which can be used as examples of the new format: 
- 218/2022: 628607-2022, 628608-2022, 628609-2022, 
- 220/2022: 634805-2022, 634806-2022, 634807-2022, 634808-2022, 634809-2022, 634810-2022, 634811-2022. 
 

• Your eForms notice 634807-2022 (open procedure) on TED doesn’t include group of lots. Group of lots has two mandatory fields: BT21 and BT24. Is it not mandatory to include group of lots in notices? 

Answer: BTs are mandatory usually within a specific context. In this case, BT-21 and BT-24 are mandatory in the context of a Group of Lots: for every Group of Lots, both BT-21 and BT-24 are mandatory. But they do not specify whether the Group of Lots itself is mandatory; that is set by the context for a Group of Lots, which is the notice itself. In the context of a notice, Group of Lots is optional. 

 

SDK roadmap and impact: 

• Why are the rules changing all the time (causing new and new SDK versions)? Aren't they known from the very beginning from the regulations?  

Answer: The eForms regulation states which business terms are mandatory and optional in each form. The extended annex of the regulation adds the concept of conditional mandatory, but it doesn’t state what those conditions are (i.e. rules). There are other rules to check for consistency between values which can be derived from the 2014 directives and OP aims to apply those requirements. In summary, the regulation only covers a fraction of what is needed for a detailed and clear implementation. The details are important and can be complicated, like the rules, so some of them are still being improved in each SDK release. 
 

• How many more SDK versions are expected and which of them is considered stable? Will there be a release every month? 

Answer: We don’t know exactly how many SDK versions we’ll have in 2023. Our current release pace is relatively fast while we correct and improve the SDK content but very roughly, we estimate that we might have 5 or 6 minor versions until summer 2023. There will be at least one minor version of more significance towards the end of 2023 if there is an amendment to the eForms regulation. 

Inherently, each SDK version is stable. 

 

• What is OP's commitment to the future and regarding long-term maintenance of the SDK? If it is just an optional tool, is it wise for eSenders to count on it to develop apps? 

Answer: The Office commits to the SDK for its own use and therefore shares it with users.  

 

• It was mentioned that the users don’t need to keep up with the SDK versions. However, why is Preview only accepting a certain version then? Shouldn’t it allow the version 1.0 and all the others?  

Answer: The front-end forms of eNotices2 will work with only one SDK version at a time but the API can support all SDK versions that are valid at the time. 
 

• Can you make a roadmap for the SDK? What will be improved and when? 

Answer: OP is working on it. 
 

• All SDK versions are supported in parallel until they become deprecated. Are we counting weeks or months or? 

Answer: In principle, each SDK version will be supported for at least one year. 
 

• After the 2023 eForms amendment is approved, how long will it take until it is ‘translated’ into a new SDK (and, therefore, the previous versions are deprecated)? 

Answer: It depends on the changes, but it should not take more than a couple of months. However, the amendment doesn’t imply deprecation of previous SDKs. 
 

• Given the current speed at which the SDK evolves, can OP still guarantee 1 year support and a warning of 6 months before depreciation for all versions in use at this moment? 

Answer: Yes, OP will aim to guarantee this support.  
 

• How long is SDK 1.4.1 going to be supported? Since the conditional mandatory rules have been relaxed, it would help us in faster development of the notices with this particular version. It would be good for this version to be supported for long. 

Answer: It will be supported for a year (possibly longer). 
 

• The combination of many new SDK versions and the fact that we don't have to use them is concerning. If we choose the current one, then I am concerned about the quality of the SDK. Our starting point should be an SDK that is almost finished. 

Answer: It depends on what the user needs. If certain rules are not in the SDK, the developer is free to implement all the necessary rules. If a later version of the SDK includes more rules, the developer will have to implement them, but they will be already expressed in the application.  
Example: if the codelist of currencies has obsolete currencies, it is a problem for SDK 1.3.2, but if the user isn’t given the choice to use an obsolete currency, then it is not a problem and they can submit notices in the SDK 1.3.2. 
 

• How to get to know what the latest SDK version is supported in Production? There is version 1.4 but in the presentation, you said Production has version 1.3.2. 

Answer: The supported SDK versions are mentioned on the Preview page at https://docs.ted.europa.eu/home/eforms/preview/index.html. 
 

• When there is a new set of validation rules published - how long can the legacy eForms be used and submitted for publishing?  

Answer: They would be supported for as long as the concerned SDK is valid, e.g. if it is 1.4 as of today, it would be supported for a year. 
 

• When will be the freeze of extending the SDK? Or which version of SDK can be used in October? 

Answer: Anyone who goes live in October 2023 can choose any valid SDK in that time. OP recommends using the latest version of the SDK depending on the go-live date. 
 

• Is there a major version update forced after 9 minor versions? 

Answer: No, there can be multiple digits in the minor version, e.g. 1.10.x, 1.11.x, etc. 
 

• When will the validation rules be reintroduced in the SDK? The current ‘relaxing’ of rules leads to forms full of potential contradictions, which is very confusing for end-users. 

Answer: OP will aim to reintroduce them in Q1 2023. Ultimately, it is the users’ responsibility to put correct data. 
 

• Could an XML include additional information, that exceeds the information from SDK, e.g. information that is valuable for the national eSender, but is not included in the Annex 2 and the SDK? Will this be a problem for the validation of the XML? 

Answer: In principle this is not possible. 
 

• Do you expect SDK 2 in October 2023? 

Answer: In October 2023, OP expects any valid version of the SDK, be it 1 or 2. 
 

• Until which date SDK 1 will be supported? 

Answer: At least until the end of 2023. 
 

• When the eForms SDK is updated, how should we handle multiple validation versions?  

Answer: It depends on the environment. In an editing application like eNotices2, only one version is necessary. 
 

• After November 2023 (and assuming no new amendments are published), how many versions of SDK do you expect to publish each year? 

Answer: There is very likely to be an amendment in 2023, i.e. another version of SDK, because further requirements need to be included in eForms. Apart from amendments or other significant changes, there will probably be at least around 4 versions per year, for example, to keep up with quarterly updates of EU Vocabularies but also for the continuous improvement of rules. 
 

Documentation and where to find information:  

For the ‘how to’ suggestions, please have a look at the new developer guide: https://docs.ted.europa.eu/eforms/latest/guide. Provide feedback in GitHub discussions at https://github.com/OP-TED/eForms-SDK/discussions so that we can further improve them. 
 

• The previous versions of the documentation are not available, only the latest one. Could you please make available the previous versions of the documentation - for example v.1.3.2, v.1.2.1, v.1.1.1, etc.? It is especially useful when we need to compare where the differences are. 

Answer: On the contrary, all versions of the documentation are available, since 1.0.0. In the bottom-left corner, there is a drop-down menu where you can choose the preferred version. The same is also available in the top-right corner under the search box.  
 

• Is there a document available with schematron rules? 

Answer: Schematron rules cannot be described in a document but they can be downloaded from GitHub: https://github.com/OP-TED/eForms-SDK/tree/develop/schematrons.  
 

• Where can we find schematron rules description within developer docs?  

Answer: The rules (expressed in EFX) can be found in the Developer Docs metadata reference at: https://docs.ted.europa.eu/eforms/latest/reference.  

 

• Where can we find release notes to see which specific fields, lists etc. have changed from version A to version B?  

Answer: It is not possible to provide a list of all changes in a changelog. However, there is the SDK in GitHub: https://github.com/OP-TED/eForms-SDK and every user can compare the different versions to see the changes of any file. The path is the following: GitHub – eForms-SDK – [element/file] – History – any version can be compared with any other. 

 

• As mentioned, it should be possible to implement eForms without using the SDK. As we are implementing the forms per notice type, we are urgently missing the definition of rules (and explanations) per notice type (form). How should we proceed? 

Answer: Some of the information that is in the SDK is also available in the Developer Docs and the Metadata Reference part contains all the information about rules, codelists and fields at https://docs.ted.europa.eu/eforms/latest/reference/index.html. 
 

• What is difference between the application version and SDK version? 

Answer: Each application (e.g. eNotices2, CVS, TED Viewer), is a computer software package. Each new version of the application (major, minor, patch/fix), bears an increasing number (e.g. 1.0.0, 1.1.0, 1.1.1). The SDK, is a collection of metadata (e.g. codelists, labels, XPaths, templates, etc.) that is used in different applications and is available as a package at GitHub: https://github.com/OP-TED/eForms-SDK. Each new version of the SDK bears also an increasing number. The number of the applications versions and the number of the SDK versions will likely not coincide. The evolution of the SDK and of the applications will be independent, new versions of the SDK can be used by the applications without the need for new versions of the applications; and new versions of the applications will not require new versions of the SDK. 
More about SDK versioning at: https://docs.ted.europa.eu/eforms/latest/versioning.html. 
 

• Is there a functional description of all validation rules, described at a more abstract level? Or as business rules? 

Answer: The rules are all expressed in EFX (in the Developer Docs). They cannot easily be described in plain English. 
 

• We use a self-developed framework for dynamically rendering forms and dynamically transferring forms to different datatype formats. We need rules and validation to know dependencies (i.e. if a selected value from a field is ‘XZ’, then field ‘XX’ will be shown or hidden).  

Answer: The dependencies are described in EFX in fields.json. 
 

• If you click on version 1.3.1 of the SDK Documentation and then click on the Metadata Reference, it shows information in version 1.4.1, and not the information in 1.3.1. Probably it is a bug. Could you fix it? 

Answer: Indeed, it is a bug. An alternative solution is to use the drop-down menu in the top right corner. 
 

• Is there any documentation available for the validation rules so that they can be implemented in a traditional way? 

Answer: There is a Metadata Reference section in the Developers Doc where this piece of information can be found: https://docs.ted.europa.eu/eforms/latest/reference/index.html.  

 

Change notice / stop publication / contract award notice: 

• How does TED validate a request to cancel a notice? How would a change notice, including a cancellation, work? Do I understand correctly that to stop notice TED expects change notice? What reason should be set? Note: From the eForms Policy Implementation Handbook: ‘Procedures are cancelled using a Change form, with the Change Reason Code [...] equal to “The notice (or its specific lot or part) is cancelled.’ 

Answer:  

1. The procedure to cancel a notice varies depending on the status of the notice: 

 - If the notice is in Submitted status and has not been published yet, users can stop its publication and resubmit it. It can be done only until it enters the daily export to TED and OP has initiated the process of publication of the next OJ S (which happens around 16:00 CET on workdays). 

- If the notice has already been published (or entered the daily export), it can only be cancelled through a Change notice. The Change notice is a reproduction of the original notice with an extra section to advertise changes to the procurement and procurement documents and for correction of clerical errors. If a Change notice is submitted with the reason ‘Notice cancelled’, it means that the original notice is null and void, as if it should never have existed. Buyers should use their change reason with care as it may have implications for the procedure, for example, deadlines may need to be changed. 

2. To cancel the procedure or lot, the buyer must submit a Contract Award Notice with no winner – regardless of whether the submission deadlines have been reached or not – along with a reason. The use of the Change notice to cancel a procedure as proposed in the eForms Policy Implementation Handbook would create the risk of inconsistencies and was therefore not implemented. 

 

• Should a CAN always be used for a cancellation of a procurement or a lot, while the Change notice can be used for cancelling a notice that has errors in it by making it null and void and then publish a new, correct notice for the same procedure? 

Answer: Indeed, it is mandatory to use a CAN to cancel a procurement or a lot. You can use a change notice to cancel it if it contained too many errors but be aware of the implications. 
 

• Will it be mandatory to publish a Change notice with code Cancellation intention (cancel-intent) before actually cancelling a procedure, and publish a Contract award notice? 

Answer: ‘Cancel-intent’ is a very specific type of a change (for legal reasons), and it is not mandatory for the eForms workflow. Usually, the user only needs to publish a Contract award notice.  
 

• Is the cancelation flow same for both cancelation reasons: CANCEL and CANCEL-INTENT? 

Answer: From a publication point of view, the flow is the same, i.e. there is a change notice when the user republishes the notice and mentions code ‘cancel’ or ‘cancel-intent’ and explains what has happened.  
From a business point of view, the cancel reason tells the reader that all information in the notice null and void. The notice ends up being published twice, i.e. the original notice and the change notice with the cancellation reasoning. 
The cancel-intent reason is used to notify that there is an intention to cancel, e.g. a lot, a procedure, etc., that hasn’t been done yet. 
 

• Will the withdrawal of the sent (but not already published) notice be only possible by an eSender or also by a specific CA (whose notice needs to be withdrawn)? 

Answer: It is a ‘stop publication’ functionality and it is up to the eSender to decide how this option will be offered to the contracting authority.  
Note: in case the notice is set for publication ‘as soon as possible’, the time limit to stop publication will be shorter than in the current systems, i.e. it has to be done during the same working day (before it is included in the daily export for TED). 
 

• In case a notice is withdrawn for correction, will the corrected notice that is later again sent for publication retain the same ID number?  

Answer: It is currently unclear whether this possibility exists, we will investigate. 

 

Go-live eSenders: 

• Have you received any notices in eForms format yet? 

Answer: No, we have not received any eForms yet. 

 

• Do you know when to expect the first notices in eForms format in TED? Any indications from any Member state? 

Answer: There are a few users that indicated Q1 or early Q2 2023 as a possible go-live period.  
 

• Has DG GROW made a new survey to ask the Member states when they aim to implement eForms, which forms they aim to use, etc.? 

Answer: DG GROW asked that question at the EXEP meeting on 6 December 2022. The tendency starts at the beginning of Q2, with majority in Q3 and some in Q4, too. 

 

Validation:  

• Do you need to validate a notice before trying to render it? 

Answer: No, TED Viewer will (try to) render any XML.  

 

• Will the notices still be validated manually or will notices always (when validated) be published on TED? 

Answer: Notice validation will be automated through the Central Validation System (CVS). Human validation will only be done for notices that have a ‘lawfulness’ warning. This means that the notice contains information that suggests it should not be published in the Supplement to the Official Journals of the EU. For example, notices from countries outside the EEA or that do not have an agreement with the EU. The notices will then be subject to a manual check at OP to decide if they should be published or rejected. 
 

• Can you explain what you mean by ‘no more contractors used for validation of the notices anymore’? Is the process fully automated now so that the notice can be published immediately if the validation passes or still the up to 48 hours waiting rule applies? 

Answer: When submitting a notice, users can select a preferred publication date, or can choose to leave the preferred publication date empty meaning publication ‘as soon as possible’. 

For a notice that has no lawfulness warning, 'as soon as possible' means that it will be included in the next available export, which could be that same afternoon, and the notice will be on TED on the next day (that the OJS is published).  

You may still choose to wait 48 hours to publish on your national platform or wait for the publication on TED (which might take more than 48 hours over weekends for example, even with ‘as soon as possible’).  
 

• Can older XML forms be validated with a new version of the SDK? 

Answer: Technically, they might sill pass validation but practically, they might be(come) invalid. 
 

• When submitting XML notice, if there is an error (e.g. ‘notice with same id already exists’ or ‘Could not parse notice business id’), exception code is always the same ‘code’: ‘notice.NOTICE_IMPORT_VALUE_EXCEPTION’. Any plans to have different codes for different exception reasons? 

Answer: The Publications Office is working on this to provide more meaningful error messages. 

 

Lawfulness check:  

• If the TED manual lawfulness check fails but we have already published nationally after 48h, do we need to cancel the notice nationally? 

Answer: It is the same as today, i.e. if the Publications Office refuses a notice, the user needs to handle it on their end.  

 

• If the TED manual lawfulness check fails, could TED afterwards review it with the authority and decide that they were wrong and publish the notice anyway? 

Answer: If a notice is rejected due to manual lawfulness checks, it needs to be sent again. 

 

• What is the technical implication of manual validation of eForms regarding lawfulness? Is there chance of rejection of a notice by TED after it has been accepted before? 

Answer: If a notice is rejected because of a lawfulness check, a new notice needs to be submitted. There is no trace of acceptance or rejection in the system.

 

Notice flow: 

• If only lawfulness warnings exists in the validation report, does it mean that eForm should have status submitted and will be published?  

Answer: Indeed, if there is a lawfulness warning, it means that there was a status ‘submitted’. There might be a bug now (December 2022) because if a notice falls into lawfulness, it says ‘validation failed’. 
 

• Any documentation on Notice statuses, what all statuses a notice can have after it is submitted? 

Answer: OP will document the statuses in Swagger and API. There is more information on the statuses at the eForms FAQ. 

• Is it possible to trigger notice publishing flow manually for submitted notices to speed up testing? 

Answer: It is not possible to speed up the flow of statuses in Preview, the export is done only once a day and this cannot be changed. 

 

• If the eNotice2 submit endpoint returns success: true - does this always mean that the notice status is SUBMITTED? And if the endpoint returns success: false - does this always means status VALIDATION_FAILED? 

Answer: Indeed, it is correct.  
 

• If TED gives invalid response after submit notice (e.g. infrastructure error), could it happen that the notice is still saved/submitted in TED? Can we be sure that the notice would not be rejected as a duplicate when we try to resend it once TED is back up because we need the cvsLink? 

Answer: If a notice is successfully submitted, validated and sent to OP (received by TED –Monitor 2022), it gets status SUBMITTED and there is no need to resend it again. Another notice with the same ID cannot be submitted.  
Note: in the exceptional case of an ‘error’ between eNotices2 and TED Monitor, the notice will still be in status SUBMITTED. In that case, OP will inspect those cases individually and will try to provide a solution until there is enough data to provide a structural response, e.g. by setting such a notice back to DRAFT after a set time lapse. The same scenario applies to Preview (feedback from user is necessary). 

 

API documentation:  

• Is there rate limiting for various APIs? Can you please share the link to the documentation. 

Answer: There is currently no limit but OP aims to define that in the future. 

 

• Can you demo a real use of the APIs using swagger?  

Answer: You can check out the guide on how to test in ‘Preview’ via Swagger, it was presented during the 2nd eForms Technical Workshop in September – TED Developer Portal and using eForms APIs. More information also at Preview Swagger.  
 

• Is it possible to poll for status of all the notices sent in between a particular interval by using eForms APIs? 

Answer: Yes, the eNotices2 API search has dates as its parameters too. 
 

• The API seems inconsistent (e.g. the use of the version of a notice). Will you improve the current production APIs? 

Answer: There are indeed some inconsistencies and it is OP’s priority to have a new generation of the APIs. Note: the current version of APIs will continue to work. 

 

Additional notices E1, E2, E3, E4, E5 and T01, T02, X01, X02: 
 

• When can we expect more detailed documentation about notice subtypes E1-E5? 

Answer: E1, E2, E3, E4 and E5 are the voluntary forms, they are not part of the eForms regulation, but they were included in the ‘Extended Annex’ to regulation 2019/1780.

These forms will be implemented after eForms are mandatory in October 2023 and their use, which currently has no EU legal basis, will be optional.  
 

• In the new regulation, the columns X01, X02, T01, T02, and from E1 to E5 are missing, but I didn't understand the reason.  

Answer: X01, X02, T01, T02 are not part of the eForms regulation but OP publishes them. X01 and X02 are part of regulations related to the business registrations of EU companies, cooperatives and groupings. T01 and T02 implement regulation 1370/2007 for public passenger transport services. E1-E5 are voluntary forms that are not yet part of the eForms regulation.  

 

Conversion of current TED XML forms into eForms:  

• Can OP provide more information on how to handle procurements that started before eForms?

Answer: For procurement procedures that are not finished before 25 October 2023, the user will have to continue the procedure using eForms. To ease the transition, it will be possible to import a notice that was previously published in TED, convert it and complete the missing information in order to produce a valid eForm notice. OP is aiming to provide this possibility in eNotices2.  
 

• Can OP provide a roadmap for ted-xml-data-converter? 

Answer: TEDXDC converter: https://github.com/OP-TED/ted-xml-data-converter - all Contract Notice TED XML forms (F02, F05, F12, F21, F22, F23 and F24), and all Contract Award notice forms (F06, F13, F15, F21, F22, F23, F24 and F25) are convertible. 
Work is almost finished on the PIN (Prior / Periodic Information Notice) notice forms (F01, F04, F07, F08, F21 and F22) and will be released soon. We started working on the conversion of the defence forms (F16, F17, F18, F19) in November 2022. 
TEDXDC converter will be available as an API service as well. 
 

• Can the converter always create valid eForms notices from the current TED 2.0.9 schema notice?  

Answer: No, the conversion of TED XML will always result in an invalid eForms XML because, for example, not all fields exist, or text fields cannot be turned into codelist values. However, it should allow users and systems to carry over as much as possible of existing notices into the new format, e.g. when continuing a procedure that overlaps the switch between the two schemas. 

 

EFX: 

• #non-java translate EFX for C# world please? The .net translation usefulness is dependent on the suspected release date, because who would use those versions have to consider they are able or not able to integrate toolkit to its systems.? 

Answer: OP doesn’t have resources for this at the moment. To find an alternative solution, do not hesitate to open a discussion via GitHub. 
 

• #non-java need: efx translator to javascript in javascript. Is it possible to run xPath logical expressions inside javascript?  

Answer: Please open a discussion for this question in GitHub.  
 

• #non-java efx-translator: shouldn’t a java logical expression not also directly work in javascript? There is also a transpiler from java to js: https://github.com/cincheo/jsweet?  

Answer: The EFX is written in Java and translates to XPath. For follow-up, do not hesitate to open a discussion via GitHub.  
 

• Are the EFX expressions in fields.json only used for validation or also to describe conditional fields? 

Answer: The EFX expressions in fields.json are derived from an internal database. The conditions (the presence or value of one field is dependent on the presence or value of one or more other fields) are encoded in the database. Both the validation scripts in Schematron, and the EFX expressions in fields.json are derived from these conditions. Thus the EFX expressions effectively describe the conditions, but they can also be used to generate validation rules in other languages. 

 

National tailoring: 

• Any ideas how we can gather tailoring decisions from all member states? 

Answer [DG GROW]: The approach taken in each Member State on the implementation on eForms is different. At this point in time, there is not an overview on how Member States are technically implementing eForms. In the next eProcurement Expert Group we aim to capture this information 
 

• The issue of member states tailoring is a huge problem when we talk about metadata driven applications with the goal of ‘free updates’. You have to patch every SDK version every time with the national requirements. Due to the national tailoring, a GDK is built in Germany. The German Development kit is based on the EU SDK and contains the national adaptations. These currently concern notice-types, fields, codelists. Further adaptations are already announced and concern the areas translations, schematrons, examples. In Germany, we can only hope that the meta-driven approach can also be applied with the GDK. 

Answer: Indeed, the users need to adjust the SDK as necessary in order to apply the national tailoring on the top of it. It is impossible for the Office to provide a national tailoring solution for each country. The Office aims to offer as generic solutions as possible so that it can be used by the majority. 

 

Miscellaneous:  

• If a published notice is available in several languages and a change is made in a description field, is the change expected to be added and published in all languages? 

Answer: When there is a change notice, it means that the entire notice gets published again. If there was a change in one language, it is assumed that all the language versions will carry the same information. 
 

• What are the current versions of eForms SDK involved in Notice Editor Demo? 

Answer: The code of the Notice Editor Demo supports only one version (currently 1.5). However, it is under development and it the future, it will support two or more versions at the same time. 
 

• There is a problem with a notice with more than 500 lots. Will it be possible to publish such a notice?

Answer: We are working on resolving the size limitations of large notices. Notices of 3 MB or above cannot be sent, due to a technical restriction. For more information and updates, please visit the Developer Docs.

 

• What will be the first possible date for publication in TED that a CA can set in a notice-field OPP012? 

Answer: The rule for preferred publication date is not set up yet but it would be today + 2 days, i.e. if you choose ‘as soon as possible’ and the notice reaches OP soon enough during the day, passes validation and if there is no lawfulness check, it will normally go into the OJS the next working day. If the user wants to control the date of publication, it is recommended to set the date. 
 

• Can OP deliver a weekly report about the number of eForms messages that are published in production? 

Answer: OP will take it into consideration (possibly monthly reporting). 
 

• With what intention is the viewer made available? For Contracting Authorities to check the result of their data input? 

Answer: OP applications eNotices2 and TED Monitor 2022 call the public viewer API to view notices in HTML and PDF. The viewer can be used by those users (eSenders) who do not wish to create their own viewer.  

 

• We have been using the daily-packages of XML files for quite a few years and used them for our purposes. Are these still offered unchanged?  

Answer: Yes, they will continue to be offered but the FTP will change into HTTP in 2023. 
 

• How can I identify which BTs in CANs that are allowed to be changed/modified and presented in a Contract modification notice? 

Answer: This information is not yet available. 
 

• When using a CAN where a procedure did not result in an awarded contract, do you still have to add all the mandatory fields for a CAN to get a valid XML? 

Answer: Yes, mandatory fields are required. 
 

• In eNotices2, the repeatable field BT-531-Lot is allowed to accept duplicate values. Is that valid or a bug? 

Answer: A rule initially existed to prevent such situation at CVS level, it was however not ready for integration in eNotices2. This rule will need to be set back at least at CVS level. At eNotices2 level, it could be solved either way: use of check boxes or use of a dynamic rule. Investigations and analysis are required to select the best option. Also, currently many dynamic rules are deactivated. The fix will be in a future release. 

 

• In the new regulation, the variable ‘Fax’ remains obligatory. In Italy, the Public Administration is dismissing fax. In many situations, the PA cannot accept fax-messages for privacy reasons. We use the certified e-mails now. Do you have plans to change the variable? 

Answer: Indeed, annex 2 of the eForms Regulation (EU) 2019/1780 says that fax is mandatory because the Directive 2014/24/EU says that fax must be provided. However, the user must include their fax only if they have one. This is expressed a ‘EM’ in the extended annex Excel, i.e. it is mandatory if it exists, but this cannot be controlled by any rules so EM fields are effectively optional. 
 

• How can we identify which of the procedure types (BT-105) that are allowed for each notice subtype? Is there a specification available? 

Answer: The rule is not implemented yet.  
 

• Is BG-713 Strategic Procurement in the SDK 1.3.2 version? 

Answer: Yes, BG-713 was also in earlier SDK versions as it was already there in the original eForms regulation. The 2022 amendment has added some BTs to this business group such as Green Procurement Criteria and Clean Vehicles Directive, which were added in SDK 1.3.2. 
 

• I'm just curious if anyone can estimate how long it takes to understand a rule expressed as below to check if a current eProcurement system meets it: (OPP-070-notice in ('7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','E4') and (BT-747-Lot == 'sui-act') and (BT-747-Lot == 'ef-stand') and (BT-747-Lot == 'tp-abil')) or ((OPP-070-notice == 'E4') and not(BT-747-Lot == 'sui-act') and not(BT-747-Lot == 'ef-stand') and not(BT-747-Lot == 'tp-abil')) or (not(OPP-070-notice in ('7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','E4'))) 

Answer: Rules written in EFX are meant to be read by machines, not by humans. Rules are available in plain English for humans to read at: https://docs.ted.europa.eu/eforms/latest/reference/business-rules/index.html. They are also available in EFX and in XPath for machines. 
 

• ‘BT-262-Lot' with a message like ‘message': 'rule|text|BR-BT-00262-0200'. My question is related with that '|text|' from the message. Is it possible to have a list with ‘|text|’ for each rule? 

Answer: There is a list in the SDK with all the text labels: https://github.com/OP-TED/eForms-SDK/tree/develop/translations.   
 

• Will you provide a link where the records from the webinar will be uploaded? 

Answer: It can be viewed at Agenda tab of the TED eSenders Webinar 2022.
 

• Can the past workshop links/recordings be made available in one location in the documentation site? 

Answer: All the previous editions can be viewed via: https://op.europa.eu/en/web/ted-eforms/previous-editions and via the Developers Docs: https://docs.ted.europa.eu/home/eforms/FAQ/.  
 

• For finding notice status for a single notice, is the search API the best service to use? 

 Answer: The API call is the fastest but there is the option of searching in the eNotices2 user interface. 
 

• It seems that meta-data driven applications are rather expected and considered in change management? Do you know how many meta-data driven applications are planned compared to the traditional one? 

Answer: From this workshop, it seems that metadata-driven applications prevail. The survey in December showed that around one third are aiming to have at least partially metadata- driven applications; the rest are fully metadata-driven and traditional. 
 

• Will notice-editor get capability to save notice as XML? If so, when will that happen? 

Answer: It is under development, but it saves notices in XML. For more information, please visit: https://github.com/OP-TED/eforms-notice-editor/branches. 
 

• Why should someone implement its own meta data driven application for users to fill in eForms if we have the eNotices2 app for this purpose? Our national eProcurement system is an old one (since 2007, reimplemented in 2018). It's used for performing public procurements online. Of course, one of its features is to prepare notices for TED but our users don't fill in notices, they perform procurements online: contracting authorities prepare the acquisition specifications (upload tender book and other documents + fill in structured data), economic operators upload tender documents and fill in the tender data including price and award criteria answer, fill in the ESPD, participate in online auctions, system perform automatic rankings, contracting authorities evaluate the tenders, communicate with the suppliers, manage contracts and so on. Other authorities are involved in the procurement too (to verify the acquisition for example). 

Answer: Indeed, if eNotices2 suits the user, it can be used. However, eNotices2 doesn’t have the national tailoring and the user will need to re-enter some information that exists in the national eProcurement system. 
 

• In the slide roadmap until 2023, it was described that there should be one minor release per month after June. Regarding the GDK, this would then mean that a new GDK would also have to be published every month. Were you contacted in any way or were you able to exchange information here, or does this completely bypass the Publications Office? 

Answer: We are aware of the German GDK but we are not involved in it in any way. 
 

• What do you consider as the best approach – to include SDK’s schematron in a self-build application or to build an application that calls TED validation API? Are there more controls than those implemented in the schematron files?  

Answer: There is no recommendation of the Publications Office but it is obvious that to build an application locally is an advantage because it is always available, the user can their own schematron rules, etc. The CVS validation API carries out the same schematron rules as those in the SDK. 
 

• Translations to all other languages: are they auto translated? Do they conform to national business slang? 

Answer: Some labels have been translated by the European Commission’s eTranslation tool (which has some gaps) but everything will at some point be translated by the Commission’s translators. Note: there are some countries that would like to contribute to the translations, e.g. Finland, and OP will aims to include any received feedback. 

Published: 27 January 2023.