Working group meeting 14/12/2021

Date: 14/12/2021
Participants: Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugen Costezki
*Note editor: *Andreea Pasăre

Agenda:

  • Continue discussing a new approach on structuring ePO:

    • Present Situations, Roles, Notice taxonomy, Notice Content model.

    • Present an example of instantiation of the Submission/Awarding situation. === (Future agenda)

  • Continue discussing the attributes in the eCatalogue from GH Issue #284

    • Process control: Information about the specification that applies to the transaction.

    • Business process type identifier: Identifies the business process context in which the transaction appears. It enables the buyer to process the invoice in an appropriate way.

    • Specification identification: An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms. This identifies the European invoice norm, as well as any extensions applied. The identification may include the version of the specification.

    • Catalogue validity period: A time interval or a duration of a catalogue’s validity.

    • Contract reference: A reference to a contract the catalogue is based on.

    • Contract identifier: The identifier of the referenced contract.

    • Contract type: The type of a contract that is being referred to (such as framework agreement) expressed as a code.

    • Contract issue date: The date on which the contract comes into effect.

    • Contract subdivision: A relevant subdivision of the contract a catalogue refers to.

Discussion:

Argumentation on whether we should split ePO into different modules or keep all inside one big model.
If we add all modules inside ePO module, maintenance will be a mess in the future.
An idea is not to split everything per process, but per a domain.
Further discuss with domain experts on how to structure the module splitting.

Continue discussing a new approach on structuring ePO:

Roles overview diagram:

EEIIIYSG6geR4xBCCCGE0ND8Pzvt22r40Z1PAAAAAElFTkSuQmCC

Most of the things in this new approach are not different than the old approach in ePO model version 2.0.0

The Role is a class that always is attached to a particular agent that fulfills that role.
The Role always has exactly one Context

We divided the Roles into three groups:

  • Procurement Role - those that are directly involved in a procurement

  • ProcurementSubrole- additional roles that are played by agents that are already playing another role in the procurement

  • RelatedRole - roles that need to be taken into consideration but they are not directly involved (some information providers)

It is important to make a distinction between Awarder Central Purchasing Body and Acquiring Central Purchasing Body.

This is not really a Role. Is the impersonification of an Agent in that Role.
A Role is something you can assign.

Properties that a Role should have in order to fulfill all the needs:

  • A role comes with its own properties and behavior

  • Roles depend on relationships.

  • An object may play different roles simultaneously

  • An object may play the same role several times, simultaneously.

  • The sequence in which roles may be acquired and relinquished can be subject to restrictions.

  • Objects of unrelated types can play the same role.

  • The state of an object can be role-specific.

  • Different roles may share structure and behavior.

  • An object and its roles have different identities.

6AAAAAElFTkSuQmCC

There are three things that need to be taken into consideration when we are talking about Situation:

  • Brute fact, independent of the context

  • Observer relative fact

  • Context as the observer

AwardDecisionSituation diagram:

4fH6qKsqQft4UAAAAASUVORK5CYII=

One limitation to have the Agent related to the Situation:

If we have to specify Tenderer and the Tenderer Receiver (the situation has two roles) it becomes difficult to manage what Role is for what Situation.

This approach provides not the situation of a specific Agent, but is that a Situation can provide you all the participants to this.

ContractSigningSituation diagram:

wU53839TNeTIAAAAABJRU5ErkJggg==

The difference between the old approach and the new one is that the old approach could have more Agents connected to one situation, making it impossible to find the Agent in some use cases.

Award decision phase instantiation:

+NQ0j7MEinKqUoKsfKFmcZBG5i4SECXw42y5AsGgqRxlyGScd6iJCCLke8An2uNU8No36ViHswSJEgbsKPzQMGQoWSfhQsDhSTakbKVKwSIbR22EIGaHWzQ4Wyzvl8k7pgpSz4bX5D8VVGCG4Le9SAAAAAElFTkSuQmCC

Presenting Notices module.
We should separate the core module from eNotification.
This kind of approach will help us to double check the consistency of the model.

Competition Notice Content diagram:

8BnNjaIy3LSX4AAAAASUVORK5CYII=

Notices module should be separately in an application profile.