Minutes of the third eForms Technical Workshop 

1 February 2023 

 

The 3rd eForms Technical Workshop took place online on 1 February 2023. 

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 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. 

 

eForms will become mandatory on 25 October 2023.  

All the necessary resources for the transition to eForms are available since 2019 (i.e., the UBL schema and the rules, which derive from the eForms Regulation). TED API documentation was made available in November 2022.  

The Publications Office is constantly working on improvements of all the provided services and will continue to do so.  

On top of these resources, the Office developed the SDK (Software Development Kit) as supporting material.  

The Publications Office is doing its utmost to make all information available and to give support throughout the transitional year of 2023. 

There is the Preview environment for users to test and prepare themselves for going live with eForms.  

In case of need for further assistance, there are the communication channels: the TED Helpdesk for business-related questions and GitHub discussions for technical issues.  

 

 

The lifecycle of eForms notices – Karl Ferrand – Publications Office of the European Union  

The overview of eForms statuses and workflow was presented. The statuses are: draft (only in eNotices2 UI), deleted (only in eNotices2 UI), validation failed, submitted, stopped, not published, publishing (currently only an internal status) and published. For detailed information about each status, please see the presentation.   

Publication requirements stay the same, as stated in the directives: 

• OP publishes within 5 calendar days,  

• OP gives confirmation of receipt and publication to the buyer, 

• national publication may happen 48 hours after confirmation of the successful receipt of the notice. 

Regarding dispatch dates, also referred to across the directives as ‘transmitted’, ‘sent’ or ‘dispatched’, there are two business terms:  

• dispatch date (BT-05) – when the notice is sent by the buyer to the eSender (or submitted via eNotices2), 

• [NEW since November 2022 amendment] eSender dispatch date (BT-803) – when the notice is sent by the eSender via the API; it is optional but it could be mandatory in the future. 

There shouldn’t be any time discrepancies when it comes to the dispatch date (i.e. it cannot be 1 day before the day of submission or after the current time, etc.), it should always reflect the real situation. 

The basic publications process of a notice was presented.  

With eForms, there is an option to publish a notice ‘as soon as possible’. It means that the buyer did not provide any preferred publication date and the notice will be included in the next available export (if no lawfulness check). However, if the buyer has a preferred publication date, they can consult the OJS release calendar and define the date according to it (no later than 2 months after the dispatch date). 

It was presented under which circumstances the user should use ‘change notice’ and how to close a notice lifecycle. [Note: it was mentioned during the workshop that a change notice can be used to add/remove lots. This is not correct. To add lots, there has to be a new Contract Notice. To remove lots, there has to be a Contract Award Notice with no winner.] 

Further information was presented about unpublished fields also known as ‘not immediately published’, ‘publish later’, ‘withheld’, ‘privacy’ or ‘confidential’ fields. Detailed information can be found in the presentation. 

 

---

 

Working with field metadata and the notice type definitions to create and submit notices – Ioannis Rousochatzakis – Publications Office of the European Union  

OP is updating the front-end of the Notice Editor (Sample Application), especially the JavaSript code to make it simpler, cleaner, and easy to reuse. Amongst other features, the UI and UX is also being improved. At the back-end level, OP is working on creating notice XML files.  

Notice Viewer (Sample Application) is getting a web interface.  

Regarding SDK, there are improvements of the visualisation templates and at the level of Notice Type Definitions. However, there are mainly preparatory works going on for SDK 2.0 (mainly for EFX 2).  

SDK 1.x will probably be updated every month until June 2023, afterwards only when necessary. SDK 2 is planned to be made available later in the year. SDK 1.x and SDK 2.x will remain active in parallel.  

All the notice types are in the SDK. For more detailed information about the files and their content (e.g. noticeSubTypes, documentTypes, metadata and content section; or contentType / displayType, ect.), you can replay the presentation on YouTube.  

Notice structure (visual vs. physical) and its characteristics were presented.  

Dynamic properties, i.e. property values depending on conditions, have restricting field behaviour: 

• forbidden 

• repeatable 

• inChangeNotice 
  (canAdd, canModify, canRemove)  

and restricting field values: 

• mandatory 

• codelist

• pattern (RegEx) 

• assert (EFX). 

Regarding the EFX Toolkit, it currently provides only EFX to XPath translation. EFX is needed on the client to evaluate the conditions of all dynamic properties as well as the assertions of the assert dynamic property. 

OP is working on improving the XML validation (TED CVS), i.e. the validation report in the form, and looking for ways to make validation result consumption more convenient.  

 

Questions from the participants: 

 

Start date of eForms: 

• Is the deadline for the transition to eForms still 25 October 2023? Or could it be that the deadline will be prolonged? 

Answer: The deadline for transition is set in the Regulation. 
 

• What is the life cycle of a file sent in the old format (TED-XML) like if it is sent after 25 October 2023 (eForms)? 

Answer: OP will not be able to accept notices in the current TED schema format after 24 October 2023. 

 

Sample eForms notices: 

• Could you please let us know the notices publication numbers that have already been published on TED in eForms form from November 2022?

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.  

 

Notice types:

• Notice-types json files don’t include rules for dynamic behaviour of the form, i.e. when filling out the form, there are always all fields available, no matter what kind of data are filled in, even when these data are linked together. Can we count on the addition of such rules?  

Answer: The dynamic properties are in fields.json because the behaviour of a fields doesn’t change depending on the notice-type. To find the dynamic property from fields.json, the user should use the field ID.   

 

