[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]
Powered by eList eXpress LLC