eForms FAQ

General overview of eForms

  1. Is there a general presentation of eForms available?

    The policy background of eForms is available on the DG GROW website.

    All previous editions of eForms Technical Workshops/ events can be found online. As the successor to previous eForms technical workshops, the Publications Office is organising a series of workshops in 2024 to exchange information with eSenders and their developers.

  2. What systems are available to eSenders?

    OP has developed and made available since 14 November 2022 a range of applications (TED Apps for eForms) to manage the collection, validation, processing, visualisation and dissemination of eForms notices. The relevant applications are also available through a “Preview” environment to help eSenders 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".

  3. Until when will the eNotices and eSentool applications be available?

    The submission of notices via eSentool and eNotices was closed on 31 January 2024. It will be possible to continue to view your published notices in eNotices until 30 June 2024 and your submitted notices in eSentool until 30 April 2024.

    The new eNotices2 application is an application that performs both functions carried out by the current eNotices and eSentool applications; it has been available since 14 November 2022 and ran in parallel with eNotices and eSentool applications during the transition period.

    Authorised applications can 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 can create notices within eNotices2 using its interactive web forms.

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

  4. With eSentool, several people could access the same front-end eSender account. Are eSenders 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 offers 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.

  5. Is there a fixed publication schedule with eForms?

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

  6. What sources of information are available for eForms?

    The following websites cover the various aspects of eForms:

    For any questions or issues, please contact the TED helpdesk at: ted@publications.europa

    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

  1. 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)”, as well as the "Table of correspondence between TED-XML standard forms and eForms (03/08/2023)", which were both shared on SIMAP: https://simap.ted.europa.eu/web/simap/eforms

  2. What is the lifecycle of an eForms notice?

    An overview of the lifecycle of eForms notices was presented during the 3rd eForms Technical Workshop.

  3. What is planned with eForms regarding the OJ S publication number?

    Starting on 14 November 2023, any notices submitted as eForms will have a publication number of 8 digits, meaning that any application handling eForms must use this format. As of SDK 1.7, eForms notices have up to 8 digits (leading zeros allowed). On TED, eForms notices will therefore have a publication number of up to 8 digits and the legacy TED-XML notices will continue to have a 6-digit publication number.

  4. In order to continue a procedure that was started in the legacy TED XML, how should the previous publication field be filled in given that the Procedure Identifier was not used?

    With eForms, eSenders are required to send eForms notices for any procedures that were started with the TED XML legacy forms. As there was no Procedure Identifier, 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.

    OPP-090 should be used exclusively to point to a TED XML notice if it may not be covered by other fields, i.e.:

    • Change Notice Version Identifier (BT-758),

    • Modification Previous Notice Section Identifier (BT-1501),

    • Previous Planning Identifier (BT-125), or

    • Framework Notice Identifier (OPT-100).

      Any referenced notice must have been already published. Referring to a TED XML notice, the format may only be ‘XXXXXX-YYYY’, i.e. Notice Publication ID.

    To link from an eForms Notice to a published TED XML notice:

    • When modifying one or more Contracts, use a Contract Modification Notice, with BT-1501 Modification Previous Notice Identifier holding the Publication ID of the original Contract Award Notice.

    • When changing any Notice, or the procurement documents associated with a Notice, publish a Change Notice with BT-758 holding the Publication ID of the previous Change notice, or if this is the first Change notice, the original notice.

    • When linking a Lot or Part to one or more Parts of a preceding Prior Information Notice, BT-125 should contain the Publication ID of the PIN Notice.

    • When linking a specific SettledContract to a Framework Contract, OPT-100 should contain the Publication ID of the notice related to the Framework Contract.

    • If none of the above options apply, a preceding notice may be linked to by putting its Publication ID in OPP-090.

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

  6. How can a Result Notice (eForms) be linked to a Competition Notice (TED XML schema)?

    eForms include some BTs with the identifier of the previous notice, regardless of whether the notice used TED schema or is an eForms notice. If the previous notice did 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.

  7. How can a Result Notice (eForms) be linked to a Competition Notice (eForms)?

    Association of an eForms Result notice with its corresponding eForms Competition notice is performed using the Procedure ID. All eForms result notices of a same procedure shall share the same procedure ID. OPP-090 is only expected for references to TED XML notices.

  8. What are the cases when a reference to a specific notice is expected?

    The only cases where a reference to a specific notice is expected are:

    • Identification of the notice object to a Change with Change Notice Version Identifier (BT-758).

    • Identification of the notice containing the contract subject to a Modification with Modification Previous Notice Section Identifier (BT-1501).

    • Identification of the PIN only notice whose Parts contributed to the definition of the Lot with Previous Planning Identifier (BT-125).

    • Identification of the notice that announced the Framework Contract used for the current contract with Framework Notice Identifier (OPT-100).

    • Identification of the previous notice which was a TEDXML and does not therefore contain a Procedure ID using Previous Notice (OPP-090) and for which none of the above may apply.

  9. How do we make a correction to a notice published in TED XML schema, after transitioning to eForms?

    In the same way that it is possible to link TED XML notices to eForms for procedures that started with 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 has created 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.

    There is no longer a specific form for corrections. The Change notice Business Group instead works as a separate section that is 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#

  10. What is a Change notice in eForms?

    A Change notice 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 is 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.

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

  12. 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 (with one exception: a change may not be applied on a Change notice that cancelled its previous notice).

    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.

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

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

  15. What is the correct procedure when creating a Contract Modification Notice with multiple changes, in particular, regarding Modification Previous Notice Section Identifier (BT-1501)? How should we reference previous Contract Modification Notices?

    You can consult the TED Developer Docs. As with Change notices, the Contract Modification notice should contain the consolidated information. While a Contract Modification notice may contain multiple Contract Modification sections, a Contract Modification section can only change one contract at a time and should only contain the information relevant to the modified contract, e.g. other contract(s) and lots not related to the modified contract, should not be included.

    Some additional information is, however, necessary (e.g. Contract Modification Reason) and is grouped in the Contract Modification section.

    To make sure all the historical modifications from previous notices are present, the modifications made to each contract must be initiated from the latest not cancelled notice (i.e. original Result, if no Contract Modification has been made so far, or latest Contract Modification notice for a previously Modified Contract), even if it is a Change. For each contract that is modified for the first time, the link must be made to the original contract award notice or its latest Change.

    The Contract Modification section of the notice is repeatable and multiple contracts may be modified with a single notice, given they were already all in the same previous notice; this is important for situations where a lot has multiple winners, as a modification on the lot will affect all the associated contracts.

    While the Contract Modification section is repeatable, each occurrence should:

    • refer to one and only one contract (BT-1501(s)-Contract),

    • have the main reason for that contract modification expressed as code (BT-200-Contract),

    • have further details about the reason for modification expressed as text (BT-201Contract),

    • provide a high-level textual description of what has been modified (e.g. amount, quantity …) (BT-202-Contract),

    • identify the sections of the notice in which modifications have been made (a list may be found in the documentation) (BT-1501(s)-Contract),

    • identify the notice on which it is based (BT-1501(n)-Contract).

      All data not pertaining to the modified contract(s) must be removed from the contract modification notice i.e. all lots, groups of lots, Tenders, Tendering parties, Contracts, Organizations not related to any modified contract(s).

      You may find Contract Modification examples in the SDK whose names start with “can-modif…”.

      When contracts are modified, the Contract Modification notice should contain all the updates for the modified Contract(s) and no concurrent Contract Modification Notices may be submitted.

  16. What is 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.

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

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

  19. 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 optional forms will be implemented in 2024, as defined in the second amendment to the eForms implementing regulation.

    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.

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

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

  22. What is foreseen in eForms for countries that have no NUTS codes?

    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 codes, then they are 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.

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

  1. What are the update cycles and how is change management (minor/major releases etc.) carried out for eForms?

    The technical standards are 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.

  2. What is the function of eNotices2?

    The development of eNotices2 started in 2020 and the application went in production in November 2022. eNotices2 is also available in "Preview" for testing purposes.

    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. A demo of eNotices2 front-end application was presented during the eForms Technical Workshop of May 2022.

    eNotices2 webinar video recordings are available here:

  3. Does eNotices2 propose all the fields (mandatory and optional)?

    This is the point of eNotices2: it provides all mandatory and optional fields and it has rules to determine which fields are mandatory under certain conditions. There is also be a feature for users to make some of the optional fields mandatory. In the same way, it is also possible 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.

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

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

    eSenders will need to rely on their API queries for notice status.

