Publications Office of the EU
Minutes - TED eForms
DisplayCustomHeader
Minutes - eForms - 4th Technical Workshop

 

Minutes of the fourth eForms Technical Workshop 

28 March 2023

 

The 4th eForms Technical Workshop took place online on 28 March 2023.  

These are the revised minutes, i.e. replies to questions posted live during the webinar have been reviewed and may have been regrouped or modified for this written version to allow for a more cohesive and complete response.  

Please note that some answers may no longer be accurate, as the Publications Office (OP) has followed up on comments made and may have modified its approach accordingly.   

The live sessions were recorded and are available in the Agenda section along with the PowerPoint slides of each presentation.  

 

On 14 November last year, our tools were ready to receive and to publish eForms notices and since January we have had indeed some real notices submitted by public buyers.  

There are still ongoing improvements but the essential artifacts that are needed to build eForms applications have been available since 2019. The implementing regulation was adopted in 2019 and it had already the list of forms, the business terms and the indicative rules to be applied. We produced the schema in December of 2019 and we made available the API endpoints and documentation in November 2022. With these essential artifacts it is possible to create and to send valid XMLs for publication in the Supplement to the EU Official Journal on TED.  

The Publications Office is now focusing on labels and their translations, on correct behaviour of validation rules and their appropriate error messages in a language that is understandable for end users .  

There is a test environment called Preview environment where users can test their own applications. 

For business-oriented questions, there is TED Helpdesk for guidance and assistance; and for technical issues, you can get support via GitHub. 

We try to respond as much as possible to your comments and your suggestions and to help you with a smooth transition before the D-Day for eForms, i.e. the latest go-live date – 25 October 2023.  

 

TED Developer Portal – Karl Ferrand – Publications Office of the European Union  

TED Developer Portal’s current primary function is for eSenders  to get their API key, which allows eSenders to call TED API functions, like publishing their notices.   
For testing purposes, there is the Preview environment (including the TED Developer Portal) which is closely aligned to production. Remember: do not test the submission of notices with your Production API Key! 

Note: there is also a section for TED data reusers. In principle, they don’t need to sign up but the idea is if they do, they can receive notifications (changes, interruptions, etc.).  

 

The TED Developer Portal is envisioned to be a central hub for TED developer services. OP’s intention is to gradually add features for other developer groups that are interested in other TED developer products (e.g. eProcurement Ontology, ESPD), or data services (e.g. TED Semantic Web Service). 

The Developer Profile will be deployed in the Preview and the Production environment of the TED Developer Portal. Setting up a Developer Profile will be part of the sign-up process and mandatory before eSenders/developers are able to generate or renew an API key.  

If you are a registered user, you can access the section ‘Manage API Keys’ or ‘Manage your API Keys’; to see the status of your API Key, e.g. a if it is active or not and when the date of expiry is.e upcoming weeks (now planned for June 2023), it will be possible to set up a developer profile and a public profile. For more information, please consult the presentation. 

 

 

eForms Business Issues – Karl Ferrand – Publications Office of the European Union  

For labels, it’s planned to have translations in 24 languages. They can be found in the translations folder in SDK (one file per asset type per language). The translations are carried out by EC translators but many labels are still using EC machine eTranslation. Any users willing to give feedback are welcome. Regarding translations of rules, the goal is to complete all translations by end of June. Previous SDK version will receive translation patches. For more information about translations by asset type, please consult the presentation, p. 4-5. 

 

 

SDK status update and roadmap – Ioannis Rousochatzakis – Publications Office of the European Union  

 SDK 1.6 was released at the beginning of March and it includes the following: 

  • added new properties to fields.json: 'presetValue’, ‘schemeName', and 'captionFieldId’, 

  • added XML namespace and prefix information to 'notice-types.json',  

  • schematron rules now indicate the identifier of the field or node to which each rule applies, 

  • added a file named VERSION to the SDK package,  

  • updated metadata content.  

Translations and visualisation templates were updated and all active SDK versions (since 1.3) were patched with all these improvements. 

There is a focus on improving the eForms metadata in the future SDKs.  

Notice Editor sample application is being developed, too. For further information, you can follow the dedicated GitHub page. 

In EFX 2, we will: 

  • add template block variables, 

  • improve template context tracking, 

  • improve its formatting capabilities,  

  • add more functions (e.g. for working with strings, sequences, translations, etc.). 

 

Question from the participants: 

  • There is inconsistency between the SDK and the implementing regulation, e.g. data type of some fields, some fields in the SDK are not part of the implementing regulation or some implementation fields are not part of the SDK – what is single source of truth? 

Answer: The regulation does not contain enough details, fields had to be further specified and/or added. 

 

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

Answer: The type ‘measure’ relates to durations of time. The codelist to be used is ‘duration-unit’. The filename for this codelist is ‘timeperiod_duration-unit.gc’. 

 

  • Can older versions of the SDK also be patched with the latest version of the validation rules. We had some blocking rules that will be removed. But now we are enforced to update to the newest SDK version. 

Answer: Please let us know which rules are blocking you. It’s not easy to patch rules for older SDK versions but we can assess the problems. 

 

  • Certain elements are subject to maintenance. For example, NUTS are updated from time to time. How will we deal with those updates? Will there be a hard cutover from old to new codes, courtesy period in which both coexist? How will it be when the content of notices (e.g. fields) is updated? 

Answer: NUTS are a codelist in SDK. The transition to a new NUTS version would come in a new SDK version and at some point, the older SDK versions with old NUTS will be deprecated. A changed notice will need to comply with the codelists of the SDK it is submitted in – so potentially a notice that is changed in 3 years’ time will need to also have a newer NUTS code. 

 

  • There is a duplicity in filling data into form. In case the order has no lots (i.e. has 1 lot), the data in GR-Lot-PreviousPlanning, GR-Lot-Description, GR-Lot-PlaceOfPerformance are the very same as the ones filled in GR Procedure. 

Answer: There's currently no solution for this in the SDK. There is always one technical lot at least. The XML must contain all the required fields as this is how the information has been conceived by the eForms regulation. 

 

  • GR Groups and Lots - Missing unit types (BT-36-Lot; BT-98-Lot): in some fields, only a numerical value is allowed to enter without any additional information about the unit of time (days, months,..). Do you plan to add measure unit to these fields? 

Answer: For duration as well as for elements of type code, there is most of the time no field defined for the attributes and the developers have to consider some implicit rules for that. 

 

  • GR Organisation - is it required that every Organization created in this section has a role? By other words, the ID of each organisation must be assigned further in the form? 

Answer: Indeed, each instance of ORG-XXXX (and TPO-XXXX where appropriate) must have a role attached. However, there are restrictions, e.g. if ORG-0001 is the buyer, it cannot be a tenderer at the same time. 

 

  • GR Procedure - Previous notices fields (OPP-090-Procedure; BT-125(i)-Lot): what is the purpose of the fields, what do you expect to insert here? All previous notices/just one previous notice? As notices are order related with a clear linkage, is it OK to send no value here? 

