Cumulated content of eOrdering meetings

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

  • General contract condition data model (standard model)

  • Specific contract conditions data model

    • names, parties

  • 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

  • We will not talk about Contract Performance till March 2023, but 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.

  • 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.

    • We don’t want 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.

  • So 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 what is the response

  • Order and order response are almost the same

  • Create an issue in github about data models

  • We should develop the core but developing modulus is not a major release.

  • Are there still some concepts that can be related to both order or order line?.

eOrdering and response

Revise eFulfillment

Despatch advice concepts

  • All information is in line level

  • Shipment is a company to delivery

  • 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, but it is also 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/

    • 2 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.

    • The main differences:

      • Uses of transport event (seems similar to SHipmentInformation within EPO)

      • Consignment uses are more narrow

    • It is okay to have differences

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. And maybe length, height, width (?)

      • “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)

eOrdering meeting

Date: 01/12/2022
Participants: Veit Jahns, Wim Kok, Natalie Muric, Peitro Palermo, Thomas Petterson, Svante Schubert
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Feedback for eOrdering model

  • Order-delivery-invoice relationship

Discussion

Feedback for eOrdering model

Order-delivery-invoice relationship

Problem statement

In the order head level you find the “Delivery location” and the “Internal party to whom the goods are delivered (beneficiary)”. And also the expected delivery date.
On the line level you can NOT define a different Delivery location and the Internal party. You may have different delivery dates though.
This way it’s not too complex.
In Peppol (and as it’s implemented in Sweden), if you need to place an order to a different “Delivery location” and “Internal party to whom the goods are delivered”, you just place another order.
It’s very straightforward.

In the ePO-meetings the designed structure seems to me to be much too complex as “Delivery location” and “Internal party to whom the goods are delivered” is also on the order line.

NOTE that the invoice only refers to ONE order and ONE “Delivery location” and ONE “Internal party to whom the goods are delivered” and ONE delivery.
This means that the proposed complexity will also have implications to the way invoices must be implemented.

Discussion

  • Date and Time is not in DeliveryInformation. Maybe DeliveryInformation is not the proper word.

  • DeliveryInformation contains the Delivery Location details, the Beneficiary and the Consignee.

  • This is not only about DeliveryInformation, but also at a different level, like Project ID, Contract.

  • Discuss Cardinalities for Order - Despatch - Invoice relations:

    • In PEPPOL a DespatchAdvice can refer to multiple Orders. (0..n • cac:OrderReference in Peppol Despatch Advice transaction 3.1 (T16))

    • In PEPPOL an Invoice can refer to only one Order.

    • Invoice refers to a DespatchAdvice, and the DespatchAdvice refers to the Order.

wEGYbG1Msr9qQAAAABJRU5ErkJggg==

  • In Italy the Contract and the Lot are at the Line level.

Solution 1 - subclasses

Create subclasses of Order: Simple Order and Advanced Order and subclasses for Order Line: Simple Order Line and Advanced Order Line

Pros

  • Ensures unambiguous model

  • Accommodates two ways of indicating the address

  • Maintains interoperability

Cons

  • Increases the model complexity by adding four new classes: 2 on the Order and 2 on the OrderLine

Class diagram
B6I9taKdhVbbAAAAAElFTkSuQmCC
Instance diagrams
g97cD84XgAAAABJRU5ErkJggg==
93YTyBAAAAAAOUJ4AAAAAwAHKEwAAAAA4QHkCAAAAAAcoTwAAAADgAOUJAAAAABz44f3IkAAAAAAAX0d5AgAAAAAHKE8AAAAA4ADlCQAAAAAcoDwBAAAAgAOUJwAAAABwgPIEAAAAAA5QngAAAADAAcoTAAAAADhAeQIAAAAAByhPAAAAAOAA5QkAAAAAHKA8AQAAAIADlCcAAAAAcIDyBAAAAAAOUJ4AAAAAwAHKEwAAAAA48MP74XcCAAAAAHwd5QkAAAAAHPgf377Rg7nGoC4AAAAASUVORK5CYII=
Solution 2 - granular delivery specification

