Annual TED eSenders Seminar

Seminar organised by the Publications Office of the European Union

Online/Luxembourg, 8 to 10 November 2021

 

The annual TED eSenders Seminar took place online over three half-days from 8 to 10 November 2021.

These are the revised minutes; i.e. replies to questions posed 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.

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

 

8 November 2021 – Day 1: Current status and overview

 

Welcome and introduction – Antonio CARNEIRO & Maria Manuela CRUZ - Publications Office of the European Union

Mr CARNEIRO mentioned that the focus of OP’s TED Unit has been for the past two years putting eForms in place and invited participants to share concerns and tips.

 

Current status of eSentool and data quality – Karl Ferrand - Publications Office of the European Union

Mr FERRAND gave an overview of the evolution of eSentool in 2021, including past releases and upcoming release 2.13, as well as the new versions of the TED XML package to go live on 30 November 2021. Attendees were given an outline of the TED schema and rule changes for November 2021 along with data quality figures, which included eSenders requests to TED Helpdesk and statistics on most common quality issues and errors in notices received. He went on to introduce the new monthly reporting feature on errors and warnings in last 12 months (to be sent per email every month to eSenders). He concluded with outlining other issues, such as the need for eSentool users to upgrade to TLS 1.2+ protocols by 30 November 2021, the issue of mixing languages in a notice and a reminder to eSenders to inform their users of changes.

 

The following questions were addressed:

• Will the simulation environment have the same transitional period as the production environment?

Answer: On 30 November 2021, all three endpoints of the eSentool will start allowing notices with the new XML schema version R2.0.9.S05. At the same time, XSLT package version 0.40 will also be applied to all three endpoints (Qualification, Simulation and Production). There will be a transition period of two months, from 30 November 2021 to 31 January 2022, during which eSenders will be able to test their systems in Simulation and Qualification with both the new XML schema version R2.0.9.S05 and the new validation rules XSLT package 0.40. For more details, please visit our Workspace announcement: https://webgate.ec.europa.eu/fpfis/wikis/x/9IDDN

• When will the monthly reporting E-Mail first be sent out? In order to receive the report is it enough to be registered as an eSender? How is it possible for non-eSenders to receive the report on errors and warnings?

Answer: The monthly reporting will be sent as of end of November to the eSenders main email address as registered in the eSentool. The purpose of the reporting is to   warn eSenders so that they can take appropriate measures. Non-eSenders will need to contact their eSender concerned. The OP also reminded of the importance of protection of personal data and that eSenders should ask their clients to avoid disclosing personal data in notices and to use instead general or operational contact data.

• How can we manage notices from countries or regions that have more than one language?

Answer: You will need to publish two parallel notices and provide all the information in each language. We have updated the relevant section in the Workspace: https://webgate.ec.europa.eu/fpfis/wikis/x/2IAcJ

 

General overview of eForms – Maria Manuela CRUZ - Publications Office of the European Union

Ms CRUZ emphasised that eForms is a major development and should be seen as a common endeavour. The OP tries to address all concerns which eSenders are invited to share, together with any issues and suggestions they may have on best practices. Ms CRUZ gave an overview of the eForms implementation. She presented the legal timeline for the adoption of eForms noting that as of 14 November 2022 the OP must be able to receive, process and publish eForms AND current standard forms and that as of 25 October 2023 use of eForms becomes mandatory. Ms CRUZ presented diagrams of the eForms implementation components and status as well as the implementation roadmap.

The following questions were addressed:

• We can read in the eForms regulation that it shall apply from 14 November 2022. We understand that eForms must be available on a voluntary basis as from November 2022 and will be mandatory in October 2023.  Can a Member State (MS) only propose eForms from October 2023 or will MS have to offer them from November 14, 2022?

Answer: As far as the OP is concerned, we will need to be ready on 14 November 2022 to handle the submission, validation and publication of eForms notices. Member States should know that as of 25 October 2023, the OP will no longer accept notices that are not eForms. eSenders can start submitting eForms at any time between these two dates.

• Will there be a migration of the notices to eForms?

Answer: There will be no migration of existing notices (using the current TED schemas) to eForms. Whatever is published in the current schema will remain in that format. As of November 2022, TED users will be able to visualise and download both the current and the eForms notices in their respective formats and schemas. eForms notices will be displayed via a new viewer, TED Viewer 2022, whereas the current standard forms notices will continue to be displayed with the current TED Viewer.

• After having got release 0.4.0 of eForms Software Development Kit, is there also a roadmap (release plan) for future eForms SDK?

Answer: The eForms SDK is a huge development and we are trying to make information available as fast as possible. An indicative roadmap and further information on the subject can be found in presentation “Developing eForms applications” of Day 2.

• Will there be a test system for eNotices2?

Answer: This is currently under discussion; the idea is that at some point we will be able to share a testing environment with you and we would appreciate your feedback in testing the application.

