RE: initial draft of CPP-CPA Specification

[Todd Boyle <tboyle@rosehill.net>]

Karsten Riemer said Friday, January 26, 2001 11:04 AM

> Coming from an event-driven environment within Sun, where all
> event notifications are concurrent to all authorized subscribers,
> I strongly support the notion of concurrent notification..

Karsten -- in addition to concurrentness, I advocate that the
notifications would include some mechanism sufficient for quantity,
value, and character of what was exchanged (or committed).

This respects the fact that commercial exchanges generally have
offsetting movements i.e. what increased, and what decreased.

There may be participants in ebXML exchanges who want to maintain
concurrent payables, receivables, inventory, and cash balances. Todays
SME software is monolithic and integrated and needs both offsetting
movements to be known.   The parties can workaround this, of course with
various suspense accounts and single entry, WIP types of entries etc.

Preferably, ebXML Business Process will adopt within its scope to
make both sides of each movement unambiguous, for both parties.

I believe additional elements would be needed in the Business Process
schema, http://lists.ebxml.org/archives/ebxml-coord/200101/msg00043.html

<!ELEMENT business-transaction (documentation?, request,
                                response*)>
<!ATTLIST business-transaction
	name CDATA #REQUIRED
      isNonRepudiationReceiptRequired (true | false)  #IMPLIED
	   isIntelligibleCheckRequired (true | false) #IMPLIED
	   isAuthorizationRequired (true | false) #IMPLIED
      isSecureTransportRequired (true | false) #IMPLIED
      isGuaranteedDeliveryRequired (true | false) #IMPLIED
      isNonRepudiationRequired (true | false) #IMPLIED
      isNonRepudiationReceiptRequired (true | false) #IMPLIED
      timeToAcknowledge CDATA #IMPLIED
	timeToAcknowledgeReceipt CDATA #IMPLIED
	timeToPerform CDATA #IMPLIED
	timeUnit (milliseconds | seconds | minutes |
      hours | days | weeks | months | years)    "minutes">

I admit this suggestion also affects other parts of ebXML, but
think that the above should include additional elements:

    isEconomicExchangeEvent (true | false) #IMPLIED
    EconomicExchangeEventType (resourceCommitmentOnly |
                     accountingRecognitionEvent) #IMPLIED
    EconomicExchangeEventAmountReference CDATA #IMPLIED

Something along those lines.

I'm hoping this would not be costly because the CPP-CPA knows
what kind of document it is handling, and has control of
that instance document e.g. invoice, PO, etc.

The last element, "EconomicExchangeEventAmountReference" might be
an XLink/Xpath into the XML invoice, PO, payment etc. that has
a control total amount fit to be posted.

Small business applications might be able to derive Dates, times,
parties, etc. elsewhere in the BP layer or other layers of the
ebXML protocol stack.

I believe the small business application may also be able to derive
a preliminary accounting classification (cash, AR, AP, inventory, etc.)
by refernce to the definition of the transaction (type of transaction)
within the CPP-CPA or of course the underlying doc.

Hope I haven't made a complete fool of myself here,

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


>Todd Boyle:
>>In conclusion I advocate event notification to both parties concurrently
>>sufficient for accounting recognition, rather than delegating the
>>interpretation and timing of economic events to the individual
>applications.

--------------------------Notes follow
quoting from QR090 BP specification draft,

2. Business Transactions

A business transaction is an atomic unit of work in a business
collaboration. A business transaction is conducted between two business
partners playing opposite roles in the transaction. A business
transaction always starts with a requesting activity (carried out by the
requesting role). This activity results in the sending of a request.
This request serves to transition control to the responding role who
then enters a responding activity. During or upon completion of the
responding activity zero, zero or one response is sent. Optionally one
or more business signals are also sent from the responding role to the
requesting role. Part of the pattern of a business transaction
determines when control transitions back to the requesting role.

A business transaction will always either succeed or fail. If it
succeeds it is legally binding for the two partners. If it fails it is
null and void, and each partner must relinquish any mutual claim
established by the transaction. This can be thought of as 'rolling back'
the business transaction upon failure.

A business transaction activity defines the use of a business
transaction in a collaboration. Each business transaction activity,
thus, represents an atomic unit of work defined by the business
transaction it refers to (uses) within the collaboration.

A business collaboration choreographs one or more business transaction
activities that are conducted amongst two or more parties. A business
collaboration  is not a transaction and should be used in cases where
transaction rollback is inappropriate. For example, a buying partner may
request a purchase order creating from a selling partner. The selling
partner may partially accept purchase order and thus complete the
transaction but may only return shipping information on part of the
order. The buying partner is sent any number of later notifications
regarding the outstanding portions of the order until the order is
completely reconciled.

------------------------
BP hierarchy from
http://www.ebxml.org/project_teams/business_process/wip/ccbp-analysis/mmx/on
line/index.html

* Business Operations Map
    Business Area
      Process Area
        Business Process
          * Business Requirements View
              Business Collaboration Use Case
                * Business Operational View
                    Business Collaboration Protocol
                      Commercial Transaction Activity
                        Commercial  Transaction
                          Business Activity
                            * Function Service View
                                Business Document
                                  Network Components
                                    Network Actions
                                      Network Component Collaboration