Working Group meeting 16/08/2022

Date: 16/08/2022
Participants: Peter Borresen, Cecile Guasch, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre


  • eOrdering development.

eOrdering discussion

  • Present the proposed eOrdering model.

  • Between epo:Order and epo:Item should be a reification. There are properties that are dependent on the item. (e.g. delivery conditions).

  • Introducing epo:OrderLine. In version 2.0.2 OrderLine existed.

  • The constraint on epo-ord:containsOrderLine should be kept open in order to not lose valid use cases.

  • There is a framework contract with a set of items that have been agreed upon. This contract can be used to create a system. The buyer starts a process asking the supplier to provide an optimal configuration.

  • The request might be a vague order line which gets refined in the process.

  • For an order line to be correct it must either provide an item description or specify an item.

  • There are things that are described but they do not exist in a catalogue.

  • Some attributes from epo-cat:CatalogueItem are common and they are moved to epo:Item.

  • To be discussed in a future eCatalogue meeting.

eFulfilment discussion

  • A proposed UML model for despatch advice logistics is presented.

  • Providing use cases as github issues are preferred.

  • There are no requirements for primary and secondary parties.

  • The definitions of the entities should be provided as well.

  • The proposed UML diagrams should be used. === Roles in Despatch advice

  • The scope is to align the concepts from PEPPOL ordering and despatch advice with what there is already in ePO. ==== epo:Deliveree

  • Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.

  • Renaming epo-ord:Deliveree to epo-ord:Consignee and keep the definition from Deliveree because the term Consignee is a more used term in PEPPOL. (inform Pieter as well)


  • Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.

  • The name Beneficiary gives more information.

  • Need → Initiation of Need fulfilment request → Provision of the need fulfilment means.

  • Changing the definition for epo-ord:Originator

  • When the Buyer creates a framework contract, it does not catch the real Originator.

  • Creating epo:Beneficiary with the following definition: “The role of an agent that consumes the goods and on whose behalf makes the purchase.

Additional Information:
The Beneficiary is the end-user and is often the Consignee and the Originator.

  • Adding as a requirement that the Buyer can also originate the order.

  • epo-ord:Originator should be moved to epo:Originator in the core module. To be discussed in the future meeting.