Minutes of the fifth eForms Technical Workshop 

23 May 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: 

• What logic is implemented for notice update: e.g. notice noticeID123-version01 is submitted, then update for this notice is submitted noticeID123-verion02. Then user posts the stop for the update noticeID123-version02, will noticeID123-version01 still be published or not? 

Answer: For the same noticeID: while version01 is in Submitted status, you cannot submit version02. You can only submit version02 once version01 has been published – and the information in version02 would be a Change notice with a new noticeID. 

As a reminder, the Lifecycle of eForms notices, their notices ID and (incremented) version IDs was presented during the 3rd eForms Technical Workshop. 

 

• If you delete a repeatable section and add again, its contentCount (or data-counter) is incremented. Why? It is necessary? If it is not necessary, can you tell how to remove counter incrementation in eforms-notice-editor? 

Answer: Please see the answer above. The Notice Editor is a work in progress and may contain bugs. We will look into it. 

 

• How eSender can get notice with status 'NOT PUBLISHED'? 

Answer: Status NOT_PUBLISHED refers mainly to notices that triggered a lawfulness warning and were manually rejected by the Publications Office. As stated on the Preview page, notices submitted in Preview are not currently checked for lawfulness, but we will of course assist eSenders upon request if they need to test the mentioned status in their systems. Please contact us, and we can help you upon request to manually reject a notice in Preview.  

 

• Is it possible to create error cases on the preview environment, like a failed lawfulness check? It would be beneficial if we could create such cases so that we can test our integration and handle retries and other cases that appear after a notice was submitted. 

Answer: Please contact us, and we can help you upon request to manually reject a notice in Preview (lawfulness notices are not currently checked in Preview, as mentioned on the Preview page).  

 

• When will the status PUBLISHING be implemented and available in the preview environment? Haven you implemented the 'publishing' status on eNotices2 production?

Answer: It will not be before October. 

 

• We have concerns from the business about publishing contact information of winners. When checking (at least the ones we looked at) the current result publications, this information is not public. Is there a way to see which fields are published and which are only 'internal’ to address the concerns? 

Answer: Currently it is not possible to unpublish organisation fields. We understand your concern and will look into this.  

 

• If user needs to submit the update, should the previous notice be stopped? 

Answer: Please consult the eForms FAQ. A Change form is only possible for notices whose parent notice has been published. If the parent notice has not yet been published, users can stop publication and resubmit. 

 

• Updates for 2023 in the regulation. What's the impact in the implementation. Will this ‘only’ be a new SDK version, or will it be more complex? Will this be a minor version of the SDK 2? 

Answer: In theory, it should be possible to implement the 2023 regulation changes with a new (minor) SDK version, although the version would have a lot of changes in it (schema, rules, codelists, etc.). Yes, it should be minor version changes. 

 

• The regular periodic results notices (of frameworks) currently contain a variable number of lots. Every new contract is a lot in it. That's why sometimes there is only 1, sometimes there are more lots in the periodic result notice. How can we manage that situtaion in the eform? 

Answer: E4 can be used.

 

