eOrdering meeting 01/12/2022
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
Discussion
Feedback for eOrdering model
-
There is a ZIP of some French/German standard Order-X including some UML/XSD/Schematron and PDF - https://fnfe-mpe.org/factur-x/order-x/
-
There is some ongoing walk to create Jason-LD from UN/CEFACTs artefacts - https://vocabulary.uncefact.org/r
-
Will be presented next Monday/Tuesday - https://unece.org/trade/cefact/39th-uncefact-forum
-
https://vocabulary.uncefact.org/about ←- JSON-LD
-
https://vocabulary.uncefact.org/rec20 - earlier it was in XLS or in HTML with a text blob - no fragment ids
-
The feature sub-invoice line can not be represented in the model.
-
The output might not be machine-readable.
-
We are doing mappings to current forms and eforms.
-
TC440 group wil map to UBL.
-
But there is a need to extend further.
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.
-
-
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
Solution 2 - granular delivery specification
Leave the delivery address only at the Order Line level.
Solution 3 - coarse delivery specification
Keep the delivery address only at the Order (header) level.
Solution 4 - ambiguous model
Keep the model ambiguous and rely instead on application profiles to reduce the ambiguity.
Solution 5 - coarse delivery information, with “specificity to”
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.
-
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.
-
Also diagram at the concept level:
-
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.