• Would you allow to have published a mix of schemas for the same procedure e.g. a Contract Notice using current TED schema and then later send the Contract Award Notice using eForms? Would you combine them into one publication flow?

Answer: In principle, that is the idea. If you start a procedure with a contract notice based on current forms, and in the meantime, you have implemented eForms in your system, you will be able to send a notice in eForms format linked to the preceding TED format notice by referencing its notice ID. However, a TED format notice cannot follow a notice in eForms format.

We are discussing creating a converter, so a published notice in TED format can be converted to a partial eForms notice. "Partial" because eForms notices contain much more information that TED notices. The "partial" eForms notice will have to be completed and checked in the eSenders’ systems.

• How do we make a correction (F14) to a notice published on current schema, after transitioning to eForms?

Answer: In the same way that it will be possible to link current form notices to eForms for procedures that started with the current form schema and ended with eForms. Regarding the F14, there is no longer a specific form for corrections such as the current F14. The Change Notice business group will instead work as a separate section that will be attached to any notice, to indicate that this notice corrects, changes, or otherwise modifies a "parent" notice with the use of BG-9 and in particular BT-140 Change Reason Code.

• Will all documentation be either updated (e.g. eForms BT to schema mapping via XPath) or released (e.g. documentation on business rules used in validation) in a timely manner and is there a roadmap for the release of these documents?

Answer: Our colleagues in DG GROW have mapped the current forms to eForms and we are extending the exercise to a technical mapping. As soon as this is available, it will be shared with you.

 

eForms developments and implementation in Member States – Carmen Ciciriello – DG GROW

Ms CICIRIELLO presented an overview of the change requests (for future updates of the implementing regulation) received by Member States in the areas of:

• Clean Vehicles Directive​
• Innovative Procurement​
• Green Procurement​
• Estimated value in FA​
• Variants​
• Name of Jury​
• Errors​

She went on to outline the developments in the Member States presenting statistics on the intention of using eForms (Yes-No-Unknown) for the publication of:

• below threshold contracts
• contract award notices for individual contracts within a framework agreement
• minor notices modifications​
• information on all bids received​
• voluntary notices

as well as statistics on:

• using individual contract award notices in framework agreements – National Guidelines
• implementing ESPD request into eForms
• tailoring codelists

Ms CICIRIELLO concluded with the tailoring policy timelines (from Q3-2021 to Q3-2023) and the technical implementation timelines (from Q4-2021 to Q1-2023) as declared by Member States to the Commission.

 

The following questions were addressed:

• EForms BT-774 (Green Procurement) codelist definitely needs working. Would it be possible to have the codelist fixed before going live with eForms (earliest in the end of 2022)?

Answer: We agree that it needs working, however, that depends on the suggested changes, which we have not received from Member States. We have received challenges and concerns – and colleagues in DG GROW unit C2 (Public Procurement) are looking into this. In order to include any change in the next eForms update, we would need proposals as soon as possible in the next 3-4 weeks. There is an agreement on the fact that eForms are the reporting tool for public procurement, however, codelists for green procurement are not sufficient now in terms of clarity to satisfy the requirements and needs in Member States to cover Green Procurement.

• Do you have same information somewhere available per every Member State?

Answer: We do not publish information on individual Member States to the public. Member States are currently reviewing the decisions; we can only publish aggregated data. Member States (i.e. their representatives) have their own country page in the eProcurement Wiki through which they can access data.

• Is there a plan for systematically collecting and communicating the results of the tailoring work of all MSs to e-tendering platform providers/eForms implementers?

Answer: Decisions are still ongoing in Member States, and we can only disclose aggregated data. When results are completed, we will summarise the information in a report of the eForms subgroup, but this is internal to the members of the European Commission Expert group on eProcurement (EXEP).

• Is there a best practise somewhere on how a MS should / could present the results of their tailoring, e.g. changes to fields and added rules for conditional mandatory fields etc.?

Answer: There are Member States that have made this decision already; in the EXEP eForms subgroup meeting we can further discuss this.

• How many MSs were included in the survey shown in the previous presentation?

Answer: More than 20 Member States replied, for the last two slides the actual number of Member States is given. When a MS did not have a specific timeline, i.e. the answer was “unknown”, we could not include their timeline. Regarding technical implementation, about 17 MSs could tell us when they could start.

• Are the data in GitHub more reliable and up to date with respect to that in the regulation? Should we take them into consideration when discussing and proposing solutions?

Answer: DG GROW have used a GitHub instance as a tool to gather questions and discuss issues related to the consultation process and from a policy/ legal perspective leading up to the 2019 eForms implementing regulation. But it is no longer used, and we will announce that it will be closed. Components relevant to the technical implementation of the eForms regulation – Software Development Kit (SDK) – are available through OP’s TED GitHub instance.

• Are you able to share which Member States were included in the survey?

Answer: Most of them were included; however, information on individual states cannot be provided.

