Understanding the Lifecycle of eForms and Notices Workshop
Explore the technical aspects of eForms and notices in this workshop, covering topics such as status, timing, scenarios, publishing dates, and validation processes. Discover the various actions that can be performed on different notice statuses, including draft, deleted, and validation failed. Gain insights into managing eForms effectively via the web UI and API.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
THE LIFECYCLE OF EFORMS NOTICES 3rdeForms Technical Workshop 1 February 2023 Karl Ferrand TED unit -Publications Office of the EU
eForms: status, timing, scenarios eForms: status, timing, scenarios Notice status and workflow eForms publishing dates and times Scenarios: stop, change, cancel, continue Vecteezy.com
Overview of eForms status Overview of eForms status Deleted Publishing Published eNotices2 web UI Draft Not Published Submitted Stopped eNotices2 API Validation Failed End status for a given business ID (notice ID + version ID)
Draft Draft Actions that can currently3 be performed on a draft notice via the UI: Only exists in the web User Interface (UI) of eNotices2 The UI creates new notices in draft status The notice stays in draft during editing and until it has been successfully submitted with no CVS errors When the notice is being edited in the UI, it will appear as locked 1 for other members2 When importing an XML via the UI, the notice will be imported as draft 3 An eSender cannot send a draft notice via the API We don t recommend eSenders to use the UI to manage their notices
Deleted Deleted Actions that can be performed on a Deleted notice via the UI: Only exists in the web User Interface (UI) of eNotices2 Notices can be only deleted manually in the UI Deleted is a UI status search parameter and can be queried via the API A deleted notice can be restored manually1 Deletion is permanent after 30 days A notice with the same businessID cannot be submitted via API
Validation Failed Validation Failed Actions that can be performed on a Validation Failed notice via the UI: Only exists for eNotices2 API1 At submission, a notice ends in validation failed status if it has triggered CVS errors HTTP response is 201 created with "validationReportUrl" and "success"=false The validation report is stored in eNotices22 Validation Failed is an end status before publication - the given business ID (notice ID + version ID) cannot be used again3 - a notice that has failed can be resubmitted with a different and incremented version ID4
Submitted Submitted Actions that can currently be performed on a submitted notice via the UI: Via the UI, a notice can get status submitted status only if it triggers no CVS validation errors Via API, a notice can get submitted status only if it is well-formed XML and triggers no CVS validation errors1 A submitted notice is processed by the OP s back-end application (TED Monitor 2022) If the notice has a lawfulness warning2, OP will check them manually and status remains as submitted If there s no lawfulness warning, a submitted notice is ready to be published
Stopped Stopped Actions that can currently3 be performed on a stopped notice via the UI: A buyer/eSender can request to stop a notice before it is published A notice can only be stopped when in status submitted 1 The time to stop a publication may only be a few hours (if publishing as soon as possible ) Stopped is an end status before publication - the given business ID (notice ID + version ID) cannot be used again2 - a notice that was stopped can be resubmitted with a different and incremented version ID3 - in the UI, a resubmitted4 notice will be assigned a new version ID (+1)
Not published Not published Actions that can currently3 be performed on a Not published notice via the UI: A notice rejected manually by OP for lawfulness will end as Not published OP will aim to validate faster than the maximum 5 calendar days but this is not guaranteed Exceptionally technical workflow errors at OP might also lead to Not published 1 OP will email the buyer directly to explain the reasons for rejection Not Published is an end status before publication - the given business ID (notice ID + version ID) cannot be used again2 - a notice that is not published can be resubmitted with a different and incremented version ID3 - in the UI, a resubmitted4 notice will be assigned a new version ID (+1)
Publishing Publishing Workflow of notices that did not trigger any CVS errors and no lawfulness warnings: Publishing means that the notice has started its publication process1 Notices in status publishing status cannot be stopped Notices stay in Publishing between the export and the publication on TED the next OJS day2 Publishing is not yet exposed in the UI or as an API status (planned in the coming months)3 Submitted Publishing Published Workflow of notices that passed manual lawfulness checks: Submitted Publishing Published Workflow of notices that were rejected upon manual lawfulness checks: Not published4 Submitted
Published Published Actions that can be performed on a published notice via the UI: The notice has been successfully published in the OJS on TED Once a notice is published, a user can continue procedure or create a change notice1 Status published is an end status The notice cannot be deleted from TED Once a notice is published, no other notices with the same notice ID will be accepted1
Publication requirements in directive 2014/24/EU Publication requirements in directive 2014/24/EU1 1 OP publishes within 5 calendar days OP gives confirmation of receipt and publication to buyer (notice author) National publication may happen 48 hours after receipt
Dispatch dates Dispatch dates Dispatch date (BT-05) is the date (and time) the notice is sent by the buyer to the eSender or submitted via eNotices2 Dispatch date is referred to across the directives, also as "transmitted", "sent" or "dispatched" Also fill in the eSender dispatch date (and time) (BT-803) it is currently optional but could be made mandatory in the long term Dispatch date cannot be 1 day before today or after now at the time of validation1 This allows for at least 1 whole day for possible technical delays on either side2 but if eSenders are slow to send, OP has one less day to publish
Basic publication process Basic publication process After submission and if no lawfulness check, a notice will be in the export (in TED Monitor 2022) that corresponds to its publication date The export happens in the afternoon of every working day before an OJS publication date1 There is no guarantee of the time of export: it is generally around 16:00 CET but it can be anytime between midday and midnight CET A notice included in the export will be in status Publishing and can no longer be stopped Notices are published at 9:00 CET in the Supplement of the Official Journal on TED2 The notice is updated with the TED publication ID and publication date can be queried via API Until a notice is published, it cannot be changed or continue its procedure Once a notice is published, no further notices can be submitted with the same notice ID
Preferred publication date and "as soon as possible" Preferred publication date and "as soon as possible" If no preferred publication date is provided, it means the buyer has chosen to publish "as soon as possible and the notice will be included in the next available export (if no lawfulness check)1 Buyers can set their preferred publication date (BT-738) - OP will aim to satisfy if the OJS release calendar allows it It can be no earlier than 2 days before and no later than 2 months after the dispatch date2 There is no guarantee that the preferred publication date will be respected, mainly due to weekends and non-working days If the publication date isn t possible, the system will pick the earliest possible date after it3 If you choose to publish on the national platform without waiting more than 48 hours and OP rejects your notice after 48 hours, it is your responsibility to handle the situation on the national platform Preferred publication date (and the OJS release calendar) allows you to define the publishing timing of your choice with the option to publish in less than 5 days
Change notice Change notice It is possible to change a notice only once it has reached Published status. With a Change notice, a new notice is published, including all the information of the original notice, with both the unchanged and changed fields - unlike the current F14, it consolidates and logically replaces the original notice (which remains published) A Change notice must have a new notice ID It must link to the (published) notice that is being changed If you want to change a notice that has not yet been published, you must first stop the publication of the original notice and then submit a new notice (not a change) We will not implement Change notice as a separate notice type1 planned in a future SDK Rules (to come): most fields can be changed, except notice subtype, legal basis, CPV and other core fields
Reasons for Change notice Reasons for Change notice A Change notice must include the reason for change (BT-140): Corrections: a common reason, usually by the buyer but can also be by the eSender Information updated: also common, to add or update something Info release: for when new information becomes available that was originally postponed for some reason Notice cancelled: makes the notice null and void - but this has consequences, like dates and deadlines, because everything starts from scratch as if the original notice had never been published. This should only be used exceptionally and before any further steps in the procedure. Once a notice is cancelled, it can no longer be followed by any other type of Change notice. Cancel notice is not cancel procedure or lot! Cancel intention: this is just an indication that buyer intends to cancel the original notice, needed to satisfy a court case Also see the descriptions for each code in the codelist at: https://op.europa.eu/en/web/eu- vocabularies/concept-scheme/-/resource?uri=http://publications.europa.eu/resource/authority/change-corrig- justification
Cancel lot or procedure Cancel lot or procedure In all cases, each lot or procedure must be closed with a contract award notice To cancel a lot or procedure, the contract award notice will have no winner chosen (BT-142) and must provide a reason (BT-144) - this is the only mandatory step to complete the lifecycle of the lot or procedure. Optionally: change the contract notice with additional information to say what has happened and provide an indicator if the procedure will be relaunched or not (BT-634) A lot that has a CAN with no winner will continue to be in the CN forever it cannot be removed even if there are changes to the other lots Recap: make sure you and your users distinguish clearly between: - Stop publication to catch the notice before publishing - Cancel notice - an exceptional type of Change notice to use very sparingly - Cancel lot or procedure nothing is cancelled in terms of publication, it just closes your notice lifecycle
Continue procedure Continue procedure Notices should follow a logical sequence like PIN->CN->CAN Use the same procedure ID to link them together - except for Planning notices that have no procedure ID and must be linked via previous planning ID The link to the previous notice must be to a published notice If the procedure overlaps the transition to eForms, link back to the previous TED-XML publication ID Rules (to come): some fields cannot differ from the previous notice, like legal basis, CPV and other core fields EC/OP plans to list the logical sequence of forms but this won't be enforced by rules - certain rules will already impose some constraints, like needing to keep the same legal basis
Unpublished fields Unpublished fields Also known as "not immediately published", "publish later", "withheld", "privacy", "confidential" fields Every unpublished field has a reason code, description and a date when the field can be published The publication date (BT-198 Unpublished access date) can be up to 10 years after the dispatch date and must be at least 1 day after the dispatch date (rules will be set in SDK 1.6) If the publication date is not provided, the field will never be published Unpublished fields are visible in the public notice but the values are masked1: -1 for numbers, "unpublished" for texts/codes/id/url, 0 for indicators, 1970-01-01Z for dates The back-end application TED Monitor 2022 will keep track of all notices with unpublished fields no action is needed by the buyer/eSender and notices stay in Published status When the publication date is reached2, the notice is published again on TED, with the same notice ID but a different publication number and OJS issue - this can happen multiple times if there are unpublished fields with different publication dates
THANK YOU FOR YOUR ATTENTION Links https://docs.ted.europa.eu - Developer guide, APIs, Preview, FAQ, every SDK version https://github.com/OP-TED/ - Components and code for developers, SDK, discussions https://op.europa.eu/en/web/ted-eforms - OP eForms events Any questions? Business: ted@publications.europa.eu Technical: https://github.com/OP-TED/eForms-SDK/discussions/