• Does eNotice2 API return reason code in the case that TED switches publication state to NOT_PUBLISHED state (eSentool returns it, but we can't get it in the new API)? 

Answer: We have not implemented any reason codes so far – we may have something later for lawfulness and workflow errors.  

 

• Could you please explain again what are Voluntary forms? 

Answer: The Public Procurement Directives list various notes that have to be used. The voluntary notices do not fall under them but gives more possibilities to public buyers: 

• Pre-market-consultation (E1): Currently there are no 'EU’ forms that allow to do market consultations implicitly. Therefore, buyers use often another form like PIN and indicate in the additional information field that this is just a PMC. With the PMC form buyers can explicitly use a form for this. 

• Completion notice (E5): The completion notice is used in some Member States. It is published after the contract was implemented. It depicts how the contract was fulfilled (in time, in budget). It is important to use this form to understand not only the awarding of contracts but also how it was completed. 

• Below EU-Thresholds notices (E2-E4):  Currently, if a buyer wants to publish a notice on TED that is below the EU-Thresholds, they have to use an EU form and indicate in the additional information field, that this does not fall for example under 2014/24/EU. With those forms, a buyer can publish a form on TED that is explicitly a ‘national form’. We recommend to use those forms in the future as well for below the thresholds, because this will help to have harmonised data for notices in public procurement. 

 

• Some fields are described in fields.json but they are missing in the notice-type structure, although the form should contain them according to the regulation. For example, the information about Clean Vehicles Directive in form 29. How should eSender manage it? 

Answer: It’s possible to submit 2022 amendment fields in the XML, e.g. CVD fields. We will add the missing fields to the notice type definitions in SDK 1.9. 

 

• What if there are multiple change notices: should they reference the original contract notice as a 'parent’ or a previous change notice? If there was a change notice - should the following award notice reference the change notice or the original contract notice? 

Answer: In the eForms FAQ - A Change notice may only concern a single notice and contains all the information from that initial notice with applied changes in addition to the information on those changes. 

When a change is applied to a previous Change notice, the consolidated text must integrate all changes from previous versions, and only the latest changes are described in the changes section. 

The following award notice should refer to the last published notice, i.e. in this case to the latest published change notice. 

 

• Is there a way to have a custom HTML of a notice content without writing our own EFX files? 

Answer: Everyone can turn XML into HTML as needed. You can use the EFX provided by OP. If you have any special needs, you need to find your own solution.  

 

• We are waiting for 1.8 because of the translation. Will SDK 2.0 predates the release of 1.8? 

Answer: Most probably SDK 2 will have the same content as 1.8, just different EFX.  

 

• Are you going to make some examples to use EFX tookit? With conditions like '{ND-ServiceProvider} ${OPT-300-Procedure-SProvider is present}'? With EFX do you convert expressions in XPATH conditions? Will you release a jar that we can put in pom.xml to parse those expressions? 

Answer: We will aim to provide you more documentation. However, there are already hundreds of examples in the EFX toolkit.  

 

• The SDK 1.7 xsdSequenceOrder contains some improper value (mainly under ND-Organizations fields) and the xsd validation still fails. When and in which version do you plan to release a fix for these? 

Answer: Thank you for spotting this, we know about it and we are already planning a correction (included in SDK 1.8).  

 

• About Table 1. Organization details requirements in doc https://docs.ted.europa.eu/eforms/latest/schema/parties.html what do they mean the symbol ‘EM’, ‘CM’ in this table? 

Answer: The letters are used in the same way as the extended annex Excel: M is mandatory, O is option, CM is conditionally mandatory, EM means mandatory if the buyer has the information (exist-mandatory). 

 

• For a change notice you metioned that about 10 fields will not be allowed to change. To determine possible impact for us, can you share which fields (the about 10 fields) you are now thinking of? 

Answer: The fields/BTs that we have concluded should not be changed via a Change notice are: BT-04 Procedure ID, BT-03 Form Type, BT-02 Notice Type, OPT-070 Notice Subtype, BT-105 Procedure Type, BT-23 Main Nature, BT-702 Notice language, BT-1501-(n)-Contract previous notice, BT-142 Winner chosen and the BT-195 Unpublished identifiers. This list may still vary before the rules are implemented but we don’t expect any significant changes.

 

• Which API should be used to find information about the submitted notices? On Preview environment, the Publication API /search-esentool does not retrieve anything, however they are listed on eNotices2 under 'My notices'. 

Answer: If you are referring to your own notices, sent by you, you should be able to find them - see Swagger Preview – reminder, the API is not aware of the context of workgroups as stated in the Preview page. 

​

 

• Is EFX used by you to create XML notices from conceptual model? 

Answer: No.  

 

• Why eNotices2 generates valid XML eForms and the editor demo project not? 

Answer: The Notice Editor is only a demo, it doesn’t have all the functionalities. 

 

• Can the source code for eNotices2 be made available so that it can be adapted to own needs? 

Answer: No, we don’t have the resources to make the eNotices2 source code available in a reasonable way. The Notice Editor sample application aims to help implementers (and avoids unnecessary functionality that is specific to eNotices2). 

 

• It is allowed to publish a kind of 'contracted' CAN in the main procedure about the results of the procurements under framework agreement / dynamic purchasing system. How do you deal with them? In this case what does ‘procedure’ and ‘LOT’ level mean? 

Answer: If a procedure is divided into lots, then it is logical to provide contracts for the lots and not for the procedure.  

 

• Is it mandatory to involve all the LOTs of the procurements under framework agreement published in one CAN in the main procedure? 

Answer: No, it is possible to publish multiple CANs for different lots. You can have for example the issue that one lot is not awarded, then you could publish a CAN for this one and publish the other ones later. 

 

• How much time does it take from the reception of the eForms to the effective publication? 

Answer: Please visit the previous workshop presentation about the publication process – Lifecycle of eForms notices. If no preferred publication date is provided, the notice is published as soon as possible, i.e. included in the next available export (during the afternoon of working days) and published at 9:00 the next (working) day on TED. 

 

• We haven’t found 'BT-735 CVD Contract Type' in the notices edited on eNotice2. This BT is optional, e.g. in notice 29. Is this filed under development? 

Answer: Some 2022 amendment fields still need to be added to the notice type definitions (in SDK 1.9), which eNotices2 uses to display on the screen. 

 

• What information do you expect to see in a Changes section of a Change notice? For example, I changed 5 fields in one lot, do I need to present 5 changes with separate description or only one change with some generic description saying e.g. ‘lot X has been changed, compare it yourself’? 

Answer: The Change section should refer to the section/lot that has been changed. The details of the change should be written in the change description field, preferably in a helpful way for the reader (but OP will not check the quality of this information). 

 

• On which 1.x SDK Version the Version 2.0.0 will rely on? Aren’t the rulesets the same or will they be different? Or did they just enhance rulesets in SDK 1.x? 

Answer: SDK 2.0 is still a work in progress, but we plan to have it aligned with the latest version of SDK 1.x at the time it is released. There might be some additional or improved rules, for things that we were not able to express fully or correctly with EFX-1. For further information, please revisit the presentation about EFX 2 / SDK 2 

 

• Will there be a change in the response structure from eForms in the upcoming SDKs? 

Answer: Could you please be more specific? Please contact us via TED Helpdesk. 

 

• Will you add a 'message' property to the 'pattern' object in fields.json that explains the expected format to the user in a human-readable way? 

Answer: We will try to look into it and see what we can do.  

 

• Could you clarify where we can get a list of accepted units for the 'amount' and 'measure' field data types? 

Answer: An amount is composed of a figure (content of the XML element) and a currency (content of the currencyID attribute of the element). Valid currency codes may be found in the currency code-list. (e.g. <cbc:ValueAmount currencyID="EUR">5000</cbc:ValueAmount>) 

Fields of type Measure are exclusively for duration. A duration is composed of a figure (content of the element) and a unit (attribute unitCode of the element). Valid unit codes may be found in the duration-unit codelist. (e.g. <cbc:DurationMeasure unitCode="MONTH">4</cbc:DurationMeasure>) 

 

• Will changes in Codelists will always require a new minor release or could these changes also be implemented in patch releases? 

Answer: Codelists will always be changed through a new minor release, unless there’s a significant problem that requires a patch to previous versions, e.g. to add an essential codelist value (never to remove one). 

 

• In a metadata driven application, is it possible to implement notice types one by one, or by group of notices (e.g. first only the notices based on directive 2014/24/EU, and then on other directives)? 

Answer: Yes, you only need to use the relevant parts of the SDK – and still be SDK-driven.  

 

• I have the following error: rule|text|BR-OPT-00201-0101 with the message: 'Any existing touchpoint should be associated with at least one of the following role/subrole[...]' The message appears to refer to the OPT-201 field which is not displayed in the form. How should I assign a role? 

Answer: Roles are assigned in their context. From an XML perspective, some information is available at https://docs.ted.europa.eu/eforms/latest/schema/parties.html#linkingRolesSubrolesToOrganizationsSection and the XML structure is closely reflected on the UI. Should you have a particular case, don’t hesitate to contact us via TED Helpdesk. 

 

• For the procedure identifier (BT-04), we have seen that there are the following controls: - ensure its uniqueness; - check consistency amongst received notices. Are there any other checks? It is also mentioned that this information does not exist for planning type notices. Why is this? 

Answer: There is no procedure ID for planning notices. Procedure ID helps group notices of a same procedure together. When a new procedure is started, it shall have an ID that differ from any other existing ones. Procedure starts with the Competition. 

 

• Could the need to re-use in eForms notices certain data from existing e-procurement platform be an obstacle in building a fully metadata driven application? 

Answer: Most probably not. We don’t have information about this.  

 

• We have experimented a version shift on eNotices2. I created my account and I don't have all the fields in mandatory. The accounts of my collaborators were created several months ago. I don't have the same version. For them all the fields are mandatory. They have difficulties sending the form 

Answer: Please contact TED Helpdesk with more detailed request. 

 

• Is there a way to see/download in the eNotices 2 Front tool the visual model formed before/after generating the physical model? 

Answer: eNotices2 allows users to export their XML or to view it in PDF or HTML but doesn't expose anything about how it generates the XML.

 

• We have seen differences in some fields between the Front eNotices 2 tool and the eForms Notice Editor. For example, in the durations field (BT-36) in Front eNotices 2 there are two fields (duration type and duration) and in eForms Notice Editor there is only one field (no type). What is the reason? 

Answer: They are two different applications. The Notice Editor is only a demo application, not having all the functionalities. 

 

• In the schematron file ‘complete-validation.sch’ we have at the beginning: queryBinding="xslt2" But some compilators (oXygen) fire a fatal error: Syntax error at char 30 in regular expression: Non-capturing groups allowed only in XPath3.0. Why do you not change with the xslt3 value which is valid? 

Answer: Thanks for your feedback, we were not aware of this issue, as the tools we use do not report this as an error. We will review our regular expressions, and replace the use of non-capturing groups with capturing groups. As we don’t use backreferences, this should have no other impact. Switching to use XSLT3 might cause issues for other users of the Schematron files, so it would be preferable to avoid it. 

 

• How are we supposed to deal with a notice rejected after 48 hours and already published at the national level? 

Answer: It is the same as how the current standard forms are handled. 

 

• The customization ID can be different between the parent and its change notices. A change notice must be a copy of its parent with a change section added. What happens when two rules are contradictory between the two versions of the SDK used, e.g. 1.5 and 1.6? (the change will never validate) 

Answer: The change must comply with the SDK version it has been created with, which may differ from the one of the original notice. There are a few fields that may not be modified. If an information is wrong and couldn't be detected because rules were not applied/inappropriate, the value may still be updated in the change notice which will contain the appropriate rule. 

 

• In March we asked for a complete matrix where all BTs, OPPs, OPAs and OPTs are presented for each subtype. Will you be able to provide such a matrix? 

Answer: No, it is not possible to provide a complete matrix. However, we already provided CSV files – see https://docs.ted.europa.eu/eforms/latest/reference/index.html#_downloads  

 

• Is it possible to get full empty XML files for each sub-type notices? 

Answer: No, we don’t have anything like that.  

 

• When may we expect TED to accept notices with CustomizationIDs containing national tailoring identifier in addition to the SDK identifier? 

Answer: We don’t plan to do that. National tailoring is out of the scope of eForms on TED.

 

• How long does it take to get access to the new TED APIs? No feedback from support. 

Answer: All TED Apps for eForms are already freely available: eForms Preview environment :: TED Developer Documentation (europa.eu). Unfortunately, we don’t register any open questions regarding this. Please contact TED Helpdesk again and we will come back to you. 

 

• Which eForm is suitable for conducting a Market research? E1 (Preliminary market consultation notice) only?  

Answer: Indeed, it would be the E1 form 

 

• Will a blank PDF file of each eForm be published? Just to make the structure more readable and clear to the general public. 

Answer: No, there will be no PDFs. eForms are not designed to be represented as static PDF forms.

 

• The section GR-Procedure-Scope-MainClassification (Main CPV code) is repeatable in some notices, e.g. 29 (award notice) - is this a bug? In other notices e.g. 16 (Contract notice) it is not repeatable which is probably the correct option. 

Answer: We will look into it, thank you for spotting that (fixed in SDK 1.8).

 

• At the moment, in the Preview environment it is still possible to submit update if a previous notice is in status submitted (not published and not stopped yet). Did I understood correctly from your previous comment that should not be possible? 

Answer: When dynamic checks are in place, users will not be able to do this; in any case, users should already respect the flow of eForms notices.  

 

• Technically, how it will be possible to submit group notices on a quarterly basis of the procedures creating the framework agreement, if the number of lots cannot change during the procedure? 

Answer: Multiple LotResults for a given Lot and each their associated contract. 

 

• It was said we may contribute and open a new pull request. What parts do we have the right to modify? What if I see a clear issue in fields.json, may I propose a change instead of asking for changes in GitHub discussions? 

Answer: The eForms-SDK repository on GitHub can only be modified by members of the OP team. So to propose a change you can fork the repository, make the changes, and then create a pull request from your repository to this one. For more details see the GitHub documentation at: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork. Please note that most of the content of the SDK is exported from a database, so we might not be able to merge pull requests. But you can always use a pull request to show precisely what you like to be changed. 

 

• My eNotice2 registration: I could not create a change notice. The change notice is not in my list of the possibility procurement types. My colleague has a change notice in the list but she has not contract modification (but I have). I saw settings I enable all of proc.types. What causes the discrepancy? 

Answer: Please contact TED Helpdesk and we will get back to you. 

 

• Have the eForms sent from Spain been sent through the eNotices2 tool? Could you tell us which organization has sent them? 

Answer: It was sent by Ayuntamiento de Ripoll: https://ted.europa.eu/udl?uri=TED:NOTICE:262891-2023:TEXT:EN:HTML&src=0 

 

• Does the eNotices2 tool use the SDK? What version? 

Answer: The eNotices2 web interface gets updated to use the latest SDK version so it moved to SDK 1.7.0 this month (May). The eNotices2 API accepts notices submitted in all active SDK versions, currently 1.3 to 1.7 (eNotices2 now supports up to SDK 1.8).

 

• How can we find the published eForms? 

Answer: There is an expert search query that gives the list of eForms on TED: 

TD=[NOT (C or E or G or I or D or P or M or Q or O or R or 0 or 1 or 2 or 3 or 4 or 5 or 6 or 7 or 8 or 9 or B or S or Y or V or F or A or H or J or K)].  

 

• Changes/modification: Does the customization ID for a change notice shall be the same that its parent notice? 

Answer: No, all ‘active’ SDK versions are acceptable. It’s also possible to send a Change notice linked to a notice that is in a deprecated SDK version. But the changed notice must be in an active SDK version (and therefore respect the schema and rules of that version). 

 

• Wrong definitions in fields.json - BT-15-Lot in form 16 is mandatory in fields.json (with no condition), but also conditionally forbidden, which is contradictory. We also checked the schematron files, this field is not mandatory, so probably just the fields definition is wrong. Same with BT-615-Lot. 

Answer: In fields.json, no condition is added to the mandatory rule as it shares the same condition as the forbidden rule (i.e. as soon as it is allowed, then it is mandatory). 

BT-15-Lot and BT-615-Lot are exclusive (access to procurement document is either restricted or not). 

The absence of rule in the schematron is most likely due to the deactivation of the conditional rules which are being progressively reactivated. 

 

• Will the validity check notices be done on weekend/holidays? 

Answer: The TED APIs are available 24/7. Whenever you submit a notice, it will be validated.  You can also call CVS separately whenever you want. The only manual intervention that happens on working days is for notices that need to be checked for lawfulness (e.g. notices from outside the EEA that don’t use EU funds). 

 

• Conversion of notice subtype code issue from TED-XML (JOUE) notice: in case of a change notice applied to an ‘old’ TED-XML notice, how can we determine the notice subtype code? 

Answer: There is not an exact correspondence between current TED-XML notice types and eForms notice types but most have a clear equivalent. A table of correspondence was published in August at https://simap.ted.europa.eu/documents/10184/320101/Correspondence+between+eNotices+and+eNotices2/9f5cd4ee-158f-44a4-988a-b86e16441655 

 

• What kind of controls could lead to a rejection (not published) after 48 hours? Can you tell us more about your manual rejection process? 

Answer: If your notice was validated successfully and there is no lawfulness warning, then there should be no rejections. Our internal OJS coordination team review lawfulness and possible technical rejections on working days. 

 

• In which version of the SDK the XSD is supposed to be final or at least ‘stable’? 

Answer: Each SDK version is stable and consistent by itself. You can go live with any SDK version from 1.3 onwards. We do not expect any signification XSD schema changes in SDK versions until the next regulation amendment. The schema changes in each SDK version are small improvements but they don’t stop the successful validation of notices. 

 

• Will the tagging of rejection motives be more explicit than other reason? 

Answer: The messages for CVS rules will be improved with SDK 1.8. Could you clarify what you mean by ‘other reason’? Please contact TED Helpdesk and we will get back to you. 

 

• We are having problems running the Schematron validation. Generated XLST's are huge. What is the recommended way to do this without entering into performance and memory issues?  

Answer: For our Central Validation Service, we are using the Java library 'ph-schematron', in the 'pure' mode. This approach does not convert Schematron into XSLT files, and seems to require less memory that the other approaches we have tested. 

Based on our experience, using generated XLSTs can also validate notices with good performance, provided the XLSTs are kept in memory between each validation. 

 

• About API expiration key: we encountered a problem with expiration of API key. Why? Could we be notified if API key expired? 

Answer: It was a bug. It was related to missing email notifications for expiring API key. It was fixed in Preview on 20/06/2023 with release 1.1.2 and on 10/07/2023 in PROD with release 1.1.3.

 

• Is there already a timeline how long which SDK version will be accepted? E.g. how long will SDK 1.5.1 still be supported? 

Answer: Please see the presentation: 1.5.x will be active and supported until January 2024. 

 

• Does dynamic validation happen when the notice being changed has been published with ted-xml? 

Answer: We don’t plan any validation for a Change notice that refers to a TED-XML notice. 

 

• In case of unavailability of the publication or validation API, will you lift the rule on the dispatch date after restoring your service? 

Answer: This is not planned but we will see what contingency measures could be needed. SDK 1.7 requires that the dispatch date must be between –2 days and +1 day from today – so OP would have 2 days to restore the service. 

 

• Is the Schematron validation in the SDK identical to the one performed by the CVS? 

Answer: Yes, CVS uses the Schematron files from the SDK. 

 

• How are we supposed to deal with the customization id in case of a major SDK release? 

Answer: Can you be more specific? Please contact TED Helpdesk and we will get back to you.

 

• About preferred publication date: shall we wait the european publication before publishing at the national level? 

Answer: According to the Directive 2014/24/EU, Article 52(1) Notices referred to in Articles 48, 49 and 50 and the information contained therein shall not be published at national level before the publication pursuant to Article 51. However, publication may in any event take place at the national level where contracting authorities have not been notified of the publication within 48 hours after confirmation of the receipt of the notice in accordance with Article 51.

 

• XSD schema is based upon UBL Standard. What could provoke a modification in the XSD? 

Answer: Amendments to the eForms regulation are biggest source of changes to the XSD. Other changes are limited to small improvements or corrections. 

 

• What are the commitments in terms of service availibility of all the APIs? 

Answer: We cannot provide a commitment in terms of availability. The current services are available as much as possible and we expect to provide the same kind of service for eForms. Any downtime of services is communicated beforehand.

 

• DISPATCH DATE: new rules are integrated in 1.7 version of SDK. Which impact for change and modification notices since the 1.7 version? 

Answer: We haven’t yet implemented any specific rules for Change or Modification notices. 

 

• In which version type (minor or revision) of the SDK the XSD could be modified? 

Answer: A schema/XSD change is considered a minor SDK version, e.g. 1.7 may include a schema change compared to 1.6 but 1.7.1 will never have a schema change compared to 1.7.0. 

 

• If a notice is accepted because it does not contain errors, what are the subsequent steps until its publication in TED? Concretely, can it happen that it is manually rejected, whatever the reason? 

Answer: See previous workshop presentation about the publication workflow and notice lifecycle (Submitted->Publishing->Published) - The Lifecycle of eForms notices. Manual rejection is basically due to lawfulness checks. 

 

• If we stay on a previous version of the SDK (e.g. 1.6), will the additions of future versions be integrated in this previous version? In particular, will the new fields always be patched in the later versions (regardless of the 12 month support period)? 

Answer: Only view templates and translations are systematically patched on earlier active versions. New fields will only be added to new SDK versions. 

 

• How to manage rule conflicts between two SDK versions? 

Answer: Each SDK version is self-contained so there are no rule conflicts. It could be that a later SDK version adds, improves or corrects rules from earlier SDK versions. 

 

• Can the Publications Office ensure that eForms generated in v1.6 of the SDK will forever be accepted for publication in TED ? 

Answer: No, SDK 1.6 is planned to be deprecated in March 2024, i.e. 12 months after its release. 

 

• How can we populate the html with previously entered data considering repeatable sections? 

Answer: Please clarify your question by contacting TED Helpdesk. 

 

• How can we cancel a whole procedure? 

Answer: Procedures are ended by publishing a contract award notice. If the procedure is cancelled, the CAN must say there’s no winner (for all lots if applicable). 

 

• When do you think you give us final version of translation and patches on previous version of SDK? 

Answer: The translations in SDK 1.7 are being patched on earlier version (1.3 to 1.6), which hopefully will be completed in the next week or two. SDK 1.8 includes the translations for rule messages, which have also been patched back to SDK 1.3

 

• Where is it possible to find examples for each eForm subtype? 

Answer: Please see the /examples folder in the SDK for sample XML files for each SDK version. 

 

• How can we insert personalized messages to tell the user how to fill in a specific field? For example, if you enter a URL in the wrong format, indicate a correct format. 

Answer: The CVS rule messages should provide some guidance to buyers about any errors in their notices. You may choose to add other types of messages (especially in your web front-end) to assist your users, based on the rules in the SDK. 

 

• Can you please elaborate on the new dynamic rule for Notice dispatch date and the reason for adding it? "New dynamic rule added to ensure that BT-05(a)-notice Dispatch date is -2 days or +1 day from current date" 

Answer: OP has 5 calendar days to publish the notices we receive.  We cannot afford too much delay between the date the buyer submits their notice (in the eSender’s system) and the date OP receives it. 2 days provide a generous time for the eSender to submit their notices (compared to the current 12 hours in eSentool).  +1 day has been added for dates which might be ‘in the future’ due to the time zone. 

 

• eNotices2: transfert with another context: what does it mean? 

Answer: Context means private organisation/workgroup/structured organisation/parts. 

Reminder to eSenders: in the Preview page regarding workgroups: 

If you are an eSender, please note that the concept of Workgroups is reserved for users of eNotices2 web User Interface (UI). eSenders/ users of eNotices2 API can still create workgroups in the UI of eNotices2 but the API is not aware of the context of workgroups, i.e. no API function can be performed on a notice that has been manually transferred to the context of a Workgroup. 

 

• Lot identifiers. Is it fine if we carry over the technical ID (i.e. LOT-001, LOT-002) of the prior notice, or the lots in the new notice (say, the CAN), HAVE TO go from scratch and ONLY the internal ID matches? 

Answer: It’s fine to keep the same technical IDs throughout the procedure but we chose not to impose this requirement. You are free to use the internal IDs that work best for you or your buyers. 

 

• With regard to the provisions of paragraphs (2)-(3) of Article 50 of Directive 2014/24/EU, we will have the possibility to submit group notices of the results of the procurement procedure for contracts based on the framework agreement on a quarterly basis? 

Answer: This will not change. You can still submit contracts based on framework agreements on a quarterly basis. The same applies for DPS Article 50 (3). 

 

• Do we understand well, that in the case of a multi-lot procedure, we will be able to submit a contract award notice (CAN) for each lot one by one, considering the independent life of the lots? 

Answer: Yes, for a given procedure there may be a Result notice per lot when needed.

 

• There is a procurement and we published the competition notice. How can we add or delete a lot after it? 

Answer: It’s not possible to add or remove a lot for a notice as this is a significant change to the procedure. You will need to publish a new competition notice. 

 

• Are the fields company ID (BT-501), telephone number (BT-503), email address (BT-506) for contractors and bidders (according to SDK V1.6) mandatory and will this information only be of administrative nature or will this information be published in the notices? 

Answer: All these are part of public information as recorded in the business register. No personal information is expected, and this information will be published 

 

• If I have to make a change notice. Why do I have to set that procurement document is changed or not, in every change section? 

Answer: There is no other way to detect that Procurement Documents have changed than having this clearly stated using the indicator. The use of the indicator is only mandatory when a change to these documents has taken place. Multiple lots and their respective procurement documents may be subject to changes which may therefore require the existence of multiple ‘change’ with the indicator.  

 

• Change notice: There is a case: the procurement document has changed only. The document applies to the whole procedure. What is value of the Change Previous Section Identifier (BT-13716)? 

Answer: If it is a case of a procedure not subdivided into lots, multiple Section IDs may be listed and the ones to be included depends on the object referred to (please consult the documentation at https://docs.ted.europa.eu/eforms/latest/schema/identifiers.html#_referring_to_sections_of_a_notice ) For procurement documents, one of the identifiers to be present is PAR-xxxx/LOT-xxxx which refers to the technical identifier of the Part/Lot (or pseudo-Part/Lot in case of non subdivision) inside the notice. 

 

• Is there a check (or validation) on TED in which the change notice checks for changes compared to the original notice? Does it cause any problem if there is any differences between the original and change notice and it is not indication in the change section? 

Answer: There are no validation rules yet for Change notice but it is planned, mainly to check that certain fields are not changed. We don’t have any plans to compare the content of all fields to check that the change has been correctly mentioned in the change section. 

 

• BT-719 Procurement Documents Change Date. Now this date is when the notice is published. What date can we add here? We do not know when the notice will be really published. 

Answer: Procurement Documents Change Date refers to the actual change date of the Procurement Document (publication date of the updated procurement document).

 

• Is there any differences between TED CVS and SDK Schematron validation rules? There are a lot of wrong error messages without usage in SDK. Example: BR-BT-00719-0004 vs. BR-BT-00719-0054 

Answer: CVS uses the Schematron files from the SDK. There are messages in rule_*.xml that are not used by Schematron: we don’t always remove messages when removing a rule, and when patching an older SDK we might add a new message for a rule that did not exist in that older version. You should not use the content of the rule_*.xml files as a reference for the rules currently in place. 

 

• There is an ‘inChangeNotice’ element in fields.json. It has 2 occurence in the json file. Do you plan to use this element more widely to indicate which field cannot be modified in change notice? 

Answer: This is present in fields.json when there is an associated rule which has values for canAdd, canModify, canRemove. As you can see there can also be associated constraints. Concerning the wider use, we have more rules for this but they are marked as draft for now. It is possible that in the future we will enable these rules and thus the fields.json would have more cases like this. 

 

• Sometimes all the details of awards criterion are in the procurement documents. Is there any option to not specify the award criterion, but to indicate that it is found in the document? 

Answer: We are seeing with GROW what options we could provide for these cases.

 

• Notice E1 - when we can develop this notice? When we can find its settings in fields.json? 

Answer: E1 notice will only be implemented in 2024, after the 2023 regulation amendment. 

 

• How can I treat a situation when the buyer or the tenderer has a legal succession or company fusion (change a lot of data, e.g. tax number)? 

Answer: Such a scenario can be handled with a Change notice if it's before the contract signature or with the Contract Modification if it's afterwards. 

 

• Change notice: BT-140 Change Reason Code. What is the differences between the ‘cancel’ and ‘cancel-intent’? 

Answer: ‘Cancel-intent’ is a very specific type of a change (for legal reasons), and it is not mandatory for the eForms workflow. Usually, the user only needs to publish a Contract Award Notice.   
The ‘cancel-intent’ reason is used to notify that there is an intention to cancel, e.g. a Lot, a procedure, etc. 

Additionally, we don’t recommend eSenders to offer ‘cancel’ to their buyers as it has many implications for their procedures. 

 

• There is a case: there is procurement I have published 16 (competition), 29 (result) notice and after that I published a contract modiciation. Can be a situation when I have to let to make a result change notice? If I have to let it, does it have any consequence to the contract modification notice? 

Answer: The contract modification comes after the result notice – and it is a change logically of what was agreed at the time of the award. While there can be additional contract modification notices, the result notice should not be changed due to a contract modification.  

 

• When a new version of the eforms notice viewer will be released as open source and what the further development plan for it is? 

Answer: The sample notice viewer (at https://github.com/OP-TED/eforms-notice-viewer) is developed as resources allow. It is available under the EUPL licence: https://github.com/OP-TED/eforms-notice-viewer/blob/develop/LICENSE  

 

Published: 25 May 2023
Last update: 5 September 2023