Leave the delivery address only at the Order Line level.

Pros

  • Allows for granular delivery location (and possibly other info) specification

  • Maintains interoperability ====== Cons

  • Differs from PEPPOL

  • Possibly a bit model burdensome for implementers to handle (but not really).

Instance diagram
Gli0iYiIiIhOAIs2EREREdEJ+N+6dg1ERERERGRfLNpERERERCeARZuIiIiI6ASwaBMRERERnQAWbSIiIiKiE8CiTURERER0Ali0iYiIiIhOwP8DaoHL5mo5SvMAAAAASUVORK5CYII=
Solution 3 - coarse delivery specification

Keep the delivery address only at the Order (header) level.

Pros

  • Clean approach

  • Aligned to PEPPOL

  • Maintains interoperability ====== Cons

  • Cannot satisfy the requirements of some Member States that need granular specification

Instance diagram
upu+nt3KX4AAAAASUVORK5CYII=
Solution 4 - ambiguous model

Keep the model ambiguous and rely instead on application profiles to reduce the ambiguity.

Pros

  • Models both approaches in a simplistic way ====== Cons

  • Bad modelling practice allows for the same information to be expressed in multiple ways/places.

  • Implementers will need an extra level of conflict/contradiction resolution.

  • Breaks interoperability.

Instance diagram
8GNYQ0AACpK4ehC9VMff8CJem5Q3dTHXwcMawAAAAAAfGBYAwAAAADgA8MaAAAAAAAfGNYAAAAAAPjAsAYAAAAAwIdDK78vCAAAAAAA8IZhDQAAAACADwxrAAAAAAB8YFgDAAAAAOADwxoAAAAAAB8Y1gAAAAAA+PAvGW+DAoRfpAYAAAAASUVORK5CYII=
Solution 5 - coarse delivery information, with “specificity to”
AxeaMrzeqCCCAAAAAElFTkSuQmCC

Doing a new instance example for this solution:

  • Copy from order sandbox diagram

Doing a new instance example with Contracts included:

  • Contract can also be at OrderLine.

  • A solution might be to create a hub class, ContractualInfo, that binds a Contract to Order and OrderLine.

QBKRigjnaDIbQAAAABJRU5ErkJggg==

  • Proposal to specify all the Concepts at the OrderLine level.- solution 2. If something is represented at the header level, then it must be because we can not represent it differently.

sgxBCiPZwRJQ5fuQg3Btrak+QRI8QQnSu59xrDgghhGgfriqcHYjfVFgd+saTPEj0CCFEx3rOOEOVEEKI9qJmdGMVXgQ6iUSPEEJ0LokeIYRocxI9GokeIYToXBI9QgjR5iR6NBI9QgjRuSR6hBCizUn0aCR6hBCic0n0CCFEm5PoEUII0emeM76LvBBCiPYTEMUXPwpA49eEEEK0N4keIYToAMaNf0fyljB+TQghRFuT6BFCiA5g3PgLIYQQnUSiRwghOoBx4y+EEEJ0kv8PbUX6USWTK0sAAAAASUVORK5CYII=

  • Also diagram at the concept level:

A90DDGQOM7cDAAAAAElFTkSuQmCC

  • This will be taken as homework and come to a conclusion.

  • The solution with the concept hubs is preferred.

  • This pattern should be applied to all the delivery messages.

eOrdering meeting

Date: 17/11/2022
Participants: Veit Jahns, Natalie Muric, Peitro Palermo, Thomas Petterson, Ivan Wiler
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Order-delivery-invoice relationship

In Sweden we have had e-business up and running in the public sector since the 1990’s. The first standard was in EDIFACT-format and was based on GS1 EANCOM. It was named SFTI/ESAP 6.
Later we have been adopting to Peppol. The complexity regarding the order-delivery-invoice is about the same. Of course we are using the standard Peppol BIS Billing 3 as the recommended invoice format.

