Minutes of the sixth eForms Technical Workshop 

 

26 September 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.

 

 

 

Questions from the participants: 

 

• In the May workshop it was commented that the fields that should not change through a change type notice are the following: BT-04 Procedure ID, BT-03 Form Type, BT-02 Notice Type, OPT-070 Notice Subtype, BT- 105 Procedure Type, etc. In this case, should a notice be generated with a new ContractFolderId? 

Answer: The XML element 'cbc:ContractFolderId' contains the Procedure ID (BT-04) which may not be updated with a Change. A change therefore should have the same Id as the referenced notice. 

 

• Through the Discussions (https://github.com/OP-TED/eForms-SDK/discussions/679) you told us that there are notices that are published in production but their XMLs are not completely correct (for example section 6.1.2). Are manual validations not applied to detect these problems? 

Answer: In this case, a notice was published where a Tendering Party did not include any Organisations. There are currently no rules to control this (and there is no manual validation except for lawfulness). 

 

• What is the expected end of life for SDK 1.5? 

Answer: January 2024. 

 

• What is the expected end of life for SDK 1.7? 

Answer: May 2024.

 

• What are the expected release dates for SDK 1.9 and 2.0? 

Answer: SDK 1.9 should be available in early October. SDK 2 will come next year. There will be one more Alpha release within 2023. Beta, RC and final releases in 2024. 

 

• Will the whole eSentool-API be unavailable or will only specific API-Methods be unavailable after 25.10? 

Answer: Submissions will be stopped on 31 January 2024. Other eSentool functions should be available for a further 3 months.

 

• Will the current interface for receiving notices still be available after 25 October in the production environment? 

Answer: Yes, eSentool will remain open for submitting notices until 31 January2024. 

 

• Will it be possible to query the status of a notice submitted after 25.10. via eSentool API (for example to query if a notice will be published)? 

Answer: Yes, it should be possible to keep read-only APIs active in eSentool after the deadline. 

 

• What will be the technical API-Responses from the esentool API if it will be made unavailable? 

Answer: During the temporary unavailability of the API, the returned HTTP code can be 503 or 500.

 

• Why is there a 24-hour rule (a legally binding date) associated with field BT-05 (Notice Dispatch Date)? What could you suggest if all notices are manually checked for lawfullness by the eSender (Official Org). This may take 1-2 days. Don’t you think that the rule should set on field BT-803. 

Answer: BT-05 is the successor of NOTICE_DISPATCH_DATE in the current TED-XML. It’s up to the eSender to fill it with the date they consider is most meaningful. BT-803 is a new optional field for eSenders to add their timestamp when they send the notice to TED via the eNotices2 API. 

 

• The pdf format of notices published on TED do not contain the BT ID's. What is the reason for? It would be recommended that the notices on TED contain BT ID's. 

Answer: This is a choice to avoid overwhelming readers on TED (tenderers etc) with IDs that don’t help them to understand the notice. 

 

• When are the extended notices E1-E5 expected? 

Answer: November 2024.

 

• How do you expect us to develop our software when you don’t have a stable version for over a year. All changes that you do have to be done by everyone else. There are massive time delays. 

Answer: Please see the presentation about SDK and the meaning of 'stable'. 

 

• Is TED using the dynamic schematron files to validate notices? 

Answer: Please see the Busines eForms Issues presentation (6th workshop) – we currently have 2 dynamic rules (one since SDK 1.7 and one added in 1.9).

 

• How to deal wrong paths in sdk 1.8? Example BT-271-Procedure attribute @currencyID is not present?

Answer: SDK 1.9 makes this easier. The example isn't a wrong XPATH. It is something that is implicit, such implicit things were so 'obvious' (an amount does not have any meaning without a currency) that they weren't added to the early SDK versions. To simplify things it has been decided to enrich the SDK and add this information explicitly.

 

• Is there a documentation on which fields are allowed to be changed when sending a change notice?

Answer: Please see the Busines eForms Issues presentation (6th workshop) which lists the fields that shouldn’t be changed (the rules are planned to be implemented once SDK2 EFX is available.

 

• Is it possible to put multi-line text to BT-24-Lot with data type text-multilingual? Will it be rendered as multi-line in the generated HTML? 

Answer: No, text Fields in eForms do not allow multiple lines / line breaks. When a notice is rendered in HTML or PDF, only one language from each text-multilingual Field will be displayed. 

 

• Functionality of eNotices2 is limited, compared with eSentool. We cannot manipulate the status of notices in, which limits the testing which we can do. E.g. publication of notices can take anywhere from 1 mins to 5 days; cannot reject notices either. Plans to have a better system in place? 

Answer: There is the possibility to submit, stop notices, query their status, and request a validation. There are no plans to add features for the moment. There were some temporary issues in the Preview environment to get notices to their 'Published' status. If you need to text 'Not Published', please contact the TED Helpdesk to organise a manual lawfulness rejection. 

 

• Authentication/login structure for TED eForms is very limited. Using one single generic user account to do everything is a horrible practice in identity management. Generic account should be forbidden. By when will there be a state of the art architecture?

Answer: For now, we have one account per eSender in the Developer Portal. We don’t plan to revise this but we’ll see what could be done in the future.

 

• Is status PUBLISHING already implemented? 

Answer: This is planned to be deployed in October.

 

• Is the status polling API expected to be updated with the SDK? What's the strategy there?

Answer: The API functions don’t depend on the SDK. 

 

• When will you improve the test environment by including the 'publishing' state and by allowing us to manually set a certain state (e.g. switch the status manually to 'published' to see how or systems respond) 

Answer: Preview environment did have problems with setting the 'Published' status. This should be resolved now.

 

• Will there be user-readable error-messages from the validation endpoint in the future? 

Answer: We will continue to improve the rule messages (in the SVRL reports returned by CVS), e.g. refer to fields consistently with a [field-name] ([field ID]) convention. 

 

• Have you secured extra staffing on the 25 of October in case there are lots of helpdesk calls? For example on how to use eSentool in case a national eSender is temporarily not available. 

Answer: As eSentool will still be available after 25 October, the switch to eForms should be relatively less congested around 25 October.

 

• When a notice is not published for lawfulness human check error. Will there be a report that could be retrived with the API explaining why the notice isn't published?

Answer: If a notice is rejected after a manual lawfulness check, the buyer (NoticeAuthorEmail) will get an email to tell them that the notice is Not Published.  This status can also be retrieved by API.  In future we will add reason codes for why the notice is Not Published. 

 

• Where can we get the API key for going live as an existing eSender? 

Answer: eSentool accounts are not migrated. All eSenders need to create a new profile to generate a key from the TED Developer Portal: https://developer.ted.europa.eu/home 

 

• When all translations for errors and warnings will be available in DE language?

Answer: All labels, including for rule messages (since SDK 1.8), are available in all 24 languages. A small number of missing labels (e.g. exclusion-ground codelist) will be translated with SDK 1.9 (and patched for earlier SDKs). 

 

• Will form E1 be available when eForms become mandatory? If not, how should one publish a market exploration? 

Answer: We will work on the E1 form after the adoption of the second amendment to the eForms regulation and it will be available no later than November 2024. It is a voluntary form so its use is not mandatory. 

 

• Is there a document where all the fields and their characteristics are reported as was done in the old 'validation rules.xls'? 

Answer: Please see the Busines eForms Issues presentation (6th workshop) – use the CSV files at https://docs.ted.europa.eu/eforms/latest/reference/index.html#_downloads and import into Excel if you wish. 

 

• How do you guarantee that the eForm is only filled out in the language chosen (no mixed language)? This is not a subject of lawfulness check, is it? Or it is the notice author's responsibility? 

Answer: We will no longer manually check if the language of notice content matches the declared language. Perhaps in future we could use some sort of machine detection of the language and flag inconsistent notices for lawfulness check.

 

• Can a new change notice be summitted for the same procedure/lot before the previous one has been published in TED?

Answer: No, the previous change notice needs first to be cancelled (in which case referred notice will be the same between the 2 change notices) or published (in which case the change will apply on the previous change notice).

 

• Will the 'PUBLISHING' status first be available on the preview environments so we can test the interaction with our platform? 

Ansewr: The new release to expose the 'Publishing' status will be available in Preview one or two days before Production. But note that the Preview environment has a mock process to imitate the TED website to switch notices to 'Published' status so they will not be available in 'Publishing' status overnight (or longer) like in Production.
 [Preview is currently configured to export the OJS at 15:00 CET and set the status to ‘'Published’' at 16:00 CET, meaning that notices stay in ‘Publishing’ status for one hour to allow for testing].

 

• The regulation (art. 51 (5)) uses the term 'confirmation of the receipt of the notice... Such confirmation shall constitute proof of publication'. This is OP's responsibility. Now there are multiple dates set by sender and no such status in Notices2. How do we deal with this? 

Answer: We notify the sender when a notice is published by email the same way we did before. We also notify the notice author (email set by the eSender as parameter in the API call). 

 

• Is there a checklist for a go-live with enotices2? 

Answer: eNotices2 is already live with eForms. For eSenders using the API, we don’t have a checklist – your readiness depends on your situation. 

 

• In Italy we have the need to archive only PDF/A files. Our eSender downloads though an automation the notices from eNotices, which are in PDF, not in PDF/A. If I am not wrong, notices published in TED are in PDF/A. Is it possible for an eSender to implement a service that downloads PDF/A from TED? 

Answer: Yes, it is possible. If the user wants to get the notice in PDF, they should use the direct link of the notice. The direct  link of a notice has the following format:
- The prefix http://ted.europa.eu/udl?uri=TED:NOTICE: 
- the document number, not padded with zeros (e.g. 223-2009);  
- the view type TEXT (notice view), DATA (data view), PDF (PDF view), PDFS (signed PDF view in an original language), or XML (received notice in XML); 

 So, if the user wants to get the PDF of the notice 579970-2023, the URL will be as follows: 

https://ted.europa.eu/udl?uri=TED:NOTICE:579970-2023:PDF:IT:HTML 

 

• SDK Version depricates in 12 months. Systems have to be constantly equipped with developers, there is no time for carrying out a procurement. It will then take a few months for analysis, few months for development and then time for testing. Few months LIVE and circle starts again? Is it really ok? 

Answer: We currently update the TED-XML schema every year and we give everyone 6 months to change.  With the SDK you can choose the version you want to support and upgrade at your own pace in up to 12 months. We also have eForms regulation amendments every year. So annual change of some sort seems inevitable and we all need to set up our systems and organisation to handle these changes. The SDK can be part of this flexibility and agility. 

 

• What happened to planned SDK 2.0? 

Answer: SDK 2.0.0-alpha.1 has been released. We initially intended to press it for release in June/July 2023. We decided that there is no need to rush as very few if any eSenders would be ready to jump to SDK 2. It will be released in 2024.  

 

• Is it possible to create Contract modification notices (ex SF20) for design contests? Our eSender told us that it is only possible to generate Change notices (ex SF14) for design contests 

Answer: Contract Modification Notices can only be created on Result notices. For design contest this would be forms 36 and 37.  

 

• By when we can expect an SDK mature enough so that it'll receive support for more than 12 months? Upgrading to minor versions here and there sounds reasonable, but major upgrade every 12 months is a disaster. Imagine if the EU authorities were upgrading laws every 12 months.

Answer: The EU authorities (i.e. the European Commission and the Member States) are already updating laws every 12 months – see the annual amendments to the eForms regulation. The SDK is a vehicle to help handle these changes. 

 

• When we have talked about the links, in the case of the Awards within a framework contract: use OPT-100. What should be linked to what? 

Answer: OPT-100-Contract should be used to refer to the contract notice establishing the FA.

 

• In form 16 there is a node 'ND-StrategicProcurementType' inside the group 'ND-LotTenderingProcess' but its parent is 'ND-LotProcurementScope', why this inconsistency? How can we manage them? 

Answer: For now you need to handle these inconsistencies. We will continue to review the NTDs to improve them. 

 

• You have many developers testing your software and the schema and everyone is finding errors that are not only technical but of legal matter. Before you have a stable version of your SDK (legally and technically) we should not go live and the deadline should be postponed. 

Answer: We have come across a couple of mistakes in the SDK (and which we need to backport in SDK patches).  The SDK is stable enough and does not block you from submitting in eForms. The availibility of the current systems after 25 October is however a welcome announcement to help to iron out issues. 

 

• You mentioned in the emails slide 'buyer gets email when notice published with the same buyer name'. There's no concept of buyer account (as in eSentool). Where is the original buyer name gotten from? How are they associated with an email address? Is there like a DB of buyer names built on the fly? 

Answer: This workflow has been disabled for API notices. It remains only in the UI for administrators of Structured Organisations.

 

• If a delegated contracting authority manages the 'contracting phase' (publication of contract notices + CAN + changes) and the delegating contracting authority manages the contract execution (contract modification notices), is it possible for the delegating authority to publish with its address info? 

Answer: We discourage different user accounts from interacting with the same notice through API, or mixing API and UI features of TEDEN2.
In principle the buyer of the CAN should be the same in the Contract Modification notice – but we can’t control this (as it’s also possible for the same buyer to have changed its name or address).

 

• Please elaborate on the feature that will send e-mails based on 'buyer name'? What e-mail addresses will you use for this? What BT will this be based on? As an eSender we send lots of notices for the same 'buyer organisations', but please don't alert each buyer every time the org. publishes.

Answer: See the previous answer. 

 

• Please consider that we need more time in order for everyone (all EU Member States) have enough time to implement and train all Contracting Authorities. Your constant legal and technical changes caused by your errors are creating delays on our side. 

Answer: The SDK versions provide improvements but they do not block you from going live with eForms. 

 

• Will there be a national form, for example E6 for contract modifcation? 

Answer:  TED and eForms only handle EU-level notifications. We don’t know if you will use E6 at national level. 

 

• When will the validation via the CVS service be complete with all the compilation logics? (e.g. conditional mandatory, mutually exclusive fields) 

Answer: SDK 1.8 added many conditionally mandatory/forbidden rules. We will add a few more in SDK 1.9 and 1.10. We are reaching the potential CM/CF rules that are relatively less valuable, e.g. a description can only be provided if its associated indicator is true. 

 

• It was said that we can use both TED publication number ([1-8 digits]-[year]) or eForms UUID to link notices. TED publication number format is not accepted in SDK 1.5 and we are facing blocking issues in higher versions. Will we face any issue using only eForms UUID ? 

Answer: We had an issue with the pattern used to validate the publication number (not accepting leading zeroes). This has been resolved in SDK 1.7.0. We are not aware of any issues for the eForms notice identifier (UUID). Please note that only eForms notices have this identifier, so it cannot be used to reference notices published in the old format. 

 

• Organisations part of the notices is really a bad solution. Please consider that the notices in the end need to be read by economic operators. 

Answer: Organisations can have more than one role. In the viewer (HTML and PDF) we have chosen to put the bulk of the organisation details at the bottom to make it easier to read the notice. We are open to feedback and suggestions for improvement. 

 

• You have commented that changes should not be sent until the notice is published. Wouldn't it be enough for the previous notice to be in publishing status? 

Answer: This is partly a question of principle: you cannot change something that isn’t published yet.

 

• Are there future plans for LTS releases? 

Answer: No, for now all SDKs are supported in a similar way.

 

• End of support = not active? 

Answer: Yes. 

 

• Is it true that Voluntary ex ante transparency notices have to be published only it the type of procedure is a negotiated procedure without prior publication of a call for competition? Or can it be also another type (e.g. Contract direct award)? 

Answer: Other single stage and Other Multi-stage procedures are also possible.

 

• All of your past SDK Versions are not only software versions but legally false. How do you expect us to use prior SDK versions that have legal and technical problems? 

Answer: Please tell us what is legally false about the SDK versions. 

 

• OP does publish an SDK version every 2 or 3 months. Do you really think it's realistic to expect eSenders to update once a year if you change your mind this often? 

Answer: Yes, prepare to update at least once a year. We don’t change our mind: we improve. And regulations are also adopted that you will need to comply with. 

 

• Will the E1-E6 not be specified until the autumn 2024?

Answer: They will be included in an SDK by November 2024. 

 

• E1-E6 November 2024 deadline for OP - is this a precautionary timelines? We would like to adopt some of the voluntary eForms as early as possible next year. If the relevant SDK element were not available until November 2024 but this creates difficulties for our implementation. 

Answer: We will see what could be defined before November 2024 but we cannot commit to it.

 

• In one single slide, you tell us you're working on 1.9, 1.10 and 2.0, all unrelesed. What's the point? Why not focus on one and make it stable? This is definitely not rationalizing efforts within the OP, and it's crazy for the eSenders. 

Answer: SDK 1.9 is in testing, 1.10 is in development. SDK2 is in alpha. Pick the version that you need; multiple SDKs is our problem and we can handle it. 

 

• Will the additional metadata include information on if the field is allowed to be changed in a change type notice? 

Answer: This is being assessed internally.

 

• Every version of the SDK includes 'updates in the rules'. What do these changes respond to? Updates in the law? Defects? 

Answer: Most rule updates are additions. In some cases they are corrections or improvements.

 

• You claim you are trying to release faster. That seems the wrong objective and mindset. Releasing less means more stability. 

Answer: We want to release faster, meaning the time between freezing the scope of an SDK and getting it into your hands, but also to provide you with improvements faster. 

 

• What is the state of your help support? We have been trying to find an answer for one of our eNotices2 issue for some time now and are not getting the help required. 

Answer: We aim to answer all questions – but please insist if you don’t get an answer.

 

• It was said that we should introduce issues with SDK in GitHub. Should we reintroduce in GitHub our requests to the HelpDesk that are not fixed yet? 

Answer: No, business-related questions to the TED helpdesk should stay there. Unless the Helpdesk ask you, there is no benefit from asking the same question in GitHub, which should be used for technical questions about the SDK. 

 

• How to implement that if the name of the buyer changes only? What is the change notice section? 

Answer: It’s possible to signify a change of name and/or address in the Organization section which you used for the buyer and the BUYER section.

 

• We want to go live with eforms on 25 October. What is the solution in that case when TED ask a shortage for an old notice in old format on 23-24 October? We have to drop out the old notice and make a new one? (Because the system forms and fields very differ in the old and new notice.) 

Answer: We assume you mean that your TED-XML notice might be manually rejected in the days just before 25 October. Ideally you should be able to submit the TED-XML notice with the necessary corrections. The old systems will remain available after 25 October so this can give you the flexibility to handle these sort of issues that overlap the switch between formats. 

 

• I was told by the EU-helpdesk, that there will be new information given during the workshop on the transition from FTP-->HTTPs for the notices bulk download. (reuser) Do you have any news on this topic? 

Answer: This is not related to eForms but to the new TED website, which is planned to go live early next year. For now, reusers of TED data can continue to use the exists ftp server but should prepare to move to https with the new TED website. More information for TED reusers will be shared at the next workshop on 18 October and you can also see what was explained at the previous reusers workshop in June. 

 

• There was a CVS problem on Preview system on 9 August until 11:30am. On that day, we held training on our new eforms compatible system, so we were quite sensitively affected by this unexpected interruption. Can we expect a similar service disruptions later? 

Answer: This was a temporary disruption. We of course aim to avoid all unplanned technical disruptions, although our Preview environment does not benefit from Production-level support from our hosting teams. 
Our general policy is to email all API users (as registered in the Developer Portal) of any planned downtimes in Preview or Production. We aim to fit these into timeslots between 7:00 and 9:00 CET. Please get in touch in advance if you have any particular plans. 

 

• The HTML/PDF-API is flaky and slow - can we expect it to be stable enough to use for prod workloads on launch?

Answer:  Please get in touch with details of any issues you have had. The next release of the software should improve performance but it’s useful to get feedback. The service is already used in the production TED website, as well as eNotices2 and as an API for eSenders, and we are not aware of any particular stability problems so far.

 

• What do you think if you apply the 24-hour rules to BT-803 instead of BT-05, because as national eSender and Authority, we have two days by law to check the notices? 

Answer: BT-05 is mandatory Dispatch Date that was defined in the original 2019 eForms regulation. BT-803 is an optional date of when the eSender sent the notice to the Publications Office so it’s not a reliable field to use for any rules. We don’t know what happens in the process between buyers and eSenders but BT-05 is the successor to the TED-XML notice dispatch date so if you keep the same logic then the switch to eForms should cause no issues for you. You will also have a bit more flexibility as the rule has been extended from 12 to 24 hours. 

 

• SDK contains errors, the application must correct this deficiency by forcing a certain behavior.When you fix the error it isn't 100% certain that the application will continue to work. How is possible to create a stable SDKbased application if the SDK itself is not stable and is constantly changing? 

Answer:  Please see other answers about the interpretation of 'stable'. Every SDK version is stable. 

 

• There are some (eforms) change noticse on TED publication webpage but we cannot find the previous notice. The notice contain UUID reference to the previous notice but we cannot filter TED notices on webpage with UUID procedure value. What is the plan, can we filter to procedure id (UUID)? 

Answer: In the current TED website, the user does not have the possibility to search based on the 'Procedure identifier '. In the future TED Website, the user will be able to search based on the 'Procedure identifier '.

 

• Would it be possible to get into a more reliable SDK release cycle in the future? E.g. a new release every 2 month including patch-releases for the former but still supported SDK? This would help the evaluating and Aadaption processes according to the local tailoring. 

Answer: It’s currently difficult to have fixed dates for SDK releases, though we understand this would be useful for eSenders to plan ahead. 

 

• In case of interruption on the eform submission service, will the dispatch date rule be disabled temporarily?

Answer: In general we would hope to fix technical issues in less than 24 hours but we will check internally for what options could be available.  

 

• BT-24 description: In case of modification notice 6000 characters are not enough to describe 'of the procurement before and after the modification'. Could be increased the size of the field in case of a contract modification? Or could we get a new bigger size field or a new field for this purpose? 

Answer: The modifications for a contract modification notice should pertain to the contract section and the Result section. It would be better not to change BT-24 and focus more on the specific fields in those sections. There are several 'Additional Information' fields that can also be used.

 

• As you are set 24-hour rule on BT-05, you force the eSender to change the original notice at at least one point. Is it okay? 

Answer: We are not involved in the process before submission. It’s up to the eSender to know what to put in the BT-05 dispatch date. We assume it will be the same as the dispatch date that you currently put in the TED-XML.

 

• There are a lot of unidentifiable message what the user can see (and we saw it on the form): eg: 'All order of importance associated values must be lower or the same as the total number of occurences' The problem is we cannot identify the BT field for these messages. Can you accurate the message? 

Answer: We are aware that some messages can be difficult to expose directly to end users. Some of them do not depend on a specific BT so more accuracy cannot be provided. We will keep working on the messages to see what could be improved. 

 

• We do not understand why we get XML error when a field is mandatory: eg: 'nformation under 'ND-BusinessAddress' is missing (element 'cac:PostalAddress' is mandatory under this path: /*/cac:BusinessParty)'. Why don't we get Schematron error? 

Answer: These rules are automatically inferred by the mandatory existence of descendant elements and help detect the absence of nodes in the XML. These are Stage 1 schematron rules and may be found as part of the validation-stage-1...sch files. In addition to the XSD they help detect invalid XML structures. They refer to nodes with a rule key of the type 'rule|text|ND-xxxx'.

 

• Did i understand it correct that it will be possible to send v9 publications until the end of January? 

Answer: Based on the announcement during the workshop, we can confirm that the Publications Office will keep eSentool running until the end of January 2024 for all notices.

 

• Is there a manual on how exactly account for eSender should be created?

Answer: We suggest reading the FAQ and the Preview page in the docs Documentation for TED developers and eSenders :: TED Developer Documentation (europa.eu). As an eSender, you would need to generate your API key from the TED Developer Portal and log in once in the corresponding environment of the User Interface to pair their API key with your eNotices2 account. 

 

• The TED support: the public email is not working, the good one is: OP-TED-HELPDESK@publications.europa.eu If I have a business or API problem, I have to write to this email address. Do you plan to install a public problem ticketing system (or manage Git issues) for eSenders and API users? 

Answer: Please continue to email the TED helpdesk for business or operational issues. They will keep track of the issue and follow up its resolution but their ticketing systems is internal. For technical issues directly related to the SDK, you can open a discussion on GitHub, which can also keep track of open issues. 

 

• MC Schmidt said there that TED will accept the old forms till the end of January 2024. Will Member States receive this information officially? The regulation still includes the deadline 25 October. We need legal certainty. 

Answer: The current forms allow you to publish notices containing all the information that is mandatory under the Public Procurement Directives. Interested economic operators will continue to have access to that information. It is not for the Commission services to assess whether economic operators would challenge contracts awarded by contracting authorities on the ground of the underlying notices’ non-compliance with the prescribed standard forms. The Member States who approached us will receive an answer.

 

• It was said that 1.8.0 will include all translations, professional translations (by human) We were waiting it very much but it was disappointed for us, because they were full of bad Hungarian translations. When will you fix it? 1 month to go live.

Answer: We know that not all translations will be correct because of the context or specialised terminology. We will see how best to share the translations with agreed Member State contacts so we can collect your feedback and corrections. Any translations we add to new SDKs will be included in patches to earlier SDK versions. 

 

• Why do you make new SDK until October 25? Why don't you fix the errors of old SDKs faster? There are a lot of PDF and translations error. We have to wait for a fix 4-6 months. 

Answer: SDK 1.9 should be released in early October. It will improve some translations and view-templates for PDFs. We fix issues as fast as we can and try to focus according to priority. Please get in touch for any issues that are blocking you. 

 

• There is no information about API updates, or any release notes. Earlier CVS gave message-codes not only messages,but after 08.23.2023 CVS did not pass message codes. We used these message-codes so this update messed our system's working.Can we have any information about API's updates in the future? 

Answer: SDK 1.8 added the labels and translations for rule messages. The CVS response includes the message code and the message text. Before 1.8, we didn’t have translations for the message texts so CVS filled the message text with the message code. If you were using the message text as the code, you’ll need to adapt your application to use the message code. 

 

• Can you please confirm in writing that it will be allowed to publish notices in the current format until January. 

Answer: Yes, the current format of notices can be submitted via eSentool or eNotices until 31 January 2024. 

 

• There is a framework agreement. We published its contract awards quaterly, not only one but all contracts in that quater. Every contract was a lot. That is the good operation in the old TEDXML. That is why sometimes there is 1 lot, sometimes 10 lots in the same notice. Can we do this in eforms? 

Answer: Yes.

 

• There are a lot of pointless BTs due to technical design. Our client and testers want to see this pointless BT-s on the forms but we cannot this, because these fields are not exists. When will the CELEX amend?

Answer: There is no need to 'audit' the implemented BTs against the regulation annex. The documentation about the schema in the TED Developer Docs also list which BTs are pointless by design. The regulation annex and its extended Excel 'CELEX' annex cannot represent all data structures in a useful way. 

 

• The minutes of the webinar is very important because there are questions with no or no accure answers on webinar. Can you do the minutes in 1-2 weeks instead of 2-3 months? Thanks in advance. 

Answer: The draft May minutes were provided in 2 days (all participants were notified via e-mail). We only needed more time to get full answers for some of the questions. 

 

•  You have informed in your presentation that front end enotice2 web interface should not be used notices submitted by API. What function is affected by this? In case there is an error in the API or a notice needs to be stopped or changed urgently - why can't we use the web interface for this purpose?

Answer: The front-end of eNotices2 was not designed to act on notices submitted by API. If for example you stop a notice via the UI, your own system will not have this information. All actions should be carried out by API calls so that the eSender application is in control. The only scenario that may be useful and will work is to view the notice status via the UI, for example, a business person submits in their eSender/eProcurement system and wants to see immediately if eNotices2 has received it successfully – this could be useful when testing but your application should be handling the notices directly. 

 

• There are a lot of mistakes and mistypes in the PDFs. There are translations what means the opposite the english text and it can be seen in the PDF. The bugfix takes 3-6 months. How can you use them in the production? I don't understand because these PDFs are legal documents.

Answer: Please see other answers about translations and PDFs. We need to fix them but they are not blocking issues.

 

• It was presented, that SDK can have issues / bugs that affect validation and publishing. What should we do in the case that an error in the SDK prevents the notice to be published? In this case it would be too late to wait for the next SDK Version. 

Answer: You and your buyers will encounter error messages that are difficult to understand or to resolve. But it should be possible to figure out the problem and to provide a notice that validates successfully so you won’t be blocked or wait for an SDK release. 

 

• After publication we automatically download from TED the signed PDF version of the notice in the original language. Sometimes no signed version is available, only the regular PDF is there. What could be the reason? 

Answer: There are 2 cases where the signed PDF is not available: 

- In case there is a request for anonymization :   

- example Supplies - 608975-2022 - TED Tenders Electronic Daily (europa.eu)    

- Link to signed PDF https://ted.europa.eu/udl?uri=TED:NOTICE:608975-2022:PDFS:FR:HTML 

- In eForms, the  issue not yet solved  when the notice contains the code of the character  '>' or '<' . For this case the notice cannot be rendered to both  HTML, non-signed PDF or signed-PDF  

- example : https://ted.europa.eu/udl?uri=TED:NOTICE:580198-2023:TEXT:FR:HTML&src=0 

 

• One month and we have to go live. The generated PDFs are full of errors and a lot of missing information. The TED announcements are more authoritative than the national announcements, which, however, are now richer in content. How can you manage this until October 25? 

Answer: We improve the PDFs with each SDK version (and patch the previous versions). Please let us know of any specific errors or missing information that you have spotted. 

 

• If we e.g. have submitted a contract notice in the old schema, is it then possible to submit a 'change' to this as the first eForms form, in other words can the initial contract notice within a procedure already have a changes section?

Answer: Yes, this is possible. The original notice will be in TED-XML and the Change notice will be in eForms. The Change notice needs to include the information from the original TED-XML notice (with the changed sections) and may also need to be enriched with fields required by eForms (so it’s a valid eForms notices). The Change notice will also contain the change section to describe the changes, with a reference to the original TED-XML (using the TED publication number). The Change notice would indeed be the first eForms notice for this procedure. With the acceptance to send the current forms until end of January you can  continue sending corrections to old notices but this would just be a transitional solution to help end users (as using F14 will be easier than having to create an eForm notices). 

 

•  As you have announced, it will be possible to publish 'old' Forms until end of January 2024. Will it also be legally OK for contracting authorities to publish 'old' forms after October 25th 2023 despite the (apparently) unchanged deadline in the Commission Implementing Regulation (EU) 2019/1780? 

Answer: The current forms allow you to publish notices containing all the information that is mandatory under the Public Procurement Directives. Interested economic operators will continue to have access to that information. It is not for the Commission services to assess whether economic operators would challenge contracts awarded by contracting authorities on the ground of the underlying notices’ non-compliance with the prescribed standard forms.

 

• When sending a notice to TED, it includes an SDK version. That version determines the validations, because each SDK is self contained and with different rules. Saying that using the SDK is optional and we can use different means is not realistic, in practical terms. Dependency on SDK is very strong. 

Answer: It is true that you must respect the schema and rules if you want to submit notices for a specific SDK version. This is the core requirement, which broadly corresponds to what has been done for TED-XML where eSenders figure out everything on their side to provide valid XML. What is optional about the SDK is how you use the machine-readable components that have been made available via the SDK, which you may use to reduce your development effort and make it easier to handle changes. So there are two aspects to the 'use' of SDK: one mandatory 'use' is when you submit a notice, which is checked against the schema and rules of that version (and where notice-types, view-templates, translations, etc are irrelevant), and one optional 'use' of what components of the SDK you integrated somehow into your systems to be able to produce the XML that you submitted. 

 

• I'm afraid everything will stop on October 25th. There will be a lot of blocking errors because many countries go live on this day (including us). TED support how will handle this situation well? 

Answer: We hope that blocking errors are identified before you go live. We will continue to support you with the resources we have. The acceptance of the current forms until end of January should help spread out the number of eSenders switching on the same day.   

 

• Grateful for greater clarity on what the announcement from DG-GROW on standard notices and January 2024 means for MS. If not today a separate webinar is required ASAP and also clarification in writing to have legal certainty and to inform policy decisions on implementation.

Answer: The current forms allow you to publish notices containing all the information that is mandatory under the Public Procurement Directives. Interested economic operators will continue to have access to that information. It is not for the Commission services to assess whether economic operators would challenge contracts awarded by contracting authorities on the ground of the underlying notices’ non-compliance with the prescribed standard forms. 

 

• When will the guideline for procurement officers be published? 

Answer: There is currently no planned date to publish guidelines. 

 

• We understand the SDK is always changing but not enough quick. When we fix an SDK bug and after that the SDK will change, we have to fix it again or we have to remove the fix. That is why we do not want to fix bugs rather SDK and more quickly than now. I think you understand this point as well. 

Answer: Yes, we understand there is an effort to fixing issues. We include improvements as best we can in each SDK release. 

 

• In the discussions we have been told that eForms sent through API should not be consulted (their PDF) through eNotices2 Web UI. Is there a faster way to do it than through the TED Viewer API? 

Answer: The visualisation API TED Viewer is the fastest way and should indeed be used for visualisation purposes instead of eN2 web UI.

 

• Can we have view templates that do not hide the zero or negative values? The design decision to hide zero or negative values makes it much harder to perform correct content validation. 

Answer: This is a design decision to avoid overwhelming readers with the numerous optional fields that exist in eForms and that will probably be left empty by the majority of buyers. It is not helpful for example to put a label for a fax number that is not provided, and for every organisation in the notice. 

 

• Will deprecated versions of the SDK be supported in preview? 

Answer:  We don’t see any case where it would be useful to keep a deprecated SDK version active in Preview if notices can no longer be submitted in this version. In any case, TED Viewer will support all SDK versions 'forever' (10 years on TED) as it needs to display notices in any previous version. But get in touch if you see any reason to keep a version. 

 

• How should a market exploration be published, if form E1 will not be available before 2024? 

Answer: You can see if you can communicate the information about a market consultation using a Planning notice (Buyer profile or PIN Only). It’s not the intended use of these notice types but there would be no technical issues as long as you can fill in the required fields of the Planning notice. 

 

• Will there be a stable version of the TED-Visualisation API that is able to handle some tens of requests a second without throwing HTTP-Status 500 on each request? 

Answer: If you detect such issues, you should report them to Helpdesk with as many details as possible, e.g. screenshots and dates of the full error message, user etc., and we will look into them.

 

• Is there a possibility to provide the validation API as open source, so it can be reused internally? 

Answer: We look into this when the resources allow.

• Rules in the different versions of SDK are filled with errors and thereby the legality of the SDK Versions is in question. 

Answer: Please let us know of any issues that would make an SDK version illegal. 

 

• BT-06 sits lower in buyer view than the strategic fields to which it refers. Given BT-6 has been made mandatory our end having it appear below the other strategic procurement bts is confusing. Can this be remedied in the SDK? 

Answer: It is related to the NTDs. We will aim to update this as soon as possible.

 

• Did I understand correctly that you mentioned: status 'publishing' will appear in the preview environment 1-2 days before production? That is not enough for testing. Do you already have dates when it will be deployed in preview and production?

Answer: Our current plan is to deploy the update in October. The Publishing status is useful but it shouldn’t block your applications. It just allows the applications and users to understand why a notice cannot be stopped. Until now, the user sees their notice in Submitted status and doesn’t understand why their request to stop fails. Once the Publishing status is visible, the limitation becomes clear. 

 

• Could you extend the visualization endpoint and the notice viewer with the BT identifier next to field names? 

Answer:  It’s not feasible for the main Viewer application to display the BT identifiers beside the field names. TED users and economic operators do not need to know this background information and it would only make eForms less readable. If you use the Notice Viewer sample application as an inspiration, you can adapt the code to suit your needs. 

 

• The rule BR-BT-00262-0211 causes a legal issue in Germany. Are you fixing tis before October 25? 

Answer: This will be fixed in SDK 1.9 and we are seeing to patch the previous SDK versions as this is an exceptional case of a rule that is not legally correct for certain CPV combinations. 

 

• Will there be a written announcement that the deadline of 25 October 2023 for mandatory eForms usage doesn't stand anymore and now instead the old way of publishing can be used until end of January 2024? 

Answer: This is not planned.

 

• Any guidelines for migrating data from one SDK version to another? 

Answer: eNotices2 has its own internal function that copies notice data from one SDK version to another one a best-effort basis. It works for SDK versions that are not too different and the user may have to complete or adjust some fields to satisfy the newer SDK version. We can see if some of this logic could be shared. 

 

• Would it be possible to deploy a local version of the TED-API to avoid possible downtimes of the TED servers? 

Answer: The code of our applications is not available for you to run local instances. You could use the Schematron files in the SDK to run local validations or build your own viewer using the view-templates. But for submission of notices you will depend on eNotices2.

 

• There were 2 legal issues mentioned that had to be corrected until now - could you briefly elaborate on this?

Answer: We corrected: 

1.  a constraint on BT-02-notice to allow ‘can-modif’ notices when the legal basis is Directive 2014/23, 

2.  rules BR-BT-00262-0211, BR-BT-00262-0212 and BR-BT-00262-0213 to also allow CPV codes for services (in addition to works). [In the end, all three rules have been removed in SDK 1.9.1 and in patches to earlier SDK versions] 

 

• The integration between ESPD and eForms could really need some improvements. Is that something you have planned for? 

Answer: Yes, the ESPD, Ontology and eForms teams are working on it. We do not have an estimated date yet though. Currently we are working on ESPD – Ontology alignment.

 

• Do we understand correctly, that we must generate a new API key for the eNotices2 Prod environment even if we currently use eNotices? (So, we can not use our current prod API key to send eForms?) 

Answer: The clean-up of Developer Portal accounts in Production will only affect accounts that haven’t completed their profile. For the accounts that are ok, we won’t touch the API keys and there is no change. We’ll double-check the accounts before we delete any, to be sure not to delete the handful of eSenders that are already live with eForms in Production. Please make sure to provide an accurate go-live date in your profile to help us plan ahead. 

 

• It might be easier and more transparent if business related questions asked at https://github.com/OP-TED/eForms-SDK/discussions be answered there by TED helpdesk? Especially, because often you can not really distinguish between business and technical aspects and need to look at it together. 

Answer: The TED helpdesk is not set up respond on forums like GitHub discussions. We are aware that some issues are somewhere between technical and business issues but please focus on purely technical SDK issues on GitHub to help our team to address them. Perhaps in future a separate forum could be set up with the Commission/DG GROW to handle business issues. 

 

• So does MC Schmidt's (DG GROW) message mean the extension only applies to eSenders in countries that have raised a problem while eSenders in other countries still have to abide by the 25 October deadline? 

Answer: No, it is not limited to the eSender or Member States who approached GROW. eSentool will remain available to all eSenders until 31 January 2024. 

 

• There are many fields that are defined in an imprecise and interpretable way. Do you plan to improve the definition of the fields? 

Answer: The field definitions come from the eForms regulation. Some might be clarified in the latest amendment but this is more of a policy issue. 

 

• Even if old notice are still accepted by the Publications Office, the previsions notices are not exactly legales identiques to the new eForms, Will you provide some guidelines to about how to chose the notices to be published according to the requirements of the 2019/1780 regulation? 

Answer: In eNotices2 we have implemented a wizard to help the buyers to find the right form. You might also find it useful to consult the table of correspondence between the current standard forms and the new eForms – see the post of 3/8/2023 on SIMAP. 

 

• If I publish a ContractNotice in SDK Version 1.5, can I then publish a ContractAwardNotice in SDK Version 1.6 referencing that ContractNotice, or does the ContractAwardNotice also have to be in SDK Version 1.5? If so, how will this be affected in edge cases where support for 1.5 ended?

Answer: Each notice has its own SDK version and there is no need for all notices in the same procedure to have the SDK version. So it’s possible (and likely for long procedures) that a CAN has a later SDK version than its CN. One issue to consider is that the CAN in a later SDK version must conform to the fields and rules in that version. For example, the CAN includes many fields from the CN so if there are new fields or rules for the CAN’s SDK version, then they must be filled. 

 

• BT-171-Tender (Rank in the list of winners) is a mandatory field, IF BT-1711-Tender (The tender was ranked) is set to 'FALSE'. Why should a user be forced to provide a rank in the list of winners if there is no ranking in the first place. For us this rule does not appear logical. 

Answer: Please contact TED Helpdesk with further details (SDK version, etc.) and we will look into it. 

 

• Can MC Schmidt (DG GROW) share on what date the amended implementing regulation will be published? Will it before or after 25 October? 

Answer: Late November at the earliest.

 

• Mentioning the running of notice-viewer locally: The resulting PDF/HTML files of the code in your open-source repositories is way different then what the webservice provides. Publication of the same source code would help immensly in tailoring and hosting a own version of notice-viewer.

Answer: The sample Notice Viewer application does not attempt to recreate the function of the main TED Viewer API. It is a work in progress to showcase how to use the view-templates should you choose to use them. Please get in touch if you have any specific issues.

 

• If it is possible to legally extend the deadline for accepting v9 to end of January. Will it then also be possible in January untill for example the end of 2024? And why would that not be possible? 

Answer: We have decided to keep the acceptance of the current forms open until the end of January 2024. The current forms allow you to publish notices containing all the information that is mandatory under the Public Procurement Directives. Interested economic operators will continue to have access to that information. It is not for the Commission services to assess whether economic operators would challenge contracts awarded by contracting authorities on the ground of the underlying notices’ non-compliance with the prescribed standard forms.

 

• Is there a place where we can find help regarding those 'E1 hacks' mentioned before? 

Answer: We don’t have any particular support for the option to use a Planning notice for a market consultation – this is just a suggestion that is technically possible. 

 

Published: 2 October  2023
Last update: 10 November 2023