Visualisation and display of eForms notices

  1. Is a standard visual display applied for eForms? Is it possible for the Publications Office to share (PDF) templates of eForms?

    The eForms are displayed as standard forms, both within the application that is used to create and submit them (eNotices2) and for their display on the TED website. The visual display focuses on user-friendliness. 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.

  2. How are eForms notices published and displayed on the TED website?

    This information was shared during the workshops organised by the Publications Office for the Reusers of TED DATA, available at: https://op.europa.eu/en/web/ted-reusers-workshops/home. All recordings and presentations from previous editions are available on the events site of the TED Data Reusers.

  3. What preview solution do you provide with eForms TED API?

    TED Viewer 2022 is available through an API in order to visualise the notice in HTML and PDF. It is possible to preview a notice before sending it for publication.

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

  5. 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 available through an API.

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

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

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

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

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

    The lifespan of the various SDK versions is documented on the Active SDK versions page, however, eSenders should always consult the information provided by the TED API.

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

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

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

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

  8. 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 ted@publications.europa.eu

    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 has also developed an application to convert from TED XML to eForms XML using these XSLT files and which is 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. You can use the "watch" repository feature of Github to receive notifications for new releases.

APIs and Web Services

  1. Is there a TED qualification environment available for eForms? How can we test the submission of eForms notices?

    There is no qualification procedure for eForms and any user with an API key and an eNotices2 account is able to submit notices via the API. eSenders, however, are required to be familiar with the “Terms of service”.

    The environments available are 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 before going into Production. Users can check the version range of the currently available SDK at any given time via the CVS API and version-range. See Getting active SDK versions through TED API in the documentation and Swagger.

    The Central Validation Service (CVS) is 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.

    SDK active versions and their planned removal/ end of support can be found at: https://docs.ted.europa.eu/home/eforms/active-versions/index.html

  2. Will there be any limitations for using the Central Validation Service?

    The Central Validation Service (CVS) is 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.

  3. What is the authentication method used for eForms and TED API?

    TED Apps for eForms use an API Key that verifies the user’s identity and through it, the user will be able to connect to various services, i.e. to submit/ validate/ visualise/ search (for one’s own) notices. Any user can be a Web Services user as long as they have a valid API key.

  4. 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 TED API of eNotices2 (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. To avoid authentication issues after generating a key, eSenders should perform at least one valid API request to eNotices2 with their key.

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

  5. Does my API key expire?

    Yes, your key has a validity of 2 years from the date it was generated from the TED Developer Portal (you may have different API keys generated in both in Preview and Production environments). 28 days before expiration, the owner of the key will receive an email with a token/ link to prolong their key; the token is valid for 21 days and can prolong the key’s validity period to 1 year from its previous expiration date. A last reminder will be sent 1 week before the key expires.

    For a key to work with eNotices2 API, there needs to be a corresponding eNotices2 account. eSenders need to log in once to pair their key and perform at least one valid API request to eNotices2 API with this key in order to avoid authentication issues.

  6. 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 is the Developer Profile which eSenders must complete in Preview and Production environments.

    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 next steps of the TED Developer Portal were presented in the 4th eForms Technical Workshop of 28 March 2023.

  7. Where can I find the URLs and TED API documentation?

    Please read the TED Developer docs.

  8. Will there be some API available, which users can use to transform/ convert TED XML to eForms?

    OP has developed a converter which takes a TED XML and converts it to a partial eForms XML. “Partial” because eForms notices contain more information than TED XML notices, often in a different format. 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).

    The XSLT code for the TED XML to eForms Converter (TEDXDC) is published on GitHub. The current release of the tool can partially convert all the main forms for the R2.0.9 schema: PIN, CN and CAN. The converter is available as an API in Production and Preview environmnets.

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

  10. What are the notice statuses that eSenders will be able to query via the API?

    eSenders will 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

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

  12. Are there any differences in the notice workflow and statuses between Production and Preview environments?

    Production and Preview environments of eNotices2 are closely aligned. However, notices submitted in Preview are not published in a test environment of TED and "Publishing” and “Published” are only mock statuses that are assigned to submitted notices at around 15.00 and 16:00 respectively when these enter the export. Status “not published” is done upon request in Preview provided that the submitted notice triggers a lawfulness warning. For more details, please see the Preview environment page.

  13. When using TED API of eNotices2, it is required to specify in the metadata "noticeAuthorEmail" and "noticeAuthorLocale". What should an eSender input in the parameters?

    Notice author email (mandatory property “noticeAuthorEmail” in the metadata) must be a valid email address. The email is used to identify the person responsible for the notice, i.e. the Contracting Authority.

    eSenders must make sure to provide a valid email address to identify the buyer when submitting notices for publication to the Production environment, so that the Publications Office can notify them regarding e.g. the rejection/ publication of their notices.

    Mandatory property “noticeAuthorLocale” in the metadata indicates the EU official language in which the Contracting Authority wishes to be notified by the Publications Office. Locale value should conform to ISO 639-1 Language Code List and must be one of the following: bg, cs, da, de, el, en, es, et, fi, fr, ga, hr, hu, it, lt, lv, mt, nl, pl, pt, ro, sk, sl, sv.

  14. What are search parameters "submittedAt", "updadedAt" and “expectedPublicationDate” and what dates do they represent?

    "submittedAt" reflects the value that an eSender inputs in Notice Dispatch Date (BT-05). It is up to the eSender to input a value; as long as the notice passes CVS validation and lawfulness, it will be published.

    "updadedAt" reflects the date the most recent update was done on the notice. For instance, if you stop publication on a submitted notice, the "updatedAt" date will also be updated to reflect that. In the future, OP is planning to introduce search parameters for the date/ time of Notice Dispatch Date eSender (BT-803) in the XML (if any), as well as a search parameter for the date/ time a notice was created in eNotices2 application.

    “expectedPublicationDate” is assigned by our internal system (TED Monitor) and is the next available OJS issue date based on the release calendar from the date the notice was successfully submitted. Notices will be published by default as soon as possible when the eSender has not indicated a Notice Preferred Publication Date (BT-738).

