Cumulative content of Working Group Meetings in 2025

Working Group Meeting

Date: 25/09/2025
Participants: Natalie Muric, Paul Donohoe, Sellitto Giovanni Paolo
Model editor: Andreea Pasare
Note editor: Andreea Pasare

Agenda

  • Missing definitions

  • Discuss GitHub issue 788: Unmappable eForms fields regarding transportation in T02 notice subtypes

Discussion

A set of proposed definitions were agreed and skos:historyNote tag with value "WG approval 25/09/2025" will be added to the specific concepts with their new definition.

Contract terms and other information of a Tender:

OPP-035-Tender and OPP-033-Tender are codelists with single values and were not implemented.

Because T02 notice is published after the Contract is signed, it would mean there will a one to one relationship between the Tender and the Contract.

It was agreed to implement these terms at the level of the epo:ContractTerm. If, in the future, there will be a need to link these terms at the level of the epo:Tender, a predicate epo:Tender epo:foreseesTerm epo:Term will be added.

OPP-080-Tender: Kilometers Public Transport

Implemented the predicate epo:ContractTerm epo:definesPublicTransportationKilometers epo:Quantity

OPP-032-Tender: Revenues Allocation

A new definition was approved for the attribute epo:hasTicketsSalesRevenueAllocation: "Share of revenue with regard to ticket sales."

OPP-034-Tender: Penalties and Rewards Description

A new definition was approved for the attribute epo:hasPenaltiesAndRewardsDescription: "Explanatory text about the applicable penalties and rewards."

OPP-031-Tender: Contract Conditions Description (other than revenue allocation) & OPP-030-Tender: Contract conditions Code

Implemented 5 values from codelist contract-detail as attributes at the level of the epo:ContractTerm:

  • epo:hasCompensationCostParametersDescription with the following definition: "Explanatory text about the parameters of the financial compensation."

  • epo:hasParticularConditionsDescription with the following definition: "Explanatory text about conditions not mentioned elsewhere."

  • epo:hasGrantedExclusiveRightsDescription with the following definition: "Explanatory text about the applicable right entitling a public service operator to operate certain public passenger transport services on a particular route or network or in a particular area, to the exclusion of any other such operator."

  • epo:hasPublicServiceObligationsDescription with the following definition: "Explanatory text about the requirement defined or determined by a competent authority in order to ensure public passenger transport services in the general interest that an operator, if it were considering its own commercial interests, would not assume or would not assume to the same extent or under the same conditions without reward."

  • epo:hasSocialStandardsDescription with the following definition: "Explanatory text about the standards required, including staff concerned, detail of their contractual rights and obligations and conditions under which employees are considered to be linked to the services."

All definitions used for concepts implemented for T01 and T02 notices will be refined once we have more information about the values within the contract-detail from DG-MOVE.

OPP-040-Procedure: Main Nature - Sub Type

epo:hasTransportServiceType defined and implemented at the level of the epo:ContractTerm. It is used in both T01 and T02.

FwAAgHoIZ0BjvbMwn4QF2MnmXn9NOAMAgIYSzoBGi+NZPPOsKJ6lA4+7qmgmnAEAQHMIZ8BjqRgaYCcpft8BAIB6CGfAY6kYGmAnKX7fAQCAeghnwGOpGBpgJyl+3wEAgHoIZ8BjqRgaYCcpft8BAIB6CGcAAAAAUEE4AwAAAIAKwhkAAAAAVBDOAAAAAKCCcAYAAAAAFYQzAAAAAKggnAEAAABABeEMAAAAACoIZwAAAABQQTgDAAAAgArCGQAAAABU+P8gQXQvxdTBeQAAAABJRU5ErkJggg==

Working Group Meeting

Date: 23/09/2025
Participants: Natalie Muric, Paul Donohoe, Sellitto Giovanni Paolo
Model editor: Andreea Pasare
Note editor: Andreea Pasare

Agenda

  • Discuss GitHub issue 788: Unmappable eForms fields regarding transportation in T02 notice subtypes

Discussion

The following model is proposed (see also meeting minutes from 21/01/2025):

cuOAbgAAAABJRU5ErkJggg==

Lot tendering terms (execution requirement)

OPT-070-Lot: Reserved Execution justification is used only in CEI, while BT-736-Lot: Reserved Execution (that is mapped to the codelist "applicability") is used in other notices as well.

"Reserved execution" within the context of Directive 2014/25/EU refers to a situation where the law or a regulation specifically assigns a particular task or service to a certain entity, thus reserving it from being opened up to open competition through a standard procurement procedure. This means a contracting entity, even one covered by the directive, might be legally obligated or permitted to engage a specific provider, rather than conducting a formal tender.

Implemented epo:hasReservedExecutionJustification to be used when mapping OPT-070-Lot: Reserved Execution justification in the case of a CEI notice with the following definition: "An explanation about why the Contract must be performed in the framework of sheltered employment programmes."

A new definition was approved for the predicate epo:ContractTerm epo:hasReservedExecution at-voc:applicability: "Relation indication whether the execution of the contract must be performed in the framework of sheltered employment programmes."

A new definition was approved for epo:QualityTargetInformation: "Information about a specific performance goal."

