OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


I think i understand the requirement but it may help if you can draw out the required flows (swimlanes) as you see them.  that is create the figure 23  variant you require.

I would like to know if some of this functionality is catered for in the freight management/logistics process (such as packing list) but am unclear of the roles each party plays.  In other words are we dealing with "shipment" perspectives or "order" views of the transaction?


On 11/03/2014, at 5:56 PM, Duvekot, Kees wrote:

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

-----------------
Regards 
Tim McGrath
tim.mcgrath@documentengineeringservices.com
Fremantle, Western Australia
http://www.documentengineeringservices.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]