• When will you be able to publish specifications about which types of procedures that are allowed for each subtype? 

Answer: This information about the type of procedure allowed per subtype is available in the legislation. 

 

• In https://docs.ted.europa.eu/eforms/latest/notice-types/index.html#_properties_of_field_elements you state that one of the possible field display types is CHECKBOX. However, no notice subtype definition seems to use this. Will this display type be used in the future, or can we ignore it? 

Answer: It should not be ignored, it will be used. 

 

• Can we use the order defined in the content section of the subtype json for getting the correct order of XML elements? 

Answer: No, at present, the schema XSDs are the only source of correct ordering of XML elements. 

 

Business rules and business terms: 

• OP previously removed certain conditions/rules in the fields.json. When can we expect them to be shown again in the file? 

Answer: OP removed the conditional mandatory rules from SDK 1.3 in November. We expect to reintroduce progressively most of the rules in the up-coming releases of the SDK.  
Note*: All the rules removed can be found in SDK 1.2.  

 

• Is there a way to understand the business rules in human language? Where can we find the right directives which describes the rules behind each business term? 

Answer: Most of the rules come from the regulation and the annex to the regulation. For each form, there is a legal basis.  

 

• BT-36 Duration Period contains only ‘day, week, month, year’ values. We need ‘Workday’ as well. Can you add ‘workday’ to this field? 

Answer: We cannot add ‘workday’ to the allowed values for BT-36, as the definition of workday differs by country, and so the number of actual days cannot be accurately determined. 
 

• Measures – some fields are declared as measures in the fields.json file, e.g. BT-36-Lot, but there is no associated measurement unit codelist for this field. How can we figure out which measurement unit codelist to show for the user in our application, e.g. time-period-duration-unit? 

Answer: For durations, the accepted unit of measures are the ones in the duration-unit codelist (covered by the timeperiod_duration-unit.gc file). 
BT-36-Lot, BT-36-Part and BT-98-Lot which are of type Measure, for these, the list to be used is timeperiod and only the following duration units are allowed: YEAR, MONTH, WEEK, DAY. 

 

• What are the codes for BT-736? Could you please list the possible answers to this field? 

Answer: The codes are in the codelist in the SDK with identifier ‘reserved-execution’ (filename “applicability_reserved-execution.gc”). The allowed codes are ‘no’, ‘yes’ and ‘not-known’. 
 

• Why is BT-3201 mandatory in notice types 38, 39 and 40? For example, notice type 29 has a direct contract without tenders and the buyer would like to change something in the contract. CVS will give a validation error ‘Tender identifier (BT-3201-Tender) is mandatory for a notice with subtype 38’. 

Answer: In the regulation annex, BT-3201 is optional and could not exist for VEAT notices. In contract modification notices, this is however mandatory. Modifying a contract uses a Contract Modification on an existing contract and requires the identification of the associated tender. For a VEAT, although a contract is foreseen, the contract could not be signed, and it was not deemed necessary to provide an ID for the tender. For the implementation, as soon as a tender is specified, then BT-3201 is also mandatory. 

 

• Forbidden fields - some fields, e.g. OPT-301-ReviewReq are forbidden in all notices. Are you planning to add these fields into some notices or we can ignore them completely? 

Answer: The users can ignore these fields for the moment. They are related to form E5 (Contract completion) which is not implemented yet.  

 

• We'd like to have the rule ID in the SDK specification (metadata reference section), e.g. I need to find the description of the rule BR-BT-00262-0209 on this website. 

Answer: OP will try to improve how rules are shown in the metadata reference – thank you for this proposal. 

 

• BT-31-Procedure (Maximum number of lots for which one tenderer can submit tenders) and BT-33-Procedure (Maximum number of lots for which contracts can be awarded to one tenderer) are type ‘number’, not ‘integer’ – is it for some reason or is it just a bug? 

Answer: Indeed, it should preferably be defined as integer as decimal values wouldn't make much sense. This should be fixed in a later release. 

 

• Some Rules like Lot-0001 if not mentioned, schematron will fire an exception. For Document Qualification the ID is not in the mandatory fields although it is mandatory.  

Answer: The Extended version of the Regulation Annex is a representation of eForms. The associated model is based on normalized data where objects (i.e. the Business Groups) and their properties (i.e. the Business Terms) are connected to other objects using identifiers and identifier references. The Regulation Annex does not list the references that interconnects the objects. 
A same object (Business Group) may have some meaning for: 

• the procedure as a whole

• Parts

• Lots, and 

• Group of Lots 

and depending on the target (e.g. Procedure, Lot, ect.), the rule may vary. 

Let’s illustrate with the Business Group 'Purpose'. 

This repeatable Business Group contains the description of what is to be purchased and there will be: 

• one occurrence of this BG for the Procedure as a whole (any notice type), and 

• as many occurrences of this BG as the number of Parts (PIN only), and 

• as many occurrences of this BG as the number of Lots (except PIN profile and PIN only), and 

• as many occurrences of this BG as the number of Groups of lots (except PIN profile and PIN only). 

The 'Purpose' Business Group contains a Business Term BT-137 which is a technical identifier of the concerned object. 

• For the Procedure as a whole, BT-137 is not allowed

• for a Part, BT-137 is mandatory for PIN only (containing Parts only) and forbidden for other Notice Types (not containing Parts) 

• for a Lot, BT-137 is mandatory for any Notice Type except PIN Profile (no detail about Lots in the notice) and PIN Only (defines Parts and not Lots)