A new definition was approved for epo:hasQualityTargetDescription: "Explanatory text about the performance goal."

A new definition was approved for epo:hasQualityTargetCode: "Relation indicating the type of performance goal."

A new definition was approved for the predicate epo:hasQualityTargetInformation epo:concernsContractTerm epo:ContractTerm: "Relation indicating the type of performance goal."

Assets in a Contract

It was mentioned that the T02 notice is published within a year after the Contract is awarded.

8D1AIuaU3XM7EAAAAASUVORK5CYII=

It was mentioned that if the indicator OPP-020-Contract: Assets related contract extension indicator is false, than the OPP-021-Contract: Used asset along with its significance OPP-022-Contract: Significance (%) and predominance OPP-023-Contract: Predominance (%) are forbidden.

The proposed model for Assests was approved and in the next working group meeting the definitions for the related concepts will be treated.

Working Group Meeting

Date: 16/09/2025
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasare
Note editor: Andreea Pasare

Agenda

  • Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Discussion

The following definitions were approved and a skos:historyNote tag with value "WG approval 16/09/2025" will be added for each concept in ePO conceptual model:

epo-eva:EvaluationReport

Summary of the Evaluation.

epo-eva:Evaluator

A Role of an Agent that asses the Tender submitted for a Lot.

epo-eva:ExcludedCandidateList

Record of Candidates prevented from participating in a Procurement because one or more Exclusion Grounds apply.

epo-eva:TenderClarification

A Document sent by the Tenderer to the Buyer in response to the Tender Clarification Request.

epo-ful:ReceiptAdvice

A formal reply from the Buyer to the Seller acknowledging the physical or electronic receipt of goods or services delivered.

epo-ful:ReceiptAdviceInformation

Information about the Receipt Advice.

epo-ful:ReceiptAdviceLine

Details concerning the fulfilment of an Despatch Line.

epo-inv:CreditNote

A Document sent by the Seller to the Buyer to reduce or cancel all or part of the amount previously invoiced.

epo-inv:CreditNoteLine

Details concerning a given unit of goods, services or works mentioned in the Credit Note.

epo-not:Notice1

Notice of the publication of a prior information notice on a buyer profile - general directive

epo-not:Notice10

Prior information notice used as a call for competition - general directive, standard regime

epo-not:Notice11

Periodic indicative notice used as a call for competition - sectoral directive, standard regime

epo-not:Notice12

Prior information notice used as a call for competition - general directive, light regime

epo-not:Notice13

Periodic indicative notice used as a call for competition - sectoral directive, light regime

epo-not:Notice14

Prior information notice used as a call for competition - concessions directive, light regime

epo-not:Notice15

Notice on the existence of a qualification system - sectoral directive

epo-not:Notice16

Contract notice - general directive, standard regime

epo-not:Notice17

Contract notice - sectoral directive, standard regime

epo-not:Notice18

Contract notice - defence directive, standard regime

epo-not:Notice19

Concession notice - concessions directive, standard regime

epo-not:Notice2

Notice of the publication of a periodic indicative notice on a buyer profile - sectoral directive

epo-not:Notice20

Contract notice - general directive, light regime

epo-not:Notice21

Contract notice - sectoral directive, light regime

epo-not:Notice22

Subcontract notice - defence directive

epo-not:Notice23

Design contest notice - general directive, design

epo-not:Notice24

Design contest notice - sectoral directive, design

epo-not:Notice25

Voluntary ex-ante transparency notice - general directive

epo-not:Notice26

Voluntary ex-ante transparency notice - sectoral directive

epo-not:Notice27

Voluntary ex-ante transparency notice - defence directive

epo-not:Notice28

Voluntary ex-ante transparency notice - concession directive

epo-not:Notice29

Contract award notice - general directive, standard regime

epo-not:Notice3

Notice of the publication of a prior information notice on a buyer profile - defence directive

epo-not:Notice30

Contract award notice - sectoral directive, standard regime

epo-not:Notice31

Contract award notice - defence directive, standard regime

epo-not:Notice32

Concession award notice - concession directive, standard regime

epo-not:Notice33

Contract award notice - general directive, light regime

epo-not:Notice34

Contract award notice - sectoral directive, light regime

epo-not:Notice35

Concession award notice - concessions directive, light regime

epo-not:Notice36

Design contest result notice - general directive, design

epo-not:Notice37

Design contest result notice - sectoral directive, design

epo-not:Notice38

Contract modification notice - general directive

epo-not:Notice39

Contract modification notice - sectoral directive

epo-not:Notice4

Prior information notice used only for information - general directive

epo-not:Notice40

Contract modification notice - concessions directive

epo-not:Notice5

Periodic indicative notice used only for information - sectoral directive

epo-not:Notice6

Prior information notice used only for information - defence directive

epo-not:Notice7

Prior information notice used to shorten time limits for receipt of tenders - general directive

epo-not:Notice8

Periodic indicative notice used to shorten time limits for receipt of tenders - sectoral directive

epo-not:Notice9

Prior information notice used to shorten time limits for receipt of tenders - defence directive

epo-not:PIN-CFCSocial-D25

Prior information notice used as a Call For Competition using the light regime under Directive 25.