Schema and field definitions

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

    Grouping lots may provide some economic benefits for the buyer; when all the lots of the group are awarded to the same provider, costs may be reduced (e.g. impact of the learning curve, required investments for the provider) and the value of the group of lots may generally be lower than the sum of the values of the lots taken individually. Some specific Group of lots Business Terms have been defined to cater for that.

    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.

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

  3. 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 in the competition notice. If there is only one ProcurementProjectLot element, then the procurement is not divided into lots.

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

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

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

    OPT-301

    Additional Info Provider Technical Identifier Reference

    OPT-301

    Document Provider Technical Identifier Reference

    OPT-301

    Employment Legislation Organization Technical Identifier Reference

    OPT-301

    Environmental Legislation Organization Technical Identifier Reference

    OPT-301

    Tax Legislation Information Provider Technical Identifier Reference

    OPT-301

    Mediator Technical Identifier Reference

    OPT-301

    Review Information Providing Organization Technical Identifier Reference

    OPT-301

    Review Organization Technical Identifier Reference

    OPT-301

    Tender Evaluator Technical Identifier Reference

    OPT-301

    Tender Recipient Technical Identifier Reference

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

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

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

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

  11. 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 standard used to build the schema (UBL) defines numerous elements not used in eForms; “cbc:ActivtyType” is defined in to allow for further information in a text form, while eForms does not expect this, and all possible activities are covered by the codelist.

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

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

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

  15. 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 using BT-195 and then will have to insert BT-197 (why it is unpublished). A user may also want to add BT-196 (an optional description), and BT-198 (when this field will be made public).

    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.

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

    BT-198 should be within the next 10 years; Unpublished Access Date (BT-198) value must be between 2 days and 10 years after the Notice Dispatch Date (BT-05). If the date is not filled, the unpublished fields will never be published (and the notice is therefore only published once).

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

  18. 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" (i.e. PIN Only). 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. BT-1251 is used to identify the Part of the PIN Only notice, that alone or together with other Parts from the same or other notices, lead to the definition of the Lot or the self-standing procedure.

  19. 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 the technical implementation 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 an occurence of a Business Group (and its content) to one or more specific lots. In the XML, (the Regulation Annex is a normalized representation); in the technical implementationthis information is pointless by design as the information of the Business Group may be found inside the element representing the lot (except for some Result specific information, the Technical Implementation is a denormalized representation).

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

  20. 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 60 days into the future.

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

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

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

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

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

  26. 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. The codelist “vehicles” (file vehicles.gc) is distributed with the SDK.

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

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

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

  3. 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 in 2024. 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.

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

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

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

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

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

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

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

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

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

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

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

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

  16. With eForms, is the Publications Office validating the dispatch date of notices?

    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),

    • (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. CVS checks dynamically the dispatch date (BT-05) value against the current date. The rule may be currently more permissive, allowing for Notice Dispatch Date (BT-05), or Notice Dispatch Date eSender (BT-803) (if provided), to be 1 day before or after the current date. As of SDK 2.0, the rule will strictly only allow the dispatch date to be between 0 and 24 hours before actual reception date/ time.

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

Codelists

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

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

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

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

  5. 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
    https://op.europa.eu/en/web/eu-vocabularies/releases

    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
    https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/contract-nature.

    The XML file does not indicate the “EFORMS” context for the "combined" concept, therefore combined is not used in eForms:

    <start.use>2021-03-17</start.use>
<use.context>TED</use.context>

    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>

ESPD

  1. 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 4.1.2.1 of the eForms Policy Implementation Handbook.