• for a Group of lots, BT-137 is mandatory for any Notice Type where Group of lots are defined, except PIN Profile (no detail about Group of lots in the notice) and PIN Only (defines Parts and not Lots/Group of lots). 

So: 

• for PIN profile, where the Purpose only exist for the Procedure BT-137 is not allowed 

• for PIN only the Business Group Purpose exists for the Procedure and for Parts; BT-137 is forbidden for the Procedure and mandatory for Parts, therefore BT-137 is marked as CM (Conditionally Mandatory) to cover both situations 

• for other Notices, the Purpose may apply to Procedure (for which BT-137 is forbidden) and Lots and Group of lots when these exist (and for which BT-137 is mandatory) 

The existence rule for BT-137 in the extended annex is an aggregated way of expressing all these constraints, the introductions of the fields concept helped express the rules expressed in the schematrons univocally. 

 

• Some labels seem to be very technical like ‘BT-500-Organization-Company is mandatory for a notice with subtype 16’. Can we have a label like ‘Official name (BT-500-Organization-Company) is mandatory for a Contract notice – general directive, standard regime (subtype 16)’? 

Answer: OP will keep on working to improve and harmonise the labels for error messages. 
 

• Is there a way to validate business rules without using EFX toolkit or CVS? What if we would like to implement a tailored solution inside our software? 

Answer: You can do your own implementation of the rules. However, they need to comply with the CVS. 
 

• In Commission Implementing Regulation (EU) 2022/2303 of 24 November 2022 BT-08 ‘Organisation Role’ is mandatory for all the notices. Why is BT-08 ‘Organisation Role’ missing from the SDK then? 

Answer: Organizations assume specific functions (role/subrole) in different contexts.  
There are multiple roles and subroles defined, and subroles are only accessible to organizations which already have a given role assigned. As the concept of roles and subroles is context specific and many roles require individual solutions, we could not implement BT-08 as mandatory. 
 

• Why is field ‘Dispatch Invitation Tender (BT-130)’ validated to be before field ‘Deadline Receipt Requests (BT-1311)’ in non dynamic procurement? Should it not be the other way around?  

Answer: Yes, it is a bug, it will be fixed in the SDK 1.6.

 

Validation: 

• The schematron validation does not supply the XML validation structure. Is it possible to include the XML structure validation to schematron rules? 

Answer: The structure of the XML is checked by validating it against the schema, which is done before applying the schematron rules. A new property was added in fields.json, named ‘xsdSequenceOrder’, to be included in SDK 1.7, to indicate the position of each element among its siblings. 

 

• Regarding SVRL validation report, it would be nice to have errors in a format like ND-XXX[idx].BT-XXX[idx], error: Rule-XXX. 

Answer: It is not possible to have that format in the SVRL validation report because the XML and XSLT cannot include the concepts of ND or BT. The XPaths in the SVRL validation report can be compared against those in the fields.json to identify the Nodes and Fields, and the number predicates in the XPath can identify the index values. 

 

The lifecycle of eForms notices: 

• When will the status PUBLISHING be implemented? 

Answer: It should be exposed in production after April.  

 

• If a notice is not published, you should expose the reason for it via the API and not only send an e-mail to the buyer. This information is also relevant for the eSender (which is not the same as the buyer). 

Answer: OP will look at ways to include the Not Published reason in eNotices2 and in the API. 

 

• Is it possible to set the status from submitted to stop/not publish via the API? 

Answer: The API has a function to stop publication. The status Not Published can only be set by OP. 

 

• In which status will a notice stay, if the ‘preferred publication date’ is one month ahead? 

Answer: The notice will be in Submitted status until it enters Publishing. 

 

• Which notice statuses will be supported by the API? Currently on the preview environment the Publication API only returns notices with PUBLISHED status. 

Answer: There are all the status in the preview API. 
Note*: the status Publishing is currently only internal status but it will be added in the coming months.  
 

• What is the recommended way to query notice statuses using the API? Currently on the preview environment the Publication API only returns notices with PUBLISHED status. 

Answer: The Preview Swagger is still under development, but it has all four basic API functions including how to search notices: https://enotices2.preview.ted.europa.eu/esenders/webjars/swagger-ui/index.html  
 

Lawfulness check: 

• Lawfulness warnings – is there any probability estimation on when/why these notices might be refused after manual validation? 

Answer: OP does not have estimations for the number of rejections or approvals.  

 

• Will there be a notification to inform about lawfulness warnings or to inform that the manual check was successfully finished even before publishing? 

Answer: There is only a notification to the buyer if a lawfulness check leads to rejection and status Not Published. 
eSenders have the possibility to check in advance whether their notice contains lawfulness warnings since OP made CVS publicly available as a separate API; i.e. eSenders have the possibility to check their notices for errors and warnings before submitting them to eNotices2 API and make sure in advance that they will not be manually checked for lawfulness. 

 

• As far as I understood the submission states, there is no ‘extra’ status for lawfulness warnings. Notices with lawfulness warnings will end up in ‘Submitted’ status? 

Answer: Yes, that is correct. 

 

• Is there a way to see or check that a submitted publication triggered the manual lawfulness review? Is there a way to see the mentioned ‘lawfulness warning’?

Answer: You can call CVS API separately before submitting a notice to check for lawfulness warnings. 

 

eNotices2: 

• What's the authentication endpoint for eNotices2? There is the Authorize button on swagger-UI but we can't find the authentication specifications. 

