eForms Preview environment

Scope and purpose

The Publications Office (OP) has developed a range of applications for the collection, validation, processing, visualisation and dissemination of eForms notices. These applications are collectively known as "TED Apps for eForms" and went into production use on 14 November 2022.

We have prepared an additional "Preview" environment for eSenders and stakeholders, where we deploy releases of the TED Apps for eForms as they become available. This environment allows access to the applications before they are deployed in Production, and provides a testing environment that is closely aligned with production, but with no guarantee of features, data or availability.

Users should consider that there is a limit to the capacity of the Preview systems, and they should not submit excessive volumes of notices while testing; the systems currently can handle around 5000 notices per day with no disruption, shared between all eSenders. See our Terms of service for TED publishing services.

The application features, URLs as well as the data present in the "Preview" environment, are subject to unannounced changes.

URLs and API keys in "Production" and "Preview" environments are not interchangeable. For accessing the web applications in the "Preview" environment (eNotices2 and the TED Developer Portal), you need an EU-Login acceptance environment account which you can get at https://ecas.acceptance.ec.europa.eu/cas. To access eNotices2 API in Preview, you need to generate a key from the TED Developer Portal in Preview: https://developer.preview.ted.europa.eu/home

TED Apps for eForms

The TED applications for eForms are:

TED eNotices2

eNotices2 is the reception system for eForms. Notices can be submitted and managed through the web front-end or via the TED API. eNotices2 replaces the current eNotices and eSentool applications. eNotices2 calls the Central Validation Service to validate submitted notices before sending them to TED Monitor for processing and publication.

TED Central Validation Service

The Central Validation Service (also known as TED CVS) provides an API for validating eForms notices. It is called by eNotices2 to check the validity of a submitted notice, but it can also be called by eSender applications to validate a notice at any time.

TED Viewer

Also known as "TED Viewer 2022" this notice visualisation service provides an API that allows applications to render an eForms notice in the HTML or PDF format.

TED Developer Portal

The TED Developer Portal is envisioned to be a central hub for TED developer services. At this point in time, the portal allows eSenders to sign-up and obtain/manage their API key which is required for calling TED APIs.

TED Monitor

Also known as "TED Monitor 2022", this application is the internal production system used by OP to prepare the publication in the Supplement of the Official Journal (hosted in the TED website) of the public procurement notices submitted every day. It also allows OP to check the lawfulness of certain notices and to mask unpublished fields.

TED Monitor is not accessible by eSenders in the "preview" environment.
TED Website

TED is the public dissemination website for European procurement notices. It is the digital (and only) form of the Supplement to the Official Journal of the EU (OJ S). The new TED website, also known as TED 2.0, was developed to handle eForms notices.

The TED website is not available in the "preview" environment.
systems diagram

Accessing TED Apps in PREVIEW

eNotices2

The URLs and parameters may change in subsequent releases.
Please be aware that the interface and the notice forms still need further work to improve the user experience.

Currently available

Application version

1.16.3

SDK versions

You can find the SDK active versions per environment at: https://docs.ted.europa.eu/home/eforms/active-versions/index.html

In this version, the application is expected to allow users to create the 40 eForms notice types plus the 5 other notice types which include the 2 transport regulation notices, the European economic interest grouping and European company/cooperative registration forms, and the call for expression of interest.

In the codelist fields, prefilling of values is supported.

Users can see the validation returned from CVS and have their notices rendered in HTML and PDF.

Before you can create a Change notice or continue a procedure on a published notice, bear in mind that submitted notices go through another workflow in TED Monitor before they can be published, which takes place every working day.

The application also allows users to act upon notices and procedures, archiving, renaming and transferring them to other users or other procedures as well as export notices in XML.

There is also a search feature which allows users to sort through long lists of procedures.

Users can create workgroups between themselves and test the definitions of roles and permissions within these workgroups. They can also work and submit notices worked upon collectively.

