Thanks for the update. I agree that the process has two sides that are linked .. so it does not matter from which end we look at things, it should be mirrored in both places.
I looked at both overviews you created. I have no issue with the first one .. because that is generic and high level.
In the second diagram (https://www.oasis-open.org/apps/org/workgroup/ubl-psc/download.php/55292/15-03-00016.000.jpg)
you show the “Advance Shipment Notice” in two places …
I would prefer to split those into two distinct documents ..
I see the “Advance Shipment Notice” from the BuyerParty to the DeliveryParty is an “order” from the BuyerParty to the Deliveryparty authorizing him to receive goods and perform inspection etc on
them on behalf of the BuyerParty.
It is also important to remember that the BuyerParty does not need (or have to) know that that the SellerParty is sending the goods from a DespatchParty. If the goods are send directly from the SellerParty
to the DeliveryParty should not require a different document.
This Order can also be used to “invoice” the BuyerParty for the time/effort etc that the DeliveryParty has performed actually receiving the goods.
The same is true for the “Advance Shipment Notice” from the SellerParty to the DespatchParty. That is also an “order” from the SellierParty to the DespatchParty to perform an action (picking and
making items available for transportation) on behalf of the SellerParty.
So also here this order could be used for financial settlement between the SellerParty and DespatchParty.
That is why I’m talking about a ReceiptOrder in the first situation .. and a DespatchOrder in the second situation. The term “Advance Shipment Notice” is confusing because that is also used as the
alternative business term for the DespatchAdvice.
The DespatchAdvice that is send from the DespatchParty is now “duplicated” and send to both the DeliveryParty and the SellerParty, but that does mean that the BuyerParty does not know that the goods
are on route. Is that needed? If so then we need to look into that. In UBL in general it is, at least to me, unclear how we need to deal with documents that needs to be send to multiple parties. Are those two separate instances of the DespatchAdvice? With
both their own document ID etc? or the exact same document but based on the role that a party plays in the document they need to perform different actions?
For the DespatchAdvice that is received by the DeliveryParty .. how does the DeliveryParty know that this DespatchParty is the allowed party to send this document to him? Even the BuyerParty does
not really know about the DespatchParty role in his Order flow .. unless included in an OrderResponse from the SellerParty (deep down far away in a Despatch element on header or line level).
So should we move the flow of the DespatchAdvice from the DespatchParty to the SellerParty and then from the SellerParty to the BuyerParty and then to the DeliveryParty?? Doing it that way would
make the flow identical even if no separate DespatchParty/Deliveryparty is used.
The whole synchronization between the DespatchParty and DeliveryParty on when the goods can be received/despatched is not described in this flow, but that is something we also need to look into.
In order to be able to optimize both processes, and maybe including the transportation phase, this needs to take place. (I also do not know how to handle this … and there is a “chicken/egg” problem .. so maybe treat this as a separate issue) I also feel that
the DespatchAdvice should be received and accepted by the DeliveryParty before the goods can be physically received. What it they try to send less then ordered ? or more? How to deal with that .. those kind of things should be solved before the goods are even
on transport I think.
Just like the DespatchAdvice we might even need to look at the ReceiptAdvice flow and how to deal with multiple recipients of a document. In your diagram it is send directly from the DeliveryParty
to the SellerParty. Or should the ReceiptAdvice send back to the DespatchParty .. that in turn forwards it to the SellerParty? An alternative to this could be the reverse of the DespatchAdvice flow I suggested above. Then it would be DeliveryParty -> BuyerParty
-> SellerParty -> DespatchParty?
As you can tell I have a lot of questions and no real answer yet .. but at least we are talking about it …
Let’s continue the discussion …… and if other members have any input that would be appreciated.
It has just past its anniversary but I can finally announce a first pass at developing a solution to your requirements.
Have a look at the comments on the issue (UBL-1) at:
and let me know if this is on the right track.
PS. I know you suggested we focus on Inbound first but i see this as a reflective process so we also have to address the supplier’s Outbound (and possibly their warehousing) as well.
In order to start the discussion around the use of UBL to communicate to an outsourced warehouse I would like to start discussing the process flow around ReceiptAdvice.
In particular I would like to start the discussion around the following process flow as is currently in the UBL 2.1 documentation.
You can find the current process flow at the following URL:
and the flow it self:
In the following discussion I treat the DeliveryParty as the outsourced Warehousing party.
As you can see the flow start at the top middle of the diagram with “From Order”. So the first question that comes to mind is:
Where has been defined that the DeliveryParty should receive the “Order” and who is sending it to the Deliveryparty?
In the ordering process the DeliveryParty is not mentioned in the process flows. Also you can argue that the DeliveryParty should not receive the actual order, but a “stripped down” version with enough information in
order to receive the goods (so no financial information).
So I would propose a process where the BuyerParty is sending a UBL document to the DeliveryParty with these details. And this UBL Document could be called a “ReceiptOrder”. This would be an order from the BuyerParty to
DeliveryParty instructing them to receive goods, performs some checks etc etc.
In the diagram you see that for the communication between the DeliveryParty and the SellerParty UBL documents are used. But not between the DeliveryParty and the BuyerParty. There you only see the “Advice Buyer of status”
but no formal UBL document to do this “advice”
So for this communication stream we should define a UBL document. In my view this could be the actual ReceiptAdvice it self, but then from the DeliveryParty to the BuyerParty. But that would also have impact on the communication
as defined in this process between the DeliveryParty and the SellerParty.
By directly sending the ReceiptAdvice from the DeliveryParty to the SellerParty it is difficult for the BuyerParty to still reject the goods. Some sort of request/response could be needed between the DeliveryParty and
the BuyerParty to determine what should happen with the goods and that ultimately the BuyerParty is responsible to send the ReceiptAdvice to the SellerParty with the final end result of the receipt (Goods have been accepted, rejected etc)
I hope this is enough to start a discussion around these flows and the place an outsource warehouse with the whole communication chain.
Fremantle, Western Australia 6160