Answer: Please see the presentation about linking notices, p. 9. 

 

  • GR Procedure - BT-763: here we get only one value in the combobox (“The tenderer must submit tenders for all lots”). We would expect here more values (or yes/no question) to be in accordance with implementing regulation. 

Answer: BT-763 serves as an indicator. The tenderer must submit for all tenders if the code is used. 

 

  • Can we expect to get a complete matrix where all BTs, OPPs and OPTs are presented per form subtype? 

Answer: There is no easy way to present this matrix but the CSV lists might help in future. 

 

  • I have found that some rules (such as BT-01252-00** ) are currently deactivated. How can we know when the rules will be activated in future SDK versions? 

Answer: We will aim to document this in the release notes. Many of the conditional rules for this field will be included in SDK 1.8. 

 

  • What is the business meaning of the group of lots? Documentation specifies constraints on what it contains but it does not give a clear sense of what a group means for the end user. 

Answer: A group of lots allows to have the same values for more than one lot – but unless this is used or needed in your country, we suggest you hide this from the end user. 

 

  • In a CAN, sections Tendering parties and Tenders. Is it expected to have all the tenders/tenderers for the lot, or only the ones which are awarded, referred to from section ‘Results’? 

Answer: Non-winning tenders and associated tenderers may be reported too. 

 

  • What is the purpose of the field OPT-999 'dummy tender award date'? 

Answer: This is defined to satisfy a schema constraint. The award date is mandatory but the way results are structured in UBL does not match the way it is expected in eForms. To remain user friendly, the extensions had to be defined. The schema constraint for the UBL part however remains and it required the definition of this field to which no business semantic should be associated. 

 

  • Section ‘Information about contracting party and provider’, section ‘GR-Procedure-SProvider’. What is this intended to model? Concretely: there's a place to list an eSender, must the eSender be listed here, as a party in the notice? What does it mean a ‘Procurement Service Provider’? 

Answer: eSenders should fill the ‘TED eSender’ organisation role for their notices. ‘Procurement Service Provider’ is optional and can be used for buyers to refer to any other type of service provider. 

 

  • Can you give the legal basis for the validation rules? We are looking for the reason why some of the schematron validations are added. 

Answer: The validation rules are derived from the eForms regulation, the procurement directives and to ensure valid workflows and data quality. 

 

  • What is the reason for this rule? The duration of the DPS is not the same as the deadline of receipt request in the first phase of the procedure. BR-BT-01311-0150 "For a ""Dynamic purchasing system"", the Deadline Receipt Requests (BT-1311) value must be equal to Duration End Date (BT-537) value" 

Answer [DG GROW]:  Compared to any other procurement procedure (technique), a DPS stays open until the end of the duration. Meaning that at any time until the end new bidders can submit their requests to participate. 

 

  • We are not able to find which field signifies UnRestricted Access Url (UAV) in eForms. Can you please let us know about the Business term for the same? 

Answer:  

If you are referring to the F02 PDF, the following section: 

‘Electronic communication requires the use of tools and devices that are not generally available. Unrestricted and full direct access to these tools and devices is possible, free of charge, at: (URL)’.  

This is implemented in TED XML as element ‘URL_TOOL’. In eForms, it was mapped to BT-124 Tool Atypical URL. 

If you are referring to the following: 

‘The procurement documents are available for unrestricted and full direct access, free of charge, at: (URL)’ 

This is implemented in TED XML as element ‘URL_DOCUMENT’ when associated with element ‘DOCUMENT_FULL’. In eForms, it was mapped to BT-15 Documents URL associated with BT-14 Documents Restricted with a value of ‘non-restricted-document’. 

 

  • Can you clarify this rule? BR-BT-00105-0108 If Notice Type (BT-02) value is equal to ('CAN standard' or 'Contract or concession award notice – social regime') and Procedure Legal Basis (BT-01) value is equal to 'Directive 2014/23/EU', then Procedure Type (BT-105) value must be equal to ('Negotiated without prior call for competition' or 'Other single stage procedure' or 'Other multiple stage procedure'). 

Answer: This rule came from DG GROW, it was provided as part of the set of rules shared with OP in March 2019. It ensures that only certain procedure types are allowed for the type of notice and the relevant directive. 

 

  • BG-320 Tender: In the result should we give only the winner or all of tenders? 

Answer: Winners are necessary when they exist. For non-winners, this is a choice of the buyer. Tenders and Tenderers provided information should be consistent. It is not possible to provide information about non-winning tenders without identifying the associated tenderers. 

 

  • No EFX JavaScript parser – the eForms SDK uses proprietary language EFX, which is hard to parse to programming languages. There is an EFX Java parser, but most countries need a JavaScript parser (for web applications), and it is highly inconvenient for all countries to program their own parser. 

Answer: There is no JS parser planned for now; there is not enough resources at OP to produce it. 

 

  • Will you provide detailed documentation about changes made in EFX in SDK 2? 

Answer: OP will aim to provide consistent and detailed documentation for further changes in EFX. SDK 2 was presented in more detail at the 5th eForms technical workshop on 23 May. 

 

  • How is it possible not to use EFX? What other method is to implement conditional rules? 

Answer: Please let us know what you mean by ‘implement’, via TED Helpdesk, and we will come back to you with an answer. 

 

  • Currently, the CVS returns the error texts in English. It will be returned in other languages in the future and when? 

Answer: Please see the presentation for further information; it will be done most probably in June with SDK 1.8. 

 

  • eNotices2 - duplicity - GR-LotResult-1: the Buyer just summarizes what is stated in the subsections following this subsection. Besides that, to be able to fill this subsection in, you need to skip this subsection and first after filling in the other data can come back. 

Answer: There is no duplicity. Gr-LotReuslt1 contains the references to the contract, to the lot and to the tender. 

 

  • When can we expect the specifications regarding fields that are not allowed to be changed in a Change notice or Modification notice? 

Answer: It is planned for June, although the implementation will be carried out in a later SDK. 

 

  • How do we change (with an eForm) an ‘old fashion’ notice, already published in TED? 

Answer: The original notice must be converted into eForms format. 

 

  • When you said that the form-type ‘change’ and notice-type ‘corr’ will be deprecated no later than June, did you mean only the eForms?  

Answer: Form-type ‘change’ and notice-type ‘corr’ only exist in eForms. Current TED-XML notices will continue to use F14 for corrigenda. 

 

Answer: The latest version of all mappings are in the XSLT files, in GitHub. 

 

  • Are there any eForms already published in the OJEU? 

Answer: There is an expert search query that gives the list of eForms on TED:  

TD=[NOT (C or E or G or I or D or P or M or Q or O or R or 0 or 1 or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or B or S or Y or V or F or A or H or J or K)].   

 

  • How can I display appropriate validation messages to the user without using the schematrons? Is there a way to retrieve the translation keys using fields.json alone? 