Users can define personalised settings for the legal basis and notice types that they want to use, as well as default languages in the notice, and tailoring of some fields is available:

  • Optional fields can be set to mandatory or hidden, however; please see the application Help page for more information: “I want to submit a notice but I have too many validation errors. What can I do?”

  • Confidential fields can be set to be always confidential or non-confidential.

In the notice sections a search feature has been added and pagination for up to 2000 lots is supported.

Improvements as of application version 1.15

Notices submitted through the eNotices2 user interface now have an extra organisation (ORG-0000) to identify the eSender service provider. This organisation is not visible in the form-filling tool and is automatically filled in with the details of the EU Publications Office when the notice is submitted for publication on TED.

“Live” validation

The form-filling tool now has “live” validation, which means that it adapts dynamically to the values in the fields to help to fill in the required fields and to avoid business errors. This includes the following features:

  • All strictly mandatory fields are identified by an asterisk.

  • Fields that become mandatory under certain conditions will appear only when the conditions are fulfilled. Once they are mandatory, these fields will also be identified by an asterisk.

  • If fields become forbidden due to the values that have been entered, they will be marked with a new icon so that they can be easily identified and corrected.

Known issues

  • Some use cases and features are still in the process of being implemented.

  • Some validation errors are currently displayed as a pop-up window, without pointing to the error location. Please set a default currency to avoid validation errors in the notices created in the user interface that can lead to a message that the: “notice is probably incomplete”.

  • All the error messages and labels in the user interface (UI), notices and fields are subject to change – translation of labels is still work in progress.

  • Notices go through CVS validation when they are submitted, or when the user clicks on "validate" in the user interface, however, the feature may be unstable.

  • Conversion from older SDK versions may have issues. If editing a notice leads to an error (server error) or 'Notice Locked', the workaround is to export (download) the xml and reimport it somewhere else in eNotices2, even if it is in the same procedure.

  • Feature “Add a new language” and using the automatic translation service to prefill your new notice linguistic version will lock the notice while the notice is being processed for eTranslation. If there is no language version added, it means translation has failed.

  • OPP-080-Tender field cannot be used in T02. This issue is resolved in Preview as of 24 July 2024 and will be resolved in Production with the next release (as of SDK 1.12).

The following issues have been identified as of application version 1.12.3:

  • If you have procurement documents, then OPT-140-lot must always be filled in.

  • If you have a prize, then BT-44-lot must always be filled in.

  • If you have selection or award criteria, please make sure that there is a weight and a number.

The following issue has been identified as of SDK 1.11:

  • With the implementation of the new rules, both fields BT-759-LotResult and BT-760-LotResult, Received Submissions Count and Received Submissions Type, have become mandatory in Result notices. In order to avoid a validation error both must be completed.

The following issues have been identified as of application version 1.15.2:

  • BT-1375-Procedure: lot distribution for the group will show an error in the live validation even if there are 2 or more different lots correctly referenced. The user can ignore this and validate on CVS. If valid, the notice can be submitted.

  • Procedure section and lot: The type of procedure must be chosen before entering the lot sections. Since many fields are procedure type dependent, this is to ensure that the form filling tool will respond correctly with the live validations.

Known eNotices2 API issues

The eNotices2 API URLs and parameters will change in later releases. The Swagger UI provides basic documentation of the four functions.

  • Please note that the HTTP responses are still a work in progress; in certain cases, error code 500 is returned instead of 400. We are in the process of identifying these cases and correcting the responses and their corresponding messages to clearly indicate that the error is on client side and not on the server side. For instance, an error code 400 would mean that the notice is rejected by eNotices2 API and does not even get validated by CVS. In this case, the instance/ notice cannot be created in eNotices2.