epo-not:PIN-CFCSocialNotice

Prior information notice used as a Call For Competition using the light regime.

epo-not:PIN-CFCStandard-D24

Prior information notice used as a Call For Competition using the standard regime under Directive 24.

epo-not:PIN-CFCStandardNotice

Prior information notice used as a Call For Competition using the standard regime.

epo-pay:PaymentInformation

Information about a remittance.

epo-pay:RemittanceAdvice

Document sent by the Buyer to the Seller, informing about the payment made.

epo-pay:RemittanceAdviceLine

Details concerning a given Invoice from the Remittance Advice.

epo-qua:EvidenceOutcome

Result concerning the submitted Evidence.

epo-qua:EvidenceReceipt

A Document sent by the Buyer to the Economic Operator confirming the receipt of an Evidence Submission.

epo-qua:EvidenceRequest

A Document sent by the Buyer to the Economic Operator asking for the submission of an Evidence.

epo-qua:EvidenceSubmission

A Document sent by the Economic Operator to the Buyer which contains an Evidence.

epo-qua:QualificationDecisionInformation

Information about the aggregated result of the Evidence Outcomes.

epo-qua:QualificationReponse

A formal reply from the Buyer to the Economic Operator informing the Economic Operator that it may participate in a procurement.

Working Group Meeting

Date: 11/09/2025
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasare
Note editor: Andreea Pasare

Agenda

  • Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Discussion

The following definitions were approved and a skos:historyNote tag with value "WG approval 11/09/2025" will be added for each concept in ePO conceptual model:

epo:Documentation

A structured collection of records, reports, or supporting materials that provide context or explanation regarding a process, requirement, or decision within a procurement activity.

epo:EmploymentDocumentation

Documentation concerning the general regulatory framework for employment protection and working conditions.

epo:EnergyEfficiencyInformation

Information about the energy performance, consumption, or sustainability characteristics of a product, service, building, or process relevant to the execution or evaluation of a procurement procedure.

epo:EnvironmentalDocumentation

Documentation concerning the general regulatory framework for Environmental Protection.

epo:InternationalProcurementInstrumentMeasuresInformation

Information about the legislative framework adopted by the European Union to promote reciprocity in international public procurement markets.

epo:LocalLegalBasisInformation

Information about the legal basis at the level of the Member State.

epo:MaskableObject

Entity within the procurement data model whose visibility, accessibility, or disclosure may be conditionally restricted due to legal, confidentiality, or security requirements.

epo:PlannedProcurement

A high-level description of a procurement activity foreseen by a Buyer.

epo:ReviewInformation

Information about the Review Decision or the Review Request.

epo:SpecificationInformation

Information about the characteristics and standards used in a technical implementation.

epo:TaxDocumentation

Documentation concerning the general regulatory framework for taxes.

epo:UniqueResponsibleOfTheProcurement

A Role of an Agent that holds sole responsibility for initiating, managing, and executing a procurement procedure.

epo-awa:AwardDecisionNotification

A formal communication sent by the Buyer to inform Tenderers of the Award Decision.

epo-cat:CatalogueResponseInformation

Information about a Catalogue Response.

epo-cat:DimensionInformation

Information about the physical or measurable attributes of the instance of the concept described.

epo-cat:EnvironmentalEmissionInformation

Information about the emissions related to a product, work or service that are released into the environment.

epo-cat:Line

Component of a document providing specific information.

epo-cat:PostAwardDocument

Document created after the award of a Contract during a Procurement Procedure.

epo-con:ContractModificationInformation

Information about a Contract Amendment.

epo-con:Deliverable

Item that the supplier is obligated to provide under a contract.

Some definitions were modified:

  • Updated definitions for epo:TaxInformationProvider, epo:EmploymentInformationProvider, epo:EnvironmentalProtectionInformationProvider to fully align with the definitions from the organisation-role codelist.

  • Added additional information to epo:PlannedProcurementPart: "A Lot or a Procedure can also cover one or more parts of the Planned Procurement."

  • Removed "Additional Information: This Procurement Criterion can be only Exclusion Ground, Selection Criterion or Award Criterion. Each of these Criteria can contain subcriteria (Criterion class)."" from epo:ProcurementCriterion definition.

Action Points

  • Create GitHub issues for:

    • Make and epo-ord:Order a type of epo:Contract.

    • Rename epo-eva:EvaluationCriterion concept.

Working Group Meeting

Date: 09/09/2025
Participants: Paloma Arillo, Victorio Bentivogli, Natalie Muric, Dragos Stoica
Model editor: Andreea Pasare
Note editor: Andreea Pasare

Agenda

  • Discuss proposed definitions for the concepts that do not have a definition in ePO 5.1.0

Discussion

The following definitions were approved and a skos:historyNote tag with value "WG approval 09/09/2025" will be added for each concept in ePO conceptual model:

epo-qua:EvidenceOutcome

epo-qua:fulfillsRequirement

Indicates whether the Requirement is realised.

xsd:boolean [0..1]

epo-qua:QualificationDecisionInformation

epo:hasQualificationDecisionDate

The official date of the Qualification Decision.

xsd:dateTime [1..1]