[post-event] answer: There is no separate authentication endpoint for eNotices2. Authorization parameter needs to be present in the header of every eNotices2 API request. Concerning the mentioned Authorize button: In eNotices2 swagger, when the user clicks on the Authorize button, the API key will be entered and stored in the session. Then swagger will include Authorization parameter (with value = Bearer $APIkey) in the header for any API call that will be launched from the swagger, e.g.: 
-H 'Authorization: Bearer 1234567890'. 

 

• In eNotices2, what is the ‘workspace’ for eSenders? Is it the ‘workgroup’ in eNotices2 the equivalent to eSentool for eNotices? 

Answer: The concept of workgroups is reserved for front-end users of the web UI and not for eSenders. The API does not know the concept of workgroups, which can only be created manually in the UI and we would therefore suggest against using them.  
Later through the TED Developer Portal, eSenders might be able to organise themselves but accounts can only be linked to one API key and one EU-Login. 

 

• What is the url to access the eNotices2 web UI (test version)? 

Answer: For accessing TED Apps in Preview, we have a dedicated page where you can find all the information: https://docs.ted.europa.eu/home/eforms/preview/index.html. 
For eNotices2 UI: https://enotices2.preview.ted.europa.eu/home. 

 

• I wasn't able to fill a notice in eNotice2 and validate it. Even if all mandatory fields are filled in, the message is ‘Your notice is not complete. Please check for empty mandatory fields.’ No answer from CVS with a detailed message. 

Answer: The application still needs to handle CVS errors better – OP is working on it. 
This is documented at ‘Known issues’ at eNotices2 Preview page – notices go through CVS validation when they are submitted, or when the user clicks on ‘validate’ in the user interface. However, the feature may be unstable. 

 

• We did not manage to fill out a notice (all required fields) in the eNotice2 application correctly. We always get multiple validation errors, which are not understandable to us. 

Answer: OP is working on improving the messages for validation errors. 

 

API authentication: 

• As you know, a central national eSender is being set up in Germany. All existing platforms will have to send the notices to this node. Will we still keep our existing eSender identifier and can we set up API keys to access methods of the eSentool API which will not be offered from the national node? 

Answer: If all German notices come via the central national eSender, all notices will come from that single API key. You will need to work with the national eSender to handle ‘your’ notices as this information will not exist in eNotices2 or in TED. 
 

• Where can we generate API key for the production operation? 

Answer: At the TED Developer Portal: https://developer.ted.europa.eu/home. 

 

Change notice / stop publication / contract award notice: 

• Which is the number of the eForms 'change notice'? 

Answer: Change notice does not have a form on its own. It will have the same form as the one it is referring to. 

 

• Do we understand it correctly, when publishing a change, the buyer needs to fill data in the section ‘Change’ to describe the changes he did in the other sections of the form? In other words, the buyer updates the previously published data and at the same time describes all the changes in the section Change? 

Answer: Yes, that is correct. 

 

• Will it be possible for a buyer to send for publication a CN (standard form) using an eSenders’ application and then to continue filling in and sending for publication the following notices in eForms format (i.e. change of the CN notice, CAN, etc.) using the eNotices2 application (user interface)?  

Answer: Once the use of eForms becomes mandatory (25 October 2023), eSenders will be required to send eForms notices for any procedures that were started with the current standard forms. 

It will not be possible to continue filling in eForms notices referring to current standard forms via eNotices2 web UI because it is not possible to edit a notice that has been submitted via API. The eNotices2 UI will show the notice as Submitted.  

In any case, eSenders should refrain from mixing the use of API and of the web UI. 

For scenarios like yours, OP would recommend using the TEDXDC converter: https://github.com/OP-TED/ted-xml-data-converter. A notice published in TED XML format can be converted into a partial eForms notice; ‘partial’, because eForms notices contain much more information than TED notices. The partial eForms notice will have to be completed and checked in the eSenders’ systems. 

 

• If we have a previously published notice with an old XML structure and we start using eForms notices and now want to create a change notice on that old notice. Should we use the NO_DOC_EXT value to fill BT-758 (Change Notice Version Identifier) in the new eForms change notice XML? 

Answer: The reference to the previous TED XML notice (as published in the OJ S) must be entered in the ‘previous publication’ field in the eForms notice. See BT-758 Change Notice Version Identifier in the documentation.  

It can be found: 

 

• in the "DOC_ID" attribute of the root "TED_EXPORT" <TED_EXPORT xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://publications.europa.eu/resource/schema/ted/R2.0.9/publication" xmlns:n2021="http://publications.europa.eu/resource/schema/ted/2021/nuts" xsi:schemaLocation="http://publications.europa.eu/resource/schema/ted/R2.0.9/publication TED_EXPORT.xsd" VERSION="R2.0.9.S05.E01" DOC_ID="104583-2023" EDITION="2023036"> 

• on the top of the notice in TED and in the Data tab as ‘ND: Notice publication number’: 

  ​

• or in the search results in TED under the Document number: 

  ​

 

• When are you expecting change notices? Are they only accepted after publication or also before (instead of increasing versionID)? How does the linkage/referencing work? Can change notices be stopped?  

Answer: You can only send a ‘Change notice’ for a notice that has already been published. A ‘Change notice’ can be stopped before publication like any other type of notice. The link to the original notice that is being changed is in BT-758-notice efbc:ChangedNoticeIdentifier. 

 

• Is there a complete list with the ‘core fields’ that cannot be changed with Change notice? 

Answer: OP is working on it.  

 