The Preview environment is for testing purposes; new SDK releases will first be made available on Preview before deployment in Production. Please note, however, that Preview only simulates Production and notices submitted in Preview are not published in a test environment of TED. "Publishing” and “Published” are mock statuses that will be assigned to submitted notices at around 15.00 and 16:00 respectively when they enter the export. If there is a preferred publication date, Preview will show status “published” as soon as the export finishes, which is the previous working day at around 16:00 CET. As an example, if the preferred publication date falls on a Monday, the status will change to "published" the previous Friday at around 16:00 CET, when the export takes place (provided Friday is not a public holiday).
Notices submitted in Preview are only checked for lawfulness upon request. Please note that the lawfulness feature is activated in Preview as of 24 May 2023; this means that any notices submitted in Preview that trigger a lawfulness warning will remain in status "submitted" unless we receive your request to manually reject it. The feature has been activated so that eSenders can test the status "NOT_PUBLISHED" that a notice will receive when manually rejected by OP. Precondition for this is that the notice triggers lawfulness warning and we receive your request to reject it by business ID (i.e. notice ID + version ID).
In Production (live environment), the actual export to TED happens on workdays around 16:00 CET depending on the number of notices to be published in the next OJ S. When this process is initiated and a submitted notice is in the daily export, it will be published on TED no later than 09:00 CET in the next available OJ S based on the release calendar. Its status will then change to “Published”. Please note that stopping publication of a notice is not allowed at this stage, i.e. between the export and publication. In the Preview environment, a notice reaches Publishing status on workdays between 15:00 and 16:00 CET once the export is done by our internal service. In Production, the notice will be in "Publishing" status between the daily afternoon export and publication on TED the next morning (working days). For more information on notice statuses, please see the eForms FAQ.

Tips for using the form-filling tool of eNotices2

Please consult our Help page to get started.

We are currently in the process of providing more guidance for users of the eNotices2 web interface. Until we can provide some more guidance and until known issues are fixed and more rules are re-enforced, we have provisionally gathered here some tips to help users with avoiding validation errors:

  • Each TPO (Touchpoint) should be assigned a role; users may have to remove TPOs from the notice if there are not enough roles to fill. In particular, for notice subtypes 1 to 3, no roles can be assigned to Touchpoints at the moment, meaning that all touchpoints should be removed from the notice.

  • In multi-stage procedures (BT-105), the second stage indicator should be set to 'yes' on one of those 3 groups where the criterion is used.

  • Please avoid using the section “Information about late submission” except for the mandatory fields and the “Description of the NDA”.

  • Any date field which has a time attached must always have a value in the time field.

  • For structured organisations, to get started, please fill in Organisation Name, Organisation Identifier and Organisation Part Name under My Form Settings > Main Buyer Settings.

  • When filling in the subcontracting section of a tender (GR-LotTender-Subcontracting), you should complete the field BT-773-Tender. If you need to enter the value or the percentage of the subcontracting, you should also set the corresponding indicator (fields BT-730-Tender and BT-731-Tender) to ‘yes’.

  • We encourage users to fill in forms by starting with the procedure section, then completing the information about lots, and then, if relevant, finishing with the results.

  • Some fields are excluded from the live validations, namely the fields to publish some information later (unpublished fields). If you don’t need any confidential fields, it is possible to hide this option via Form Settings → Confidential fields → Set all non-confidential. This setting will then apply to newly created notices.