• You mentioned some national pages where Member States are reporting their tailoring results, is it public information? Is the list of similar pages documented somewhere?

Answer: The Expert Group on eProcurement (EXEP) has their own Wiki managed by DG GROW and MS representatives have access, where they upload and update information on the country developments. We have created a specific section on eForms where MSs are updating the data, but this is not publicly available information. Country pages are only available in Wiki to MS representatives.

• Is there a list of MS representatives of the national eForms sections?

Answer: This is personal data; we cannot share contact names or addresses.

Ms Cruz invited participants to share information - should they wish so - on best practices and solutions to eForms-related issues. Day 1 concluded with participants answering some sli.do questions, the results of which were shared live.

 

 

9 November 2021 – Day 2: Technical

 

Ms CRUZ welcomed the guests, presented the agenda for the day and opened the floor for participants to answer some sli.do questions, the results of which were shared live.

 

Developing eForms applications – Ioannis Rousochatzakis - Publications Office of the European Union

Mr ROUSOCHATZAKIS described the short-, mid- and long-term goals the OP is working on in parallel. A more detailed presentation of the eForms Software Development Kit (SDK) was given, along with the goals it is intended to achieve. Mr ROUSOCHATZAKIS went on to describe the purpose of eForms metadata, giving examples of important information that cannot be found in the schemas and described the metadata packaged in the SDK and which can be directly used to drive the eSenders’ applications. He then presented individually the SDK contents together with their respective use, i.e. XML Schema Definitions - Notice Type Definitions - Field metadata – Authority Tables (Codelists) - Validation rules - Translations – Examples ​(of notices and validation reports).

Mr ROUSOCHATZAKIS introduced participants to the SDK semantic versioning (major.minor.patch), current SDK version 0.4.1 and the foreseen releases and evolution. He also explained the notion of “backward compatibility” of the SDK versioning with examples of “breaking changes” as well as the possibility of parallel SDK versions and what this will mean in practice for eSenders, eSenders’ applications, TED Viewer 2022 and eNotices2. He concluded with a presentation of the TED API and an explanation of the API keys.

The eForms Software Development Kit is available at: https://github.com/OP-TED/eForms-SDK

TED developer documentation for eForms is available at:  https://docs.ted.europa.eu

 

The following questions were addressed:

• What is the role of notice definition in JSON notation, while other notice artefacts are in XML notation?

Answer: JSON is just a format that is more flexible and shorter than XML, which requires different kind of parsing. JSON was the format of choice, as it is simpler to read and maintain.

• I couldn’t find the notice-types and codelists in the SDK on GitHub.

Answer: The notice types and codelists will come with next SDK version 0.5.0; we are currently working on them.

• Will all technical and tailored codelists be included in SDK 0.5.0?

Answer: With every new SDK release, we include everything we have at that point in time.

• There are lists missing e.g.  BT-712 (review-type) and BT-715 (green-procurement). We have requested them and several more, but they are still not in the SDK. When will all lists be included in the SDK?

Answer: We are currently working on the missing codelists. As soon as something is available, we release it with every new SDK version.

• Is it possible to set fixed, reliable SDK release dates?

Answer: The idea of the SDK is not to be bound by specific release dates.

• What is the release date for version 1.0.0 of the SDK?

Answer: There is currently no set release date for version 1.0.0 of the SDK. For this, all components of the SDK would need to be in place and complete, along with stable file formats and all metadata in the way we need them to be available for November 2022. Having all features in place is not foreseen before the summer of 2022.

• Should applications connect directly to the SDK to read the forms definitions?

Answer: Yes, you should foresee a mechanism that retrieves data from GitHub and uses it in a way and structure that is convenient for you. An example of this is what we do in eNotices2, which has its own repository, i.e. the SDK is published in GitHub, eNotices2 picks up the data and parses them putting everything in its own repository and then behaves based on the data that is on the SDK.

• Is the SDK compatible with .NET?

Answer: .NET can read JSON and XML; there should be no compatibility issue.

• Who receives and decides on suggestions for improvements to translations of Business Terms in SDK?

Answer: For the moment, the translations we included in the SDK are automatic, using the Commission’s machine translation service, until all labels in English have been finalised. The idea of sharing the translations with you will have the benefit of allowing us to receive suggestions and corrections from you. Through the SDK and GitHub we will be able to integrate your suggestions for specific fixes in specific labels.

• Is there a way to contribute to the translations? At least some Finnish translations need a lot of work: for example, they do not comply with WCAG reading level requirements.

Answer: Internally, we have all Business Terms translations in a database. The translation files are generated/ exported by the database; the idea is to import into the database fixes and improvements you may suggest and merge them back into our own system for future versions of the SDK. For the time being, translations are machine-based and were provided as a way to help. We will go through the formal way of making sure translations are accurate. Member States can of course contribute to their accuracy.