• If a change notice includes fields changed that are not allowed to be changed, in which status would the change notice end up being? Can a faulty change notice be stopped and a new change notice submitted again? Would the second change notice still refer to the stopped change notice?  

Answer: If you submit a Change notice that tries to change certain fields that is not allowed, the notice will be rejected (by CVS), i.e. there is nothing to stop.  
 

• Is STOP function available for change notice or only for initial notice? 

Answer: Any notice can be stopped before publication. A Change notice is a notice like any other. 

 

• For Changes, BT-758-notice refers to the publication ID or the Notice ID? 

Answer: Both are possible. 
 

• How would a notice be cancelled? Would the change notice be of a specific type or just contain fields defining the cancellation? Or will there be an additional endpoint like stop to cancel a notice?  

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 would never have existed.  

Buyers should pay attention to the change reason they use as it may have implications for the procedure, for example, deadlines may need to be changed.  

2. To cancel the procedure or a 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. 

 

• What is to be done if another lot is added to an ongoing procedure (provided, of course, that the submission deadlines are met)? Is this a correction to the original notice? 

[post-event] Answer: If a Lot needs to be added to a procedure, then a new Contract Notice should be created. 

 

Conversion of current TED XML forms into eForms:   

• Can you elaborate a bit about the TED XML to eForms converter. How does it work and when will you be done with the development ? 

Answer: The TED XML Data Converter is written in XSLT. The XSLT code is separated into a number of files. To convert a TED XML to an eForms XML, an XSLT processor (we use the Saxon XSLT processor) reads the XML file and the appropriate main template and produces an eForms XML file. Currently, we only provide the XSLT code and associated files. Please check the status in the following link: https://github.com/OP-TED/ted-xml-data-converter . We will provide an API to convert a TED XML file in the future.  
 

• We are still waiting for the roadmap for the ted-xml-data-converter. Any updates and will R2.0.8 be supported? 

Answer: We started working on the conversion of the R2.0.8 in November 2022. 

 

• Is there a structure XML somewhere that lists all possible XML fields for all notice types with the corresponding BT / BG number? We found something in the folder TED XML data converter, but are not sure if this covers all fields of version 1.5. 

Answer: The converter is mapping the current forms to eForms. However, it will always be only partial because eForms have some extra fields that don’t exist in the current notices.  

To see which fields correspond to which notice types, it can be viewed in fields.json. 

 

• Is the correlation between the old forms (TED-XML F01, F02, F03)...with the new notice-subtypes documented somewhere? 

Answer: There is not a straight forward correspondence. The TED XML Data Converter uses an XML file ‘notice-type-mapping.xml’  for this purpose. Currently only the mappings for the TED standard forms covered by R2.0.9 are complete. 
 

• When will the conversion API be ready? 

Answer: OP is currently unable to provide a firm date. 

 

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

• When can we expect to get specifications for the below threshold subtypes E1-E5? 

Answer: E1-E5 forms will be included in the 2023 amendment to the eForms regulation. OP will start to specify them once the current developments are close to the end. 

 

• In the eForms FAQ section in Developer Docs, Question 15 about notices E1-E5, it is written that ‘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’ and ‘Member States could send below threshold notices via eForms as from November 2022 as long as they comply with the rules for their equivalent above threshold notices’. The problem is that E1 and E5 notices don’t have ‘their equivalent above threshold’ notices. So, if we want to create, validate and send for publication eForms E1 and E5 before October 2023 – will that be possible? And if is possible – how? 

Answer: E1-E5 will not be implemented before October 2023. In the meanwhile, notices for procurement below the threshold must fit into eForms 1 to 40. 

 

Translations: 

• Some codelists have just English values – are you planning to add translated values to all codelists?  

Answer: Yes, OP is working on it, all the codelists should be translated in the coming months. However, all the codelists that can be found at EU Vocabularies are already translated. 
 

• If we use the 1.3.2 version, we cannot get the Estonian translations that were added later with versions like 1.5 and so on, i.e. if we were to go live with the 1.3.2 version, would our notices remain bilingual due to the lack of Estonian translations? 

[post-event] Answer: We have released patches for eForms SDK 1.3, 1.4, 1.5 on 14/03/2023. The patched versions include updated translations of text labels as well as updated notice visualisation templates. 
 

• We noticed that some codes were not translated into French in the Translations directory. Is an update of the files in this directory planned? 

Answer: We will translate all codelists, some technical ones are indeed only in English. 

 

• The translation files (even the English version) are not complete and sometimes the Slovak translation is not correct. We could complete/correct them in our app, but then we could have problem with upgrading to newer version of eForms SDK. It would be more appropriate to correct these values in the SDK. One possible solution would be that we would do pull request with completed translation files into the eForms SDK GitHub. Is this solution appropriate for you, or could you recommend some better solution?    

Answer: Please contact us via TED Helpdesk to signal missing translations, this will help us to fill in the gaps.

 

• Are you going to publish patch versions for old releases (1.3, 1.4) when translations are ready? Currently only English speaking countries may use old releases due to lack of complete translations. 

[post event] Answer: We have released patches for eForms SDK 1.3, 1.4, 1.5 on 14/03/2023. The patched versions include updated translations of text labels as well as updated notice visualisation templates.  

 

Publication deadlines: 

• Please confirm that there is no publication at the weekend (Sun & Sat), only through the working week (Mon – Fri).  

Answer: It is correct, OP never publishes the OJS on weekends. There is also no publication in some of the common bank holidays (e.g. Christmas).  

 

