Re: [ubl] Process flow ReceiptAdvice in relation to outsourced warehouse

[Oriol Bausà Peris <oriol@invinet.org>]

Hi Kees

When the delivery party is an outsourced warehouse, I basically agree with you in three things:

1) It is not described how and what information to send to the delivery party from the buyer party to inform about the ordered items

2) The information to be submitted from the delivery party to the buyer party to inform about the reception process is not defined

3) It has to be defined who is responsible for submitting the receipt advice to the seller… the delivery party or the buyer party itself?

If we dig into that issue, there is also another added complexity, the use of a Despatch Party, where we can also see the need for more transactions to communicate the seller with the despatch party. I think this is also part of your scenario Kees, and it will come up soon...

But as Tim has suggested, if you can draw out the flows we would get a better common understanding.

 

Regards

Oriol

El 11/03/2014, a les 10:56, Duvekot, Kees <kduvekot@Wehkamp.nl> va escriure:

All,

 

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:

 

http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-RECEIPT-ADVICE-BUSINESS-RULES

 

and the flow it self:

http://docs.oasis-open.org/ubl/os-UBL-2.1/art/UBL-2.1-FulfilmentReceiptAdviceProcess.png

 

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.

 

Regards,

 

Kees Duvekot