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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: Re: multiparty (was) Fwd: Re: message routing


Hi there,
    I think that documentary credits etc. may be a multi party
collaboration - unfortunately I don't have time to elaborate here however.
it involves an advising bank, a reimbursing bank a buyer and a seller.
Cheers, Phil
----- Original Message -----
From: "bhaugen" <linkage@interaccess.com>
To: <ebxml-cppa@lists.oasis-open.org>
Cc: <ebxml-bp@lists.ebxml.org>
Sent: Thursday, July 26, 2001 1:41 PM
Subject: Re: multiparty (was) Fwd: Re: message routing


> This is really an important conversation.
>
> I think it is imperative to think of the business requirements here
> and not trip off into all the possible permutations of multi-party
> interactions.
>
> * Questions:
> 1. What are the real business scenarios requiring business collaborations
> composed of multiple related transactions?  (I mean transactions in
> the BPSS BusinessTransaction sense here.)
>
> 2. What are the real business scenarios requiring multi-party
> collaborations?
>
> * Tentative stabs at answers:
> 1. The most common business scenario will probably be order-fulfillment,
> where one transaction forms the order (a kind of contract) which could be
> composed of many commitments (e.g. line items) to deliver and pay for
> goods or services.
>
> So in this case, some of the transactions in the collaboration will have
> commitment-fulfillment relationships between them.  (This is all described
> or at least sketched out in UMM.)
>
> I have proposed on the BP list that commitment-fulfillment relationships
> be used explicitly to manage multi-transaction collaborations in the next
> stage of BPSS work, when UN/CEFACT gets rolling.
>
> But you can still think of them implicitly as one of the main business
> requirements for multi-transaction collaborations, where one transaction
> has depencies on another.
>
> 2. One of the main scenarios involving multiple parties is when one
> party needs help to fulfill commitments to another party.  I think,
> but cannot yet prove, that most or all of these scenarios can be
> resolved into reciprocal commitments between two parties.
> (Bill McCarthy says there is proof that all multi-party scenarios
> can be broken down into binary commitments.)
>
> So it may be possible to resolve multi-party collaborations to
> a simpler group of related dialogs, not only as a temporary
> expedient but as a permanent solution for at least a large
> majority of real use cases.
>
> I agree with Jamie that good examples are required here.  Besides
> the one that he sketched out, the dropship scenario used in the ebXML-BP
> Worksheet document would work for a starter.
>
> I fully agree that there important unresolved issues of who controls
> the overall multi-party collaboration, who gets what information,
> who controls each transaction (which will be different from who controls
> the overall collaboration), etc.
>
> -Bob Haugen
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>
> _____________________________________________________________________
> This message has been checked for all known viruses by the
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
>



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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC