Cumulative content of Working Group Meetings in 2024

Date: 01/10/2024  
Participants: * Wim Kok, Natalie Muric, Giovanni Paolo Sellito
*Model editor: * Andreea Pasăre
*Note editor:
Achilles Dougalis

Agenda

  • Enterprise Architect Version change to EA 17.

  • Q4 Roadmap

    • Documentation of workflow

    • eEvaluation (new module)

    • Maintenance work

      • 4.1.0 was published.

      • 4.1.1 patch.

      • 4.2.0-r.c.1 was published

      • Towards publishing 4.2.0  (by mid November)

        • EA file modifications

        • Github issues with milestone "4.2.0"

      • Github issues

        • Main focus: Issues related to eform mappings.

        • Issues related to the next release.

        • Post-Award alignment with PEPPOL

        • Pre-Award alignment with PEPPOL

Discussions

  • The eInvoicing release was discussed (ePO 4.2.0) :

    • It was mentioned that some feedback on eInvoicing will be received in mid November.

  • A road map for Q4 was presented. (see agenda)

  • It was decided that an agenda of any upcoming meetings will be posted each friday.

  • It was decided that PostAward WGMs will be on Thursdays, and WGM meetings on eEvaluation on tuesdays.

  • Next Thursday (3/10) we will continue covering ePO github issues.

  • https://github.com/OP-TED/ePO/issues/153 was discussed, and closed.

  • Discussion About the Annex implementing Regulation 2023/2884

    • We need to make sure that the ontology covers all the new BTs listed there.

Action Points

  • To post an agenda of upcoming weekly meetings each friday.

  • For thursday: Discuss about award decision outcome. Specifically about MiniCompetition. We need to either change the class or its definition.

    • The problem is that in eForms we do not know if a framework agreement is a mini competition.

    • epo:resultsFromMiniCompetittonAwardOytcome should be renamed, and epo:MiniCompetitonAwardOutcome should be split into 3 classes. What we have right now is the following diagram:

8DdOvW8qEBI8AAAAAASUVORK5CYII=

What we should have is this:

X+7TDUrdTueGgAAAABJRU5ErkJggg==

 Need a different naming for the epo:FurtherStageAwardOutcome predicate.

xmKF0gyXTzAAAAAASUVORK5CYII=

 Need a different naming for the epo:FurtherStageAwardOutcome predicate.

\

Working Group meeting

Date: 18/07/2024
Participants: Kenneth Bengtsson, Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre,
Note editor: Achilles Dougalis

Discussion

Github tickets with the 4.2.0 milestone were discussed.

Action Points

  • Create a ticket: Predicate epo:specifiesSubcontractor should be deleted in ePO 5.0.0

+OmAeHKAUQZVAi4xys5jjlDtOKQpQCiDIokXFuVqdPt8O0ohClAKIMSmScp9Ucxe0wrShEKYAogxIZ5291uqgdphWFKAUQZVAi40JYzVF4h2mlIUoBRBmUyLhAVqdPssO0ohClAKIMSmT8H6rVKw1m636ZAAAAAElFTkSuQmCC
  • Create a ticket Further Investigate whether we should remove the codelists of epo:Notice , since the values of the codelists are represented as concepts in ePO.

AAAAAElFTkSuQmCC

Working Group meeting

Date: 16/07/2024
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre,
Note editor: Achilles Dougalis

Agenda

  • Fill in the ePO mappings on the PEPPOL despatch advice data model.

Discussion

Regarding the despatch advice data model mappings, it was mentioned that :

  • Carrier is an Organization.

  • The transport_means_operator is an epo:Person.

  • It was noted that Delivery information should be mandatory.

oEsg1D7D4mo5Lc7Ksa2AAAAAElFTkSuQmCC
  • Predicate epo-ful:hasDespatchPeriod was added. Definition: "The time period when the Despatcher picks-up the goods to be delivered. WG approval 16/07/2024"

ueWq7YHqlywAAAAASUVORK5CYII=
  • The definition of epo-ful:specifiesPlaceOfDespatch predicate was updated: The time period when the Despatcher picks-up the Goods Items to be delivered.
    WG approval 16/07/2024".

  • It was agreed that in the next eFulfilment meeting we will tackle the despatchLine concept from the despatch advice data model.

Action Points

Working Group meeting

Date: 11/07/2024
Participants: Kenneth Bengtsson, Ioannis Fountoukidis, Dragos Stoica,

Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Add definitions to eInvoice concepts.

  • Discuss about tickets with no milestones.

Discussion

  • Github Issues 653, and 652 were resolved.

  • The following definitions were added:

    • epo-inv:InvoiceLine: Details concerning a given unit of goods, services or works mentioned in the Invoice.WG approval 11/07/2024.

    • epo-inv:Invoice Note: Textual note that is relevant to the invoice as a whole. WG approval 11/7/2024

      • Attribute hasInvoiceNoteDescription of class epo-inv:Invoice Note: A textual note that gives unstructured information that is relevant to the Invoice as a whole.WG approval 11/07/2024

      • Predicate epo-inv:hasInvoiceNote: Contains Invoice Note. WG approval 11/07/2024

    • Epo-inv:PaymentInstructionsInformation: Information about the payment. WG approval 11/07/2024.

    • Epo-inv:hasPaymentMeansDescription: The means for how a payment is expected to be or has been settled, expressed as text. WG approval 11/07/2024

    • epo-inv:hasPaymentMeansType:The means for how a payment is expected to be or has been settled, expressed as code. WG approval 11/07/2024

    • epo-inv:hasRemittanceInformation: A textual value used to establish a link between the payment and the Invoice, issued by the Seller. WG approval 11/07/2024.

    • Predicate epo-inv:hasBankingIdentifier: A unique banking reference identifier of the Payee or Seller, assigned by the Payee or Seller bank. WG approval 11/07/2024.

    • Predicate epo-inv:hasDebitedAccountIdentifier: An identifier for the account to be debited by the direct debit. WG approval 11/07/2024.

    • Predicate epo-inv:hasPaymentAccountIdentifier: A unique identifier of the financial payment account, at a payment service provider, to which payment should be made. WG approval 11/07/2024

    • epo-inv:hasPaymentServiceProviderIdentifier: An identifier for the payment service provider where a payment account is located. WG approval 11/07/2024.

    • epo-inv:PaymentCardInformation:

      • Attribute epo-inv:hasPaymentCardPrimaryAccountNumber: The series of digits embossed on the front of a credit, debit, or prepaid card used for payment. WG approval 11/07/2024.

      • Attribute epo-inv:hasPaymentCardHolderName:The name of the account holder of the card used for payment. Additional Information: An account holder is the entity listed or identified as the holder of a Financial Account by the Financial Institution.

    • WG approval 11/07/2024.

    • epo-inv:CreditTransferInformation: Information about a direct payment of money from one bank account into another.WG approval 11/07/2024. '

      • Attribute epo-inv:hasPaymentAccountName: The name of the account that can send and receive payments to and from a payment service provider. WG approval 07/11/2024.

    • epo-inv:Payee: A Role of an Agent that receives the payment. Additional Information: The role of Payee may be fulfilled by another party than the Seller, e.g. a factoring service. WG approval 11/07/2024.

    • epo-inv:SellerTaxRepresentative: A Role of an Agent that can represent an Organization for taxation purposes. Additional Information: The Seller Tax Representative Role is not a Legal Representative. WG approval 11/07/2024.

    • epo-inv:TaxBreakdownInformation: Information about tax breakdown by different categories, rates and exemption reasons. WG approval 11/07/2024.

      • Attribute epo-inv:hasTaxExemptionReasonDescription: An explanation on why the amount is exempted from tax or why no tax is being charged according to the legislation, expressed as a text.WG approval 11/07/2024.

      • Attribute epo-inv:hasTaxExemptionReason: An explanation on why the amount is exempted from tax or why no tax is being charged according to the legislation, expressed as a code.

    • epo-inv:hasTaxPointDate: The date when the tax becomes accountable for the seller and for the Buyer. Additional information: The date can be determined and differs from the date of issue of the invoice according to the national implementation of the directive.

  • An example of invoice with multiple VAT was presented.

  • It was mentioned that all the information Classes are specifications of epo-cat:InformationHub

A71Sd87vWePqAAAAAElFTkSuQmCC

Action Points

  • To revisit the model in order to add more epo-inv:PaymentCardInformation attributes if required by the ePO users.

  • Create ticket: Delete predicate epo-inv:hasTaxCategoryTaxableAmount

vurwAAAABJRU5ErkJggg==
  • To generate the glossary for eInvoicing.

Working Group meeting

Date: 09/07/2024
Participants: Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss tickets with the 4.1.0 milestone.

  • Discuss tickets with the 4.2.0 milestone.

Discussion

4.1.0 milestone

Ticket 607

It was discussed that the predicate epo-sub:refersToOtherESPDResponse should be removed and epo:refersToPrevious at the epo:Document level should be used on its stead.

wE0Sx0MXQaxUQAAAABJRU5ErkJggg==

Ticket 637

It was confirmed by the working group that the predicates epo:answersExclusionGround and epo:answersSelectionCriteria should be removed from the Ontology.


Ticket 596

epo-con:ContractModificationInformation is a concept that belongs to eContract module and should not be present in any diagram of ePO core module, thus it was removed from the ePO core module diagram (for 4.1.0-rc.3 version).


Ticket 628

It was decided that epo-cat:hasExternalSpecification will be deleted. epo-cat:Item epo:hasSpecification epo-cat:ProductSpecification mapping will be used instead in all post-award modules. We added a temporary cardinality for epo-cat:hasExternalSpecification predicate as [0..*] with a proposal to remove it in a next major release (ePO 5.0.0).