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! 

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

• Production: https://developer.ted.europa.eu/home 

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