Working Group meeting 17/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Robert, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: eOrdering

  • The WG created a new diagram named "eOrdering" for discussion of the phase. The following picture shows the classes added into the diagram:

eOrdering
  • Regarding the AdditionalDocument, the WG raised the need to discuss it because eOrdering is also a ProcurementDocument. The doubt is if the AdditionalDocument can be used also for Order. According to the ProcurementDocument definition, these documents are created for the Procedure by the Buyer (it is defined by the directive). Therefore an order cannot be considered as a Procurement Document as defined in the ontology and the Public Procurement Directives.

  • The WG also said the eOrdering does not always start at the procedure level, they used quotation to define the tender. The WG said that this quotation could be the FinancialOfferValue class that already exists in the model. The definition of the FinancialOfferValue class has been changed: "Monetary amount for which the economic operators commits to fulfil a given request". The WG saw the need to have another class that aggregates financial offer values. Due to the different discussions, the WG proposed why not to start modelling Order.

  • The WG explained that Order is the result of a tender, and this tender maybe a quotation. A new class named "Order" was created and which is a "Contract". The WG also said that Order has "OrderLines", there is a structured way to express what is bought. The WG created the class "Line" to represent the order line and also drop in the model the "Item" class because the order line defines Item. The Line class was connected to Order with the property "epo:hasLines". Also, the "Line" was associated with the "Item" through the property "epo:specifiesItem".

  • The WG discussed the different Value classes existent in the model. The WG remember that there was a discussion where the decision was just to keep the Value class since the rest of the classes did not add many details. WG will check the previous version of the diagram to see how the Value was modelled.

  • The WG asked what is the meaning of the datatype "Amount", "Quantity", "Measure". Everis explained that these datatypes come from the UBL 2.3 standard. The definitions of the datatypes were added into the model.

Action Point:

  • To check the ccts definitions and where the measure and amount are used in the model. Maybe in some cases, they are used wrongly.