Annual TED eSenders Seminar
8-9 October 2019
minutes
Welcome and introduction – Antonio CARNEIRO
Mr CARNEIRO launched the seminar by welcoming the guests and gave special thanks to the Italian eSender for accepting to do a presentation to show their challenges and developments. He mentioned that the focus of OP is now on eForms and in the new application eNotices2 that will be developed to be compliant with eForms, Code lists and ESPD. By 2023 eForms will be in use together with the corresponding format UBL.
Adoption of the agenda and approval of the minutes from last year – Maria Manuela CRUZ
Ms CRUZ introduces the seminar agenda, stressing that the main focus this year will be on eForms. The new Commission’s regulation was approved on 30 September 2019 and as soon as it is published there will be 3 years to implement it, so by 2023 the Publications Office will need to be ready and everyone will have to use eForms.
Refering to the 2018 seminar, Ms Cruz recalled the following points:
- It was decided not to implement XML schema 3.0, given the effort that this would require and the fact that it will be shortly followed by eForms.
- A new publication approach, from Monday to Friday, was adopted.
- UBL will continue to be a topic of discussion with eForms as it is based in UBL.
- In an attempt to ensure a clear planning OP will continue to follow a life-cycle of changes of the schema.
TED XML Schema – Cyrille ZACHARIE
The main reason for having a release in 2019 was the request to change and adjust some things in order to remove production obstacles and increase the quality of published notices.
The first release date with soft rules (WARNING) is 10 October , followed bytwo months of implementation; 10 December is the final go-live (ERROR). Following the request of some eSenders, the go-live date was postponed to 15 January 2020.
The main features of the release are:
- Increase maximum length of several fields, after MS consultation; - Warning on missing information in Award of contract section of Defence form; - Review and externalize patterns on EMAIL and URL;
- Accept date in section IV.2.2 of Periodic Indicative notice;
- Allow links to procurement documents in section I.3 of PIN only notices. Some other features of the release are:
- Enforce the Original notice reference in section VI.6 of Corrigendum;
- Check compatibility between country code and Nuts code in addresses,
- Check Official name of Review body compared to Official name of Contracting Authority;
Check that National ID is likely to be correct;
- Reviewed severity of some rules.
The rules with severity Error are:
- R105 on the eMail;
- R125 on the URL
- R127 on compatibility between country code and Nuts;
- R388 on main CPV code;
- R560 on previous publication (contract award);
- R710 on original notice reference (corrigendum);
- R999 on maximum field length.
The rules with severity Warning are:
- R126 on the validity check of National ID;
- R711 on the Official name of Review body compared to Official name of Contracting Authority;
- Rules on the mandatory information in Award of contract section of Defence form;
- Rules on the number of tenders in section V.2.2 (R612, R613, R614, R615, R616, R617).
The following questions were addressed:
- How will the review body be checked? The rule to be applied is that there will be a warning when the contracting authority (CA) and the review body (RB) are the same. The message will be the following: please verify the content of the review body official name field. The review body and the contracting authority should not be the same institution/entity.
- Will it be possible to examine the old Defence forms of 2.0.8 with XSLT rules? The answer is yes, from this year they will be integrated within the package, the XSLT can be already checked.
- Will Defence forms be moved to 2.0.9? OP does not plan to move it before eForms.
- Will 2020 be the last year when the schemas will be changed? OP does not yet have any requests for change coming from eSenders or DG GROW. However, it is possible that some requests will still arrive. The last schema release is not yet decided.
eSentool current status – Marketa VELOVSKI
Ms VELOVSKI explains that the new feature of the last version (TED eSentool 2.9.0) installed in July was only the update of the legal notice and the new version, eSentool 2.10.0, should be released at the end of October. The main features will be:
- Update of TED eSenders Workspace
- Waiting for information status – obsolete
- Simulation endpoint – Publication information
- at the moment, when the user sends the notice in simulation, it changes automatically into the published status after 3 days from the dispatch date, but with the new release it will change after 1 day from the dispatch date in order to avoid waiting.
- status will change at 9 am so that it reflects the production scenario.
Ms VELOVSKI invites eSenders to send any recommendation to amend the Workspace via email.
Ms VELOVSKI gives an overview of the Help Desk statistics. The main topics are production process and new schemas. After this, a brief overview of notice quality statistics is presented, the main errors R008 Dispatch date (with flexibility of +/- 12h) should match +/- 1 day the Submission date, as R013 NO_DOC_EXT duplication is the second reason of most notices being rejected.
The following questions were addressed:
- Changes of severity of rules should be announced beforehand or be better notified. Furthermore the Workspace is not the best way to inform of such changes, as some eSenders prefers a direct mail. These changes are announced both via the Workspace and eSentool and it was the case for the rule R008 as well.
- Can validation rule errors be transferred via REST API or at least a link to notice URL in eSentool in order to have more information? It will be considered.
- Is it possible to filter the errors per validation rule? At the moment it is not possible, but it will be considered.
- Statistics of the most common production errors per country since last year (2019 up to today) and errors by eSender will be provided to the users individually.
- Information on changes regarding eForms impact on the current applications will be provided next seminar.
Quality issues related to data received in TED – Laura VON-WEISSENBERG
Ms VON-WEISSENBERG highlights some of the most common quality issues found in notices.
Further details are available in the Powerpoint presentation.
The following comments and suggestions were made:
- Lack of national registration number (R126, warning). In reply to a German eSender who says that in Germany they do not have a national registration number (only regional), Ms VACCA explains that this can be valid in this case. The same happens with the organization ID. More than one ID is also allowed (no standard is checked).
- Issues related to dispatch date: given the time limits (5 days for publication, 35 days at least for reception of tenders after contract notice), and in order to make sure that the dates of the legal application of the notice are accomplished, the dispatch date should be as close as possible to the actual date of sending the notice, otherwise there might be some errors. Some eSenders argue that due to some problems with CAs, they do not receive the notice in time.
- Notifications regarding wrong use of F14:
o some eSenders refer that it is not clear in the email what CAs should do. Ms VACCA reminds that this information is already given to the user in the lower part of the notification email.
o one eSender requests to be in bcc instead of cc in rejection emails, at least for F14. OP will take into account this suggestions;
- Modification regarding number of lots: it is not possible to use F14 to create or increase the number of lots
- The use of mixed languages in the same notice is not possible. If a user wants to publish in two languages, they have to send two full versions of each language, if not, the notice will be rejected. This does not apply, however, when commonly known expressions in a foreign language are used (e.g. GPS).
- PIN and CN language coherence is currently not checked.
- Normally the contracting authority and the review body (RB) should be different, but in some cases there is no review body.
- CAs should use of unrealistic values like 1 or 99999999 should be avoided.
- Personal data and personal contact info should be avoided (functional addresses should be used instead).
- OP could add a link in the rejection emails, pointing to some information page with extended hints on how to avoid this problem in the future.
---------------------------------------------------------------------------------------------
eForms regulation – Annalisa VACCA
Ms VACCA reminds that the current regulation about standard forms will be repealed 4 years after the publication of the new regulation in the OJEU. From 2023 the actual forms will not be accepted anymore, this includes also the defence forms. The text of the regulation itself is short and mainly announces the new types of forms. There are six families of standards forms:
- Planning
- Competition
- Direct award prenotification
- Result
- Contract modification
- Change The annex details the notices related to each type of form and the different fields included in each form (saying if they are mandatory or optional). The majority of the new fields are optional.
Change forms are not forms as such, they refer to any type of form that needs to be modified and includes a section about the change and its justification.
The following questions were addressed:
- Choice of optional fields: optional fields are to be decided by country (national) authorities.
- Limit to what can be changed via a change notice: the regulation is not explicit, however it is clear that some parts of a notice cannot be changed since it will affect the creation of the notice itself. For example, changing the type of contract or the number of lots.
- Complexity of the forms: these are not forms anymore, they are just a collection of fields, so this makes it really difficult for lawyers to understand.
Net4Market presentation – Federica PISTOIA
Net4Markets has been an eSender since 2005 and they were the first eSender in Italy (IT001). In order to give a full service, they handle both national and EU publications.
Further details are available in the Powerpoint presentation.
eForms – UBL schema and business rules - Yves JORDAN
Mr JORDAN explains the main principles of eForms and the framework on which it is based (UBL). The objectives of eForms are to have stable schemas (i.e. less prone to changes), knowledge capitalization and to have as few schemas as possible. It is broadly explained why UBL has been chosen and what it offers to eForms notice representation, flexibility and customization being the main advantages. The UBL general design principles are:
- Flexibility & extensibility, to cover all requirements, and to deal easily with their evolution;
- Reusability, to improve learning curve and consistency, and to reduce development and maintenance costs;
- Naming and documentation; Clarity of structure; Simplicity;
- Support for graceful versioning, to differentiate Major from Minor releases, and to easily detect the compatibility between them;
- Interoperability and tool compatibility, consider other implementations.
Further information is available in the Powerpoint presentation.
The following questions were addressed:
- Support for ‘below threshold notices’: currently the main focus now is on the regulation itself, but in the future it may be extended.
- Handling modifications: It is explained briefly how the changes can be incorporated in the XML structure.
- Business and Validation Rules: Business Rules are primary requirements (i.e. part of business and technical implementation), and use natural language). Validation Rules are the technical transcription of business rules (highly linked to technical implementation).
Mr Christopher SCHMIDT reminded that there is a funding opportunity (CEF) to help with the implementation of eForms.
eForms and code lists – Natalie MURIC
The Code lists used in eProcurement are published on EU Vocabularies by the Publications Office. They are constantly maintained and dynamic, provide different use contexts (for the moment eForms and Ted Schemas) within the eProcurement domain and are available in different formats.
Codes and concept are presented. Codes represent concepts for machine readability and are language independent; the content associated to a code may change but the code is constant. Concepts have a label/name and generally a definition (sometimes there is not a definition, because the label tells you exactly what it is, so there is no need for a definition). The definitions are only available in English. The label/name and definition provide the human readable content. Labels are available in all official languages.
The following questions were addressed:
- Availability of several versions of one label in the same language (e.g. German labels used in Germany and in Austria): OP will make available one version in a specific language taking into consideration the Interinstitutional Style Guide. However that does not prevent other translations of the code being used on local systems.
- Changes in CPV: DG GROW has foreseen a further study on this subject.
- Link between eForms and EU Vocabularies: eForms will use the authority tables available in EU Vocabularies.
eForms – the new generation of standard forms – Jáchym HERCHER
The Schema and general information for the forms will be published by OP around September 2020. From then onwards the eSenders will have a period of 2 to 3 years to fully adapt their systems.
The main benefits of the implementation of the eForms can be summarized in the following points:
- Accuracy
- Simplicity
- Digital
- Universal
Descriptions for the fields will be more accurate and useful.
Fields will be easily adapted to the policy makers’ needs in terms of issues or topics that might be required to be tackled.
eForms will bring more transparency. The identification of the user will be easy to trace and allow for a better contextualization of the form.
The implementation cost of this will be reduced since the data schemas will share a lot of aspects and technology across notices. It will also allow the reuse of a lot of resources.
The technical implementation of the eForms is totally paperless and also gives a lot of flexibility so that users with different levels of expertise can freely use them.
Due to differences between country legislation, some fields are only mandatory if they can be filled.
eNotices2 – User interface – Annalisa VACCA
The main objective in the upcoming development of the eNotices2 UI is to bring it closer to the eForms.
The main principles of the tool are: customize, reuse, reduce, quality and share.
Customize – the user will be able to customize its workspace to its needs and also in terms of what forms is he/she using.
Reuse – the old database will be kept so there will be no loss of information.
Reduce – in order to facilitate the use for newcomers only the necessary fields of a given form will be displayed to the user so that the user can choose what kind of notice should be created and the tool will give a template to fill in easily.
Quality – a validation will be implemented. This will include the crosscheck information between two related notices.
Share – the new UI will allow for greater work coordination capabilities among users.
Machine to machine Service – Bertrand LORENTZ
All the services to be used on the tool will be accessible via webservices. Some improvements are being considered, such as the possibility to have push notifications via web hooks.
ESPD – Maria FONT, Enric STAROMIEJSK,. Sofia BERENGUER
A presentation of the ESPD chronology is shown to demonstrate the alignment of ESPD with the other developments (eForms) and the current situation.
The documentation is available on GitHub. Further steps will be taken to make the documentation more accessible (reduce length and give a better structure).
The main objective for the future version of ESPD will be to produce the necessary alignments to the new developments:
- Alignment with the eForms
- ECERTIS alignment
- TOOP alignment