Tips for eSenders

  • If you are an eSender, please note that the concept of Workgroups is reserved for users of eNotices2 web User Interface (UI). eSenders/ users of eNotices2 API can still create workgroups in the UI of eNotices2 but the API is not aware of the context of workgroups, i.e. no API function can be performed on a notice that has been manually transferred to the context of a Workgroup.

  • eSenders should only use the API for the submission of notices and refrain from using the User Interface of eNotices2 for this purpose. The output of eNotices2 is not intended to reflect the correct format of notices submitted via API. Likewise, eSenders should not continue a procedure or create a Change notice via the User Interface for a parent notice that was originally sent via the API, and should not use the UI to manage or to import/export notices submitted via API.

  • To avoid authorisation issues when using eNotices2 API, make sure you generate your API key in the corresponding environment of the TED Developer Portal:

  • To avoid authorisation issues when using eNotices2 API, log in at least once in the corresponding environment of the User Interface to pair your API key with your eNotices2 account and make sure that you perform at least one valid API request with your key to eNotices2 API:

  • You can find the SDK active versions per environment at: https://docs.ted.europa.eu/home/eforms/active-versions/index.html. For the value to indicate in the cbc:CustomizationID element, it should always have the format "eforms-sdk-major.minor". See this page for more details: https://docs.ted.europa.eu/eforms/latest/versioning.html#_significance_of_the_sdk_version_in_notice_handling_and_validation

  • Dynamic rules that check between notices are not yet in place, users, however, should still respect the workflow of eForms notices. For instance, users may currently be able to submit a Change notice that refers to a parent notice that has not been yet published. The notice will still be blocked by our internal system (will enter in error). Currently, it is not possible to stop the publication of a notice that has entered in error in the Preview environment, but we are seeing what could be improved for these situations.

  • Currently, there are some checks performed by eNotices2 API upon submission of a notice, e.g. eNotices2 will check (and reject) a notice with the same id and version id if it already exists in the system. In the future, such checks will be performed by CVS.

  • With application version 1.13.2 we have added "expectedPublicationDate" to the list of notice metadata, which is retrieved as the results list of the searched notices, or the notice being stopped.

  • As of application version 1.14.0, which went into Production environment on 16 May, we have improved the automated notifications/ emails regarding the various statuses of notices so that the eSender’s email address is included in copy. As part of the improvement, the Publication notification email includes a link to the published notice on TED. As a reminder, mandatory property “noticeAuthorEmail” in the metadata must be a valid email address and is intended to identify the buyer, i.e. must correspond to the Contracting Authority, so that the Publications Office can notify them about the workflow of their notice, e.g. the publication/rejection of their notices.

  • Application version 1.16.3 brings two new features to the Publication API for better tracking of notices, as requested by eSenders, which are available in Production from 31 October 2024 onwards:

    • createdAt: Shows when each notice was first created in eNotices2, in UTC format (e.g., 2022-07-25T14:30:00Z).

    • transmittedAt: Records the dispatch date of the notice as per BT-803 (Notice Dispatch Date eSender) in UTC (e.g., 2022-07-25T14:30:00Z); this will be "null" if not provided and is only for future notices.

Planned updates

Indicative planning

November 2024

Application version

1.16

SDK version

1.13

This version of the application is focused on improvements to the UI experience and the correction of bugs.

Current application version in Production as of 31 October 2024.

TED Central Validation Service

Currently available

Application version

1.8.0

SDK versions

You can find the SDK active versions per environment at: https://docs.ted.europa.eu/home/eforms/active-versions/index.html

Scope

Complete implementation, including the execution of the validation rules (Schematron).

We are working on resolving the following limitations and known issues:

  • Since SDK 1.7, the dispatch date (BT-05) rule checks the value against the current date. The rule may be currently more permissive, but as of SDK 2.0, it will strictly only allow the dispatch date to be between 0 and 24 hours before actual reception date/ time.

The validation mode "dynamic" checks data that may vary in time, e.g. the current date or information in another notice.

TED Viewer

Currently available

Application version

1.7.0

SDK versions

You can find the SDK active versions per environment at: https://docs.ted.europa.eu/home/eforms/active-versions/index.html

Scope

Final version of the application with full rendering of HTML and PDF and using the view-templates defined in the SDK

Planned updates

Scope

Ongoing improvements with successive SDK releases

Known issues

  • Currency values are currently not rendered correctly, e.g. “10,000,000.00” instead of “10 000 000,00”. This will be fixed with SDK 2.0, so that currency values are also correctly displayed in the OJ S.

TED Developer Portal

Currently available

Website URL

https://developer.preview.ted.europa.eu/home

Scope

Users can generate an API key. As of 5 July in Preview and 10 July 2023 in Production, eSenders can set up their Developer Profile as it is now mandatory.

Planned updates

Indicative planning

Q2 2025

Scope

Public profiles will be made available at a later stage as a catalogue of eSenders and will eventually replace the list of eSenders on SIMAP.