In the order head level you find the “Delivery location” and the “Internal party to whom the goods are delivered (beneficiary)”. And also the expected delivery date.
On the line level you can NOT define a different Delivery location and the Internal party. You may have different delivery dates though.
This way it’s not too complex.
In Peppol (and as it’s implemented in Sweden), if you need to place an order to different “Delivery location” and “Internal party to whom the goods are delivered”, you just place another order.
It’s very straight forward.

In the ePO-meetings the designed structure seems to me to be much too complex as “Delivery location” and “Internal party to whom the goods are delivered” is also on the order line.

NOTE that the invoice only refers to ONE order and ONE “Delivery location” and ONE “Internal party to whom the goods are delivered” and ONE delivery.
This means that the proposed complexity will also have implications to the way invoices must be implemented.

Hi Thomas, as in the invoice we have the same reasoning to do: if we forsee a multiple relationship between order and delivery location 1:n in case one country decide not to have it, it will issue an usage specification to reduce cardinality to 1:1 remaining still compliant to the semantic model.

Putting in the model a 1:1 relationship, instead, will mean that countries with more complex environment (like Italy) have to use extensions to reach the desired result.

Discussion

Order-delivery-invoice relationship

Questions

  • How many invoices can correspond to an order?

    • Many (in Italy)

    • One (in Sweden)

    • One (PEPPOL)

  • How many orders can be covered by an invoice?

    • …

  • How many deliveries/dispatches can be done from an order?

    • …

  • How many orders can be covered by a delivery/dispatch?

    • …

Issues

  • Same relationship at the header and line levels leads to the problem of possibly conflicting information

    • In ordering

      • Delivery information

      • Discount information

      • Charge Information

    • In despatch

      • Shipment information

  • In despatch some information is mirroring order, how can this be reduced?

    • For example, item is described in the DespatchLine, isn’t it enough to make a reference to the order line?

Notes

In Sweden the delivery address is only at the header level.
If an italian order is sent to a sweden supplier there will be problems.

An order may specify some information at the Header Level or at Line Level, but NOT both at the same time.
A solution may be to create two subclasses: SimpleOrder and AdvancedOrder.

If delivery information is present at both line and header level, you choose whatever we want. But this solution might lead to multiple interpretations.

An Order will contain a Lot ID.

An invoice has a project reference and contract reference at the header level. In the line level there are no references to contract, project, order, despatch advice because an invoice to be as simple as possible in order to be accepted in every environment.

eOrdering meeting

Date: 03/11/2022
Participants: Natalie Muric, Thomas Petterson, Giampaolo Sellito, Ivan Wiler
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Order only model overview

Discussion

  • Starting by discussing the PEPPOL Order only use cases.

Use case 1

  • Last time we discussed the first use case from Order only - ordering of numbered items/articles.

5f4kRmij2F0z2AAAAAElFTkSuQmCC

  • We have an Order concept that is linked to an OrderLine. We can not have an OrderLine without specifying an item.

  • An OrderLine specifies a delivery by using the concept DeliveryInformation. The DeliveryInformation specifies a place of delivery and a place of storage.

  • The OrderLine specifies an Originator

  • The DeliveryInformation specifies a Beneficiary and a Consignee.

  • A Buyer and Seller are both specified at the level of Order.

  • The Order is invoiced to an Invoicee.

  • The Order can also specify a Despatcher.

Use case 2

  • This use case contains an order of free text articles.

  • A Validity Period is specified at the Order level.

  • The flow is the following:

    • The buyer creates the order with 2 different lines and items.

    • The seller receives the order.

Use case 3

  • An order of translation services.

  • Delivery location and period is specified.

  • The flow is the following:

    • The buyer creates the order with one line requesting translation between Swedish and Spanish.

    • The seller receives the order.

Use case 4