Answer: No, the fields.json contains the identifiers of validation messages only for some ‘co-constraint’ checks, that is when the permitted values of one BT depend on the values of another BT. For the majority of validation messages, the only way to link a validation error with the appropriate message is in the schematron files. 

 

  • For information that is common across all the notices in a process. Will there be validations enforcing the information in the former notices, e.g. a CAN is pretty much a CN + results: is it mandatory that all the information about parties, procedure, lots, etc. is the same in the CAN as in the CN? 

Answer: If the information is the same and it exists in both notices and has the same meaning, then the value should be the same. They should be identical. 

 

  • Schematron stage 6 are validations for a notice which relates to a previous notice. There are more validations then mentioned in the presentation. Will notices with a change section be validated with the shematron 6 stage validations? 

Answer: Notices with a change section will have a specific set of rules applied, to check that only the fields that are allowed to be modified are changed, and those rules will be in the ‘stage 6’ Schematron files. Please note that rules that use information from another notice are currently not enforced, due to a technical limitation. 

 

  • When can we expect the specifications regarding form subtypes E1-E5? 

Answer: Not before the 2023 amendment to eForms regulation. 

 

  • When can we expect the specifications for T01, T02, CEI? 

Answer: They are already included in SDK but T01, T02 might be adjusted a little after DG MOVE’s review. CEI is reserved for EU institutions. 

 

  • For below threshold eForms, will it be possible to use E4 to publish award notice for contracts awarded off a Framework or DPS? Can E4 be used without having published E3 to TED? 

Answer: Nothing is implemented yet for these voluntary below-threshold notices. If you publish below-threshold notices on TED, you must follow whatever rules apply to the above-threshold notices, as specified by the eForms regulation. 

 

  • Where can I find documentation on how to implement the more complex field types, i.e. 'amount', 'measure', 'text-multilingual'? 

Answer: You can consult the documentation https://docs.ted.europa.eu/eforms/latest/fields/index.html#data-types. However, if you need further information, please open a discussion for this question in GitHub. 

 

  • How you suggest to edit a notice? For example saving VisualModel and using it when making the html? 

Answer: There's a lot of techniques for notice editors to edit a notice, e.g. to create an empty form and then look up the values from an existing notice. 

 

  • Are you going to publish another version of eForms-Notice-Editor showing xsd validation and notice editor? 

Answer: The Notice Editor is not a priority for OP but we are doing our best to provide updates.  

 

  • Can we use the TED render API to render a notice which has been tailored to national specifications? 

Answer: The TED Viewer API will display whatever is in the XML that is provided to it. If your national-tailored XML is a subset of eForms, then it will display. However, it won’t, for example, display codelists that don’t exist in eForms SDK. 

 

  • When could we expect SDK 1.3.3 compatible viewer service? 

[post-event] answer: The TED Viewer API was already patched to SDK 1.3.3 in March. 

 

  • For the version with all translated rules, will it be only translations? Or could it include some evolution of the structure of the notice? 

Answer: The SDK with translated rules will also contain other updated components, e.g. rules. 

 

  • The 'Other' options in the legal basis. Can that be used to bypass the schematron validation rules, e.g. for sending national notices to TED – e.g. form 16 with legal basis 'other'? 

Answer: In general, rules will be applied according to the notice subtype (e.g. 16) rather than the legal basis. If you submit a notice for form 16, you’d be subject to directive 24/2014 rules. 

 

  • In the mandatory section of fields.json, noticeType is always the first object of constraints array where mandatory value is false? 

Answer: When reading fields.json (or any other JSON file), you should not rely on the specific position of properties, but always use their name: ‘noticeTypes’, ‘value’, etc. 

 

  • Is it possible to get read-access to the metadata database? It is always said that the files made available to us were generated from this Metadata Database. So it would be an advantage if they were made available, or is there something against it?  

Answer: It is not possible. However, we would like to have a public visualization of the content of the database in the future or at least the SDK. 

 

  • Why did you make it all so complicated? No one is happy with that, and when 100+ questions are asked at every meeting, something seems amiss. 

Answer: We are implementing the eForms regulation which was agreed by Member States in 2019, and amended with the agreement of Member States in 2022. 

 

  • What file is the ‘Extended annex’ Excel? 

Answer: It’s a working file: it is the Excel version of annex 2 of the eForms regulation, with some additional information - see link from https://single-market-economy.ec.europa.eu/single-market/public-procurement/digital-procurement/eforms_en 

 

  • How can we retrieve the TED publication ID of the Contract Notice that was submitted with TED-XML after the migration? We only have the NO_DOC_OJS for it. 

Answer: For eForms, you will get the ‘publicationId’ of notices in status Published. 

 

  • We receive the NO_DOC_OJS in format 2023/S 123-123456. But we need the publication ID in format 123456-2023 to link CAN to CN after migration. Are we supposed to simplay extract the first part of the publication ID "123456" from the NO_DOC_OJS and rearrange it to the format 123456-2023? As i said we did not find any way to retrieve the TED Publication ID in format 123456-2023 via old or new rest interface. But maybe we just missed that. (Looking up the ID on TED is not an option of course.) 

Answer: For TED XML Schema, you have to extrapolate from the eSentool API 2023/S 123-123456 => 123456-2023. For eForms, the eNotices2 API returns the publicationID in the new format ‘01234567-2023’. 

 

  • The presentation stated that leading zeros in the TED Publication ID could be omitted. However, SDK 1.5.1 specifies exactly eight digits. 

Answer: eForms notices will get an 8-digit publication ID when published on TED but it is possible to reference publication IDs on TED without leading zeros if you wish. With SDK 1.7.0 it is possible to link to a previous notice using publication ID with or without leading zeros, i.e. the number can be be between 1 and 8 digits, followed by the year. 

 

  • Must a contract award notice contain all the lots of the contract notices? Or can you also publish the lots of a contract notices in separate contract award notices, e.g. a contract award notice per lot? 

Answer: Contract award notices do not have to contain all the lots of the previous contract notices but they may contain all the not-yet awarded lots; there can be many contract award notices published following a contract notice. It is also possible to publish a contract award notice for a single lot. 

 

  • Do you expect it would be possible to stay and go live with version 1.8? 

Answer: Yes, SDK 1.8 should have what you need.  

 

  • Regarding service providers (SP) that are active in several countries. If country A requires the service provider to use SDK version 1.7 and country B version 1.6, etc. How would this effect the service provider? Does the SP need to support all versions? 

Answer: This is outside OP’s scope; we don’t impose SDK versions. In principle, each country shouldn’t need to impose an SDK version and the latest version will generally be the ‘best’ one. 

 

  • If a competition is announced on one platform using standard notices but awarded after October 2023, will it be possible to publish a CAN (based on new eForms) to TED without having published previous notices such as PIN or CN in the new format? 

