Working Group meeting 12/01/2023
Date: 12/01/2023
Participants: Jana Ahmad, Natalie Muric, Giampaolo Sellito, Peter, Thomas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre
Agenda
-
Ask for volunteers on eContract (planned for March 2023)
-
What are the good sources of reference?
-
-
Remind of the publication in December of eOrder and invite people to send feedback as GitHub issues.
-
Revise eFulfillment
-
Continue with Ordering and response
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
-
Resource: https://docs.peppol.eu/poacc/upgrade-3/profiles/28-ordering/
-
Update the eOrdering old version
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
-
http://bis.beast.se/peppol-logistics/main/syntax/AdvancedDespatchAdvice/tree/
-
two diagrams are still to be received from the meeting depicting “that”
-
Advanced despatch is based on UBL 3.1 and aims at including the simpel despatch.
-
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)
