General overview of eForms
Is there a general presentation of eForms available?
The policy background of eForms is available on the DG GROW website.
The 2022 TED eSenders annual seminar provided an updated overview of eForms implementation.
The May 2022 eForms Technical Workshop focused on eForms technical implementation for developers and on building metadata-driven applications.
A second eForms Technical Workshop took place online on 29 & 30 September 2022, followed by the 3rd eForms Technical Workshop of February 2023.
The Publications Office is organising a series of follow-up eForms events for 2023.
What is the planned transition for eForms implementation on the TED portal?
Starting on 14 November 2022, usage of eForms by Contracting Authorities and Contracting Entities is optional and the Publications Office (OP) will accept both the current TED schema notices and new eForms notices. The TED portal will show both the current TED schema and eForms notices.
From 25 October 2023 onwards, the usage of eForms is mandatory and the Publications Office will no longer accept the current TED schema notices but only eForms notices. The TED portal will continue to show the TED schema notices that will have been received until 24 October 2023.
The last day when OP will accept notices in the current TED schema format will be 24 October 2023, in line with the repeal of Implementing Regulation (EU) 2015/1986.
Which systems will be available for eSenders during the transition period?
OP is developing a range of applications to manage the collection, validation, processing, visualisation and dissemination of eForms notices. OP will progressively make available the relevant applications through a “Preview” environment that will help eSenders to develop and test their own applications. A guide on how to test in "Preview" was presented in Day 1 of the second eForms Technical Workshop: "TED Developer Portal and using eForms APIs".
Notices sent to the current eSentool will continue to be accepted until 24 October 2023 and published on TED. As of 14 November 2022, eSenders will have the possibility to send notices in the new format; however, this will not become mandatory before 25 October 2023.
On 14 November 2022, TED will display the new eForms while it will continue showing all notices submitted for the past 10 years even after 2024. From 14 November 2022 until 24 October 2023, the Publications Office will run two systems in parallel, but it is up to the eSenders to implement changes on their systems as and when best suits them during this time. The current reception (eSentool and current eNotices) and production systems will be discontinued at the end of 2023.
Until when will the current eNotices application be available?
The current eNotices application will be available to submit notices until 24 October 2023.
The new eNotices2 application is available as of 14 November 2022 and will be running in parallel with the current eNotices application during the transition period.
eNotices2 is an application that performs both functions carried out by the current eNotices and eSentool applications. Authorised applications will be able to send complete notices to the API data interface of eNotices2, and if they are valid, they will be published in the Supplement to the Official Journal of the European Union (OJ S). Individuals with an eNotices2 account will be able to create notices within eNotices2 using its interactive web forms.
eNotices2 will not take into account the different tailoring policies of Member States. As long as a submitted notice is valid against the eForms schema and the validation rules which implement the EU procurement regulations, it can be published in the OJ S. It will be up to the notice authors to apply any additional tailoring required by an individual Member State.
Currently with eSentool, several people can access the same front-end eSender account. Will eSenders be able to organise themselves the same way in eNotices2?
eNotices2 web user interface was designed with front-end users of eNotices2 in mind. eSenders are API users and other than logging in eNotices2 once to pair their API key, we would discourage them from using eNotices2 web user interface to avoid certain manual actions that may interfere with using the API.
For instance, eSenders can use eNotices2 to create “workgroups”, however, the API is not aware of this context and no API function can be performed on a notice that has been manually transferred to the context of a “workgroup”. We would, therefore, discourage any manual operations on notices via the user interface of eNotices2; these sort of groupings and permissions should be handled in the eSender’s application instead.
For generating an API key via the TED Developer Portal, only one EU Login (and its email address) is allowed per account. As an eSender, you should use a functional/ shared email address to generate your API key and your eNotices2 account.
The TED Developer Portal will soon offer the possibility to eSenders to add additional contact emails to their “Developer Profile” so that they can receive communication from the Publications Office, such as important announcements. Any email notifications coming from eNotices2 application that OP may develop in the future for eSenders will still be addressed to the one email address/ EU Login of the eNotices2 account.
With eForms, will there be a fixed publication schedule as there is today?
The release calendar on TED includes the dates on which there will be an issue of the OJ S. The OJ S will continue to be published from Monday to Friday apart from certain national holidays.
When submitting a notice, users can select a preferred publication date, or can choose publication “as soon as possible”.
What is the earliest possible time by when eForms could be introduced on a national level?
The application of the eForms regulation in national legislation is not under the control of OP or the European Commission. We assume that in any case the earliest possible time by when eForms could be introduced at a national level would be the same as for the EU level, namely 14 November 2022.
See also the section on implementation in EU countries.
What sources of information are available for eForms?
The following websites cover the various aspects of eForms:
Legal basis: Commission Implementing Regulation establishing standard forms for the publication of notices in the field of public procurement (eForms)
Policy background from the European Commission (DG GROW: Directorate General for Internal Market, Industry, Entrepreneurship, and SME)
SIMAP: information about European public procurement
eForms presentations from the TED eSenders annual seminar in November 2021
eForms presentations from the eForms Technical Workshop in May 2022
eForms presentations from the second eForms Technical Workshop in September 2022
eForms presentations from the TED eSenders annual seminar in December 2022
eForms presentations from the third eForms Technical Workshop in February 2023
TED developer documentation portal
eForms Software Development Kit on GitHub
For any questions or issues, please contact the TED helpdesk at: email@example.com
For developers, please see our eForms Developer Guide.
For technical and development-related questions, GitHub discussions are open for developers: https://github.com/OP-TED/eForms-SDK/discussions/. The forum is to allow eForms application developers to provide feedback and share their experiences using the eForms SDK. The eForms SDK development team at the Publications Office may collect feedback but may not be able to engage in discussions. If you want to report a bug in the eForms SDK, please create an issue: https://github.com/OP-TED/eForms-SDK/issues.
Please note that the document "XPATHs provisional release v. 1.0.docx" is outdated and will no longer be updated. The equivalent information, and much more, is now available in the eForms SDK, which also takes into account the fact that some Business Terms occur in different contexts, and that the rules may differ between these contexts.
Forms and procedures
Is there a mapping of standard forms to eForms notices?
For a mapping of standard forms to eForms notices, please refer to COMMISSION IMPLEMENTING REGULATION (EU) 2019/1780 and Table 1 of the Annex as the authoritative source of information.
You may also find useful the “Initial mapping of current TED-XML schema to eForms (13/04/2022)”, which was shared on SIMAP: https://simap.ted.europa.eu/web/simap/eforms
What is the lifecycle of an eForms notice?
An overview of the lifecycle of eForms notices was presented during the 3rd eForms Technical Workshop.
What is planned with eForms regarding the OJ S publication number?
Starting on 14 November any notices submitted as eForms will have a publication number of 8 digits, meaning that any application handling eForms must use this format. On TED, eForms notices will therefore have an 8-digit publication number and TED-XML notices will continue to have a 6-digit publication number.
The current TED website will continue to have a limitation of 6 digits when addressing a notice in its URL, meaning that it will be necessary to remove the two leading zeros in the publication number when linking to an eForms notice. For example, to link to eForms notice 00654321-2022, the URL would be https://ted.europa.eu/udl?uri=TED:NOTICE:654321-2022:TEXT:EN:HTML
TED publication numbers will not exceed 1 million per year and can continue to be expressed in 6 digits. This limitation will end with the launch of the TED 2.0 website in the second half of 2023.
Will eSenders have to send eForms for procedures that were started with the current standard forms? If so, how will the previous publication field be filled in, given that the Procedure Identifier is not used in the current forms?
Once the use of eForms becomes mandatory, eSenders will be required to send eForms notices for any procedures that were started with the current standard forms. As there is no Procedure Identifier in the current forms, in these cases the notice number of the previous TED XML notice (as published in the OJ S) must be entered in the previous publication field in the eForms notice. See Previous Notice (OPP-090) in the documentation.
In the documentation we can read that we must use a UUID version 4 for the Procedure Identifier. Are there any limitations? Can we use every possible identifier and is it possible that two or more eSenders use the same number identifier in this case?
The Procedure UUID is not linked to the eSender but to the procedure. Same Procedure UUID documents will be linked together in the same family of documents; this is the case - for instance - for a continued procedure. In practice, it would be possible to send same family documents (linked together through the same Procedure ID) through different eSenders/ platforms.
There are no limitations at this stage and version 4 UUID was chosen as the chances that the same UUID will be generated is close enough to zero to be negligible.
How can a Contract Notice (current schema) be linked to a Contract Award Notice (eForms)?
eForms include some BTs with the identifier of the previous notice, regardless of whether the notice uses the current TED schema or is an eForms notice. If the previous notice does not use eForms, the identifier will be the OJ S Notice ID (XXXXXX-YYYY). For eForms, the previous notice identifier can be the Notice ID (UUID-vv).
See also Previous Notice (OPP-090) in the documentation.
How do we make a correction (F14) to a notice published in current schema, after transitioning to eForms?
In the same way that it will be possible to link current form notices to eForms for procedures that started with the current form TED schema and ended with eForms.
The notice in eForms format will link to the preceding TED format notice by referencing its OJ S number. However, a TED format notice cannot follow a notice in eForms format.
OP is currently creating a converter, so a published notice in TED format can be converted to a partial eForms notice; "partial", because eForms notices contain much more information than TED notices. However, the "partial" eForms notice will have to be completed and checked in the eSenders’ systems.
Regarding the F14, there is no longer a specific form for corrections such as the current F14. The Change notice Business Group will instead work as a separate section that will be attached to any notice, to indicate that this notice corrects, changes, or otherwise modifies a "parent" notice with the use of BG-9 and in particular BT-140 Change Reason Code. Both the original notice and its change notice will be published.
See Changes-associated elements in the documentation and questions concerning change notices on GitHub: https://github.com/OP-TED/eForms-SDK/discussions/88#
Currently an F14 may not be submitted until its previous notice is published. Will there be a change with eForms?
With eForms, there will be a Change notice, which is a reproduction of its parent notice with an extra section to advertise changes to the procurement and procurement documents and for correction of clerical errors. Major changes such as adding or removing Lots to a published Contract Notice cannot be done through a Change notice; in this case, a new CN would be expected.
A Change form is only possible for notices whose parent notice has been published to avoid the possibility that different users may act on the same notice at the same time. If the parent notice has not yet been published, users can stop publication and resubmit.
In case of many clerical errors, it will be possible to cancel a notice, which will cancel the notice itself and make it null and void, but this will not cancel the procedure. The user can - in this case - republish the same notice. To cancel the procedure, we would expect a Contract Award Notice with no winner - regardless of whether the submission deadlines have been reached or not – along with a reason.
Even when the Contracting Authority decides to end the process for one lot only (out of many) with no winner in the CAN, the lot would be expected to be present/ carried over for all changes in the future. The Contracting Authority may choose to indicate that the lot will not be relaunched through BT-634.
Please note that all notices that are successfully submitted will be published. The publication of a notice itself cannot be cancelled unless a user stops it before it reaches the daily export to TED.
Does the publication of a CAN to cancel one / some of the lots automatically require the buyer to also publish a Change notice for the original Contract Notice, in order to “update” it?
There is no obligation to publish a change; the buyer could, however, change the notice and use BT-634 to explicitly note that this lot/ these lots will not be relaunched.
When creating a Change notice, should we send a new notice version with all changes included AND the section with the information of what has been changed or should we only send the Change notice separately?
The Change notice Business Group works as a separate section that will be attached to any notice to indicate that this notice corrects, changes, or otherwise modifies a "parent" notice (identified by NoticeID and VersionID) with the use of BG-9 and in particular BT-140 Change Reason Code.
A Change notice must contain all the information reported in the initial notice, with changes applied, as well as a section describing the latest changes (to the immediately preceding Notice):
Changes may apply to notices of any form type. A Change notice may only concern a single notice and contains all the information from that initial notice with applied changes in addition to the information on those changes.
When a change is applied to a previous Change notice, the consolidated text must integrate all changes from previous versions, and only the latest changes are described in the changes section.
A Change notice may report that the procurement documents referenced by the initial notice have changed, and the date of that change, using BT-718 Procurement Documents Change Indicator and BT-719 Procurement Documents Change Date. A description of the changes to the procurement documents may be included in BT-141 Change Description.
The Notice VersionID is described in the Notice & Version Identifiers section: "Versions of a notice are purely editorial and for a given Notice ID, a single version may be published."
The Notice VersionID can relate only to the editorial versions of the same notice (with the same Notice Identifier), managed by the generating application (e.g. eNotices2 or an eSender’s system), before publication of the notice. Only one of these versions will get published.
The version ID values of different notices do not relate to each other. So, the VersionID of a Change notice is not related to the VersionID of the preceding notice.
In the Change Notice section, the word "version" is used to describe a notice or any of the related Change notices.
We understand that the Change notice shall have its own identifier and version that differs from the one of the notice that has been changed. Does that mean that the initial notice always keeps the same version number?
Yes. Multiple version IDs are for pre-publication, when eSenders might have multiple versions of the same notice on their systems and submit some of them. Each time a notice with the same notice identifier is submitted and accepted by the destination application (and publication is not stopped by the user), it must have a different version ID (starting at "01" and incrementing).
The first time the notice is accepted and published, the version ID of the notice they submitted is then final, and no other notices with the same notice identifier will be accepted. The version ID should increase if the notice is stopped and resubmitted or in case of error.
The association of a Change notice to its parent notice is performed using BT-758. There may be multiple changes applied in a single change notice (each change refers to the relevant section using BT-13716). When changes appear at different points in time, then successive Change notices have to be submitted, each referring to the previous one.
Changes may only be applied on published notices, therefore, the use case where a second change should be applied while the first one has not been published should be addressed either way:
Complete and submit the first Change notice to have it published and then proceed with the second
Integrate all changes in a single valid Change notice
When the non publication of the first Change is purely associated to non reliable transmission, then, if the first Change has to be published separately, use an alternative channel (e.g. eNotices2).
BT-13716: Change Previous Notice Section Identifier refers to sections of the published notice. These reference identifiers should match identifiers that exist in the change notice. The list of section identifiers is reported in table 3 of Referring to sections of a notice.
Can you please clarify the meaning of each choice in the codelist Change corrig justification and when to use them?
Please refer to the definitions in the Change-corrig-justification codelist on EU Vocabularies.
This codelist is required for BT-140 Change Reason Code when using a Change notice.
What will be the notice status of an eForms notice through its lifecycle?
A user working on the user interface of eNotices2 will be able to see the following notice status:
Draft: The notice is being drafted.
Submitted: The notice is successfully received, validated and sent to OP (received by TED-Monitor-2022).
Published: The notice is published online on TED.
Stopped: Publication of the notice was stopped by the buyer/ eSender before publication and the request was accepted.
Not published: The notice was received but not published on TED.
Deleted: The notice has been deleted by front-end user.
Archived: The notice has been archived by front-end user.
Publishing: Publication process in progress, i.e. the notice has been added to the daily export for TED.
The following notice statuses can be queried via the API for eSenders: DRAFT, SUBMITTED, STOPPED, PUBLISHED, DELETED, NOT_PUBLISHED, ARCHIVED, VALIDATION_FAILED, PUBLISHING. For more information, see the relevant section: https://docs.ted.europa.eu/home/eforms/FAQ/index.html#_apis_and_web_services.
What is the meaning of notice status “Not published”? Will there be reason codes for “Not Published” notices?
If a notice is rejected due to manual lawfulness checks, or a technical error occurs in TED Monitor 2022, the notice will obtain status “Not published”, which can be queried through the API. Rejection due to lawfulness manual check will be communicated via email to the contracting authority only.
What is the meaning of notice status “Publishing”?
Every working day, (generally around 16:00 CET depending on the number of notices to be published), the Publications Office initiates the process of publication of the next OJ S. If a notice is in the daily export to TED and the process has been initiated, the status of a “submitted” notice will then change to "publishing". “Stop publication” action is no longer possible for notices in status “publishing”. Once the notice has been published, you will be able to submit a change notice for publication in the OJ S cancelling the initial notice, i.e. by creating a change notice with reason “notice cancelled”. Both the original notice and the change notice will be published in the OJ S in this case.
What is meant by E1, E2, E3, E4 and E5 in the Excel document annexed to the eForms regulation?
E1, E2, E3, E4 and E5 refer to forms that are not part of the eForms regulation, but they were included in the “Extended Annex” to regulation 2019/1780 available at: https://ec.europa.eu/docsroom/documents/43488
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.
They would extend (E) the set of the other forms and correspond to the following notices:
Preliminary Market Consultation (E1)
PIN below threshold (E2)
CN below threshold (E3)
CAN below threshold (E4)
Contract Completion (E5)
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. Member States may choose to require other fields for national publication, but these are outside the scope of eForms.
What is the legal value of the five other non-eForm forms?
The Implementing Regulation has 40 eForms. The 5 other forms are not eForms and implement other EU regulations but they are included in the same systems at OP:
T01, T02: regulation 1370/2007 (public passenger transport by rail and by road)
X01, X02: business registration (European economic interest grouping and European company/cooperative society)
CEI: call for expression of interest (by EU institutions)
What is the notice variant Business Registration Information used for?
The “Business Registration Information Notice” scheme refers to European Company and European Economic Interest Grouping notices, currently available as interactive PDFs only.
They are not part of the eForms Implementing Regulation but they are implemented in the same systems at the Publications Office so they appear in the eForms schema and rules as forms X01 and X02.
What is foreseen in eForms for countries that have no NUTS code?
The eForms Regulation Annex 2 states that for both BT-507 Organisation Country Subdivision, and BT-5071 Place Performance Country Subdivision, "The NUTS3 classification code must be used." BT-507 and BT-5071 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. SDK 0.5.0 and future versions have reduced the NUTS codelist to only level 3 NUTS codes.
BT-507 is only mandatory if one or more of BT-513 Organisation City, BT-512 Organisation Post Code, or BT-510 Organisation Street is present. And BT-5071 is only mandatory if one or more of BT-5131 Place Performance City, BT-5121 Place Performance Post Code, or BT-5101 Place Performance Street is present.
BT-514 Organisation Country Code, and BT-514 Place Performance Country Code, are used to specify a country. If the country is used as a geographical region, neither BT-507 nor BT-5071 is required.
When Place Performance Services Other (BT-727) has the value "anyw-cou" (Anywhere in the given country), the Place Performance Country Code (BT-5141) is mandatory.
How will tailoring by Member States be handled by TED and the Publications Office?
National specificities and their implementation at national, regional and local level are outside OP’s remit.
In the eNotices2 form-filling tool user interface, users will be able to fill in and send notices based on the eForms regulation. eNotices2 is not aware of and does not apply any compliance with Member State tailoring; for example, it will not check if an optional field (according to the EU regulation) is mandatory at national level.
The same applies to notices sent by eSenders via the eNotices API (the successor of eSentool). All notices go through the same checks of the Central Validation Service, not applying any Member State tailoring. It is up to each user (or eSender) to ensure that their notices comply with the national implementation of eForms.
Planning and development
What are the update cycles and how is change management (minor/major releases etc.) carried out for eForms?
The technical standards will be based on the eForms SDK, which is versioned clearly, in particular to distinguish any breaking changes.
See also the developer documentation about SDK versioning at: https://docs.ted.europa.eu/eforms/latest/versioning.html
The formal change management governance is currently being set up and a change management board is envisaged.
Has development of eNotices2 started?
The development of eNotices2 started in 2020 and the application is foreseen to be in production for November 2022.
The scope of the application is to implement the eForms requirements in a product that will allow at least the same functionalities that are available in the current eNotices and the main functionalities that are currently available in eSentool.
The application also has a number of new features that will make it easier and more streamlined for contracting parties to publish notices, while mitigating the inherent complexity of the eForms regulation as much as possible.
Presentations are available at the 2021 eSenders seminar. An updated demo of eNotices2 front-end application was presented during the eForms Technical Workshop of May 2022.
eNotices2 is also available in "Preview" for testing purposes.
From 14 November 2022, will EU public buyers be able to create their eForms in eNotices2? Will it propose all the fields (mandatory and optional)?
This is the point of eNotices2: it will provide all mandatory and optional fields and it will have rules to determine which fields are mandatory under certain conditions. There will also be a feature for users to make some of the optional fields mandatory. In the same way, it is also foreseen that if an optional field is not relevant for some users, the administrator of the organisation can “hide” these optional fields from view should they wish so.
Will there be a test system where users can test their eForms applications/ development?
An instance of the OP applications is currently being deployed as a “Preview” environment. The applications started to be made progressively available during Q2 2022.
Will you continue to send email notifications, e.g. to the Contracting Authorities, to remind them to publish a contract award notice?
We have foreseen quite an extensive notification system, which will contain several methods for communication with eNotices2 users, including email communications. We should also provide the means to retrieve the information about the contracting authority sending notice through an eSender via the Notice Author concept, when it is needed. We have not yet decided if the reminder to publish a Contract Award Notice will be sent through an email notification, though it will likely be the case at some point.
Will eNotices2 send email notification for notices submitted by Web Services about publications or non-publication?
This is currently under discussion. There is going to be an extensive notification system within eNotices2 and once this is in place, we may consider continuing with email notifications. For notices sent through Web Services and which have failed validation, an email notification will be sent to the Notice Author detailing all the rules that failed.
For the initial stages, there will be no email notifications for eSenders that submit notices via the API. eSenders will need to rely on their queries.
Visualisation and display of eForms notices
Will a standard visual display be applied for eForms? Is it possible for the Publications Office to share (PDF) templates of eForms?
The eForms will be displayed as standard forms, both within the application that will be used to create and submit them (eNotices2) and for their display on the TED website. The visual display will focus on user-friendliness. As part of the ongoing development of eForms, the provisional samples of the 40 mandatory notices in PDF format was published in July 2021 at: https://simap.ted.europa.eu/documents/10184/320101/eForms+notice+PDF+samples+2021-07-22/c6785da3-8907-4071-9980-bb670b8ae9b8
An updated HTML file was published in May 2022. It provides sample data to make it easier to see the TED Viewer structure, understand how the elements fit together and allows to switch between different notice types. The biggest structural change compared to samples from July 2021 is the decision to group almost all the organisation information in one section. The current version is not yet final but it is quite close to what the eForms TED Viewer will produce.
The view-templates available in the SDK contain the technical definition of how an HTML/ PDF will be generated by TED Viewer 2022.
The eForms notice viewer is available on GitHub as a sample application that can visualise an eForms notice in HTML; it is not a production-ready application.
How will eForms notices be published and displayed on the TED website?
For information about the future changes planned for the TED website, please refer to the relevant presentation in the 2021 eSenders Seminar: https://op.europa.eu/documents/8651547/0/eForms-in-TED-and-the-future-TED-2-0-2021-eSenders-seminar.pptx/317c4f15-9a18-58c3-a38e-be283206b977?t=1636106124942.
What preview solution do you provide with eForms TED API?
TED Viewer 2022 is going to be available through an API in order to visualise the notice in HTML and PDF. It will be possible to preview a notice before sending it for publication.
What will be the retention period for the display of the eForms notices published on TED?
The retention period for displaying all notices (including eForms notices) on the TED website is 10 years (data available as of 1/1/2014).
Will the Publications Office be providing eForms-rendering stylesheets?
OP does not intend to provide XSL stylesheets. The view-templates in the SDK define how eForms will be displayed by TED Viewer 2022, using the eForms expression language (EFX).
Users will also be able to render eForms notices in HTML or PDF using the service provided by TED Viewer 2022, which is going to be available through an API.
Will the Publications Office be providing XML notice samples for every PDF notice sample?
The PDFs are only examples of how notices could be displayed. There are also examples of XML notices in the SDK at https://github.com/OP-TED/eForms-SDK/tree/main/examples/notices.
They are not the same notices as the ones used in the PDF views but they are aligned with the other SDK elements (like the schemas and rules).
What is the meaning of section 10.CHANGE in eForms 40 - Contract Modification Notice?
eForm 40 is the equivalent of current TED schema form 20; it is used to publicise changes in ongoing contracts. As with all other forms, it may be corrected, in which case, a form 40 will contain section 10 (change) and will be published as a Change notice for a Contract Modification Notice.
Technical documentation and Software Development Kit
Where can I find the latest technical documentation published on eForms (schemas, business or validation rules and other relevant information)?
Technical information on eForms, relevant to developers and experts, can be found in the eForms Software Development Kit (SDK) on GitHub at https://github.com/OP-TED/eForms-SDK
What is the purpose and governance of the SDK?
Provisional releases of the eForms Schema and eForms Documentation were provided in 2019 and 2020 through separate announcements on SIMAP. In order to assist eSenders and eForms developers, new releases of the eForms artefacts are now bundled together in the form of a Software Development Kit (SDK). This includes the eForms schema, Schematron validation rules, eForms documentation, sample XML documents and other elements. All artefacts are versioned together with the version number of the eForms SDK.
The eForms documentation will indicate the version of the eForms SDK that modified it. Likewise, the sample XML files will indicate the version of the eForms SDK used when they were created or last modified.
For more information on SDK versioning: https://docs.ted.europa.eu/eforms/latest/versioning
The purpose of the SDK is to assist eForms developers in creating applications that generate eForms notices in order to send them to eNotices2. Our eForms Developer Guide aims to address some of the most common issues faced by developers of eForms Applications.
The components of the SDK are intended to be directly consumed by these applications. Multiple versions of the SDK will be maintained and remain available as long as they are supported by the legislation or business rules, allowing for more flexibility on the timing of upgrades on the eSenders’ applications. Updating applications to use new versions of the SDK should require minimal effort if the applications are built to integrate the SDK components.
More information about the SDK was presented at the 2021 eSenders seminar.
The May 2022 eForms Technical Workshop focused on building metadata-driven applications using the SDK, followed by the second eForms Technical Workshop of September 2022 and the TED eSenders annual seminar of 2022.
For more information and examples of metadata driven applications: https://docs.ted.europa.eu/eforms/latest/metadata-driven-applications.html
Is there a roadmap (release plan) for future eForms SDK releases or a set release date for SDK versions?
The eForms SDK is a complicated development and information is made available as fast as possible. An initial version of the SDK roadmap is available at eForms SDK roadmap and will be updated progressively. The page was created with a view to outlining the changes and additions to the eForms SDK planned in the upcoming releases.
The idea of the SDK is not to be bound by specific release dates. Please note that version 1.0.0 refers to the technical compatibility of the SDK as described in eForms SDK Versioning.
The metadata of the SDK, in particular the schema and the rules, have still changed after version 1.0.0 and until shortly before November 2022.
This is because the European Commission has published an amendment to the 2019 eForms implementing regulations which changed and added several business terms: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2303
The BTs included in this version of the annex are the same ones that we have included in the SDK and that the amendment has; please note that there are some limited changes since the public consultation involving BT names and descriptions.
Since the codelists are bound to SDK versions, is there a risk that an SDK version/ lifetime can be short-lived?
Versions of the SDK might be short-lived due to various reasons; however, multiple versions of the SDK can be used at the same time provided they are still acceptable. OP will aim to avoid breaking changes but stopping support for an SDK will often come for legal reasons and will be given a six-month transition time. Technically, there would be no reason to deprecate a version of the SDK. Significant business changes, such as making mandatory some fields that were previously optional, might force us to deprecate an active version of the SDK after a pre-announced transition period.
Having a metadata-driven approach to this should enable users to make the technical transition with little to no effort. In theory, a metadata-driven approach could render any changes directly consumable by an application without human intervention and the goal of the SDK is to minimise the effort. For more information on SDK versioning and backwards compatibility: https://docs.ted.europa.eu/eforms/latest/versioning. See also related GitHub discussion from a technical perspective: https://github.com/OP-TED/eForms-SDK/discussions/222.
Is it possible to predict and announce how many SDK releases there will be or how often these will happen before October 2023?
We cannot predict with certainty how many SDK versions we will have in 2023. Our current release pace is quite fast while we correct and improve the SDK content but, very roughly, we estimate that we might have 5 or 6 minor versions until the summer of 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.
There will be as many patch releases as needed for each SDK version, i.e. releases that don’t affect the validity of submitted XMLs, like essential changes to translations or the view templates. As multiple versions of the SDK can be used at the same time given that they are still acceptable, eSenders would not need to upgrade to the latest SDK version; we would, however, encourage you to try to plan regular updates as this will gradually make the adjustment effort necessary less and less significant.
With which SDK version can an eSender go live by October 2023?
We will not stop support of an SDK version before a 6-month transition period, during which eSenders will have time to update their applications and test in Preview environment. Supporting several SDK versions in parallel allows for more flexibility as to when eSenders choose to upgrade their applications.
We would, however, suggest that keeping up to date with later SDK versions (and changes these will include) may help eSenders adjust more easily and minimise the effort required.
Other standardisation efforts provide information on how the business terms are mapped to the syntax. Currently OP provides a fields.json which is a highly specialised tool used by OP. The fields.json contain max length constraints on fields, albeit no such limitation is found in the documentation.
Fields.json does not attempt to follow or set a standard. It is a custom representation of field metadata that was chosen as the most suitable way for eForms systems to consume the information. OP is using it for its own applications (like eNotices2), and we aim to have a stable structure that can also be useful to external parties. The eForms implementing regulation does not define any maximum length constraints but we consider they are needed and have encoded them for each relevant field. Procurement notices are not intended to replace all the documents of a procurement procedure so there should be no need to publish very long texts.
The XML schemas, its documentation and especially the mapping from business terms to fields in the schemas is essential to implementers in regard to technical and legal correctness. This includes the mapping of business terms to the XML schemas (XPATHs).
The XML schemas and all relevant documentation are available on the eForms SDK; the IDs for Fields are always based on the "parent" BT. We have a specific definition for Fields. They most often map to single XML elements, but not always. The mapping of Fields to XML elements is contained in the fields.json file.
If we were to use the SDK, would there be the need to customise for the national adoptions?
Yes, customisations and tailoring would need to be applied locally, on the user’s application.
Will OP be providing a mapping of current TED XML schema to eForms?
To support the transition between the two data formats, OP is mapping the fields of the current TED XML schema to the eForms schema.
This mapping in Excel builds on the 2021 mapping of business terms by the European Commission and completes it with the technical mapping of TED XML to the fields of the eForms schema at XPath level.
Not all standard forms (SF) are included, and there is not an exact business correspondence between each SF and each eForm notice.
This Excel file is provided "as is" and may serve as a guide. It will not be further updated but any feedback is welcome via firstname.lastname@example.org
OP is sharing the XSLT files with the actual implementation of these mappings, which will be progressively enriched: https://github.com/OP-TED/ted-xml-data-converter.
OP is also intending to develop an application to convert from TED XML to eForms XML using these XSLT files and which will be provided as a public API service.
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. But it should allow users and systems to carry over as much as possible of existing notices into the new format, for example, when continuing a procedure that overlaps the switch between the two schemas.
Please note that the eForms SDK is updated regularly. Updates are announced on SIMAP and on the TED eSenders Workspace.
You can also use the "watch" repository feature of Github to receive notifications for new releases.
APIs and Web Services
Will there be a TED qualification environment available for eForms? When will there be a way to test the submission of eForms notices?
Unlike the current standard forms in eSentool, there will be no qualification procedure for eForms and any user with an API key and an eNotices2 account will be able to submit notices via the API. Similarly, Qualification and Simulation endpoints will cease to exist. The environments available will be instead Production and Preview.
The Preview environment will be available indefinitely so that users can test validation of notices against new versions of the SDK. The latter will first be implemented in Preview environment during a pre-announced transition period before going into Production. An SDK Management Service will be accessible as an API so that users can check all active versions of the SDK at any given time.
A Central Validation Service (CVS) will be remotely available so that you can check the validity of eForms notices. As our developments have no awareness of national tailoring, the application of the eForms regulation in national legislation will not be taken into account for the CVS.
Any announcements on the availability of the CVS will be made via SIMAP at
Will a Sandbox be provided for testing the Web Services?
A “Preview” environment is gradually being made available. We plan to offer the possibility for users to go through all the steps from submission to publication, but this is done incrementally, gradually adding steps to the environment.
Will there be any limitations for using TED API Validation Service?
The Central Validation Service (CVS) will be available to users the same way as for eNotices2. There should be no limitations in using the CVS through the TED API. However, there will be some throttling to prevent that possible abuse of the system would degrade the experience for users. Therefore, there will be some limits to make sure the system works well for everyone, but the exact limitations will be communicated at a later stage.
Will there be change in authentication method for the new eForms and if so, what authentication method will be used for the API?
For the new systems, we will be using API Keys, which is - as a mechanism - very close to what we have in eSentool. Instead, however, of basic authentication with a username and password, an API key will be sent to the user in another HTTP Header; this API key will verify the user’s identity and through it, the user will be able to connect to various services, i.e. submitting/ validating/ visualising notices. Any user can be a Web Services user as long as they have an API key.
Where can I get an API key?
API keys can be generated from the TED Developer Portal. Only one API key is allowed/ active at a time per EU Login.
API keys are only valid for the environment they were created in. For instance, to send notices to Production via the eNotices2 API, you would need to generate your key in the Developer Portal in Production.
For a key to work in a Preview environment, e.g. CVS API in Preview, it needs to be generated in the Developer Portal in Preview.
To use eNotices2 API (either in Preview or in Production), an eSender should log in at least once in the corresponding environment of the User Interface to pair their API key with their eNotices2 account.
A guide on how to test in "Preview" was presented in Day 1 of the second eForms Technical Workshop: "TED Developer Portal and using eForms APIs".
What is the purpose of the Developer Profile?
The Developer Profile was first presented to eSenders and their developers in the 2nd eForms Technical Workshop of September 2022 (TED Developer Portal and using eForms APIs).
The TED Developer Portal is envisioned to be a central hub for TED developer services. OP will be gradually adding features for developer groups that are interested in TED developer products or data services. One of the first features will be the Developer Profile (to be deployed in Preview and Production environment in Q2 2023).
The Developer Profile can be used by eSenders to set up/ manage their eSender profile as part of the sign-up process in the TED Developer Portal and before they are able to generate an (or a new) API Key. For eSenders, we would recommend using a functional/ shared email address instead of a personal email address to set up your eSender profile in the Developer Portal in the Production environment. The identifier of your eSender profile should also be used as the identifier of your eSender organisation in the XML of the eForms notices you submit. We recommend that you only have one eSender account in Production, while your developers and testers can have the accounts they need in the Preview environment.
Making the profile public is entirely optional. The information eSenders provide in “Public profile” will be used (with their consent) to automatically generate a list of eSenders using eForms, which is the next step in the development. These lists will eventually replace the page SIMAP-List of TED eSenders, which will not be maintained with eForms.
The latest developments and the next steps will be presented in the 4th eForms Technical Workshop of 28-29 March.
Will the URL to which we send the messages remain the same?
The URL used for eForms notices will be different to the one used for the current notices in eSentool.
For the URLs and TED API documentation, please read the docs: https://docs.ted.europa.eu/api/index.html
Will there be some API available, which users can use to transform/ convert TED XML to eForms?
A converter is being developed, which will take a TED XML and convert it to a partial eForms XML. “Partial” because eForms notices contain more information than current TED notices. We will expose the converter to users through an API as a call service; however, a full conversion will not be possible. For notice types that the converter does not cover, the information from the previous TED schema form will need to be entered again in the eForm for procedures that span the transition period. If a field in a TED XML notice doesn’t exist in eForms, it’s only possible to use the free text of Additional Information field (BT-300).
A new release of the TED XML to eForms Converter (TEDXDC) has been published on GitHub. This release of the tool can convert all TED Contract Notice forms and all TED Contract Award Notice forms. It also caters for the multilingual versions of text elements and added options to control the reporting of messages to the user.
Can I send an incomplete notice via Web Service-API and continue via eNotices2 UI?
No, the notices must be complete before they are submitted via API.
What are the notice statuses that eSenders will be able to query via the API?
eSenders will be be able to query their notices with the below statuses:
DRAFT, SUBMITTED, STOPPED, PUBLISHED, DELETED, NOT_PUBLISHED, ARCHIVED, VALIDATION_FAILED, PUBLISHING.
Notice status VALIDATION_FAILED is only relevant to eSenders (users of eNotices2 API) and refers to notices that failed validation – i.e. that triggered CVS errors – upon submission. Such notices will never reach status “submitted” and will instead appear in the user interface and when querying the API with status “validation failed”.
HTTP response is in this case “201 created” with "validationReportUrl" and "success"=false. The validation report is stored in eNotices2 and can be retrieved with the given URL (with proper authentication) or exported directly from the User Interface of eNotices2. The same notice businessID (noticeID + versionID) cannot be reused.
Via the concept of Notice Author, an email notification will be sent to the Contracting Authority only, detailing what failed validation.
An overview of eForms notice statuses was presented during the 3rd eForms Technical Workshop - The lifecycle of eForms notices
When can I stop publication of a notice via the API?
Only when the notice is in status “SUBMITTED”. Once the status of the notice has changed to "PUBLISHING" or "PUBLISHED", it is no longer allowed to perform this action. When a submitted notice has entered 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), its status will change to “PUBLISHING” and subsequently to “PUBLISHED” (once published in TED). In this case it will only be possible to submit a change notice for publication in the OJ S cancelling the initial notice, i.e. by creating a change notice with ReasonCode “cancel” from change-corrig-justification.gc. Both the original notice and its change notice will be published in the OJ S.
Schema and field definitions
What is a Group of Lots and is it optional?
Grouping of Lots is optional and simply a question of ease of use, as some buyers might find it easier to group lots together for a particular reason.
At the level of Competition, you may have some lots that you feel can be grouped together under a specific set of tendering terms and allow companies to submit their offers for the group. This is also related to the maximum awarded lots and the quantity of lots the buyer wishes to award to the same company. At the level of the Result, the Group of Lots is just a concept, meaning that the award should only be per lot, even if the lots form part of a group of lots. eForms regulation states that each lot has its own result; for each lot there will be one contract signed and one winner among the tenderers and all the non-winning tenders should also be mentioned. It is still going to be possible to award all the lots in the same notice, but only one by one.
Should a single lot in a notice have the ID LOT-0000 or LOT-0001? What makes a lot "technical"?
In eForms, at least one Lot is mandatory. A single Lot is a "technical" lot with LOT-0000 as the only accepted identifier. This means that a LOT-0001 would only exist if there were also a LOT-0002. Numerical sequence in numbering does not have to be observed and there can be gaps in the numbering. If the notice contains multiple lots, it is not allowed to have a technical lot. If you need to refer to a lot in the next step in the procedure, you would need to refer to the Internal Identifier, BT-22, which will be implemented as mandatory by OP.
Similarly, a Prior Information Notice or Periodic Indicative Notice used only for information without multiple parts should have a “technical” part with ID "PAR-0000". The Internal Identifier BT-22 also applies here.
See Table 1. Numbering schemes for Parts, Lots and Group of Lots in the documentation.
Which BT is planned to identify if the procurement is divided into lots or not?
None. This will be implied from the number of ProcurementProjectLot elements. If there is only one ProcurementProjectLot element, then the procurement is not divided into lots.
We find a lot of fields with OPT and OPP. However, there are no field definitions for these kinds of terms. Will there be a new section in the documentation regarding OPTs and OPPs? Will there be a mapping between OPT/OPP and BT/BG, respectively do we need to map these?
Basing the development of the eForms schema on the UBL schema, as well as conferring many advantages, has also imposed some constraints. These constraints have required the creation of a number of fields which were not anticipated in the eForms regulations; they do not have a true Business justification. They have been assigned different abbreviations to distinguish them from the BT terms defined in the eForms regulations, and to avoid potential conflicts if new Business Terms were created by DG GROW in the future.
Two abbreviations for these fields have been introduced: "OPP" and "OPT". "OP" is the abbreviation for "l’Office des publications". "P" stands for Production; these fields are required for the production processes, particularly for the non-standard forms (not defined in the eForms regulations) that also use the eForms schema. "T" stands for Technical, these are required by our use of UBL as the base schema for eForms.
Some of the OPT and OPP fields are defined in the fields.json. More of these will be added in a future release of the SDK. Descriptions and usage information for all of the introduced OPT and OPP fields will be added to the documentation, each in the relevant section. Where they are intended to be used instead of other Business Terms, this will be stated. They may be listed in a table in a new section. A mapping between OPT/OPP and BT/BG is not currently foreseen.
What does ORG-XXXX or TPO-XXXX mean? How is this value defined? What does the value for field "OPT 300" mean and how do we find these values?
Each organisation used in a Notice is defined in an <efac:Organization> element, see https://docs.ted.europa.eu/eforms/latest/schema/parties.html#organizationSection. It has a single identifier, which must follow the pattern "ORG-XXXX", where "XXXX" is four digits. The first organisation would have identifier "ORG-0001", the second one "ORG-0002", etc, but numerical sequence in numbering does not have to be observed and there can be gaps in the numbering.
An organisation might have several contact details, each for one or more different functions. Each contact is defined in a TouchPoint, which has an identifier following the pattern "TPO-XXXX". An example XML for a Buyer is shown in: https://docs.ted.europa.eu/eforms/latest/schema/parties.html#buyerSection.
Within the rest of the notice, any function performed by an organisation can then link to that organisation, or to one of its touchpoints, by using the relevant identifier as a reference. Examples of this can be found in: https://docs.ted.europa.eu/eforms/latest/schema/parties.html#_legislation_information_provider and the following section: https://docs.ted.europa.eu/eforms/latest/schema/parties.html#_other_rolessubroles
These references use fields OPT-300 and OPT-301. These and other similar references are listed in: https://docs.ted.europa.eu/eforms/latest/schema/identifiers.html
What are the Roles/ Subroles with which a TouchPoint can be associated?
Roles/subroles it may be associated with are in table 2 in the Documentation section IDs & References.
A Touchpoint could be referred to for the following roles/subroles:
Business Term Name of the Business Term
Additional Info Provider Technical Identifier Reference
Document Provider Technical Identifier Reference
Employment Legislation Organization Technical Identifier Reference
Environmental Legislation Organization Technical Identifier Reference
Tax Legislation Information Provider Technical Identifier Reference
Mediator Technical Identifier Reference
Review Information Providing Organization Technical Identifier Reference
Review Organization Technical Identifier Reference
Tender Evaluator Technical Identifier Reference
Tender Recipient Technical Identifier Reference
How should we fill in BT-3201 Tender Identifier?
For TenderID, as for most identifiers, a dedicated scheme similar to that defined for other identifiers, has been specified. Information is available in the documentation in the eForms SDK.
What happens when CA_ACTIVITY_OTHER is given in current F02?
The current TED XML element CA_ACTIVITY_OTHER allows free-text content. This often leads to inconsistencies in reporting the main activity of the contracting authority.
In eForms, this possibility has been removed and only one value from the list of values in the "main-activity" code list is allowed.
How can I deal with multiple NUTS codes in OBJECT_DESCR?
In the current TED XML, the location(s) of each Lot is indicated with only one MAIN_SITE element, but multiple NUTS elements.
In eForms, there is the possibility to have more information about each location: a full address, a description and a NUTS code. These are held in the cac:RealizedLocation element. This element is repeatable within each Lot.
How is joint procurement handled in eForms?
Joint procurement / consortia are handled by use of the Tendering Party (https://docs.ted.europa.eu/eforms/latest/schema/competition-results.html#tenderingPartySection). A Tendering Party may contain one or more tenderers.
In the .xsd files elements "cbc:ActivityTypeCode" and "cbc:ActivityType" are found for BT-10 and BT-610, but in samples it’s used rather as only a value from the codelist. Is ActivityType ever implemented or is this element redundant and all activities are covered by the codelist?
The element cbc:ActivityType is not implemented for eForms. The requirements for BT-10 and BT-610 are only for code values, hence only the element cbc:ActivityTypeCode is used. The element cbc:ActivityType is redundant, and all activities are covered by the codelist.
What is the meaning of “multilingual text” in BT-500?
"Multilingual Text" means that the text may be language-specific and repeated. In some cases, such as textual descriptions, this means that the text may be repeated, once for each official language used in the notice. In other cases, as with some uses of BT-500, the text may be the name of an entity that may exist in multiple languages.
BT-500 (Organisation Name) is used in four contexts:
BT-500-Organisation-Company - A company may have different names in different languages.
BT-500-Organisation-TouchPoint - A contact unit within a company may have different names in different languages.
BT-500-UBO - This is the personal Name of the Ultimate Business Owner, and so cannot be expressed in multiple languages.
BT-500-Business - Only allowed for X01 and X02 notice type forms. As these are Business Registration Information Notice forms, only one Business Name is allowed.
Is BT-78 (Security Clearance Deadline) intended for submitting some documents after the tender deadline? Validation of this BT against other deadlines is not described in the documentation.
For BT-78, the description field BT-732 can be used to define how the Security Clearance Deadline related to other dates in the procedure. As the fields are optional, there are no plans to have any business rules for them and can be used as needed.
Is BT-195 really an identifier?
BT-195 is named as "Unpublished Identifier" in the Annex spreadsheet. It is an identifier in a general sense, in that it is intended to identify the BT that is "unpublished". But in the UBL schema, the XML elements for the BTs that need to be unpublished do not have identifier elements associated with them. Instead, we have created a codelist which maps codes to the associated BTs. This codelist is included in the SDK identified by the listName attribute "non-publication-identifier", filename non-publication-identifier.gc.
How does BG-8 Not Immediately Published work in practice?
The unpublished fields are the eForms equivalent to the confidential fields of today. There are several fields involved, which can be "unpublished", some related to all Directives and others only for Directive 25. The fields themselves are handled by the use of a codelist and for each of them the fields of BG-8 are requested in the XML.
For example, BT-118 Notice Framework Value, can be unpublished. If that is the case, the user will be able to identify it as such and then will have to insert BT-197 (why it is unpublished), and BT-198 (when this field will be made public). A user may also want to add BT-196 (an optional description).
On TED, the unpublished fields will still be present, but their content will be replaced with masking values, e.g. text fields will contain "unpublished" and numbers will be set to -1.
With BT-198 (Unpublished Accessibility Date) it is possible to give the exact date on which the information will be made available. How will this actually work and how will the publication work in practice when the deadline has passed?
You should include the information not meant for immediate publication in the form. As each expiry date is reached, OP will re-publish the form with the relevant information included. Not Immediately Published Data is masked in notices before the Unpublished Accessibility Date (BT-198), and then the notice is published.
Whenever an Unpublished Accessibility Date (BT-198) is reached, the notice is republished with the relevant Not Immediately Published Data included. The notice has the same Notice ID, but a new Publication ID.
The BT-198 should be within the next 10 years. If the date is not filled, the unpublished fields will never be published (and the notice is therefore only published once).
How will BT-702 Notice Official Language work in practice?
Any Contracting Authority may publish an eForms Notice in one or more of the EU Official languages. The chosen languages are considered of equal status. EU Institutions publishing eForms Notices are obliged to publish them in all 24 EU Official languages.
If more than one language is chosen, all text content of the Notice is capable of being expressed in different languages must be expressed in all chosen languages. Due to the technical requirements of UBL, only one language may be specified using the element <cbc:NoticeLanguageCode>; the others must use the element <cbc:ID> within the element <cac:AdditionalNoticeLanguage>. There is no implication or meaning to the choice of which language is specified using <cbc:NoticeLanguageCode>.
BT-125 and more specifically BT-1251 refer to the Previous Planning Part Identifier. What is a “part” of a notice. How can one define a “part” without using lots?
The "Previous Planning" refers to Notices of type "Planning". The "Part Identifier" refers to a Part that is included in such Planning Notices. The Part may later become a Lot or a self-standing procedure. Field BT-125 Previous Planning Identifier is only to be used to identify previous planning notices. Within a framework agreement, the field BT-1252 "Direct Award Justification Previous Procedure Identifier" should contain the identifier of the procedure under which the framework agreement was concluded (BT-04).
Why is BT-1371 Previous Planning Lot Identifier not documented?
Most of the elements “XYZ Lot Identifier” Business Terms that exist in the extended annex spreadsheet do not appear in this annex as they are just a way to link a BG to a Lot/Part. When looking at the regulation extended annex (file “CELEX_32019R1780_EN_ANNEX_TABLE2”) you will observe for multiple Business Groups the presence of elements of the kind “XYZ Lot Identifier” just after the row for the Business Group; in most cases this is a way to associate a Business Group (and its content) to one or more specific lots. In the XML, this information is pointless by design as the information of the Business Group may be found inside the element representing the lot.
Some of the BTs for identifiers are not needed due to the way that the schema has been developed. There is a list of these in the documentation, under the section "Pointless due to design".
BT-738 allows to choose a preferred notice publication date. How will this work exactly?
The BT-738 Notice Publication Date Preferred is available to help the buyer to coordinate publication dates at national and European levels. The submitted notice will be stored in the OP internal system (TED Monitor 2022). When the preferred publication date is reached, the notice will be published on TED. The preferred publication date can be set for up to 3 months into the future. With SDK 1.6, Notice Preferred Publication Date (BT-738-notice) shall be between 2 and 60 days after the Notice Dispatch Date (BT-05-notice). Previous SDK versions will still allow the extra month.
What is the meaning of BT-634 “Procurement Relaunch”, having in mind that it is applicable both to Competition and Results notices?
BT-634 would never be used in the initial Competition Notice. Its only function in a Contract Notice would be to allow the Contracting Authority (should they really wish so) to go back to the CN and change it to mark that the procedure/ lot would be relaunched.
Should "BT-746 The winner is listed on a regulated market" be added for each winning organisations in case of several winners as a Tendering party?
As an indicator, it should be added to each and every single tenderer in the notice.
If several suppliers are joint as a winning tendering party, shall the BT-165 Winner Size be reported for ALL different supplier/tenderer organisations?
Every organisation that exists in the notice and participated to a tender submission shall have that information specified (at the level of the organisation) where the BT is mandatory. Where the BT is not mandatory but allowed, the choice should, however, be consistent.
Which fields need to be present in a contract award notice if the procurement contains several lots and some are in status "not yet awarded"?
For the LotResult concerning a “not yet awarded” lot, BT-142 and BT-13713 are the two mandatory fields.
When is BT-759 "Received Submissions Count" to be provided? Do we correctly understand that all code values should be sent from BT-760 "Received Submissions Type" and that BT-759 should indicate the numerical value of relevant code even if the value is “0”?
As seen in the fields.json file, BT-759 (for certain notice subtypes) is forbidden when procedure equals “open-nw”. Therefore, BT-759 is to be provided (mandatory) when procedure is “selec-w”, “close-nw” for the defined notice subtypes. All codes from “Received submission type” are expected in BT-760, even when null.
Are BT-715 and BT-716 made redundant through OPT-155 and OPT-156? In this case will there be a codelist available for the three applicable vehicle types?
Yes, BT-715 and -716 have been made redundant by OPT-155 and OPT-156.
Only three fields have the new property inChangeNotice. Will it be added to all other fields? Can a field without the property never or always be changed?
The default value for the "canAdd", "canRemove" and "canModify" sub-properties of the "inChangeNotice" property will be "true", meaning that by default a field can be added, removed or its value changed in a Change Notice. The "inChangeNotice" property will only be added to fields where a restriction is required. A field without this property can always be changed.
The property was added to three fields to allow us to verify that the property worked correctly, and that schematron rules can successfully be generated. We will be adding it to other fields in the near future.
Business and validation rules
What are referred to as business rules in the context of eForms?
Business Rules are business-driven rules used to ensure a certain quality of the reported information. They define or constrain the existence of business information in a procurement notice (e.g. whether some information is mandatory, the possible values of a field, etc.). They have their origin in the Directives and the eForms Regulation or are based on common sense (e.g. an end date is later than a start date) as well as on the legal bases, the public procurement Directives and the eForms Regulation:
When will the business rules and field validation rules be made available?
The current Schematron validation rules together with some examples of valid and invalid XML files are published on GitHub as part of the eForms SDK.
We will keep updating these artefacts regularly as they evolve.
What is the role and status of the Extended Annex Excel, and differences with the Implementing Regulation?
The Extended Annex to the Regulation was made available (https://ec.europa.eu/docsroom/documents/43488) to provide additional information and clarifications.
As stated in the Legend tab of the Excel sheet, the Extended Annex spreadsheet is identical to Table 2 of Annex of the "Implementing Regulation establishing standard forms for the publication of notices in the field of public procurement", except for three differences:
The spreadsheet differentiates "M", "CM" and "EM" fields (see below). The Annex of the Implementing Regulation does not - it denotes all as "M".
The spreadsheet explicitly lists lot identifiers (e.g. Purpose Lot Identifier BT-137), while the Annex of the Implementing Regulation does not.
In both cases, these additional details are useful to know for technical implementation, but are an excessive technical detail to be included in the act itself.
The extended Annex includes additional notices that will be made available to national authorities for voluntary use after October 2023. These are marked as "E1" - "E5" in the notice number field and their use is explained in chapter 3 of the eForms Policy Implementation Handbook. Extended notices E1 and E5 contain fields not used in other notices. These cases are marked in column AZ of the ‘Annex’ sheet.
What are CM and EM fields?
EM is mandatory if the related information exists, i.e. if the Contracting Authority has the information, they should fill it in. CM is Conditional Mandatory, i.e. mandatory if certain conditions are met.
References to CM and EM are not part of the annex to the Regulation; they are included in the so called “Extended Annex” Excel sheet that was provided for information and clarification purposes.
Are the rules for CM documented in detail? If so, where can one read about these conditions?
The conditions are visible in the Schematron rules as well as in the eForms expression language, efx-grammar.
Are the error messages returned by CVS translated?
Translations of the messages that can be returned by CVS when rules are not respected are still work in progress and are progressively added in the translations file on the SDK on GitHub. When calling CVS API, the “text” element in the validation report will be returned in the language you passed as a parameter to your request.
Why do the validation rules differ in some cases between the Extended Annex to the Regulation and fields.json? For example, CELEX states that BT-52 (Successive Reduction) for eForm 16 is mandatory, but fields.json has no mandatory rule for this field.
The validation rules in the fields.json differ from those in the CELEX table because the business logic requires the aggregation of multiple conditions, and sometimes the introduction of interdependencies, not all of which are directly shown/visible in the Regulation Annex. Not all of the required business rules have been implemented in the SDK, and so the fields.json is not yet complete.
BT-52 belongs to a Business Group (BG-709 Second Stage) which is CM (Conditionally Mandatory) and may not always exist; in fact, BG-709 may only exist when the procedure is a "competitive dialogue", "innovation partnership" or "negotiation with a prior CFC".
BT-541 is not marked as mandatory in CELEX and fields.json, but it is mandatory according to schema. Which one should be considered correct?
BT-541 is held in the element efbc:ParameterNumeric which is mandatory within its parent element efac:AwardCriterionParameter. But the parent element efac:AwardCriterionParameter is optional, and so in the context of a LOT, BT-541 is optional. The element efac:AwardCriterionParameter is designed to hold a single criterion, with a number value (BT-541) and a dimension (BT-5421, BT-5422 or BT-5423).
What are Schematron files for eForms? Can you provide samples of them?
The eForms schema applies basic structural rules to the XML notices. Schematron files are used to apply further validation rules to the XML notices, ensuring that for each notice type, mandatory fields are present and correct field values are used. Schematron files are available as part of the eForms SDK in the GitHub repository.
As the creation of Schematron files is a work in progress and they will not be ready for official publication for some time, the versions in the SDK only contain a preview. They are provided as-is, without any commitments from the Publications Office for their completeness or stability and without any documentation or support at this stage. The SDK in the repository will be updated periodically.
Will OP be providing an Excel sheet with the validation rules of individual fields for eForms?
OP does not intend to use an Excel spreadsheet to document the validation rules for fields within eForms. Due to the increased number of fields in eForms compared to the existing TED XML, there will be a very large number of validation rules, and an Excel spreadsheet listing the validation rules would be difficult to maintain and use. Instead, we are providing the validation rules as a set of Schematron files, included in the eForms SDK. These rules are still being developed, and more rules will be added in future releases of the SDK.
Are the Schematron validation rules documented in a more” human readable” form? Can you provide a data model for eForms domain - something like an "entity -relationship diagram"?
Some of these rules are in the documentation, e.g. which field must use which codelist. We currently do not have an exhaustive human-readable documentation or an entity-relationship diagram, but OP is working on human-readable versions of the business rules that can be linked to the technical validation rules. For the time being, all information is communicated through the SDK, but ideas for documenting rules are welcome.
Will we receive translations for the error messages that are foreseen in the Schematron validation files?
We are currently working on creating translations for the error messages in the Schematron validation files. These will be included in a future release of the eForms SDK.
In the future, users will be able to decide in which of the 24 languages they would like to receive the returned validation report in Schematron Validation Report Language (SVRL).
If a field is mandatory but left empty or if a code choice is mandatory but not chosen, will the notice be rejected and not published? Are there no "content" checks beyond that, for example if a monetary value doesn’t make sense?
If mandatory fields are not filled in, it will not be possible to submit the corresponding notice and the notice will, therefore, be rejected. There will be several additional business rules that will check the validity of the content of different fields, i.e., combinations of fields, in a way equivalent to what is done today with the existing forms.
As with the current TED notices, there will be rules that will block (reject) the submission of eForms notices, particularly in cases that violate or contradict the Procurement Directives. All these rules are currently under construction and implemented using Schematron. Only after 14 November 2022, when eForms are introduced, will the Publications Office inform users in advance of any new rules to come.
Notice validation will be automated through the Central Validation System. 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 be subject to a manual check at OP to decide if they should be published or rejected.
From a technical point of view, would an eForms notice be rejected if the names of some business terms and descriptions are changed at the national level?
The eForms notices submitted for publication on TED should conform to the eForms schema, XPaths and field IDs, which are the same for all Member States. This means that any notice submitted that doesn’t conform to this schema will be rejected by definition.
On the other hand, what is done and published at national level is under the responsibility and control of the National Authorities, which means that a notice published at national level may not look exactly the same on the national site (which follows the national terminology) as on TED (which follows the EU terminology).
What are the technical restrictions in eForms?
There will be some throttling to prevent possible abuse of the system. The new eNotices2 application currently being developed will have a limit of 2000 Lots for the user interface, however, OP may decide to impose lower limits in the future.
The technical limit for the number of LOTs is 9999. This is because the technical identifier of a LOT is "LOT-" followed by four digits. The identifier value "LOT-0000" is reserved as a "technical" lot for Procedures without LOTs.
There are other technical identifiers which impose the same limit of 9999 on numbers of: Parts (PAR-XXXX), Groups of Lots (GLO-XXXX), Organisations (ORG-XXXX), TouchPoints (TPO-XXXX), Contracts (CON-XXXX), Tenders (TEN-XXXX), Tendering Parties (TPA-XXXX), Ultimate Beneficial Owners (UBO-XXXX).
These limits, and other restrictions, can be found in the fields.json file in the SDK. They are defined as regular expression patterns associated with the relevant fields, within "pattern" keys.
Are there any official regular expression patterns that will be used to validate received notices regarding e.g. email addresses, phone numbers, URLs, postal codes etc.?
The regular expression patterns we currently have (used in the Schematron files) are used to validate certain fields. Many of these validate the format of identifiers: Procedure and Notice Identifiers, and the internal identifiers for parts of a notice such as Lots, Tenders, Organisations, etc. There is a pattern for email addresses, and one for telephone and fax numbers. We don’t have one for URLs at present. As the format of postal codes varies by country, and new formats can be created at any time, we have currently no plans to validate these using regular expressions.
We have not published a list of these regular expressions, but they can be found in the fields metadata JSON file by the key "regex".
Are all eForms codelists published on the EU Vocabularies site? Where do we find the most recent and correct version of the codelists, on GitHub or the EU Vocabularies Authority tables and taxonomies?
There are codelists that have no relevance or use outside the context of eForms; these are not published on the EU Vocabularies website but are published as part of the eForms SDK.
The codelists in the "codelists" folder of the SDK in GitHub should be used for developing eForms applications. This is because:
Some codelists are "tailored" codelists, using a subset of values from their "parent" codelists. These will not be published on the EU Vocabularies Authority tables page.
Some codelists are "technical" codelists that are required only because of the use of UBL to implement eForms. The "conditions" codelist for BT-70 is an example. These will not be published on the EU Vocabularies Authority tables page.
Some codelists are made available first in the SDK on GitHub, because the process for publishing them on the EU Vocabularies Authority tables page takes longer due a quarterly publishing schedule.
For more information, see Tailored Codelists in the documentation.
Are the filenames and format of the codelists as intended? We are wondering about the suffix ‘.gc’ and whether them containing all languages renders the translations unnecessary.
The codelist files use the OASIS standard Code List Representation (genericode) format (see https://docs.oasis-open.org/codelist/genericode/v1.0/genericode-v1.0.html) which typically uses the "gc" suffix for filenames. They contain translations in the 24 official languages of the EU. The translations files contain translations for all business terms, fields and decorations used in eForms. For convenience to developers, the codelist translations are also included in the translations files.
The values of the @listName attributes correspond to the identifiers of the codelists. The filenames of the codelists match the codelists identifiers for entire (published on EU Vocabularies) or technical codelists. But tailored codelists contain subsets of entire codelists, and their filenames are derived from both the tailored codelist identifier and the parent entire codelist identifier.
For more information, see Tailored Codelists in the documentation.
Will eForms use Supplementary CPV codes?
As supplementary CPV codes are not mentioned in the regulation, they will not be implemented in eForms. Current use of supplementary CPV codes is very low and there no plans to use them in eForms.
However, the eForms schema will allow the addition of other classifications if needed in the future.
BT-755-Lot, BT-772-Lot and BT-777-Lot all reference codelists in the“xpathAbsolute”/”xpathRelative” field, have a “type”-attribute called “text-multilingual” and a “legal-type”-attribute called “TEXT” and therefore a codelist is not attached to these fields. All those codelists are at least referenced in the “xpathAbsolute” field. How are these fields validated against the codelists?
These Business Fields contain multilingual text, so their validation is limited to checking the declared language codes; they are not validated against codelists. However, codelists are referenced in their "xpathAbsolute" field, in an ancestor or sibling node of the Business Field. Validation of the codelist values of these nodes is included in the Schematron validation files in the SDK.
For example, Business Field BT-755-Lot has field "xpathAbsolute" with a value of: "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:ProcurementProject/cac:ProcurementAdditionalType[cbc:ProcurementTypeCode/@listName='accessibility']/cbc :ProcurementType".
The leaf element cbc:ProcurementType is validated for compliance with language rules. The sibling element cbc:ProcurementTypeCode has a @listName attribute set to "accessibility". The Schematron includes a rule which restricts the content of this sibling element to the values in the "accessibility" codelist.
Why are you adding codes to eForms Business Terms and how often this will be done?
Some BTs represent fields whose values come from predefined lists. These values are represented by codes. Such code lists are not specific to eForms and they can be used in other domains. Code lists are dynamic and can be updated. Standard releases and release dates can be found at
The concepts in the EU Vocabularies authority tables and taxonomies that are used in eForms are indicated in the XML and SKOS formats by the ”EFORMS” use context. These formats are available for each vocabulary under the “Downloads” tab.
For example, in the case of contract-nature available at
The XML file does not indicate the “EFORMS” context for the "combined" concept, therefore combined is not used in eForms:
whereas the XML file indicates the use eForms context for the "services" concept, therefore "services" can be used in eForms:
<start.use>2019-09-18</start.use> <use.context>CODIF_DATA</use.context> <use.context>EFORMS</use.context> <use.context>TED</use.context>
Could you provide a clarification about the integration of ESPD into eForms (BG-701 and BG-702)?
The possibility of some level of integration of ESPD requests into eForms notices (avoiding multiple encoding of the same information by reusing it) has been considered and the feasibility of this is still being evaluated. However, it will not be a complete substitution, and ESPD requests will remain necessary.
For more information, please see section 184.108.40.206 of the eForms Policy Implementation Handbook.