Answer: Yes, your CAN in eForms will refer to your PIN or CN in the legacy TED-XML format on TED using the publication ID. 

 

  • Will there be LTS versions of the SDK with support time more than 1 year? 

Answer: It’s not planned.  

 

  • There is few information about OPT, OPP, OPA fields in TED document pages. I found them in fields json but that’s all. Could you give us more information (documentation) about them, all of them, e.g.: OPP-040 when do we have to use it and why? 

Answer: OPP is for OP Production fields, OPT is for OP Technical fields and OPA for OP Attributes fields.  

 

  • The type of BT-722-Contract is code in the fields.json. In notice type 29.json, its type is textarea. Is there an issue with the notice? 

Answer: It Is currently a textarea in all subtypes. It must use the values from the codelist = eu-programme. 

 

  • BG-703 Organisation should be filled only with data regarding the eSender, is that right? 

Answer: BG-703 is expected for any organization having a role in the procedure.  

 

  • Is there a method to evaluate the rules (assets) with json result that field validation? For Exemple : Input => générated XML + FieldId (OPP-070-notice). Result =>{ mandatory: false, forbidden; false, ruleValidation: false, messages: ["rule|text|BR-OPP-00070-0100","rule|text|BR-OPP-00070-0101"]} 

Answer: Could you please rephrase your question and contact us via TED Helpdesk? We will come back to you with an answer. 

 

  • A central national eSender node will be introduced in Germany. This will use its own eSender identifier (or its own API key from the developer portal) -> eSender A. Can eSender A send contract award notices even though the associated contract notice was sent by eSender B? 

Answer: Yes, it is possible. On TED, we have no trace or concept about what happens upstream from the submission, just that an eSender has submitted a notice on behalf of a buyer. 

 

  • The business identifier (UUIDv4 + incremental version) should be generated by our systems, but how do we now if it doesn't collide with another one? Should we do a search request before each submission? 

Answer: eN2 API will not allow the submission of an identical businessID. Besides, 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.  

 

  • Why is the phone number and email address of the winner mandatory? There might be problems with privacy rules in our country. Is there a legal basis for making this fields required? 

Answer: These are organization contact details which aren’t private unless the organization does not want to do business. This information is normally also available on the organization website as well at the trade office register. No personal contacts are to be included.  

  

  • How can a change notice be tested in eNotices2? 

Answer: eNotices2 UI will allow you to create a change notice on a published parent notice – please test in Preview only. 

  

  • Can you separate the validation rules for validating eForms messages from validation rules that are necessary to make a user friendly front end? 

Answer: OP is working on improvements.  

  

  • There are currently several eSenders in Germany (individual eSender identifiers / or API keys). Are these identifiers / keys retained or can each provider generates new API keys in order to use parts of the TED API / viewer, even if there is only one official central eSender in Germany? 

Answer: OP doesn’t impose if there’s one or more eSenders per country. It would work for ex-eSenders to have their own API key for CVS and Viewer APIs and only the new central eSender to submit notices. 

  

  • Is the SDK and documentation at a level that allows to meet the deadline of 25 October 2023? 

Answer: From OP side, the main gaps are translations and conditional rules – some eSenders are very advanced with the current SDK. 

  

  • We downloaded the SDK 1.6.0 in the Notice Form Editor application. Do we have to move the 1.6.0 SDK to the location "\eforms-notice-editor\eforms-sdks\schemas"? If we don't, it gives an error "java.io.FileNotFoundException: eforms-sdks\\schemas\\maindoc\\UBL-PriorInformationNotice-2.3.xsd" 

Answer: See eforms-notice-editor/src/main/resources/application.yaml  -> line 24. 

  

  • Can you rethink the authorization model of eNotices2. We have one account and several functional operators that will be able to cancel notices, etc. In our country, we need to know which operator has for example cancelled a notice. We need traceability on that. 

Answer: If you are using the front-end UI of eNotices2, then you can create workgroups or structured organizations with different roles which not only allows you to monitor who does what, but also to restrict actions at the application level. These functions should not be used if you are an eSender and submit notices via the API. 

If you are an eSender, you need to implement these sort of controls on your side.  

  

  • We understand that lot results (winner chosen/not chosen, ongoing) for all lots in the procedure should be present in Result notice. In case a Modification notice follows for one lot/contract only, should the notice really include all lot results from the Result notice linked?  

Answer: No, a Result notice does not have to include lot results for all the lots in the procedure. The contract modification notice will only be accepted for one parent (result) notice and modifications on only one signed contract.  

  

  • Is there an API exposed to download the submitted XML? 

Answer: No, there is not. 

  

  • Does BT-105 Procedure Type has any effect to other fields? This is only data or it has effect to other fields (and which fields)? We have problems with its codes, we cannot pair all of our current procedure types, e.g. competition call. 

Answer: Procedure type is used in several rules. We don’t know how national procedures map to the procedures defined in the procurement directives, which is what eForms uses. 

  

  • Can you detail the replacement for ‘corr’ as it's planned to be deprecated sooner or later? 

Answer: Instead of ‘corr’ just use the same notice-type as the original notice that you are changing. 

  

  • In the process of publishing notices through TED API, does the published status mean that it is physically published and can be viewed on the web? If not, are you planning to add a status for this case? 

Answer: ‘Published’ status means that the notice is available in the OJS on TED. Internally, the status in eNotices2 is updated by getting a response from TED that it has published the notice (after 9:00 CET each working day). We will add status ‘publishing’ to the API. 

  

  • What is the difference between Change notice and Modification notice? 

Answer: A Change notice is used to make minor changes (such as correcting a spelling error) to a previous notice.  

A Modification notice (the full name is ‘Contract Modification Notice’) is used to make changes to previously published contracts. 

  

  • What is difference Organization and Beneficial owner. It’s not very clear from the documentation in developer's doc when we need to add Beneficial owner. 

Answer: Ultimate Beneficial Owner is an optional organisation role. Given recent court cases, it should only be used if the buyer is sure that they can collect and publish this personal data. 

  

  • Will you publish XPath parsed from EFX? 

Answer: No we won't publish XPath parsed from EFX. The EFX translates partly to XPath expressions, but these are embedded in for-next loops and references.   

  

  • What is the function is the ‘OPT-090 Buyer categories’ with only one code? Can we tailor it? 

Answer: This technical field has been introduced to provide the semantic that the XML is not able to provide by itself. This may not be tailored. 

The field must be used in conjunction with BT-111, for example: 

<cac:SubsequentProcessTenderRequirement> <!-- opt-090 --> <cbc:Name>buyer-categories</cbc:Name> <!-- BT-111 --> <cbc:Description languageID="ENG">Offices of the "greater region" ...</cbc:Description> <cbc:Description languageID="FRA">Bureaux de la "Grande région" ...</cbc:Description> </cac:SubsequentProcessTenderRequirement> 

  

  • Is there a testing platform where it is possible to test the creation and publication of eForms? 

