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. 

 

  • Is there a more updated document that relates the old fields (TED Xpath) with the new fields of the eForms physical model (eForms Xpath)? I think that the last one is ‘Initial mapping of current TED-XML schema to eForms (13/04/2022)’ – https://simap.ted.europa.eu/en_GB/web/simap/eforms 

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
TED Events Series Header

TED eSender workshops

Menu Display
Minutes - TED eSender annual seminar

 

 

Minutes of the TED eSender annual seminar (13 December 2023) 

 

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: 

  • Could you share the percentage of the notices rejected due to lawfulness check? What is the average delay time until a notice is published? 

Answer: To date (13.12.2023) 25 notices have been accepted and 1 was rejected, because a buyer from an EU member State used eNotices2 to submit a CEI form, which is reserved for EU institutions. So far, all lawfulness checks have been processed daily with little or no delay to publish. 

 

  • Recently we encountered a new Notice Status: ARCHIVED. Is there any further documentation on how to deal with this status? Which Use Cases are allowed in this status (change notice etc.)?

Answer: The "Archived" status is used by eNotices2 web User Interface (UI) to declutter the users’ list of procedures and notices and, therefore, should be of no use to eSenders who should be using exclusively the API. More information on the Archived status can be found on the Help page. 

 

  • Which status will the change notice have, if the original notice was ARCHIVED (will the change notices also be ARCHIVED)? Is there any other way how a notice can get into status besides setting it manually via eNotices2 (is there any automation)?  

Answer: There is no automation for this, it is a manual operation by eNotices2 web UI users. This status can only be queried via the API. Please refer to the answer to the previous question. 

 

  • Could you please provide an example of an Archived status. How to treat it? Does it mean always Published or not guaranteed? 

Answer: All procedures/notice groups can be archived by front-end web UI users only. The status “archived” can be queried via API and is displayed on queried notices (that have been manually archived by front-end users). A front-end user can archive a procedure that has notices in it in all possible statuses, e.g., draft, published etc. eSenders should refrain from performing manual actions in the UI.   

 

  • What is a reasonable waiting time for a notice to be published before assuming that something is wrong? We have been polling notices (for publication or rejection) for 14 days, not sure if we're covered or if we should poll for some more time. If more time is needed, what's the recommended time lapse?

Answer: It all depends on whether you have chosen a Preferred publication date that might be beyond the 14 days that you poll.  If you generally publish as soon as possible, you should get a Published status (or Not Published) within 5 days as per TED’s obligation. Once the Expected publication date is made available (as of 28 February 2024 and eNotices2 application version 1.13.2), you can use that to poll until that date. 

 

  • When will the fixes for version 1.10 also be applied to version 1.7, and what is the lead time? 

Answer: Applying changes to older SDK versions is a time consuming and delicate process, as we need to ensure they do not create a negative impact or introduce inconsistencies. There are some minor issues in 1.10.0 (missing translations) so, primarily, we would first want to correct those issues before applying those corrections to older SDK versions, thus avoiding having to go through the process twice. With the holidays coming up, there might be a longer delay than usual, probably in January. 

 

  • What are the possible consequences of displaying notices compiled with SDK version 1.7 using the 'View templates' found in SDK version 1.10? 

Answer: The Viewer application detects the version of the SDK declared in the notice and uses the appropriate View templates. If you use the View templates in your own applications, we recommend using the same version of View templates as declared in each of your notices. Otherwise, it is possible that some items would not display properly. In the specific example you give, of using View templates in SDK version 1.10 to display notices created using SDK version 1.7, the award criteria, procurement document languages and framework values might not be displayed properly. In addition to this always use the latest patch of the same SDK that was used to create the notice. This is because improvements in the view templates to older SDK versions take place via patch versions, e.g., SDK version 1.7.2 has significant improvements over version 1.7.1 and 1.7.0. 

 

  • Are you considering the possibility of allowing and displaying minimal text wrapping options (line breaks, lists etc.) in fields with hundreds or thousands of characters? The current run-on text complicates content monitoring and ultimately the work of the economic operators. 

Answer: Unfortunately, this possibility is not envisaged and although technically possible, it would be very complex to implement potentially leading to negative side-effects on the processing of notices. The UBL schema on which eForms was based does not allow any formatting in text fields. 

 

  • Would you consider the possibility that the visualization endpoint could be switched by a parameter to display negative or unfilled values? 

