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] UBL TransportationStatus to multiple parties?


I will leave it for others to describe the specifics of the Transportation Status usage but in general it helps to separate the messaging protocol from the message.  Things like SBDH header and other transport protocols describe the details required for the routing of the message.  The UBL message itself describes who is the intended final recipient.   It is rather like the contents of a letter and the envelope it is carried in. Sometimes the destination on the letter matches that of the envelope but it is not always the case (and the details may vary).  How they are used depends on the business process requirements. 

For example a broadcast message (such as status updates) may use a separate distribution list to route the message.  Some may prefer to create multiple instances with different ReceiverParty in each but sometimes this is overkill and create complex MessageIDs. Which is why it is not mandatory to have a specific ReceiverParty identified - it can be omitted. 

Where it is significant that the parties know who has also been sent the message (such as with Bills of Lading) a DocumentDistribution is used.

On 28 Aug 2014, at 1:27 am, Duvekot, Kees <kduvekot@Wehkamp.nl> wrote:

> All,
>  
> When I look at the description that is given in the TransportationStatus document then I read the following:
>  
>      “A document to circulate reports of transportation status or changes in status (events) among a group of participants.”
>  
> The description of “a group of participants.” is not in completely in  line with what is described in the main UBL specification document (paragraph 2.16) where it says:
>  
>      “Freight Status Reporting is the process by which a Transport Service Provider (such as a Carrier or
>       Freight Forwarder) communicates the status of shipments currently under their management to the
>      Transport Users (such as a Freight Forwarder, Consignee, or Consignor).”
>  
> So here it mentions “Transport Users” (plural) but the diagram in that paragraph only mentions one TransportUser. In all other documents around Transportation the TransportUser is the party requesting a TransportServiceProvider to perform a service, so that only be one party, not multiple.
>  
> So when I look at the actual elements in the UBL TransportationStatus document then I see the following:
>  
>      cac:SenderParty [0..1]    The party sending this Transportation Status report.
>      cac:ReceiverParty [0..1]    The party receiving this Transportation Status report.
>  
> This means that I can not specify “a group of participants” in this document because the ReceiverParty is 0 to 1 .. and not 0 to n.
>  
> So this raises some question for me …
>  
> Is this difference between single/multiple intentional?
> Should it be one or multiple?
> If I want to send a TransportationStatus to multiple recipients do I need to create multiple TransportationStatus documents? (each listing a different cac:ReceiverParty) or leave the cac:ReceiverParty empty?
> Do I need to give each document it’s own document ID or all the same document ID?
> How do the participants know who else has received the document? (do they need to know?)
> Etc
> Etc
>  
> But overall …
>  
> What is the “standard UBL way” of dealing with documents which should be send to multiple parties?
> How does that relate back to the whole logic around actual sending these documents? (like PEPPOL Transport Infrastructure, Standard Business Document Header etc etc)
>  
> Just some questions that came to mind while going through the TransportationStatus document.
>  
> Kees
>  
>  

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