• Can we submit country-based labels to the SDK?

Answer: No, as we are not managing country-based information in our application or the SDK. In TED, we must use language that is commonly understood at an EU level. The labels that are contained in the eForms metadata are Procurement labels.

• Are validation errors translated into EU languages?

Answer: Yes, validation messages will be properly translated. Currently, validation messages in the Schematron files are available only in English.

• Can we use custom labels or is the use of the provided translations mandatory?

Answer: For TED we must use the standard translations in order to ensure a uniform level of understanding; the labels will be used in the same way for notices coming from every country. At MS level, and in your applications, you should be – in principle – able to use custom labels. The SDK can be used to facilitate tailoring in this respect and from a technical point of view.

• How will you ensure an easy processing of updating translations?

Answer: From an OP perspective, Business Terms and their translations will be fairly stable. From your perspective, you have the possibility to read the translations through the SDK whenever you need a label.

• In relation to TED API, users want to see a preview before sending a notice and expect it to look exactly like the later notice on TED. Currently this is more or less possible with the HTML and PDF previews in the API. What preview solution do you provide with eForms TED API?

Answer: TED Viewer 2022 is going to be available through the API in order to visualise the notice. It will be possible to preview a notice before sending it for publication.

• Will there be change in authentication method for the new eForms and if so, what authentication method will be used for the API?

Answer: For the new systems, we will be using API Keys, which is - as a mechanism - very close to what we have today in eSentool. Instead, however, of basic authentication with a username and password, a secret API key will be sent to you in another HTTP Header; this API key will verify your identity and through it, you will be able to connect to various services, i.e. submitting/ validating/ visualising notices.

• Are there any limitations for using TED API Validation Service?

Answer: The Central Validation Service (CVS) will be available to you the same way as for eNotices2. There should be no limitations in your fully using the CVS through the TED API. However, there will be some throttling to prevent that possible abuse of the system would degrade the experience for users. Therefore, there will be some limits to make sure the system works well for everyone, but the exact limitations will be communicated at a later stage.

• Will you provide any reference implementations in different programming languages?

Answer: Our main goal and top priority for now is to have version 1.0.0 of the SDK with all its contents and fixed file formats by summer of 2022. After that, we may be able to look at reference implementations, e.g. the possibility of sharing with you the code (or parts of the code) we are writing for eNotices2.

• Will there be documentation regarding the mapping of Business Terms on the legislative side to the corresponding fields in the schema/UBL? The current documentation is from May 2020 and therefore hopelessly outdated.

Answer: Much of it is the same as in 2020. In the SDK there is a fields.json file that contains every field which indicates the BT to which it relates. Version 1 of the mapping between XPath and BT, which was provided via SIMAP in May 2020, has now been superseded and integrated into the field metadata of the SDK.

• Since the codelists are bound to SDK version, is there a risk SDK version lifetime can end up very limited? For example, a change to NUTS codelist the Commission wants to enforce could end up invalidating all previous versions for no other reason. The NUTS is just the trigger to invalidate old version. The breaking changes might be completely unrelated.

Answer: Versions of the SDK might be short-lived due to various reasons; however, multiple versions of the SDK can be used at the same time provided they are still acceptable. We will aim to avoid breaking changes, but stopping support for an SDK will often come for legal reasons and will be given enough transition time. Having a metadata-driven approach to this should enable you to make the technical transition with little to no effort. In theory, a metadata-driven approach could render any changes directly consumable by your application without human intervention. 

• We tailor codelists for juridical and policy reason, so changes on codelists have functional impact on our application. Policy officers should judge codelist changes. Moreover, we also feel the need for a stable SDK as changes will surely impact our application.

Answer: The point of the SDK is that we should be able to adapt to any change with minimum effort.  We also want it stable, but changes are bound to happen. The goal is to minimise the effort.

• Are the data in eForms SDK more reliable than the one in the EU Regulation on eForms, in order for us to properly implement them on our local platform?

Answer: The SDK contains our implementation of the regulation. We interpret and process the data from the regulation and put it in the SDK making it also available to you. If our implementation disagrees with the regulation, then that would mean that there is a bug in the SDK that we need to fix. The SDK also provides a level of detail that is not provided by the regulation, for example, some Business Terms listed in the regulation may be expressed by more than one field in the eForms schema.

• Do you intend to keep the format of the JSON stable?

Answer: We intend to improve it and we are open to suggestions. However, our goal is to keep it stable and avoid breaking changes.

• As eSender, we have many users connected. In the new eForms implementation, will it be possible to map our users to more users in the eForms SDK? Like one-to-one mapping? Or, as we do now, we need to "proxy" our users in only one user in eForms?

Answer: The SDK is a development tool, a set of resources for developers to properly set up their application and a way for us to provide updates; it is not an application or an information system. It is eNotices2 that will replace the eSentool, so the question is rather about the mapping between the users who fill in notices and the users of eNotices2.