Answer: Please see the  Preview and FAQ pages in the Developer Docs. 

  

  • The field BT-67 (Exclusion Grounds) is a text field in the Regulation. In eNotices2 environment there is a codelist available. Please, clarify and provide us with the list of possible choices. 

Answer: The codelist is available in exclusion-ground. 

 

  • Is there a dedicated TED API endpoint for retrieving a notice's status? What is the common solution for this issue? 

Answer: You can try out the get / search in Preview – swagger on preview page.  

  

  • EFX JS parser - I understand, that it is possible to evaluate the whole xml with xpath (via schematron or using EFX toolkit to generate evaluator), but I would like to evaluate the asserts linked to fields (defined in fields.json) as soon as user fills in some data to given field on the front end (in JS).  

Answer: Can you please contact us via TED Helpdesk? 

 

  • We need to send tailored eForms documents to the new German eSender node. For this we have to enter a notice dispatch date. If the new national node then sends to the TED API one or more days later (e.g. due to technical problems), does this lead to a problem? 

Answer: The notice will be rejected if the notice takes more than 24 hours from dispatch to reception by OP. This time gap should be kept to a minimum and technical issues will need to be resolved quickly. If OP allow too much time gap, then we have less time to publish within 5 calendar days. 

  

  •  Group of lots - the question is what do they represent for the business? I cannot make a conscious choice on if I want to hide it unless I know what it means, and this is not clear at all. 

Answer: Groups of lots represent business opportunities where tenderers can provide their services with common criteria. For example, a group of lots to produce office furniture could contain several lots for several specific objects (chairs, desks, etc.). There are common constraints in the group, such as common award criteria, and a common value which could be less than the value of the individual lots contained within.  

Even if a group of lots can simplify some of the constraints related to the individual lots, and tenders can be submitted for it, it cannot be awarded as an entity. Contracts must be signed for all the lots separately even if the buyer takes advantage of the conditions presented in the group. 

  

  • If the national tailoring means that the resulting eForms (in this example eForms DE) is no longer a pure subset of eForms (i.e. no longer 100% compatible), then this eForm will not be accepted by methods of the TED API or the VIEWER-APIs. Is this statement correct? 

Answer: Only notices that follow the eForms specs (SDK) can be submitted and viewed. National tailoring should be a subset of eForms - or the data must be mapped between national and EU values to be able to publish on TED. 

  

  • Where is the documentation listed and when a particular minor/major version of SDK is getting deprecated?  

Answer: OP will see the best ways to announce deprecation. CVS will also have a range function so applications can also query this. 

  

  • What is BT-741 and BT-741 in BR-BT-13713-0101 Received Tenders (BT-146) value must not be smaller than the sum of Received Tenders Inadmissible (BT-741) values and Received Tenders Unverified (BT-742) values? They are not in fields.json and also not in the documentation. 

Answer: Can you please contact us via TED Helpdesk? 

 

  • Can we use deprecated SDK versions for some more time till we migrate to supported SDK versions in future? 

Answer: Deprecated SDK versions will no longer be valid for submission or validation in Production. We will keep them available in Preview for testing. 

  

  • In a contract modification - can one publish the modification of one lot? Or do all lots from the contract notice also have to be in the contract modification notice? 

Answer: Contract modification notices can only be accepted if it refers to one signed contract in one contract award notice. 

  

  • Is there an API to get the notice data in XML format? 

Answer: No, there isn’t. 

  

  • Can XML Data Converter provide a full solution for TED schema - eForms schema 1 to 1 mapping without errors? 

Answer: No, this is not possible. The eForms specification includes much more information than is included in the TED schema specification. Also, some items of information are defined as text in the TED schema, but defined as codes or indicators in the eForms schema. Thus the converter cannot accurately provide this information. Some of this information may be required in eForms, either as a Mandatory rule, or a Conditional Mandatory rule. 

The XML Data Converter can only assist with the conversion of some information; there will always be some information that will have to be added manually by the eSender.  
 

  • In Eforms XSD, multiple UBLExtension are allowed, possibly containing multiple (and possibly multiple different values) subNoticeType. I thought that a notice should have a unique value for subNoticeType. How do we know the NoticeType ? 

Answer: Extensions are allowed at different places of the XML, and the set of elements in the extensions is shared; however for a given context, only some elements of the extensions are allowed and rules are there to check that; Notice subtype is also allowed only once. 

  

  • Is the dynamic schematron validation working with a change notice refering to an old "non-eform" notice 

Answer: No, if you're changing something that was, e.g. in 1.0 xml, we will not be comparing the information. 

 

  • Is there any information about the date of a following regulation amendment? 

Answer: No date yet. 

  

  • Why is there so many ways to link notices with other notices?  

Answer: Those are eForms annex BTs we are implementing. 
 
 

  • When sending modifications to a file, the file with the modifications must be generated with the same SDK? What happens if this SDK gets deprecated early? A prior information notice consists of parts (PAR-0001, PAR-0002, …) when creating the contract notice, we want to link it to the PIN. Do we have to use these identifiers of the original PIN to reference these? Or is a link to the notice id enough? 

Answer: The same SDK can be used if it is still valid, otherwise, you simply use a new version of the SDK. You will link to previous planning with BT-125. You don't have to link explicitly to the parts that became lots. 

  

  • The form-type ‘change’ and notice-type ’corr’ will be deprecated no later than June. Does it mean that we don't need to implement anything about these in the new version, as we go live in October? 

Answer: It depends which SDK you go live with. If it is SDK 1.5, you will need to implement them. If you go live with 1.6 (or higher), there are no rules that force you to use them. 

  

  • Is there any documentation on rate limiting policy on using eforms APIs 

Answer: There is no definition yet. 

  

  • Which function/who in the Member States are expected to provide feedback on the translations? 

Answer: The best would be to address the appropriate services at the level of DG GROW.  

  

  • When publishing a separate CAN for each Lot, is it expected to have the previous LotResult’s in the notice result section? Is information on closed lots expected as well? 

Answer:  For the moment, you need to insert all the lot results for any lot that is in the CAN. It means that if you provide a CAN with only 1 lot, you can provide a result only for that lot, but if your CAN contains several lots, then all of them must be referenced in the lot results. 

 
 

  • Follow up on previous CAN question, when publishing 38/39/40 is it enough to only include the changed Lot and contract in the notice result. 

Answer: Ideally, only the references to the lot which is related to the modified contract. 

 

  • Is it expected that the same identifier numbers (lot, res, con, ten, org, tpo) are used across multiple publications for the same sections? Or can I have my buyer org be ORG-0001, ORG-1234 etc interchangeably (edited) 

Answer: No, we don’t keep the technical identifiers. For dynamic validation checks, we will use ‘internal identifiers' and other user identified fields. 

  

  • There is no reference to the currency BTs (OPA-...) in Form subtype 16 (16.json). How is currency encoded in eForms? 

