Working Group meeting

Date: 12/01/2023
Participants: Jana Ahmad, Natalie Muric, Giampaolo Sellito, Peter, Thomas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

eContract

  • WG discussed the General and Specific contract condition data model.

  • Question: Why not limit to simply what is specified in eForms rather than a fully fledged contract model?.

    • Because the main purpose is to cover the needs of eForms.

  • proposal to align with OCD

  • WG will not discuss Contract Performance till March 2023, but they will discuss mainly what is necessary to represent Contract Modifications covered by the eForms

    • General conditions

    • Specific conditions

    • Contractor

  • Procurement with the Contract in the Center is a valid frame of reference / modelling perspective.

  • Question: What about the Contract Performance data?

    • It is hard to standardise. Only generic properties and concepts can be modelled. For example think of Service Level Agreement (SLA), which is an attachment to a contract.

    • There is no need to standardise service level agreement

eOdering order only

  • The response is part of the order model and shall be included in order to support the data exchange processes and choreography.

  • Order Only and Ordering (with Response) are artificial separations in PEPPOL like diagrams in EPO provide views on the same (whole) model.

  • Order response : information about what is the response

  • Order and order response are almost the same

  • Create an issue in github about data models

  • There is a need to develop the core but developing modulus is not a major release.

eOrdering and response

Revise eFulfillment

Despatch advice concepts

  • All information is in line level

  • eCMR and Dispatch advice should have relation

  • eCMR should link to order

  • eCMR might refer to the dispatch advice (as a barcode and URI) as the DESADV might refer to the eCMR.

  • Shipment during the delivery or despatch of the goods is accompanied by an eCMR document as it had been ratified by the majorities of the MS.

  • Consignment consists of TransportHandlingUint (THU)

  • THU is not the Package

    • THU is the container

    • Package is the Pallet or the box

  • OP does not need to take everything on despatch from PEPPOL.

  • To be modelled

Feedback

Bullet points extracted from an Email on 02/11/2022

  • Item Property. Add “ValueQualifier”, Standardized and predefined classification of items properties

  • Shipment. Addition in TransportHandlingUnit

    • “Handling unit type”, The type of packaging that represents the handling unit, such as box, pallet, container etc.

    • “Handling unit shipping marks”, Free-form description of the marks and numbers on a transport unit or package.

    • “Measurement dimensions”,

      • “Attribute identifier”, Code to indicate if the measure is gross weight or gross volume.

      • “Measure”, incl unitcode

  • “Package” within this handling unit

    • “Package identifier”

    • “Packaging type code”, The type of packaging used, such as box, pallet, container etc.

Action point:

  • Update html version of eOrdering (ordering and response) and send for revision.

  • Model the Advanced despatch from PEPPOL[here] + using diagrams from the meeting for guidance

  • Harmonise across modules (order/catalogue/despatch and their lines + the information hubs that may associate with some or all of them)