• Is it correct that the manual check might take longer than 5 days if a weekend is in the timeframe? Article 51, (2) of the directive says in 5 days, not 5 working days. Should we expect 5 working days until we can say that the notice is good to go if we haven't received a NOT_PUBLISHED? 

Answer: OP will check lawfulness taking into account that a notice should be published within 5 calendar days from dispatch date. 

 

• Does the timeline for publishing of notices (5 days) also apply for notices sent by EU institutions which needs to be translated in the different EU languages by the Publications Office? 

Answer: Notices that require translation will be published within 7 or 12 days, depending on their length. 

 

SDK roadmap and impact: 

• Will you be updating old versions with minor versions in terms of critical bugs or old major versions (1.3 for example) are no longer updated, e.g. 1.3.2.x?  

Answer: Older SDK minor versions (like 1.3.2) will have as many patch releases as needed. These patches won’t affect the validity of XMLs already submitted. 

 

• The rules to come e.g. to validate fields changed in a ‘change notice’ or fields referring to PIN/CN – will they be provided as schematron/schema validation rules? Would a new SDK version be submitted then? Would e.g. SDK 1.5. notices based on these new rules be rejected immediately? 

Answer: New rules will come in new versions of the SDK (as EFX and Schematron). This means that the current SDKs, e.g. SDK 1.5, may be more or less strict than the future releases.

 

• Will you provide further examples to describe special dependencies in notices with SDK 1.6 or later? 

Answer: If ‘special dependencies’ refers to ‘dynamic’ rules, i.e. rules that check values between notices, e.g. to compare the fields between a Change and original notice, we regret to say that they have not yet been implemented in the SDKs. 

 

• When may we expect to see fixes to the 1.3 and 1.4 releases for bugs discovered after introduction of 1.4 and 1.5? 

Answer: Please let us know which fixes in particular would need to be patched in the older SDK versions, via TED Helpdesk. 

 

• If SDK 2 is released will eForms in version 1.5. not be accepted anymore?  

Answer: SDK 1.5 will be supported for at least one year after its release. SDK 2.0 will also be supported for at least one year. 
 

• As you said SDK 2.0 will only contain EFX-improvements. Will there be SDK 3 because of potential directive amendment till the end of this year as well? 

Answer: There will certainly be an amendment to the regulation this year. It usually means that there might be changes to fields, new business terms, adapting what is mandatory/optional, adding E1-E5, etc. However, changes can appear in SDK 1 or SDK 2 in case they will only require a minor release (i.e. schema change, notice type definitions, etc.). 

 

• Why must a change to SDK 2.0 require a change to the notices when the change is only happening behind the curtains ? 

Answer: The change to SDK 2 does not involve changes to the notices, the XML structure stays the same.  
The users don’t have to update immediately to the SDK 2.0, it depends on their needs. 

 

• Before releasing 2.x, can we have a SDK 1.x.x which will be more completed? With more labels, coherent rules? The release date of 2.x.x is already announced. But we still have an incomplete SDK 1.x.x. 

Answer: Further SDK 1.x.x releases are foreseen and will include additional/improved requirements. SDK 2.x.x is needed to address some of the issues that SDK 1.x.x cannot address because of some inherent limitations in EFX. 

 

• What are the implications of submitting a file with a higher SDK than the SDK with which it was first submitted? 

Answer: There shouldn’t be any implications. The notice will be validated with the SDK it is submitted in. 

 

• The SDK seems to be still in a relatively unfinished state. There are still missing or contradictory business rules, for example. Productive transmission is not possible in all cases. We thought productive transmission would be possible with the start of the transition period, but this does not seem to be the case. As a result, is a corresponding extension of the transition period to be expected? 

Answer: The extension of the transition period is a policy decision. In any case, it is possible to submit production notices with the current SDK version. 

 

• Will there be backward compatibility between version 2.0.0 and version 1 of the SDK? 

Answer: In principle, there will be backward compatibility between SDK 2 and SDK for the major part. However, EFX will not be backwards compatible.  

 

• Why are you reflecting the SDK version in the notices rather than the format version? 

Answer: The notices have to comply with the SDK version they have been created for; the SDK defines not only the XML structure (schema) but also the constraints that apply to its content (rules).

 

EFX toolkit: 

• Do you expect new EFX to be a breaking change? Would it require to re-write a parser, etc. from scratch? 

Answer: No, you will not have to reimplement everything from scratch. In principle, you will only have to add translations for any added features functions. 

 

• This is an example of a condition ‘{ND-Company} ${OPT-200-Organization-Company in OPT-300-Tenderer}’. How can I evaluate this condition dynamically from my xml / fields.json? 

Answer: You can use the translator that is provided in the EFX Toolkit (if working with Java) to convert the EFX into XPath and evaluate the XPath against the XML. Should you need more information, please open a discussion via GitHub.  

 

Miscellaneous: 

• Is increase versionID only possible before publication to send an update/corrections? Can the versionIDs have gaps like sending 01 and then 03, e.g. if 02 was stopped before it reached TED? 

Answer: VersionID is only used before publication, so it can be used to resubmit an updated notice that failed validation, was stopped or was not published. There are currently no rules to prevent gaps between version numbers, as the versions could be increased within the eSender’s application before submitting via the API. However, the maximum version number is 99 (as it is two digits).

 

• Is there a web-component of eForms notices? 

Answer: No, there is not. 
 

• When will the production contain eForms notices in prettier view. Currently the notices are together with the old eNotices and the view is plain page and text without any design. 