• Using the SDK, can we populate the data in TED forms and can the SDK publish these forms to TED?

Answer: The SDK is for your developers to create the application and the same application should automatically reflect any changes in the metadata contained within any future releases, but you would still need to use your application to fill in the forms and send the data to eNotices2 through the TED API.

• If we were to use the SDK, would there be the need to customise for the national adoptions?  

Answer: Yes, you would need to customise it, override some of the rules and apply your own modifications instead, i.e. consume the data from the SDK and apply on top your own modifications.

• Member States are able to decide that, for example, fields are mandatory at national level, which are optional in the eForms-SDK. This results in individual Member State SDKs that extend eForms-SDK. I would like to know your opinion about this topic.

Answer: The idea would be that you would have the file delivered through the SDK and you would have a similar definition of what the same field looks like for you. In this case, you would have your own definition locally that describes the field as mandatory. Your application should read the customisation/ tailoring you have applied locally and give precedence to your own definition.

• Who will actually supply the national customisations; will it be EU or the individual countries?

Answer: Customisations are to be done at national level.  We are obligated to publish in TED what comes out of the EU directives and the implementing regulation. We understand that there may be different national implementations, but our responsibility lies with what is standardised at EU level.

• As regards the EU vocabularies, for example procurement procedure- type, we have more national procedures, how can we handle it?

Answer: If there are further national procedures, they will have to be dealt with at national level, where the Member States have implemented the directives and national implementation may therefore vary from country to country. We put together a framework for publication at European level only.

• Doesn't the codelist foresee two generic choices for national procedures?

Answer: There is no customisation foreseen for procurement procedures. If an unknown procedure code is used, we will not be able to validate the content of the XML and the notice will be rejected.

• So, if one country requires one field and another country requires another field, each eSender/developer will have to interact with all 27 countries to accumulate all these requirements?

Answer: If an eSender has clients in different Member States, it is for the eSender to accommodate the national particularities. At Commission level, we make available eNotices2 that cover optional and mandatory fields exactly as foreseen in the EU regulation. Centralising requirements from different Member States is out of the scope of the Publications Office at implementation level.

• What about interoperability, if nobody takes care of harmonization of the national standards?

Answer: eForms is what is harmonised and enables some interoperability. Some countries will use eForms directly as is and it is up to each country to decide whether they want to add or change some things.

 

eForms schema – Yves Jordan - Publications Office of the European Union

Mr JORDAN described the foundation of eForms schemas:

• UBL based: eForms XSDs based on the latest version of the OASIS standard (v. 2.3 – 06/2021)​
• Principles: use elements from UBL as much as possible and add extensions if specific to eForms  
• Information scope: Elements – Context and Purpose
• eForms extensions: Elements – Context and Purpose

He continued with what is new in terms of:

• Organization: Organization – Ultimate Beneficiary Owner – Role/ Subrole
• Result: (Notice Result) Lot Result – Lot Tender – Settled Contract
• “unpublish” fields: Field ID code – Reason (for delaying publication) – Publication Date (including time zone)
• IDs & references (used across the xml)
• Changes: Change Notice – Changes (e.g Section(s) ID(s)​, short description) – Main reason for change
• Documentation: Online at https://docs.ted.europa.eu ​

Mr JORDAN concluded with what is foreseen, including Winner “un-publication” and adjustments for other forms outside eForms (T01, T2, CEI, EEIG, ECS) and as additional rules may apply.

 

The following questions were addressed:

• Will it be allowed/possible to send an award notice per lot separately, e.g. one contract notice with 5 lots and 5 award notices, each referencing the contract notice?

Answer: This would be feasible. In a Contract Award Notice, we should expect the presence of all lots that have not yet been awarded. If we have 5 lots in this Contract Notice and wish to publish Contract Award Notices separately for different lots, we would expect for the first published CAN the presence of the 5 lots, i.e. the lot that was awarded and the others pending decision. For the second CAN we would have 4 lots, i.e. the lot that was awarded and the ones pending decision, etc. It is a matter of choice of the Contracting Authority if they wish to slice the publication of a notice this way, depending also on the time of awarding decisions, but deadlines should be respected after the award decision has been made.

• Will eForms be implementing any OCDS standards, i.e. the use of OCID for contracting processes?

Answer: OCDS is a standard for distributing procurement notices and using a public standard schema. As it is an alternative schema to UBL, it is not possible to mix the two. In terms of the actual content of the notices and XML, we will not be using OCDS standards. However, within a number of the objects, e.g. the Contract, as well as the Internal Identifier, there is an opportunity for you to use your own choice of Identifier and in those cases, you may decide to use the OCID format.

• Does the “unpublish” flag mean that information will nowhere be published? Even when publishing notice as XML-file via TED interface to public? How will then empty field contents be presented in this case?

Answer: The purpose of the “unpublish” fields is that they do not get published before the deadline is reached. TED will display the reason why the fields will not be published.