epo-qua:QualificationDecisionInformation

epo:hasRejectionDescription

Explanatory text about the rejection reason.

rdf:PlainLiteral [0..1]

epo-qua:QualificationDecisionInformation

epo:isQualified

Indicates whether the economic operator is eligible.

xsd:boolean [0..1]

epo-req:RequestForOffer

epo-req:hasSubmissionDueDate

Final date until the Submission is allowed.

xsd:dateTime [0..1]

epo-req:RequestForOfferLine

epo-req:isOptional

Indicates whether the instance of the concept is not required.

xsd:boolean [0..1]

epo-sub:OrganisationInformationSummary

epo-sub:hasBusinessClassificationDescription

Explanatory text about the size of the Business.

rdf:PlainLiteral [0..*]

epo:AwardCriterion

epo:hasFixedValue

Constant number.

xsd:decimal [0..1]

epo:EnergyEfficiencyInformation

epo:concernsTotalItems

Number of total Items the instance of the concept relates to.

xsd:decimal [0..1]

epo:InternationalProcurementInstrumentMeasuresInformation

epo:hasNumberOfTendersConcerned

Number of Tenders the instance of the concept relates to.

xsd:integer [0..1]

epo:NonPublishedInformation

epo:hasMaskableProperty

Resource that has a hidden value.

xsd:anyURI [1..1]

epo:ProcurementElement

epo:appliesForeignSubsidiesRegulation

Indicates whether the Foreign Subsidies Regulation is implemented.

xsd:boolean [0..1]

epo:QualificationCriterion

epo:hasQualificationCriteriaStatedInESPDRequest

The Qualification Criteria is specified in the ESPD Request.

xsd:boolean [0..1]

epo:QualificationCriterion

epo:hasQualificationCriteriaStatedInNotice

The Qualification Criteria is specified in the Notice.

xsd:boolean [0..1]

epo:QualificationCriterion

epo:hasQualificationCriteriaStatedInProcurementDocuments

The Qualification Criteria is specified in the Procurement Documents.

xsd:boolean [0..1]

epo:SubcontractingEstimate

epo:isSubcontractingPercentageKnown

Indicates whether the ratio of the Subcontracting Estimate is defined.

xsd:boolean [0..1]

epo:SubcontractingEstimate

epo:isSubcontractingValueKnown

Indicates whether the amount of the Subcontracting Estimate is defined.

xsd:boolean [0..1]

epo:SubmissionStatisticalInformation

epo:hasSMEReceivedTendersExcludingSubcontractors

The amount of Tenders received from economic operators that are SMEs without taking into account Subcontractors.

xsd:integer [0..1]

epo:SubmissionTerm

epo:hasSubmissionURL

The identifier of a resource used for Submission.

xsd:anyURI [0..*]

Working Group Meeting

Date: 27/05/2025
Participants: Natalie Muric, Paul Donohoe
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Discuss Github issues with milestone 5.1.0.

Discussion

  • The “Offer” folder in the Conceptual Model file was moved to the sandbox folder because an Offer module is not foreseen due to the fact that epo:Offer is implemented in the ePO-core module.

#793 was discussed: As seen in the picture below, eForms have a section tagged as “ProcurementProject”

