eForms Preview environment

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.

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.

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.

Notices submitted to Preview eNotices2 as of 27 February 2024 did not acquire status “published” due to an error in the export process. This issue, which may also have affected the “expected publication date”, was fixed on 14 March.

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.

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.

In Contract notices of the Defence directive, BT-71-Lot should not be filled in.

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

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

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.

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.