• What do the variables CEI, T01, T02, X01, X02 represent? Will there be new ones in the future?

Answer: These are forms that currently exist and that will have to follow the same way of marking information, so we are also using UBL to mark these notices. T01, T02 are DG MOVE forms (transport regulation 1370/2007), X01 and X02 refer to forms for European economic interest grouping (EEIG) and European company (EC)/European cooperative society (ECS) and CEI is for the Call for Expression of Interest of the EU institutions.

• Suppose we will have a procedure finalised with a framework agreement. When sending Contract Award Notices with subsequent contracts, should it contain all the previous contracts or only the new ones?

Answer: Framework agreements are collected and published over a given period, i.e. per quarter.

 

eForms validation – Bertrand Lorentz - Publications Office of the European Union

Mr LORENTZ introduced the topic of validation of eForms notices and how it relates to UBL, noting that UBL schemas are very permissive as opposed to the eForms regulation, its requirements and restrictions. He went on to present the Central Validation Service (CVS) for eForms notices - which will be available for eSenders via TED API (REST API)​ - what it validates and gave examples of the returned validation report in Schematron Validation Report Language (SVRL). He presented in detail all the rules currently in place in the order they apply and how the OP manages them through the SDK.

Mr LORENTZ concluded with what is foreseen in terms of refining/ complementing existing rules and adding new ones, and translating the rule messages in 24 languages.

 

The following questions were addressed:

• Can the validation report be customised so that the SVRL contains error messages in another language?

Answer: Yes, you will be able to decide in which of the 24 languages you would like to receive your messages.

• How can we identify the index of lot where the error occurred?

Answer: The XPath of the validation report will pinpoint where the error is located in the notice; examples provided during the presentation are available in the presentation file.

• Will it be possible to get the rule sets related to the technical background of the validation system?

Answer: We are still in the process of putting together the rules. All information we have, we make available through the SDK.

• Are these rules documented in a more” human readable” form? Can you provide a data model for eForms domain - something like an "entity -relationship diagram"?

Answer: Some of those rules are in the documentation, e.g. which field must use which codelist. We currently do not have an exhaustive human-readable documentation or an entity-relationship diagram, but we may consider in the future exporting validation rules from our database as AsciiDoc. For the time being, all information is communicated through the SDK, but ideas for documenting rules are welcome.

• Will there be a complete list of the error messages available?

Answer: Yes, we will publish all labels as translations, so you will have one file per language with all possible messages that can be returned by those rules, with identifiers and their corresponding message.

Day 2 concluded with participants answering some sli.do questions, the results of which were shared live.

 

 

10 November 2021 – Day 3: User Interfaces

 

Ms CRUZ welcomed the guests, presented the agenda for the day and opened the floor for participants to answer some sli.do questions, the results of which were shared live.

 

eNotices2 overview – Enrico Campanella - Publications Office of the European Union

Mr CAMPANELLA presented the front-office features of eNotices2, demonstrating the following:

• Creating and editing notices​
• Acting on My Notices​ page
• Submitting notices​
• Continuing Procedures​
• Creating Change Notices

He went on to give an overview of the form-filling tool with regards to:

• Organisations and Roles including role assignment and planned improvements
• Procedure and Lot(s), groups of lots, and future improvements
• Result Section and its contents and planned improvements

Mr CAMPANELLA continued to present some back-office features of eNotices2 and concluded with the eSender features foreseen for Q2 2022, such as:

• Submitting and searching notices through Web Services​
• Retrieving the validation report​
• Stopping Publication​
• Access to front-office eNotices2 ​
• No qualification required

 

The following questions were addressed:

• Does "No Qualification required" mean that eSenders go productive with eForms without a previous qualification?

Answer: Yes, any user can be a Web Services user as long as they have an API key.

• Could you describe the workflow of eNotices2?

Answer: The basic workflow is that once the notice is ready on your application, your application will connect to eNotices2 using your API key. After your ID has been confirmed, the notice will be submitted to eNotices2, which will send it internally for validation to TED CVS (Central Validation Service) and you will then receive an SVRL reply. Valid notices will go into a queue, to be subsequently transferred to TED Monitor before being sent to the TED website, where they will finally be published. 

• Did you use a framework for creating the form-filling tool?