Answer: Not every single XML leaf has an associated field defined. Every field of type amount is composed of a figure and a currency (e.g. <cbc:ValueAmount currencyID="EUR">5000</cbc:ValueAmount>) 

 OPA fields are not used in the xml generation. What we currently do in TEDEN2 is have the front end send a pair “number/unitCode” and hardcode that the unitCode is inserted in the CurrencyID while the value is inserted in the xml element. 

A similar process is in place for codes/listNames;  Duration/UnitCode; TextML fields/LanguageID. 

 

  • Do you already have the date when status PUBLISHING will be introduced in the preview environment and TED API? 

Answer: No, when we do, the Preview page will be updated. 
  

  • Is it possible to publish a modification notice via eNotices2 for an old non-eForms contract notice. If yes, how to link these notices? Can I use the old contract notice OJS-Number in the field "previous notice ID" in the modificatioon notice? 

Answer: It’s not possible yet. We are looking into options for converting the old notice into eForms format and then allow to continue the procedure into a contract modification notice 

  

  • Is the process of publishing working correctly in preview env, in the current moment all notices from the previous week are still in status SUBMITTED 

Answer: This is reported in the known issues of the preview page; we are working to fix this. 

 

  • For exclusion and selection criteria: Buyers will select the one that requires the least amount of filling in or choosing. Hence they would choose ‘see procurement documents' whenever possible. 

Answer: This is true – it is up to MS or eSenders to force users if they want richer data in the notices. 

 

  • The use of a contract award notice with no winner to cancel a lot or a procedure is prone to misuse if we do not have a specific provision for cancelled by the CA: after a competition with no winner the CA can use non competitive procedures so stopped by buyer would be better 

Answer: CAN with no winner is already the current TED-XML solution for how to close/end/cancel lots or procedures. The buyer can also choose to change the CN to say what happened. 

 

  • What does ‘stopping by buyer’ mean? How could the buyer access the eNotices platform and which notices will the buyer see when the buyer publishes their notices and they are not registered as eSender on eNotices2?  

Answer: The eNotices2 API allows to stop notices before they are published. eSenders can make this function available to buyers or integrate it in their systems somehow. No need to access eNotices2 UI to stop a notice. 

 

  • What is the purpose of eForm subtype? Does each subtype have a different validation rules? 

Answer: In eForms, there's five form types, e.g. planning, competition. There's the notice type which could be, e.g. Contract notice — general directive, standard regime. There’s the notice subtype which are the numbers, e.g. 16, 17, 18. Each subtype allows to decouple the ruleset from the procedure legal basis (BT-01-Notice). It means that a subtype 1 can have legal basis different from Directive 24 and still be governed by the ruleset that is specific to Pin Profile Directive 24. Notices received from Member States should always have the default value in BT-01-Notice, but other users may want to change that. 

 

Published: 13 June 2023

MyPortal
Language Selector
English
BasketSummary
Help
Menu Display
Minutes - TED eSender workshop Q1 2024

 

 

Minutes of the TED eSender workshop (20 March 2024) 

 

These are the consolidated questions and answers, i.e. replies to questions posted live during the webinar have been reviewed and may have been regrouped or modified for this written version to allow for a more cohesive and complete response. 

Please note that some answers may no longer be accurate, as the Publications Office (OP) has followed up on comments made and may have modified its approach accordingly. 

The live sessions were recorded and are available in the agenda section along with the PowerPoint slides of each presentation. 

 

Questions from the participants: 

Lifespan and Release of SDK Versions 

  • Where can I find information on the lifespan of SDK versions?  

Answer: Please consult the list of active SDK versions on the TED Developer Docs. The TED API provides this information by switch date, and it should always be consulted as the single source of truth. 

  • When do you plan to release SDK version 1.11?  

Answer: SDK version 1.11 was released on 23 April 2024 and activated in Preview and Production of eNotices2 on 14 and 15 May respectively; see the release note at GitHub eForms-SDK/releases/tag/1.11.0. Patches to SDK 1.7 to 1.10 were released on 2 May – see GitHub eForms-SDK/discussions/930. SDK 1.6 has not been patched, as its standard lifespan has ended but it can still be used to submit notices until the end of July 2024, as explained in docs.ted.europa.eu/eforms-common/active-versions/index.html. 

  • Why do some versions of SDK have a greater lifespan than others?  

Answer: The standard lifespan of an SDK version is 12 months from its release date. However, the expiration date of an SDK version can be extended beyond this standard lifespan. Exceptionally for 2024, to meet the requirements of eSenders during the ongoing transition phase, the Publications Office has chosen to prolong the lifespan of the SDK versions that are due to expire in 2024. As such, the lifespan of SDK versions 1.6 - 1.9 has been extended by approximately 4 months. 

  • Why is the lifespan extension of SDK 1.10 only 2 months?  

Answer: The amendment made in 2023 mandates its implementation by the end of February 2025. Consequently, all SDK versions released in 2024 would theoretically only be valid until that date. We’re also operating under the assumption that eSenders using the latest SDK versions will have sufficient time for upgrades. The goal is to eliminate the need for prolonged lifespans and return to a 12-month active period. 

  • When do you expect that pre-releases of SDK 1.13 will be available?   

Answer: We cannot promise to have SDK 1.13 ready before October. We will be able to share a release candidate before the final release, but this will only be a couple of weeks earlier, while we test it at OP. 

[Note: The March workshop presented three SDK releases in 2024.  This roadmap was changed in April and can be seen in https://docs.ted.europa.eu/eforms-common/roadmap/index.html/

What was originally planned as SDK releases 1.12 and 1.13 have been combined into a single SDK 1.12, including FSR and exclusion and selection criteria (but not IPI) and planned for June. 

The SDK release planned for October will be version 1.13, including IPI, EED and the six new voluntary forms. 

These minutes have been updated accordingly to refer to the new SDK version numbers (e.g. references to 1.14 refer to 1.13).]

 

Notice Submission and SDK compatibility 

  • If an SDK version is deprecated during the processing of a specific notice, is it feasible to submit the notice using the old SDK version while maintaining the same notice ID (BT-701) and introducing a new notice version ID (BT-757)?  

Answer: The management of the SDK version is handled individually for each notice at the time of submission (via CVS). For instance, if a notice is submitted on the final day of SDK 1.7, it would be necessary to halt the notice and re-submit it on the subsequent day, as the notice would then need to adhere to SDK 1.8 or higher. 

  • Can a notice, once submitted using an older SDK version, only be corrected in the new SDK version and not in the previous SDK version?  

Answer: A Change notice needs to be submitted using an active SDK version. When the SDK version of the notice to be changed is not active anymore, it is possible that additional information might be required compared to the original notice to comply with the version used for the change. 

  • Contract modifications have a changedNoticeIdentifier. If two modifications are made to the same CAN, should both references point to the original CAN notice or like a chain in change notices the second modification references the first CM?  

