Working Group Meeting
Date: 11/03/2025
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Achilles Dougalis
Note editor: Grzegorz Kostkowski
Agenda
-
Reviewing and refining ORSD for eAwarding.
-
Questions about selected GitHub tickets. Discussions
Discussions
-
A question was raised regarding outstanding GitHub issues that were to be prepared by the mappings team. It was clarified that the tickets had not yet been prepared.
-
The activities description for eAwarding ORSD was discussed.
-
It was clarified that the Dynamic Purchase System must be completed before the Call for Tender.
-
It was confirmed that the Award Notification is related to a Dynamic Purchase System only if an individual is awarded a contract within the DPS.
-
It was determined that the Award Notification does not belong to the eAwarding module.
-
It was noted that there is no suitable location for the DPS within the current structure.
-
It was concluded that the scope of eEvaluation, as described in the ORSD, contained activities that do not belong to the eAwarding phase.
-
A decision was made to transfer three transactions to a newly established eQualification module, which was extracted from eAwarding. These transactions include Tenderer Qualification Request, Tenderer Qualification Receipt, and Tenderer Qualification Response.
-
-
The participants worked on the ORSD for eQualification module.
-
A new ORSD document was created for the eQualification module based on the one for eAwarding.
-
A precise definition of eQualification was formulated, capturing its scope, which pertains to DPS and requalification systems for works.
-
The Economic Operator role was added in addition to the roles previously defined for eAwarding.
-
The distinction between DPS and the Qualification System was clarified. It was stated that the DPS is entirely electronic as for now.
-
An additional distinction was made by explaining that the Qualification System is limited in time, whereas the DPS is not.
-
The definitions of QualificationApplicationRequest and QualificationApplicationResponse were reviewed in UBL documentation. It was noted that, in UBL, the response originates from the Economic Operator, whereas the request is sent by the Buyer.
-
An explanation was provided regarding the receipt, which is a document that contains only a yes or no response.
-
A reference was made to the Directive 24, which states that the Tender Qualification Submission for DPS is considered a request to participate and is submitted by a candidate.
-
A correspondence was established between source definitions in PEPPOL and existing ePO classes to identify any missing components. It was concluded that all necessary concepts had already been modelled but some require renaming.
-
-
It was determined that the Call for Competition corresponds to the CompetitionNotice and appears to already be covered.
-
The use cases and natural language statements that were initially created for eAwarding were transferred to the ORSD for eQualification.
-
The eAwarding use cases and natural language statements were revised.
-
It was noted that an award decision is rarely published on the Buyer’s website and is therefore not always accessible to the Tenderer.
-
It was clarified that the Award Decision may be linked to Award Outcomes, but not to tenders.
-
It was clarified that the Award Decision is not linked to a Lot.
-
The statement regarding the standstill period was refined. It was originally stated that the standstill period lasts for 30 days, but it was adjusted to specify that the period lasts for one month.
-
It was communicated that the organization of tickets on the ePO 5.0.0 issues board had been modified, and some tickets had been categorized as low-hanging fruit.
-
Selected GitHub tickets were reviewed. Out of nine planned tasks, three were discussed, and a decision was reached for one of them.
-
-
-
The possibility of releasing a patch was discussed regarding ticket #476. It was noted that the ticket does not clearly specify the nature of the bug. A question was raised regarding why the ticket is included in the scope of version 5.0.0.
-
Ticket #711 was reviewed. It was noted that a decision had already been made during a past meeting.
-
Ticket #374 was analysed. It was stated that the issue is not of concern if it is harmless. Nonetheless, a suggestion was made to remove the attributes mentioned in the ticket if they do not serve a specific use case. A decision was made to remove these attributes, and the decision was documented in the ticket.