Answer: It is an Angular-based application on client side and Spring on the server side. We have an in-house framework that is used for Commission websites called EUI (https://eui.ecdevops.eu/) and we also use Agile and some other tools that our service provider has at their disposal.

• Will the software you are developing be available as open source?

Answer: Our intention is to share with you the source code of eNotices2, either partially or fully, as eNotices2 is a fairly big application. It is not possible to give a definitive answer yet as to how and when this will happen.

• Will a Sandbox still be provided for testing the Web Services?

Answer: There is going to be a training environment at a certain point. We plan to offer the possibility for you to go through all the steps from submission to publication, but this will probably be done incrementally in the beginning, gradually adding steps to the environment.

• Will there be a test system where we can test our development?

Answer: We are preparing a copy of the application we are developing with the intention of sharing it with you in Q2 2022.

• Will everyone with an API key be an eSender?

Answer: To send notices, you will need to authenticate through TED API to get an API key and create an eNotices2 account with your EU login.

• Will the term eSender still exist? Actually, everyone who creates an API key is an eSender.

Answer: The term eSender has been used for years and we will probably continue using it.  From an IT perspective, it does not make a big difference what terminology we will use to refer to API key users.

• For new "eSenders" will there still be eSender classes (A, B, C, D)?

Answer: It is not planned at the moment.

• Will eNotices2 be available in all EU languages?

Answer: Yes, in all 24 languages.

• Can we send parts of the notice via Web Services and fill in the rest via eNotices2?

Answer: You would need to choose either Web Services or eNotices2. A notice has a unique identifier; you will be able to work on a notice in the front office, but you will have to export it before you send it through Web Services.

• Will eNotices2 send email notification for notices submitted by Web Services about publications or non-publication?

Answer: This is currently under discussion. There is going to be an extensive notification system within eNotices2 and once this is in place, we may consider continuing with email notifications.

• From 14 November 2022, can we consider that every EU public buyer will be able to create their eForms in eNotices2 (if they want)? Will it propose all the fields (mandatory and optional)?

Answer: This is the point of eNotices2: it will provide all mandatory and optional fields and it will have rules to determine which fields are mandatory under certain conditions. There will also be a feature for users to make some of the optional fields mandatory. In the same way, it is also foreseen that if an optional field is not relevant for some users, the administrator of the organisation can “hide” these optional fields from view should they wish so.

• How will eNotices 2 handle national tailoring?

Answer: We will not be implementing any national tailoring. A field that is optional for eForms can be set as mandatory in the user application, but the other way around is not possible. We do not plan to implement fields that any national authority may want to add to the eForms field.

• Will eNotices2 handle national tailoring where optional fields are made forbidden to use?

Answer: A field that is optional in eForms can be set to mandatory in the user application or can be hidden. We will not forbid the use of fields, as eNotices2 is not tailored for Member States separately. The organisation administrator or person in charge will have the possibility to hide them, meaning that users filling in the forms will not be able to see them.

• Currently an F14 may not be submitted until its previous notice is published. Will there be a change with eForms?

Answer: With eForms there will be a Change Notice, which is basically a reproduction of its parent notice with an extra section to advertise changes to the procurement and procurement documents and for correction of clerical errors. In case of many clerical errors, the “void” code cancels the notice itself, but not the procedure. The user can - in this case - republish the same notice. We will not accept Change Notices for notices that are not yet published (i.e. when the parent notice has not been published) to avoid the possibility that different users may act on the same notice at the same time. To cancel the procedure, we would expect a Contract Award Notice with no winner; there is no limit to the award notices that can be sent. After the procedure is cancelled, you can send another CAN when you have the correct information. So, if a notice is already published, then you have a Change Notice and if the parent notice has not been published, you can stop publication and re-edit.

• Will publication be immediate, or will it require 5 days anyway?

Answer: If the user chooses the option to publish “as soon as possible” upon submitting the notice or if the Application_Date element is not available in the XML, the notice will be published in the next available edition of the OJS.

• Is there a possibility to set separate submit date and opening date on Groups of lots?

Answer: This is not foreseen, but it is possible per lot.

• Is it possible to award more than one lot with the same eForm?

Answer: Yes.

 

eForms visualisation – Karl Ferrand - Publications Office of the European Union

Mr FERRAND mentioned the challenges involved in displaying eForms in a way that is coherent, user-friendly and allows for the expansion of eForms. He continued with an overview of TED Viewer 2022 as a common module for external and internal systems at Publications Office, and which is foreseen to be ready by Q2 2022. The principles applied to visualise eForms notices define a single structure for all types of eForms notices, organise and number (sub)sections and adapt BT names in a way that is meaningful for the end reader. Mr FERRAND went on to present the eForms information structure per section to demonstrate subsections and content:

1. BUYER
2. PROCEDURE
3. PART​: for notices where notice type is ‘Prior information notice' or ‘Periodic indicative notice used only for information’​
4. GROUP OF LOTS​
5. LOTS​
6. RESULTS​
7. MODIFICATION: only used for notices where the form type is ‘Contract modification’​
8. ORGANISATION​S
9. CHANGE: only used for notices where the notice type is ‘Change notice’
10. NOTICE INFORMATION​

He concluded the presentation with “Not immediately published” data​: for information that cannot be published yet, a section will list “non-public information”​ and will display the justification for not publishing and the date the information will be available​.

 

The following questions were addressed:

• Will TED Viewer 2022 be able to render 10 years from now forms built with SDK 1.0.0?

Answer: Yes, because this is how long we display them.

• Can you explain the Group of lots?

Answer: At the level of Competition, you may have some lots that you feel can be grouped together under a specific set of tendering terms and allow companies to submit their offers for the group. This is also related to the maximum awarded lots and the quantity of lots the buyer wishes to award to the same company. At the level of the Result, the group of lots is just a concept, meaning that the award should only be per lot, even if the lots form part of a group of lots.

• The result is only per lot?  We have winners for more than one lot, and they sign only one contract with the authority for all the lots.

Answer: eForms regulation states that each lot has its own result; for each lot there will be one contract signed and one winner among the tenderers and all the non-winning tenders should also be mentioned. It is still going to be possible to award all the lots in the same notice, but only one by one. 

• Is grouping of lots optional? Even if two lots can be grouped, is it still optional for a buyer to do so?

Answer: Yes, it is optional and simply a question of ease of use, as some buyers might find it easier to group lots together for a particular reason.

• What is the connection of group of lots to awarded lots, if any?

Answer: The award is done by lot, but if a lot is part of a group, there will be a link in the “lots included” and “Group of lots”.

• What section will have the CPV codes?

Answer: Section 5. LOT

• Can the PDF/HTML format be obtained by querying the Web Services?

Answer: Yes, but we have to see how we deploy it.

• Is there "the one" document that explains the functional meaning of fields, as there are some new sections and fields compared to the current forms?

Answer: Currently, no, but there is some explanation of the fields in the Schema documentation at https://docs.ted.europa.eu.

• Will you provide an XSLT stylesheet for rendering as part of eForms SDK?

Answer: This is not foreseen for now.

• Will the viewer be able to generate a PDF/HTML from an XML file even before the XML has been submitted for publication, as it is possible through the API today?

Answer: Yes.

• Do you plan to include the extended notices in your visualisation (like below-threshold notices: E2, E3 and E4)?

Answer: Yes, at a later stage and only after we have eForms as of October 2023.

• How will eForms be visualised if they are published in multiple languages?

Answer: You will need to specify the language when calling the TED Viewer.

• Can we use TED-API for visualisation in our system? SLA?

Answer: We intend to make TED Viewer available to call by API, but we have not yet defined the level of service we can provide.

• Is it mandatory to use this display format at the national level or we can still use the current graphical format of the standard forms?

Answer: There is no obligation to use this layout, you can display as you wish.

 

eForms in TED and the future TED 2.0 – Cécilia Charlier - Publications Office of the European Union

Ms CHARLIER presented a timeline for the adaptation of the current TED website to eForms and the development of TED 2.0, the latter starting in Q4 2021. She gave more details about the ongoing adaptation of the current TED website to eForms and the functionalities available to TED users. Among others, changes are foreseen in the advanced and expert search, the browse by subject function and the page on contracts awarded by EU Institutions​. A new TED Notice Viewer 2022 API will provide operations to render eForms notices in various formats. Ms CHARLIER went on to present the advantages and the interface of the new TED 2.0 website, which will merge the TED and SIMAP websites into a single point of reference. The new TED 2.0 should be available as of March 2023.

 

The following questions were addressed:

• Will systems importing eNotices from TED have to be able to import eForms and standard forms starting 14.11.2022?

Answer: By November 2022, if there are notices sent to TED in eForms format, and if you wish to import the notices, you will need to consider possible ways for you to be able to import both the current forms and eForms. At this stage, we cannot be of assistance. In eNotices2 there will be a converter for the needs of Change Notice, so eNotices2 will always see the converted eForms XML, but its development is currently only under discussion.

• What search engine will TED be using?

Answer: Elasticsearch.

• Will there be some API available, which we can use to transform/convert TED XML to eForms?

Answer: This is still in design. The converter we are discussing will take a TED XML and convert it to a partial eForms XML. “Partial” because eForms notices contain much more information than TED notices. If we are going to expose the converter to you, it will be through the TED API as a call service, however, a full conversion will not be possible. More details cannot be shared at this stage.

• Will it be possible for an eSender to configure (disable) at national level the TED email reminders sent automatically to CAs?

Answer: We will have to see with the production team if this is to be considered in the future.

• For us who are designing the user interface for eForms form editor, is it correct that we will have access to see the eNotices2 application for inspiration in Q2 2022?

Answer: The application is still at a very early stage, but we could discuss giving you access to the frontend of the application by then.

Ms CRUZ concluded the webinar by thanking all participants and speakers for their participation and contribution and reminded that the Publications Office strives for solutions that will enable and facilitate solutions for eSenders. She also reminded participants that there is a lot of information already available in the eForms SDK and the TED Developer Docs site and that the OP is always available in case of questions/ concerns/ suggestions through the TED Helpdesk.

 

The 2021 TED eSenders webinar ended with participants answering some sli.do- and post-event survey questions.

 

 

Slido poll results