Answer: At the moment, OP is focusing on the structure. The visual part will be improved later. If you have any specific ideas, please let us know via TED Helpdesk. 
 

• We found a misalignment about the legal status of some subtypes between the table on CELEX file and what is indicated on website. 

Answer: Please contact us via TED Helpdesk with more details.  

 

• What is the latest useful date, for an eSender, within which it is necessary to create the web interface for the contracting authority? 

Answer: OP will not accept notices in the current TED schema format after 24 October 2023. It is up to the eSenders to plan accordingly. 
 

• Division into lots - do we understand it correctly, that even if the order is not divided into lots, we need to create one lot that includes most of parameters relevant for the order? - If so, there is a duplicity in data - fields in subsection Purpose are available twice; once when filling the data in section Procedure, second one when filling the data related to the lot (in this case 1 lot = 1 order). Is this the final solution or this will be changed to avoid this duplicity?  

Answer: The implementation reflects the eForms Regulation.

 

• How to link errors with node or fields from fields.json or {subtype}.json? 

Answer: In version 1.6 of the SDK, we will add in the Schematron rules the identifier of the field or node which is the target of the each rule. This information will be available in the validation report for each failure, in the ‘see’ attribute of the ‘diagnostic-reference’, for example: 

    <svrl:diagnostic-reference ... see="field:BT-24-Lot"> 

By combining this with the information in the "location" attribute, you should be able to relate an error with the specific item that causes the error. 

We will also add a new page in the documentation at https://docs.ted.europa.eu to provide information on the content of Schematron files and validation reports. 

 

• XML exported from eNotices2 is not valid against XSD schema V2.3, e.g. I have two elements present even if the node is a choice. Element <efbc:NaturalPersonIndicator> is not allowed at this location under element <efac:Organization>.  

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

 

• Sometimes I have an exception when generating the not summary PDF. But there are not many details to explain this exception. What can I do to move forward? 

Answer: Please contact the TED helpdesk with details so we can investigate further, namely what you mean by ‘not summary’. 

 

• Could you please explain one more time what 'dispatch date' is? 

Answer: It is the date when the buyer (not a system/application) sends a notice for publication, directly if in eNotices2 web or indirectly if via an eSender. 

 

• Why is there no readable mapping files to access, which show you in a simple way for every single field in the old notices, if this field is also included in eForms (BGroup / BTerm). By this I don't mean existing notices definitions in json or analyse existing converter apps. 

Answer: Most fields in the old TED XML do not have a direct correspondence to individual fields in eForms. The best way to achieve a mapping is to use the TED XML Data Converter. 
In April 2022, OP published an excel file with this information; it can be found at SIMAP: Initial mapping of current TED-XML schema to eForms (13/04/2022): https://simap.ted.europa.eu/en_GB/web/simap/eforms. 

 

• Where are the Business Rules XSLTs? There are only Schematron files. 

Answer: Schematron is an XML validation language and the business rules are applied by converting the schematron into XSLT and then applying the XSLT to the notice XML, that is done dynamically so that the XSLTs are not stored. 

 

• Some Groups have identifierFieldId to identify the field id of the group. But for some repeatable groups, we have an id in the content, but the group has not _identifierFieldId. Exemple 16.json, group id is GR-Lot-ProcurementDocuments, the id is OPT-140-Lot. But there is no _identifierFieldId.   

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

 

• Will you create helpful packages for different program languages to make integration easier? 

Answer: Please specify your needs via GitHub. 

 

• Will you update also the eForms Notice Editor Demo integrated into the new version of SDK, e.g. for SDK version 1.5.? 

Answer: The Notice Editor Demo application accepts all the SDK version from 1.0 onwards. Eventually, the obsolete versions of the SDK will be removed from it. 

 

• What's the difference between yellow and white fields in notice editor demo? 

Answer: It doesn’t refer to anything specific. It is a working version, colours were simply not removed. 

 

• What recommendation do you give us, regarding the implementation of the eForms (use of the fields.json, SDK in general), if we already have the forms created and we cannot use the .json of the SDK to show the visual part? 

Answer: OP would recommend to consult the eForms Developer Guide: https://docs.ted.europa.eu/eforms/latest/guide/index.html. 

 

• Can we send a Contract Notice without sending a previous Prior Information Notice? 

Answer: It depends on the national legislation. 

 

• Exclusion grounds in eForm 16 (CN) requires description for each exclusion ground, which is based on a code. However, the viewer does not reveal the code names. Is it currently an error or is it meant as such? Currently the main centre point of CN is the unproportionally long exclusion grounds section. 

Answer: OP will analyse the issue.

 

• Are or will there be manuals available for the correct use of the forms? 

Answer: Help pages will be available on eNotices2. However, the buyers are expected to know the content expected for the forms. 

 

• Which TED API should we use to check if the submitted notice is already published? 

Answer: The search API of eNotices2. 
 

• Can you provide examples of change notices and it is there maybe some video in eNotice2 which explains the complete process from creating a notice, publishing this notice and changes for this notice? 

Answer: OP is planning to prepare some videos that will be available at a later stage.  
 

• Can you provide all real examples of fields with Regex? 

Answer: For example: the email URL. They are called patterns and they can be found in the fields.json. 

 

• Can you provide an explanation and example of how to fill out the lot award criterion part in eNotices2? We are not sure how to combine these fields in relation to Price/Costs/Quality. 

Answer: Each criterion must either have a type (Price/Costs/Quality) or, if these are not available, a description of the method to be used if weighting cannot be expressed by criteria. 