Answer: When modifications to two contracts of a same Result notice have to be published, then this may be done in a single notice, given that none of the two contracts have been modified in between. When the publication of the modifications have to appear at different moments in time, they must be done sequentially, and each must refer to the notice that just preceded it; the first modification should then refer to the original notice and the second modification notice should refer to the notice that contained the latest published information for the given contract.  See also eForms FAQ: What is the correct procedure when creating a Contract Modification Notice with multiple changes? 

 

New Forms and Regulation Amendments 

  • Will the new E1-E6 forms only come with SDK 1.13 in October or will parts of the new voluntary forms be made available earlier?  

Answer: All six new E1-E6 forms will be included in the same SDK 1.13 and will be made available in the Preview environment once SDK 1.13 is released which should occur in October. 

  • Did I understand correctly that in October 2024 there will be SDK 1.13 with the new regulation and by February 2025 it will be mandatory? Does that mean we only have 4 months to implement 1.13 including national adjustments?  

Answer: Legally, yes. The intention of the 2023 amendment is that all Member States must comply with it by the end of February 2025. In practice, this means that all eSenders must be on SDK 1.13 (only available by October) by then. The regulatory reason is that eSenders must be able to handle the legal reporting requirement so FSR, IPI, and EED. They may choose not to implement the new voluntary E1-E6 forms and still be able to comply with SDK 1.13. OP expects some extension of SDK lifespans will be needed to reach full compliance, but we recommend you already plan your upgrade to SDK 1.13. 

  • Regarding the new regulations 2022/1031 (IMPI); Regulation 2022/2560 (foreign grants); Directive 2023/1791 (energy efficiency), we wanted to know when they will be available and in which SDK. Which SDK version will be aligned with the latest Commission Implementing Regulation (EU) 2023/2884?  

Answer: In 2024, there will be at least two SDK releases to satisfy the changes and deadlines required by the December 2023 amendment to the eForms implementing regulation. SDK release 1.12 will include the technical changes for business entities, the additional fields for FSR (Foreign Subsidies Regulation), the changes to exclusion grounds and selection grounds (as foreseen in the December 2023 amendment to the eForms regulation), as well as some incremental updates and improvements. The following SDK release 1.13 is a very significant release including the additional fields for IPI (International Procurement Instrument) and for EED (Energy Efficiency Directive) and the six new voluntary forms E1 to E6. SDK 1.13 should be released no later than the end of October 2024. 

  • In which SDK version will the fields associated with the eForms regulation amendment be included? Which SDK version will incorporate these new fields?  

Answer: Some fields will be included in SDK 1.12, , while the remaining fields will be incorporated in SDK 1.13. 

 

Documentation and Support 

  • Where can we find the documentation for Business Entities?  

Answer: It will be released in the TED Developer Docs when SDK 1.12.0 is released. 

  • Will the use of the new business entities become mandatory in the future? If yes, when? In that case, we need to adapt our applications. Do you have sample code?  

Answer: There is no sample code yet. We will provide documentation as needed in the developer guide. Some information in SDK (idSchemes for example) is meant to be replaced by the information provided by business entities. However, we will not remove it from SDK 1; it will only be removed from SDK 2 onwards. 

  • What is the best way to easily compare the differences in SDK rules, particularly between versions 1.7, 1.8, 1.9 vis-a-vis v.1.10? Given that v.1.10 introduces a significant change by splitting off the rules, is there a comprehensive guide available for this? It seems that a simple extract does not encompass all the rules. Is there something more complete in this regard?  

Answer: The SDK Explorer currently allows comparing fields.json and Schematron rules. We don’t yet have other tools to compare rule changes. It could be possible to compare changes in the CSV downloads of rules. eSenders are encouraged to contribute to the SDK Explorer code. 

  • Will there be a possibility to download a delta of what changed between versions from the explorer so we could scan the changes automatically e.g., via a script?  

Answer: This is not something we have considered, so please create an issue in the SDK Explorer repository where this can be discussed. The main thing we need to “invent” to achieve this, is what will be the format of the “diff” (the delta) so that it can be automatically processed. If developers want to work on this, we can help them implement and integrate it into the SDK Explorer. 

  • Do fields.json include all the rules that apply to fields?  

Answer: Currently there are approximately 30 rules that exist solely in Schematron. We will aim to incorporate these rules into fields.json with SDK 1.13. Additionally, we will also add a flag to indicate whether a rule is intended for front-end live-validation or exclusively for Schematron. 

  • What strategies are in place for dynamic rules, such as verifying content across multiple notices? It seems the dynamic rules folder in the SDK is still under development, and it is unclear which checks have been implemented.  

Answer: The only dynamic rule currently in effect is the one that compares the dispatch date against the current date. 

  • What is the most effective way to stay updated on new SDK releases?  

Answer: All release notes are published on the GitHub release page at GitHub eForms-SDK/releases. Users can watch this page and receive automatic updates for every new SDK release. 

  • Certain fields, like OPT or OPP, are not included in the relevant eForms Commission Implementing Regulation. Their descriptions are not detailed enough, leading to potential misunderstandings. Would it not be better to incorporate these fields into the “Extended Annex to the Regulation“ table?   

Answer: The fields beginning with OPT or OPP have been created to support specific structures in the XML, or to fulfil specific technical requirements. They are not related to the business requirements of eForms, and so it is not appropriate to include them in the Annex of the Regulation. Please see https://docs.ted.europa.eu/eforms/latest/fields/index.html#_fields_other_than_bt for more details. Description labels for OPP and OPT fields were added in SDK 1.11 (and backported). 

  • Where should we ask questions about eForms? As an example, if I do not understand an EFX expression from the docs or ANTLR definitions. 

Answer: EFX-related questions are technical questions, so, please ask on our GitHub developer forum at https://github.com/OP-TED/eForms-SDK/discussions. 

  • We've been looking into implementing EFX to execute directly on the visual model inside our frontend but found the development burden too heavy to justify the costs right now. Are there any plans to have an EFX interpreter made for JavaScript/ typescript?  

Answer: We also considered this for eNotices2. However, we are currently trying to improve the existing solution which runs on the eNotices2 backend. Although we would like to work on a JS/TS interpreter, or an EFX Toolkit for JS/TS it is not realistic for us to put this in our current plans due to other constraints. We are open to collaborative ideas if there are several eSenders that want to contribute to such an implementation. If that were the case, then it would be more feasible for us to make some resources available for working with you to achieve this. 

  • The support for eSenders unfortunately doesn't work well. The response times are much too long.  

