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: initial draft of CPP-CPA Specification


Todd,

	I have some comments on your latest mail.

About the need or not of a B2B middleware
-----------------------------------------
I concur with the reply that Marty gave you on this topic. Actually, in my
mind, the BSI "IS THE MIDDLEWARE". A special animal of middleware, i.e.
something that helps managing distributed (instead than centralized)
collaborations. And I think that Marty is right when he notes that this BSI
wouldn't be as trivial as it may appear. Actually, I think that the whole
concept of "runtime software" together with the "layered architecture" has
been too much out of scope of ebXML, but this is a very personal opinion and
I do not want to make any religious discussion here.

About the Ability of BSI to communicate with the legacy world
--------------------------------------------------------------
At the end, the BSI is the one in charge of isolating the actual Legacy
world from the ebXML infrastructure and is the one also in charge of
realising (and managing, imho) the choreography. One of the things that I
always had in mind is that the BSI will actually work as an "intelligent
adapter" for a legacy, i.e. something that is able to make the legacy "ebXML
compliant". In really two words, if your legacy has a "print button" to
print a PO to be snail-mailed to your partner, now this "print button" will
be communicating with the BSI to instanteneously transfer the PO to the
partner.
The one described is a synchronous mechanism. Async mechanisms may be
thought as well, without changing the philosophy. In case of async, I would
see the BSI to interface with the async middleware used by the company
instead than directly with the legacy.

Now, if this is correct, I would think that it is the responsibility of the
interface between the BSI and the legacy to define which information are
transferred back and forth according to which input/output happening in the
BSI. Using my "print button" example, the other partner will receive an
incoming ebXML message which will enter through the Message Service and get
automatically to the BSI. The BSI now either knows how to associate this
"input" to an interaction with the legacy world or it doesn't (in which case
it will deliver back to the sender a "I do not understand you" like type of
message). If it does, the legacy-hook will determine which data is important
to it.

Not every ebXML message will necessarily need to be associated with a
stimolous to the legacy. I actually think that some additional hooks need to
be provided to allow humans to manually merge exception-like type of things
(thus avoiding resposnes of the type "I do not understand", as previously
described).

My idea, I know, is far more low-level than the one promoted by Bob. Bob's
assumption is that the REA model would be able to account for every kind of
transaction. I do not object to this, but I prefer to see the things from a
technical standpoint where "I do not care too much" of what is an economic
event, I care about the choreography of commercial transactions described in
the Specification Schema, and each trx being one or more inpiut/output
messages.

Very interesting discussion!!!