Answer: With SDK version 1.11, we modified the display to represent some negative and empty values. These changes will subsequently be applied to earlier SDK versions. However, it’s important to note that this won’t apply to all negative or unfilled values. There are no plans to offer a parameter with different views of the same notice. 

 

  • What is the expected end date of SDK version 1.7? Is there a table for the end of validity of each SDK version? 

Answer: Please refer to the relevant page in the TED Developer Docs:  SDK Active versions :: TED Developer Documentation (europa.eu) . Regarding active versions of the SDK, you should always consult the information provided by the TED API version range as the single source of truth.

 

  • Do you know when the SDK version 2.0 will be made available?

  • When will the SDK version 2.0 be made available? It was supposed to be published by June 2023 and it's now mid-December. Is there a definitive release date? 

Answer: SDK version 2.0 should be available towards the end of 2024 or early 2025. Please also consult the SDK roadmap at https://docs.ted.europa.eu/eforms-common/roadmap/index.html.

 

  • Can you explain why http://www is a requirement for BT-505 and BT-508? Can this field not just begin with www. instead? 

Answer: The reason is that a URL must start with the protocol scheme (http:// or https://, etc.) for it to be valid. There is no requirement to also include www (e.g. https://ted.europa.eu is valid). 

 

  • In case of countries out of the European Economic Area, the country codes (e.g., US) were accepted in NUTS-code fields (e.g., BT-507). This seems to have changed due to CVS validation. However, the submit API still accepts them. What’s the reason for this difference? 

Answer: This situation shouldn’t occur as both the API and UI follow the same rules. A potential reason could be that the checking is done by CVS, which might explain why the submission API doesn’t halt the notice. Please note that there is no NUTS code for countries outside the EU or EEA and as such they will not be reintroduced; in fact the UK will be dropped in NUTS 2024. 

 

  • Several county codes have been removed from the NUTS-code list (e.g., US). Is it foreseen to reinclude them in the list? 

Answer: Please refer to the previous question. NUTS don’t exist for countries outside EU or EEA. They will not be reintroduced, but rules are adapted. If the country is not supposed to have a NUTS, then one is not expected to be filled in. Please note that the UK will be dropped in NUTS 2024 (planned for SDK v.1.11). 

 

  • The current display only refers to the GMT time zones as +01:00 or +02:00. Is there an option to include the standard GMT notation in the display or to issue some sort of legally binding announcement on the TED website regarding this matter? 

Answer: The W3C XML Schema standard only allows time zone offsets in date/time elements and therefore cannot change. It’s tricky to go from an offset to a time zone name like “CET” because of daylight savings, but we could see if we can have something in the display to refer to GMT, CET etc. 

 

  • Would it be possible for the HTML and PDF versions displayed by the visualization endpoint to include the BT identifiers? Or at least include an option added as a parameter to the endpoint, so this feature can be turned on? 

Answer: Unfortunately, this is currently not under consideration. 

 

  • Given the importance and oftentimes urgency (when it involves deadlines) of the problems we encounter and which we try to communicate with you, could you provide a platform where eSenders could expect prompter responses to questions like these?  

Answer: Helpdesk receives currently many requests, which may explain any delays. Notwithstanding, we are doing our very best to respond as fast as we can with regards to business or operational issues. Please note that for technical issues about the SDK, you could always use GitHub. 

 

  • Is there a possibility that a future SDK version will be good enough to be supported for longer than just 1 year? 

  • Is it possible to have a stable and final version of SDK which will last for several years? Current practice modes require us to change the version every 2 months. Also, if it happens that we skip a version, we must check all changes to field rules, translations, and final texts, which makes the whole process unbearable.  

  • Is it possible to extend the life cycle of an SDK version so that it can be used for a period of 12 months or longer in national environments? Since the setup time is usually a minimum of 3 months, the life cycle time of an SDK version at TED should be at least 15 months (or even longer). 

Answer: While each SDK version introduces enhancements, there are business or legal considerations that typically prevent an SDK from being active for several years. You can read more about the standard and extended SDK lifespans at https://docs.ted.europa.eu/eforms-common/active-versions/index.html.

 

  • Should mandatory but 'pointless business terms' be re-enabled or removed from the legislation to avoid eSenders and buyers violating the law? 

Answer: The business meaning of these BT fields is enforced by the eForms schema (the structure of the XML), so there is no requirement to implement these Fields in the XML notices. In other words, by using eForms to publish the procurement notices, the law requiring these BTs to be used is being followed. 

 

Answer: We can confirm that submissions of (TED-XML) notices via the legacy eNotices application will be closed on 31 January 2024. 

 

  • Once a notice is cancelled, it is marked as ‘cancelled’ but remains visible. The doc says, "In case of many clerical errors, it will be possible to cancel a notice, which will cancel the notice itself and make it null and void, but this will not cancel the procedure." Will this be corrected, so that cancelled notices will be removed from TED? 

Answer: No, a notice that has been published in the OJS remains published permanently (online on TED for 10 years, then offline).  A notice that is cancelled will exist twice: in the form of the original notice, plus as a Change notice that says it’s cancelled. So, this is another reason why “cancel” Change reason is not a recommended option. To cancel (end) a procedure or lot, the buyer must publish a Result notice with no winner chosen.

 

  • IDs should be unique within the notice. What happens within a family of notices? Do you check if a LOT is awarded and afterwards announced as unsuccessful? 

Answer: We are planning to introduce some checks to ensure that the change notice and continued procedures are consistent. Those will be kept to a minimum (at least initially). 

 

  • The following is a country-specific issue – in Italy, public authority employees mainly fall in the 50–59-year-old bracket and generally have little IT skills. Don’t you think that eForms are too complex and in their compilation too much importance is given to tech rules rather than law?  

Answer: While we understand that eForms were not designed with the end user in mind, this is what the Member States accepted during consultations and should have made provision for. While many rules appear to be too technical, there are other rules that are trying to enforce the directives or simply make common sense. 

 

  • Where can one find the published changes about rules between the different SDK versions? 

Answer: These can be found in the release note, since each release summarizes the rule changes in each SDK, which can also be seen in more technical detail by comparing the SDK components. For further information please follow this link: https://github.com/OP-TED/eForms-SDK/releases. Since the seminar, OP has also released a first version of the eForms SDK Explorer, which you can use at https://docs.ted.europa.eu/eforms-sdk-explorer. 

 

  • Doesn’t API v.3 necessitate more details? 

Answer: New endpoint URLs will be added in TED API v3., however the current URLs will remain functional during the transition. As always, we will keep you informed in advance of any changes, and we will make sure to plan a reasonable transition time. 

 

  • Are there any plans to improve the integration between eForms and ESPD? Particularly because the current approach does not fully support the variety of possible ESPD versions and use cases. 

Answer: Yes, the December 2024 eForms amendment is a first step towards the harmonisation of codes (criteria) across eCertis, ESPD, and eForms. This will already enhance the connection between these three services. Over the course of 2024, we’ll explore ways to further enhance this integration. As a result, this could also influence future amendments to eForms.

 

  • What kind of subtype is E6? 

Answer: This is the contract modification notice for the 2009 Defence Directive which can also be used for national purposes. 

 

  • Is it still permissible to use the "above threshold" eForms notices or national eForms  (eForms xx) notices for below threshold tenders? since E1-E6 are voluntary? 

Answer: Yes, but it would not make sense anymore and should be discouraged.  From a data perspective this would not be a welcome move and provides ambiguity. In such notices, the buyer needs to encode manually so that it does not fall under the EU Directives. 

 

  • How is it possible that a NUTS code validation gives an error by the Validation API, but not by the Submit API? One example is the code "TEN-0001 - id with whitespace” is marked as an error by the Submit API, but not by the Validation API? Isn't the same validation applicable for both APIs? TED Support does not give a clear answer about APIs.  

Answer: This is because the business rules validation is done by the Validation API, while the Submission API checks also the parsing of XML. We are working to harmonize the two. In this respect, we have opened a discussion on GitHub, where we kindly ask for your feedback: https://github.com/OP-TED/eForms-SDK/discussions/779. The rules for leading and trailing whitespace in identifiers have since been implemented in SDK 1.11. 

 

  • Will the voluntary forms, especially E2, E3 and E4 support all legal bases (2014/23-24-25/EU + 2009/81/EG) and not just "other"? On the national level, it would make perfect sense for e.g., to publish a simplified CN within the legal framework of the standard directive. 

Answer: While we check this out with our colleagues, we kindly ask you to provide us with more information about where to use a simplified CN that fits the EU framework? 

 

  • When we have questions or problems with APIs we are instructed to write to TED support. Very often, the answer provided does not give a direct answer to the questions posed. Moreover, the answers are provided with a delay of days and weeks. We have no information about API lifecycle, developments, and releases. Why isn’t the whole process more transparent?  

Answer: There are two issues highlighted in this question. In reference to the transparency issue, the reality is that the lack of communication is not a question of lack of transparency, but in the absence of significant changes or developments for APIs, we don’t see the necessity for communication. Please rest assured that any future API changes or developments will be communicated before their release. The current version of the API will be supported in parallel with the new version during the transition period.  

The second issue deals with the response delay from TED support and we would like to stress that it is usually not the norm that questions take weeks to be answered. There can be questions that justify a longer response period such as those that involve legal aspects of eForms. Should you notice a delay in response please highlight this delay in the email subject and we will give it our immediate attention. 

 

  • Which SDK version will make Exclusion and Selection criteria optional? 

Answer: The order of implementation of the 2023 amendment is still in its planning phase. The aim is to primarily focus on the IPI and FSR first for them to be available by June and the rest will follow – no later than November 2024. The eForms amendment does foresee rendering these criteria optional in the future, and it will be the buyer who must indicate where to find the exclusion grounds and selection criteria. 

Update: the Exclusion and Selection criteria will be updated in line with the December 2023 eForms amendment with SDK 1.12 in June 2024, along with FSR but without IPI. For more details, please see the SDK roadmap at https://docs.ted.europa.eu/eforms-common/roadmap/index.html.

 

  • When can we expect to receive improved descriptions of fields/BT? 

Answer: The eForms amendment should be published by the end of this year and it is envisaged that BT descriptions in an SDK version should be updated progressively after. 

 

  • According to the legislation, there are numerous BT fields that are mandatory, but which have been identified as 'pointless business terms' in the documentation and are specifically missing from the SDK versions. This practically forces eSenders and buyers to violate the law. In your opinion, which solution is most feasible: Will you re-enable these BTs or will they be removed from the legislation?  

Answer: The business meaning of these BT fields is enforced by the eForms schema (the structure of the XML), so there is no requirement to implement these Fields in the notices XML. In other words, by using eForms to publish the procurement notices, the law requiring these BTs to be used is being followed.  

 

  • For the eInvoicing question [BT-743-Lot] it seems the only acceptable answer that does not generate an error is "Required". When we enter "Allowed/Not Allowed" we receive an error. eInvoicing is not mandatory in Ireland so can "Allowed/Not Allowed" be enabled as correct answers for this question? 

Answer: The rule for eInvoicing was removed in SDK 1.9 (please refer to https://github.com/OP-TED/eForms-SDK/releases/tag/1.9.0). Please contact the Helpdesk with this issue and include an example XML of a notice which generates this error. 

 

  • When an eSender sends a notice, eNotices2 sends an email informing the buyer of the status of the notice. Will these emails change their format to one which is more like those sent by the previous system?  

Answer: Yes, the plan is to improve the emails sent to buyers (the noticeAuthorEmail that eSenders put in their API submission). We will add the Expected Publication Date, which is the date calculated by our back-end system that corresponds to an OJS publication date that considers the daily export and any preferred publication date. 

Update: As of eNotices2 application version 1.14.0, deployed in Preview on 15 May and in the Production environment on 16 May, we have improved the automated notifications regarding the various statuses of notices so that the eSender’s email address is also included in copy of these emails. As part of the improvement, the Publication notification email will include a link to the published notice on TED. 

If you have not done so already, you are reminded that 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. 

 

  • Regarding BT-765-Lot & BT-766-Lot, is there a layman's explanation of what is meant by the terms used in the drop-down selections? The descriptions for the drop downs in BT-765-Lot are especially confusing for our users and we cannot provide any guidance ourselves because we fail to understand the context. 

  • BT-765 is causing us a bit of confusion about how to support our buyers in answering the question effectively, a clearer description would be very beneficial.

Answer: BT-765 and BT-766 relate to the Framework Agreement Code and to the Dynamic Purchasing System Code respectively. This is ongoing; we will soon initiate the process to clarify the codelists and their respective meanings to provide clearer explanations to facilitate the users’ understanding.

 

  • Are there any plans to set up a change management board which will include representatives of the eSender implementers? 

Answer: The are no plans for a change management board. At the level of the implementation of eForms by the EU Publications Office we communicate and consult through the eSender workshops and GitHub discussions. You may be interested in following policy discussions between the European Commission and Member States at https://code.europa.eu/eproc/eforms.

 

  • Which rules regulate that a form needs to be checked manually? 

Answer: The only manual check that is done on any received notice is for the so-called "lawfulness authorisation". These checks are done following the business rules described here: https://docs.ted.europa.eu/eforms/latest/reference/business-rules/index.html#_lawfulness. If the rules are triggered, a member of TED team will manually check the document and allow or reject it for publication. 

 

  • During the seminar it was mentioned that the new TED web site will be made available at the end of January 2024. Will the old URL be redirected to a new site? What will happen if we point to a notice using the old URL? 

Answer: The new TED website went live on 29 January at the same URL as before. Link: https://ted.europa.eu. The old URLs of editorial pages and notices are redirected to the new URLs. 

 

  • If an error is detected or reported in the eForms implementation of TED what is the stipulated time frame for it to be fixed? 

Answer: If you see any problems with the new TED website, please contact the helpdesk at: https://ted.europa.eu/en/contact.  If there is a technical issue with the SDK, you can raise it via GitHub. 

 

  • To which email address does "Developer Portal email" refer to?  

Answer: If this question refers to the alert about an expiring API key, the email address used for this is the same as that used for the EU login account (same as used for the TED Developer portal sign up). Other email addresses are the additional ones that the developer can add for notifications from OP such as about downtimes, events and other important information.

 

  • In the future would it be forbidden to use PIN for market consultation? 

Answer: No, but it would not make sense anymore and it should be discouraged. OP/CVS doesn’t have the means to check if a PMC is somehow smuggled into the text of a PIN notice. From a data perspective this would not be a welcome move and provides ambiguity. SMEs will not be able to search for PMC specifically (or will not be able to see it all). We (EC/OP/MS/eSenders) can only advertise and encourage the use of the new PMC once it becomes available as voluntary form E1 in SDK 1.13 in October.

 

  • When will the Directives be renewed? Are there any plans to start the work? (as it is likely to take several years). I think that all these sectoral regulations make the Procurement Directives more and more ‘out of sync’. 

Answer: The responsibility of deciding whether to renew the Directives will rest with the new Commission.

 

  • An SDK explorer question: It would be nice to filter by set of given BT fields. This way I could check which fields used in Finland have changed. 

Answer: We agree this would be useful and will try to put this into action. Additionally, we are hopeful for contributions from eSenders in the implementation of new features in the SDK Explorer.

 

  • Will this app allow you to compare rule changes? 

Answer: We acknowledge the requirement in the SDK Explorer and understand that it’s the most challenging aspect to address. At present, though we have plans to tackle this issue, we haven’t yet developed a concrete design on how to effectively navigate through more than 40 000 rules.

 

  • Once the problem with the trailing comma in the URL to the documents is solved, will it be also extended to notices already published or will it be limited solved to future notices only? When will it be solved?  

Answer: The issue with the comma in the URL in TED Viewer 2022 will be rectified for all notices, both those previously issued and those that will be issued in the future.

 

 

Suggestions from the participants:

 

  • We suggest that all the bugs discovered and/or features explained (eg. BT-70, BT-77, BT-736, BT-761, BT-76-Lot - these are missing from the rendering for forms 38-40 due to a bug. This will be fixed with the release of SDK 1.10, and the fix will then be applied to previous SDK versions. These BTs will then appear for your notice in TED.”) would be communicated transparently on the dedicated site (https://simap.ted.europa.eu/web/simap/known-issues-with-the-display-of-eforms-notices), so that buyers could be informed about why the information they clearly provide fails to appear in the published notices. This would relieve eSenders from doing all the explanation and promote transparency on your side. 

 

  • Why not make SDK explorer available online through a URL? This would avoid the need to run it locally.   Update: this is now available at https://docs.ted.europa.eu/eforms-sdk-explorer/.

 

  • In the organizations section, is it possible to move the eSender’s name and address away from organizations list when the notice is published in TED. Suppliers may contact the eSender instead of the contracting authority. eSenders info could also be included as a footnote in the published notice. 

 

  • I would like to see one Directive that applies to all fields and just 5 or 6 notices in eForms - this would be possible without changing eForms…. 

 

  • I think the selection criteria would have to stay as mandatory. They are important to suppliers - much more important than exclusion grounds. On another note, exclusion grounds are missing a question on sanctions (the Russia/Ukraine situation) 

 

 

Last update: 23 May 2024