40RoYJn5FUrAAAAAElFTkSuQmCC

  • The eForms mappings map the information on the ProcurementProject as an epo:Procedure which is not correct. There should be a new concept in ePO representing the ProcurementProject accounting for the following fields:

    • Title

    • Description

    • Internal Identifier

    • Estimated Value

    • classification code

    • purpose

  • Class epo:PlannedProcurement was created as a subclass of epo:ProcurementElement. It was also made sure that the attributes on epo:ProcurementElement cover the needs of epo:PlannedProcurement.

  • Concepts epo:hasLegalBasis and epo:hasLegalBasisDescription were moved from epo:ProcurementObject to epo:ProcurementElement.

  • There is a problem with LocalLegalBasis in the mappings.An eform does not have a locallegalBasis, although it used to be in epo:Notice as a standard form requirement.

  • A a new concept called epo:LocalLegalBasisInformation was created, with the following attributes and Object properties:

    • dct:description : rdf:PlainLiteral [1..1]

    • epo:concernsProcurementElement : epo:ProcurementElement [1]

    • `epo:hasLegalBasis : at-voc:legal-basis [0..1]

9aEJ0LbSBHIAAAAASUVORK5CYII=

Working Group Meeting

Date: 22/05/2025  
Participants: Kenneth Bengtsson, Kees D
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Present the ePayment CM to UBL experts.

Discussion

  • The ePayment CM was presented

    • It was discussed that the Remittance Advice was designed to inform the Payee which invoices are paid in a single payment.

    • It was also agreed that the attribute epo-ord:hasAccountingCost shouldn’t be in epo-pay:RemittanceAdvice.

    • The predicate refersToInvoice from the epo-pay:RemittanceAdvice was removed, as it is not needed for the epo-pay:RemittanceAdvice but only for the epo-pay:RemittanceAdviceLine.

    • It was discussed that there should be a comparison between the roles from ePO and UBL.

    • It was discussed that currently in ePO a Buyer can be an AccountingCustomer and a Buyer party.

    • It was discussed thatThe Payment means should be the same as the invoice line

    • By the end of the meeting Remittance advice diagram looked as follows

wHU+WGuq2CbDwAAAABJRU5ErkJggg==

Action Points

  • To compare the roles between ePO and UBL.

Working Group Meeting

Date: 20/05/2025
Participants: Victorio Bentivogli, Pietro Palermo
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • ePayment

Discussion

  • A question regarding #757 was made: epo:resolvesReviewRequest appearing in the comments of the github issues should bcome epo:answersReviewRequest

  • RemittanceAdvice for ePayment was discussed. Specifically, the following UBL terms related to the RemittanceAdviceLine were discussed:

  • It was noted that a RemittanceAdviceLine does not require a UUID.

  • Payment Purpose Code: It was discussed that Ontology does not need such a codelist.

  • IIt was mentioned that UBL concepts 2059-2062 seen below are not needed for the Ontology

+MHXQNSN+2ejNgAAAAASUVORK5CYII=

  • It was discussed that the epo-ord:Originator should not be part of ePayment. It will be added in the future if a suitable use-case is found.

  • It was discussed that all the roles should stay on the epo-pay:RemittanceAdvice level, and not on the RemitanceAdviceLine.

  • It was mentioned that BuyerCustomerParty is not needed, and the cardinality of a relation from the Advice to the Buyer should be 1.

  • It was discussed that BillingReference will be implemented for epo-pay:RemittanceAdviceLine level and epo-pay:RemittanceAdvice level, as the attribute epo-pay:hasBillingReference rdf:PlainLiteral [0..1].

  • epo-ord:hasAccountingCost was removed from the document and the line.

  • It was discussed thatExchangeRate is not currently needed for ePO. It may be added in the future if a suitable use-case is found.

  • #773 was discussed: It is currently on hold, because we are still awaiting an answer from Catalogue Domain experts.

  • #778 It was discussed: It was decided that this is not a requirement for eOrdering, and for further information the eOrdering Specialist should be consulted.

  • #779 was discussed: It was decided that this is not currently needed for Ontology.

Action Points

  • Change epo:resolvesReviewRequest in #757 to epo:answersReviewRequest

Working Group Meeting

Date: 15/05/2025
Participants: Natalie Muric,
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

Discussion

u6rlz3zx4QEYAKAUZYaeQy02MjY15PM3evXlz9MoVRHTR+x7P7PQ0GQGgFGTEHlSr1Z1KpdlIODw7M4OILtq8fh8ZAaAIZMS+iMVitt9fAOA6ZASA65AR+4KMAFAQMgLAdciIfZFIJOwLfwCA25ARAK5DRuyLZ8+elQBAMarVqv1nFQC+X8gIAAAA6BIyAgAAALqEjAAAAIAuISMAAACgS8gIAAAA6BIyAgAAALqEjAAAAIAuISMAAACgS8gIAAAA6BIyAgAAALqEjAAAAIAuISMAAACgS8gIAAAA6JLvACpPxfRq9VtpAAAAAElFTkSuQmCC

  • It was discussed that The model2Owl configuration was tested on the epo-conceptual-model repository, and that it will be integrated on the develop branch.

  • The Requirements that need to be implemented for the ePO workflow implementation were discussed.

    • The status tags should be added to the CM.

    • The Differ for model2owl should be implemented.

Action Points

  • To organize a meeting with the eFulfilment working group.

  • Create a github issue to add purpose to planning notice.

Working Group Meeting

Date: 13/05/2025
Participants: Natalie Muric,
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Discuss the upcoming ePayment module

Discussion

  • The ePayment ORSD was discussed.

    • The introduction was modified as follows:

      • "In the procurement domain, ePayment refers to the payment data. ePayment data is checked against the invoice data in a Contract registry.“

    • It was discussed that the use cases, user stories and natural language statements should be fulfilled by the next WGM.

    • How is the bank account information handled in Ontology? It is done by Identifiers.

    • It was discussed that the ePayment expert should be consulted for which roles should be referenced from the RemittanceAdviceLine and which ones from the remittance advice, in a future WGM.

    • Exchange Rate UBL BG was discussed. A use-case was requested:

      • The exchange rate is required when dealing with different currencies. If the invoice and the Remittance Advice use different currencies.

    • The Contract describing the Exchange was discussed. It should not be modeled as an ePO contract.

  • ePO 5.1.0 github issues were discussed:

    • Issue #669 was discussed and commented as follows:

      • "Currently the use-case is eForms where the legal-basis codelist is used. We propose to ask EU vocabularies to add references to ELI resources for the Legal-basis codelist".

      • The ticket was closed as there are not any changes required in the Ontology\

    • Issue #706 was moved to ePO 6.0.0 milestone.

    • It was discussed that ESPD related issues should be dealt with after the pre-award concepts are integrated in the Ontology.

    • It was discussed that the mapping tickets can be dealt with in ePO 5.1.0-rc2.

    • Issue #777 Review request was discussed:

      • It was decided that epo:answersReviewRequest predicate will be relaxed from 1 to [0..*]

      • This was done because in eForms it is not known whether a review decision is about a specific review request, and also, sometimes a review decision may answer multiple review requests.

pJz+gAAAABJRU5ErkJggg==

  • Issue #774 was discussed:

    • It was decided to ask the fulfilment expert more information on a use-case regarding the ticket.

  • Issue #640 was discussed, closed, and converted to an alignment discussion.

  • Issue #711 was discussed. And was put back in milestone 5.0.0 since it was implemented then.

  • Issue #787 was discussed, and converted to an alignment discussion.

    • It was discussed that BT-271 is an early evaluation and BT-157 is specified for the result .

    • It was also discussed that The definition for BT-271 is misleading and the BT-271 should not be used for groups of Lots.

Action Points

  • To fill in the ePayment ORSD by next WGM.

  • To discuss the RemittanceAdviceLine in the next WGM.

Working Group Meeting

Date: 08/05/2025
Participants: Natalie Muric, Pietro Palermo
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Discuss the upcoming ePayment module

Discussion

  • The remittance advice and remittance advice amount diagrams were discussed. Both diagrams were based on UBL’s Remittance Advice. Looking at the UBL-RemittanceAdvice-2.4 model, the following assumptions were made for the ePO model:

    • The Accounting Customer is the Buyer.

    • The Accounting Supplier is the Seller.

    • The Payee is the supplier.

      • It was noted that Payee was already modeled for ePO in the eInvoicing module.

    • PayerReference: An internal reference to the payer’s order for payment. It was decided that this can be represented as a datatype property at the level of Class epo-pay:RemittanceAdvice:

      • epo-pay:hasPayerReference rdf:Plainliteral [0..1] was added.

    • PaymentOrderReference - An internal reference to the order for payment from the payer to the payer’s bank. It was decided that this can be represented as a datatype property at the level of Class epo-pay:RemittanceAdvice:

      • epo-pay:hasPaymentOrderReference rdf:Plainliteral was added.

    • InvoicingPartyReference - *An internal reference to the order for payment by the invoicing party. This may have been requested of the payer by the payee to accompany the payer’s remittance. We can drop this since we do not have modeled the Invoicing party on the eInvoicing module. (We just have the buyer and the seller)

  • It was mentioned Invoice Period is 0..n in UBL because it may refer to many lines.

w8NCaZr19TnxwAAAABJRU5ErkJggg==

  • Billing Reference: A billing document is similar to an invoice. We can use the epo:hasAccountingCost datatype property (on the level of the epo-pay:RemittanceAdvice) for this.

  • It was mentioned that the RemittanceAdvice is a specialization of epo-cat:PostAwardDocument.

  • Predicate epo:isSupportedByForTender linking epo-sub:ESPD to epo:Tender was deleted, because Tender exists in ePO core, and ESPD in eSubmission. In its place, predicate epo-sub:isContainedinTender was created linking epo-sub:ESPD to epo:Tender

jngsMdLm3t+6SR6E3RafxVBLXzKpC8JswKjAwvph9P+s2chvmlVy0AAAAABJRU5ErkJggg==

  • Class PaymentExecutor was removed from eInvoicing since it was not necessairy.

  • It was noted that the following UBL concepts are not currently needed for ePO:

    • paymentChannelCode

    • InstructionID and InstructionNote

    • PaymentMandate

    • TradeFinancing

    • Tax information

  • PaymentID is useful. We need to create this Identifier:

    • Class epo-pay:PaymentInformation was created

    • Predicate epo-pay:hasPaymentIdentifier[0..1] linking to adms:Identifier

    • Attribute epo-pay:hasPaymentDate rdf:PlainLiteral[0..1].

    • A hasPaymentInformation [0..1] predicate was added from RemittanceAdvice to PaymentInformation

    • Predicate epo-pay:hasPaymentMeansInformation was added linking epo-pay:PaymentInformation to epo-inv:PaymentInstructionInformation.

  • ServiceLevelCode this is the same as these we have in the eEnvoicing module.

  • It was noted that the RemittanceDocumentDistribution concept is the contact point of the remitance Advice Receiver.

In the end of the WGM the remittance advice CM looked as follows:

8A9L6psdhCx1gAAAAASUVORK5CYII=

In the end of the WGM the remittance advice CM looked as follows:

hlKQntALaWoAAAAASUVORK5CYII=

Action Points

  • Schedule a followup WGM on the eInvoicing module on the 20th of May.

Working Group Meeting

Date: 29/04/2025  
Participants: Gabriele Dall, Ansgar Mondorf, Natalie Muric, Andreas Schmitz
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Discuss the eQualification, eAwarding, and eRequest diagrams.

Discussion

  • The eQualification Diagram "evidence request, submission and receipt" was presented, discussed, and approved.

ER0ML7rRPrxfhhPP9nruK8THoqrl9BgnCh4P0HHh7H3EhiOVSl9EAUAAAAAAPcFBQCMVtjtPj0+PpbLZVwu5GHFZrFAAQAAAAC+P1AAwNfwEM8eBn3D2xIAAAAADxwUAPA1vH379gI8TMPbEgAAAAAPHBQAAAAAAAAAHhEoAAAAAAAAADwiUAAAAAAAAAB4RKAAAAAAAAAA8IhAAQAAAAAAAOARgQIAAAAAAADAIwIFAAAAAAAAgEcECgAAAAAAAACPCBQAAAAAAAAAHhEoAAAAAAAAADwivQJgMpm2AQAAAAAAAI8Am83+f6iEQhyzDZewAAAAAElFTkSuQmCC

  • The eQualification Diagram "qualification response" was presented, discussed, and approved.

M65ddm0gAAAABJRU5ErkJggg==

  • It was argued whether class cccev:Evidence should point at the epo:ProcurementCriterion class. It was decided that this is not necessary.

  • It was also noted that epo:ProcurementCriterion is already linked to the epo:Lot class.

  • Attribute epo:isQualified was added on class epo-qua:QualificationDecisionInformation.

Efqmy4t6DR8A1ntA2HtFHMmiEMsm+1iABEMVQJP9mxrZvOVh3mpBzeDT1tZIyvlbOed9EAuaE3on+f3sDS6V3CPBUAAAAAElFTkSuQmCC

  • The eAwarding diagram "award decision notification" was presented, discussed, and approved.

w9qeitcdDtmBAAAAABJRU5ErkJggg==

  • Attribute epo-awa:hasStandStillPeriodEndDate was added at the level of epo-awa:AwardDecisionNotification

8AAAPg9yBABgqbm5+VhGUaGw3PwpAAD4KyBHAACWghwBAGwRyBEAgKUgRwAAWwRyBABgKcgRAMAWgRwBAFgKcgQAsEUgRwAAloIcAQBsEcgRAIClIEcAAFsEcgQAYCnIEQDAFoEcAQBYCnIEALBFIEcAAJaCHAEAbBHIEQCApSBHAABb5P8Dcn18aTKvf2cAAAAASUVORK5CYII=

  • The eRequest diagram "request for offer" was presented, discussed, and approved.

4cdyQdAMNavAAAAAElFTkSuQmCC

  • UBL request for Quotation (used for eRequest) was discussed.

  • After presenting all the diagrams, the WG decided that eQualification, eAwarding and eRequest modules can be published.

  • It was decided that the epo-eva:UniqueResponsibleOfTheProcurement should be moved to ePO core.

65PunO+MWoAAAAASUVORK5CYII=
6Kwcnh0WrwPcAD9H8BJnc8lSAnZAAAAAElFTkSuQmCC

Action Points

  • To revisit the PEPPOL mappings when ePO 5.0.0 is released.

  • To check the latest versions of the CEN PEPPOL mappings documents.

  • To create a ticket to revisit the "request for offer" diagram and investigate the privacyCode for UBL’s request for quotation in ePO 5.2.0.

Working Group Meeting

Date: 22/04/2024
Participants: Natalie Muric
Model and note editor: Achilles Dougalis

Agenda

Discussion

  • Announces vs. RefersTo #781 discussion

    • The reply to the question in the above Github discussion was discussed, and the proposed predicates depicted on the table below were reviewed. It was mentioned that predicate epo:announcesRole from class epo-not:ContractModificationNotice to class epo:AgentInRole should be changed to epo:refersTo as it was discussed that a Modification Notice always refers to a pre-existing procedure with defined lots and roles, and does not introduce new roles.

llT8DyPHptno7bo1AAAAAElFTkSuQmCC

  • The eQualification ORSD and eAwarding ORSDs were reviewed and discussed.

    • It was decided that the eQualification module should only represent the qualification sub-proccess used both by open and closed (mini competition) procedures.

    • As a result, eQualification, eAwarding and eEvaluation ORSDs were modified. Specifically:

      • eEvaluation: The qualification part after the evaluation process was removed from the ORSD.

      • eAwarding: The qualification part was replaced by a reference to the eQualification module.

      • eQualification: The description of the closed procedure was removed from eQualification, keeping only the qualification part. A detailed description of qualification for both closed and open procedures was written.

Action Points

  • Create a ticket: Predicate epo:announcesRole from class epo-not:ContractModificationNotice to class epo:AgentInRole to be changed to epo:refersTo.

  • To update the diagram of the offering party to include Candidate and any other roles currently missing from the diagram.

  • To continue fixes in the eQualification ORSD.

Working Group Meeting

Date: 15/04/2025  
Participants: Natalie Muric, Pietro Palermo
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discussion

  • The eOrdering requirements were discussed:

    • All the new diagrams were reviewed.

    • OrderCancellation CM diagram: To delete generalizations to OrderCancellation so it is harmonized with the OrderChange CM diagram.

    • dct:Issued attribute representing both date and time was discussed. Thw WG concluded that It is ok to just use dct:Issued in the Ontology to represent both date and time.

    • It was decided that the Implement Item property code for ePO #773 ticket can be moved to ePO 5.1.0.

  • Announces vs. RefersTo #781 discussion: The WG decided to create a spreadsheet that indicates what predicate should be used for each Notice – Entity pair.

Action Points

  • Update the Mappings to the eOrdering data models.

    • Update OrderCancellationConfirmation and OrderCancellationChange mappings.

    • Update the concepts related to the Time Ontology.

  • Create a Github Issue: The ESPD should become independent of the ESPD request. link it to #701 Remove Predicate epo-sub:relatesToESPDRequest

  • To follow up with the open Github issues on eCatalogue.

  • create a Github Issue: We need a way to represent indefinite durations for standard forms for 5.2.0.

  • Create a spreadsheet for Announces vs. RefersTo #781

  • Create a Github issue to model E1 (premarket consultation) notice.

  • To review Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726.

Working Group Meeting

Date: 08/04/2025
Participants: Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

  • OrderResponse field BT-ORL-5 Maximum backorder quantity was discussed:

    • Predicate epo-ord:hasBackOrderQuantity [0..1] was added from epo-ord:OrderResponseLine to epo:quantity.

  • OrderResponse field BT-ROL-2 Referenced Order line status code was discussed.

  • OrderCancelation

    • OrderCancelation became a postAwardDocument.

    • Predicate Linking epo-ord:OrderCancellation with Order was changed from epo:isSubmittedFor to epo-ord:isSubmittedForOrder.

    • It appears that we do not need the predicates pointed out below. This needs to be discussed further in a future WGM.

DxW6yApQovamAAAAAElFTkSuQmCC

  • OrderChange

    • OrderChangeRejection and OrderChangeConfirmation became PostAwardDocuments.

    • To compare the implementations ofOrderChange and OrderResponse in a future WGM and decide what is the better one.

17eEuaFPcIgAAAABJRU5ErkJggg==

  • It was agreed that the OrderResponseConfirmation, OrderResponseRejection and OrderResponseSimple data-models can be modelled using epo-ord:OrderResponse.

  • For attribute epo-ord:hasDownloadURL, the following definition was added: "Location where the resource can be downloaded".

  • ePO tickets 743 and 611 were described, answered and closed.

Working Group Meeting

Date: 03/04/2025  
Participants: Natalie Muric, Thomas Peterson, Kok Wim
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

  • Field BT-OHI-6 : The field represents a reference of the Order. We are going to delete the existing epo-ord:hasCustomerReference attribute, and turn it into a predicate connecting epo:PostAwardDocument to adms:Identifier.

    • Definition: "A supplementary reference used to identify the Buyer’s internal process."

yjxf5WQQJrRpmFRAAAAAElFTkSuQmCC

  • Field BG-ADR: Question: Is this a Document, or a PostAwardDocument?

    • Answer: It should be placed at the level of the Document.

  • Field BG-IPSP: What role should we use for that? We should create the epo-ord:Invoicee role and not just use buyer as mentioned in https://docs.ted.europa.eu/epo-wgm/notes/2023-02-21-eord.html#_agenda.

    • Class epo-ord:Invoicee was created as a subclass of the Acquiring Party.

      • Definition: "The Role of an Agent who receives and processes the Invoices."

g8QZVW4Vq1HsQAAAABJRU5ErkJggg==

  • Predicate epo:specifiesInvoicee was added.

caCADlQAAAAAAAXUAA9IGZ2UVCAB43tWqvAPsACADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOX8H1mYLgD6ti2QAAAAAElFTkSuQmCC

  • Predicates epo:exposesInvoiceeChannel, and IndicatesInvoiceeContactPoint from epo:Buyer were removed.

YrXkevoI0EQAAAABJRU5ErkJggg==

  • Field BT-ODI-1-4-8

    • At the level of epo-ord:DeliveryInformation, attribute epo-ord:hasDeliveryEmail was created.

      • Definition: "The electronic address to which the products or services are to be delivered."

  • Field BG-ODT: the solution provided in the ePO Github issue #623 was explained.

    • Attribute epo:GeneralDeliveryTerm was renamed to epo:hasGeneralDeliveryTerm

    • locn:geographicName should be used for BT-ORDT-3 instead of an identifier.

    • Field BT-ORDT-4 was discussed.

      • epo-ord:hasRequestedShippingPriority was removed from epo-ord:DeliveryInformation, and was put under epo-ord:DeliveryAgreement

  • ePO Github issue #767 was discussed and marked as completed for the fields:

    • BT-OAI-6-4 "Order allowance Exemption reason text"

    • BT-OAI-6-5 "Order allowance VAT exemption reason and specification code".

    • BT-OCI-6-4 "Order charge Exemption reason text"

    • BT-OCI-6-5 "Order charge VAT exemption reason and specification code".

  • Field BT-OTO-5 in Github Issue #696 was discussed, updated and closed.

  • Field BT-OL-6-5 should only be used in the Order Change. Was removed.

  • Field BT-OL-10 implemented as discussed in Github issue #766, and the solution provided was acknowledged by the Working Group.

  • Field BT-OL-11: It was decided to re-use attribute epo-ordhasAccountingCost at the level of the OrderLine.

  • Field BT-II-10-3: To create a GitHub issue to ask about the ItemNameCode. (Code for the item property according to a property code system)

  • Fields: BT-OAHI-10, BT-OCAREHI-10, BT-OCACOHI-10, etc. :It was agreed that we shall use attribute epo:hasAdditionalInformation at the level of epo:Document for these fields.

  • The diagrams for the OrderChange, OrderCancellation and OrderAgreement were presented:

A4bXTOkFX8dqAAAAAElFTkSuQmCC

Order Change diagram