RE: initial draft of CPP-CPA Specification

[Martin W Sachs <mwsachs@us.ibm.com>]

Todd,

I don't understand "without B2B middleware".  B2B across the Internet or
other network requires a certain amount of functionality in the software at
each end.  You can either code the infrastructure functions yourself from
scratch or buy it (middleware).  Stefano's BSI (or the equivalent that
other companies may be designing) is nothing less than a high level design
for the B2B middleware.  I believe that when someone sits down to write it,
it will not be as minimal as it might look from his white paper. The
important point is that it will have economies of (hopefully) volume so
anyone in their right mind would buy it rather than roll their own.

That monolithic desktop accounting package won't be able to do any B2B
unless it at least has an interface to a browser or an interface that can
connect to BSI.  If the accounting package is browser-enabled, that client
may not need BSI but the HTTP server it is talking to will need it to do
B2B rather than just serve web pages.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Todd Boyle" <tboyle@rosehill.net> on 01/28/2001 08:08:56 PM

To:   "Bob Haugen" <linkage@interaccess.com>, Martin W
      Sachs/Watson/IBM@IBMUS
cc:   "'Stefano POGLIANI'" <stefano.pogliani@sun.com>,
      <ebxml-tp@lists.ebxml.org>, <ebxml-bp@lists.ebxml.org>, "Xbrl-Public"
      <xbrl-public@egroups.com>
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