Answer: The TED helpdesk has been very busy supporting users of eNotices2 web interface and the new TED website, so you might not have received a reply as quickly as we would have liked. If you have technical questions about the SDK, you can reach the Publications Office teams (and other eSenders) via GitHub discussions https://github.com/OP-TED/eForms-SDK/discussions. If you have an urgent operation issue, you can include [email protected] in copy of your email to the TED helpdesk.  

  • Why are maintenances to (and potential downtimes of) the TED production environment only announced the day before? It would be nice to know this at least a few days in advance. 

Answer: We aim to announce downtime in Production at least 2 days before and to limit the unavailability to 7:00 to 9:00 CET. Unfortunately, we needed some short-notice deployments that didn’t respect this approach.  

  

Validation rules 

  • Will the same limitations that apply to change notices (e.g. absence of a tree structure in references) also be enforced for contract modifications (subtypes 38/39)? 

Answer: We have not yet implemented any dynamic rules for Contract modifications. While some limitations will resemble those of Change notices, they will not be the same.  

  • How do you validate the Schematron rules you add? The past releases have added a flurry of new rules which have not always been compliant with national laws or have been impossible to satisfy without sending incorrect data. Has the process been improved, or can we expect more of the same?  

Answer: Many of the rules were provided by the European Commission during the definition of eForms. Most of the rules were not applied when eForms became available in November 2022 and they have been added progressively from SDK 1.8 until SDK 1.11. As eForms started to be used, we see there is a lot of variety at national level.  

After SDK 1.11, new rules should be mainly related to the new fields and forms, as well as incremental improvements or corrections. A better process could happen via the European Commission eForms group on GitLab at https://code.europa.eu/eproc/eforms. This will help Member States discuss future changes transparently; it will also provide guides for new fields, e.g. for FSR and IPI, which would provide the background for any rules later expressed via the SDK.  

  • Are you experiencing quality issues on the already submitted eForms, and that's the main reason why rules are more or less "loose”?  

Answer: Yes, for example, SDK 1.7 has fewer rules, and we see some notices are missing information, e.g. for winners. So, more rules in SDK 1.8+ do help data quality. 

  • Where can we find the “SDK 2 complex rules”? 

Answer: They are not available yet. We will have a pre-release of SDK 2 when we are ready to share the complex rules. 

 

Other 

  • In TED schema and in the free text fields, HTML formatting tags were supported for both HTML and PDF visualisation. However, in eForms, while HTML tags are supported for visualisation, they are not supported for PDF visualisation. Are there any plans to reintroduce this feature in pdf visualisation? It could greatly enhance the readability of large text blocks.  

Answer: Concerning HTML visualisation, there has been a change compared to the legacy TED XML. The eForms schema, which uses UBL, does not permit mixed content in text fields. Therefore, you should avoid inserting HTML tags or any formatting in your notices because they will be shown as plain text in PDFs. Currently, we do not intend to incorporate processing instructions to enable some formatting, as this could introduce an additional complication for all systems.  

  • During the Czech eForms implementation, we prepared a complete translation in accordance with Czech legislation. Can you include our translation into the next SDK versions?  

Answer: We will be in touch with the Czech authorities to improve Czech translations. A small number of labels use machine translations until we get human ones, but we are also aware that many terms are not aligned with national transpositions and practices.  

  • On March 1 2024, "expectedPublicationDate" field in the "search-esentool" operation was included in the Production environment. This caused errors on our platform, and we had to carry out an intervention between hours. Are these types of changes being communicated to the eSenders in some way? 

Answer: Once a new application version goes into Preview, we update the Preview page with any news, such as fixed or known issues, new features etc., as is the case for ExpectedPublicationDate. Please consult the preview page.   

Any breaking changes are communicated separately. For SDK releases, you can use the "watch" repository feature of GitHub to receive notifications.  

“expectedPublicationDate” was not added as a new required request parameter; it was added as a new attribute in the object returned in the response.   

We consider it a breaking change to:  

  1. remove an endpoint;  

  2. add a new required request parameter;  

  3. remove or change the type of a request parameter or response attribute.  

As this was not a breaking change, it should not have affected your implementation.  

  • TED e-mail notifications inform about notice publication earlier than it really occurs. This is confusing for our users. We suggest improving TED notification content such as procedure name, the date the notice was sent to TED etc.  

Answer: An email notification is now sent with the “Expected publication date”, shortly after submission – perhaps this is what you are noticing. A separate email is sent when the notice is published in the OJ S on TED. We do intend to improve the content of email notifications in general. As of application version 1.14.0, the eSender’s email address is also included in copy of the automated notifications regarding the various statuses of notices. As part of the improvement, the Publication notification email now includes a link to the published notice on TED.  

  • Is there any plan to improve the publication cycle e.g. publish on weekends or publish notices received on Friday before Monday?  

Answer: There are no plans to change the Monday to Friday OJ S publication dates. You might be interested in the new TED website option to download the OJS release calendar as CSV, XLS or PDF at https://ted.europa.eu/en/release-calendar.  

  • For an award notice with several beneficiaries for the same lot, is it necessary to specify a leader? This is not always effective.  

Answer: It is only necessary to identify the leader when there is more than one economic operator tendering together; it is not related to the number of winning tenders for a given lot.  

  • Can a CN notice refer to a previous planning notice which has only been published nationally, i.e. the unique id provided is not found on TED?  

Answer: This is not possible; references to previous notices can only be to those published to TED. You could refer to national sources in an additional information field. 

  • What is your philosophy for handling different SDK version? Convert all to latest SDK version?  

Answer: We will only have a maximum of 2 different major versions of the SDK active in parallel. So, SDK 1, in parallel with SDK 2 until everyone has moved to SDK 2. Minor SDK versions are not “different versions” they are just incremental updates to the current version.   

In eNotices2, we convert old continued procedures to the latest version, as soon as they are imported from TED or device.  

  • The eSender section in eForms is optional at the moment; do you plan to remove it from the user interface?  

Answer: We will not remove the eSender service provider section; it is linked to the organisations, it is where eSenders identify themselves and is also contained in the XML of the notice.  

  • In the case of a contract that is an exception from the scope of the Directives, should we use BT-01 field with the value “Other”? If this is not the recommended approach, could you suggest which field should be used instead? 

Answer: Much depends on the context in this case. It is possible to use “Other” legal basis, but you must adhere to the rules of each form, which are derived from each directive. The upcoming voluntary forms will offer more flexibility, with fewer rules in place.  

  • Is there a place where I can find an overview of all eForms-related forums/events, e.g. TED eSender, TED reuser, TED eNotice2 users, etc.? 

Answer: If you keep your Profile in the Developer Portal (Production or Preview) updated, we will let you know of eSender workshops; you can also keep up with https://op.europa.eu/en/web/ted-eforms/. 

We announce eNotices2 webinars through the application itself. We email participants of past events when we publish Questions & Answers. Links to the video recordings of eNotices2 webinars are made available on the eNotices2 help page.  

In general, the easiest way to keep up with upcoming events is the “What’s New” section available through the homepage of the new TED website.  

 

-

Last update: 13 June 2024

OSZAR »