If the criterion type is used, then it must contain a combination of a number and weight/threshold/fixed properties (for example Price is 100 % where 100 is the number and the percentage is a weighing) 

In case the weighing is an order of importance - and only that property is used, then the Justification for not indicating the weighting of the award criteria should be filled in. 

For each criterion type, the whole award criterion group must be repeated.  

Other rules may apply for any combination of the above mentioned business terms. 

 

• In the eNotice2 application not all levels of NUTS Codes are available. Is there a reduction of available NUTS Codes in comparison to the ‘old’ forms, i.e. we can only field third-level NUTS Codes, but no middle or top parent level? 

Answer: According to eForms Regulation Annex 2, the NUTS3 classification code must be used for both BT-507 Organisation Country Subdivision and BT-5071 Place Performance Country Subdivision. SDK 0.5.0 and future versions have reduced the NUTS codelist to only level 3 NUTS codes. These fields are intended to be used only when the NUTS3 level is known. If a country does not have NUTS3 code, then it is not required. To specify a country, the fields BT-514 Organisation Country Code and BT-514 Place Performance Country Code can be used. If the country is used as a geographical region, neither BT-507 nor BT-5071 is required. 

 

• We have a self-developed framework for rendering dynamical forms and convert it to appropriate data types (i.e. XML, JSON etc). What we need is a description of rules (i.e. when to display or hide some fields or which fields are required depending on the applicable rule). It very difficult to understand these rules from the available documentation in GitHub manually, because we are not using the SDK. Can you help us with a description of these rules (i.e. in the old forms these rules were nicely defined in form validation excel files)? 

Answer: These rules are listed in the documentation: https://docs.ted.europa.eu/eforms/latest/reference/business-rules/index.html 

 

• A use case: a user starts to edit a notice in the web UI. The user does not finish the notice but wants to save the data. There should be a ‘saveable representation of data’ to be stored to disk which can be ‘re-read’ when the user wants to continue. When the data is incomplete it will be impossible to write the ‘physical structure’ of the notice conform with the xls schema which could be re-read. What is the adequate format for this ‘incomplete data’? 

Answer: In eNotices2 UI, you can export the xml of the notice whenever you need, and reimport it as well. In any case, eSenders should refrain from mixing the use of API and of the web UI. 

 

• We have currently a desktop application (visual part) which contains procurement information. How can we leverage the SDK to construct a valid xml? We have no need for a visual model, we only want to construct a valid xml based on our data. Can we use the .json file or should we stick to the xsd's? 

Answer: You need an algorithm that draws input from your system and constructs the XML. The JSON files contain information relevant for the user interface and may not cover all the possible rules. The XSD only does a lexical validation. To ensure conformance of the generated XML, use the XSD and the schematron files for validation. Further controls will also be applied by CVS to ensure that there are no ‘collisions’ possible between the files submitted and the ones already received at OP (e.g. uniqueness of the Notice ID). 

 

• Which Standard form is corresponding to the new eForm 09 notice? 

Answer: There is no exact match to ‘Prior information notice used to shorten time limits for receipt of tenders — defence directive’. 

 

• Starting from scratch, what could be the best approach for implementing the solution for sending the notices? is there some software library already in place on top of the official ones? the question is for both the backend and frontend sides of the matter.  

Answer: You can look at the sample apps: 

- Notice Editor (Java): https://docs.ted.europa.eu/eforms/latest/notice-editor/index.html, 

- Notice Viewer (Java): https://docs.ted.europa.eu/eforms/latest/notice-viewer/index.html.  
 

• When will you be finished with the specifications regarding which fields that can be modified and presented in a contract modification notice? 

Answer: OP is working on it, it will come in the coming months. 
 

• There is the CELEX fields xls table, where some fields have the CM property (mandatory, only if...). I had read the documentation, have searched in Git, but I couldn't find the mandatory conditions of every CM field. How can I find these CM conditions? 

Answer: The SDK 1.2 contains the conditional mandatory rules. These were removed from 1.3 onwards, but will be progressively included 
 

• What is the purpose of section Organisations? The buyer and service provider are specified in the section Information about contracting party and provider. According to JSON definition, there is at least one obligatory entry. Should we repeat the entry for the buyer in this section? 

Answer: The Organisations section helps centralise all the detailed information about the legal entities involved in the procedure. Any organisation and the associated touchpoints also get a technical identifier that is referred to in the remaining parts of the document. This approach prevents the unnecessary repetition of information and the associated risks of discrepancies.  

 

• Some codelists have just one value, e.g. classification-type. Are you planning to add other values to these codelists, or is there some other reason to have these codelists? Choosing values from one-value codelists can be confusing to the users. Can we fill these values for users automatically?  

Answer: The eForms regulation allows more than one classification type so this codelist may be expanded in future. But for the next couple of years the only classification with remain CPV. Note that we originally had Supplementary CPV as a second classification type but this classification will not be used in eForms. For the end user, it would be helpful that this value is automatically filled by the application. 
 

• We have noticed that v 1.3.2 viewer service misses certain filled in fields in xml/pdf, e.g. contract data in a result notice. Is it going to improve for v 1.3.2? 

Answer: The viewer is being continually improved. Most fields will be covered in the next release of the SDK. In case you notice any inconsistencies, please contact us directly via TED Helpdesk.  
 

---

During the workshop participants answered some Slido questions, which provided valuable feedback for OP.  

---

 

Last update: 25 April 2023.
Published: 17 April 2023.