/Stefano


 -----Original Message-----
 From: Todd Boyle [mailto:tboyle@rosehill.net]
 Sent: 29 January 2001 02:09
 To: Bob Haugen; 'Martin W Sachs'
 Cc: 'Stefano POGLIANI'; ebxml-tp@lists.ebxml.org;
 ebxml-bp@lists.ebxml.org; Xbrl-Public
 Subject: RE: initial draft of CPP-CPA Specification


 <Martin Sachs>
 > I don't have a good picture in my mind of what this "economic exchange
 > event" would be or how it would be manifested in the CPA.  I don't
 > understand how an "economic exchange event" could be recognized
 below the
 > level of the application. It seems to me that this event is
 part of the BP
 > metamodel and needs to be defined in the BP Specification
 Schema, perhaps
 > using signals rather than business messages. Using signals would perhaps
 > enable the B2B middleware to handle the event in an
 application-independent
 > manner.
 </Martin Sachs>

 It is important that ebXML tell both parties the What and When.
 If they interpret things individually we will have unequal
 interpretations.  Anything requiring manual fixing costs 1000
 times more than making them run automatically.

 It is important to conduct ebXML exchanges without requiring B2B
 middleware, and applications capable of integrating with B2B
 middleware, at both ends.

 The big hope is that SME's might participate in ebXML exchanges with
 minimal clients such as Stefano's (Business Service Interface "BSI")
 or Haugen's (Xtreme Ease):
 http://lists.ebxml.org/archives/ebxml-tp/200010/msg00070.html
 http://lists.ebxml.org/archives/ebxml-bp/200011/msg00053.html

 So I think this question really boils down to what is achievable
 with those minimal ebXML clients and the SME's monolithic desktop
 or client/server "accounting" package.  I don't see any other way
 SMEs participating in ebXML at all.  Not even thru internet iBSP's
 (bus. svc. providers, webledgers, etc.)

 <Bob Haugen>
 > Examples:
 > I send you a PO Request and send back a Response document
 > that rejects my request with some reasons or maybe even
 > a counter-offer.  We don't have an accepted commitment,
 > but there are some business documents to handle.
 > Only the collaboration software (and the humans) know
 > what is the real situation.  If you just send the document
 > into the internal business apps, they will do the wrong thing.
 >
 > Or you send me an Advanced Shipping Notice and I find
 > something wrong with the goods and respond with a
 > Receiving Advice document that says so.  Again, we
 > do not have a confirmed receipt, but only the collaboration
 > software and the humans know it.  If you send the ASN
 > automatically to the internal business app, it will be
 > incorrect.
 >
 > So I understand "recognition of economic exchange events"
 > to mean that "the ebXML business collaboration software
 > needs to recognize when contractual commitments and
 > transfers of ownership of economic resources are agreed
 > by the trading partners to have happened".
 >
 > It's not an internal thing, it's external, part of the public
 > logic of the collaboration, shared understanding by all parties.
 >
 > Hope that was clear,
 > Bob Haugen

 Yes, I agree with all of it, especially the last paragraph.

 The draft, http://lists.ebxml.org/archives/ebxml-tp/200101/msg00060.html
 says "A CPA describes all the valid .. interactions between the
 parties... The CPA and the business process definition that it
 references define a conversation ... one or more business transactions,
 each of which is a request message from one Party and a response message
 from the other Party... for each unit of business. "

 OK.  The CPP-CPA ultimately doesn't define "transaction". The draft
 BP spec defines "transaction" -- having some booleans but still, no
 amounts, quantities, dates, parties, productIDs, etc.  (I'm looking
 for the stuff SMEs need.)

 In the course of a CPP there may be a large number of branches; some of
 them very messy.  We would still need a notification mechanism at
 least, that an economic exchange event has occurred, in the messy cases.

 There seem to be several levels of signals which the Xtreme/BSI client
 could give to the parties:  (this is just speculation.)

 1.  The simplest economic exchange notification "A type of event has
 happened, which is flagged "Economic Exchange".  Your reference
 is CPA number ##### transaction ######"  or some such.  The
 Xtreme-BSI thing would know how to set this flag, or leave it negative
 on messages that do *not* constitute an exchange.  I imagine every
 transaction that can happen within a CPP might be branded as either

  YES, economic exchange event, or
  MAYBE, or
  NOT an economic exchange event.

 2.  In addition to (1), possible accompanying information that transaction
 ###### was a document of type "OFFER" and the event was of type "Full
 Acceptance" or "Partial Acceptance" and there is/is not "MESSAGE
 ATTACHMENT".
 I believe these are knowable by the BP layer.  For examples of these
 documents see Nita sharma's "Common Business Processes" spreadsheet,
 the one with all the Edifact, X12, Rosetta, OAG, etc. message types. There
 is no reason these couldn't be flagged as postable or nonpostable.

 3.  Further accompanying data that CPA number ##### transaction ######
 is within the context of contract ###### which was created having the
 following terms: (for Cash or credit card or FOB seller, etc.etc. ) I
 suppose there might be hierarchies of attributes that could be set,
 accompanying the contract. This is purely speculative.  However, in GAAP
 accounting, information necessary for recognition and classfication is
 *often* found in the contract and/or party record, and *not* repeated
 in every invoice etc. i.e. not in the transaction layer of CPA!

 4.  Finally--it would be very useful if the message somehow communicated
 a value such as monetary amount or quantity data, in some future version.
 Even if it only succeeded in unconditionally successful exchanges it would
 be highly useful, i.e. improve the economic payoff for adoption of ebXML.
 History is full of technology that was atrociously unreliable but cranked
 out incremental economic gains and was a big success, for small business.
 Copy machines, fax machines, computers...  <grin>

 If Xtreme or BSI provides a windows "Setup" program, SMEs will probably
 download it and try it.  Probably in tens of thousands within a month or
 two.

 If it provides, furthermore, this mechanism for economic event
 recognition that includes amount, date, party, quantity, and preliminary
 chart of account classfications, a hundred little quick/peach adapters
 will turn up in the market.  Here are examples of addons.
 http://www.blocktax.com/quickbooks-addons/quickbooks-add-ons.htm

 SMEs will slam those transactions directly into their monolithic
 integrated quick/peach types of software as UTBs (Unposted Transaction
 Batches).  This does *NOT* have to work perfectly.  Nothing works
 reliably in the Quickbooks market, never did.  But they can use
 their familar interfaces to approve or delete the transactions
 and by gosh its cheap.

 Indeed there is little likelihood that SMEs will trust *any*
 digital signatures, nonrepudiation etc. from a stranger over the
 internet, anyway, since the internet has been such a disgusting joke,
 thus far.

 They might learn to use ebXML XtremeBSI interface to participate in
 other ebXML interactions, and they will still review before posting
 or paying or shipping.

 TOdd
 * Todd F. Boyle CPA    http://www.GLDialtone.com/
 * tboyle@rosehill.net    Kirkland WA    (425) 827-3107
 * XML accounting, webledgers, BSPs, ASPs, whatever it takes





[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