re: Xtreme Ease-of-Implementation

[Todd Boyle <todd.boyle@netaccount.com>]

Bob Haugen said 30 Nov 2000,
> One of the stated goals of ebXML is to enable smaller and less 
> technically sophisticated businesses to participate in electronic 
> business. 

Sophisticated SMBs require the same things needed by the general public:
ease of use, speed, efficiency, etc. 

Do you want to reach SMBs where they live, today?  They live inside their
business software, in which they create purchases, sales and payments. 
ebXML should face the truth, that all those activities have been built 
into monolithic, integrated accounting software, and avoid any 
foolhardy mission that requires SMBs to ditch their existing software.

There have been hundreds of brilliant vertical software written in
the last 20 years: they either integrated with leading integrated
accounting packages or died.  No business can afford a standalone
"thing" in their office that doesn't tie into their cash, receivables,
payables, inventory, customer list.  ebXML will not be any different.

> The collaboration protocol package contains the following commercial 
> transactions:
> 
> . Order-acceptance, 

I will be highly interested in these commercial transactions.  I will
provide you with equivalent GL templates for each transaction.

General ledger rows are the lingua franca for small business 
integration.  There are two GL dialects in common use: flat transactions 
consist of a set of flat rows summing to zero.  Two-tier GL schemas put 
the common data (transaction id, date, etc.) in a header.  Bite the
bullet and learn basic bookkeeping, e.g. here is a sale in CDEA:

 debit accounts receivable asset to increase it     1050
 credit sales revenue (increase)                    1000
 credit liability for tax (increase)                  50
 debit the cost of good sold (expense-increase)      800
 credit inventory to reduce it                       800

Basic bookkeeping is a riddle any developer can learn in a few hours. 
We have our "transaction patterns" and there is a formula for every 
kind of transaction.

CDEA can represent any offer, bid, purchase order, sales order, etc. 
if marked as draft or unposted transaction in legacy accounting systems.

EBXML should adopt classic double-entry accounting (CDEA) as the format 
for every message in which money transactions are proposed or executed.  
CDEA rows will flow across several important boundaries which 
B2B XML cannot cross:

1.  Most importantly, CDEA rows can be posted symettrically up and
down the hierarchy of existing local software applications: the 
sales or purchasing modules, and general ledger. (A2A integration)

2.  CDEA rows can be posted symettrically across networks, without 
modification, between local applications and webledgers (hosted GLS on 
the internet)

3.  CDEA rows can be posted up and down the business hierarchy from 
parent company, subsidiary, department/location and various 
subledgers.

4.  CDEA rows can contain summary amounts in various levels of 
aggregation, up to and including the complete statutory balance sheet 
and income statement of a company, with XBRL identifiers.  CDEA is
congruent with XBRL and has a one-to-one relationship with the
monetary elements in XBRL.

5.  CDEA rows can be quite terse and can be sent and received from 
devices and embedded systems.  GL software can be very small and its 
rules are very well understood.  These CDEA rows can flow unmodified 
among devices, intermediaries, settlement agents and local accounting 
software applications.  OMG GL facility is under consideration by MeT 
for mobile electronic transactions, for example.  Double entry GLs can 
be embedded in hardened linux devices which can be plugged directly into 
the internet, to do secure payments without a firewall.

6.  CDEA communicates unambiguously between clerk, manager and external
accountant.  ebXML draws upon a trained workforce of millions who are
already trained read the XML messages in raw form if they are CDEA rows.

7.  CDEA rows in XML format can be parsed by XML parsers without 
difficulty, for example transformed into POs etc. with XSLT.  At the 
same time, they can be processed by cheap lowcost string parsers. One
would ask, if they do not break XML parsers, why not use CDEA?
CDEA rows are commonly extended to be quite wide, including SKUs, 
project and other rich information.  The ultimate extension to a CDEA 
row is a text field with XML (or a pointer to an XML doc.) 

MULTIPARTY GENERAL LEDGER FORMAT.

It is relatively easy to extend the GL transaction to support multiparty
interactions by adding a few columns to the header and/or rows. 

- party identifiers (namespace:value pairs) for the originator and
   recipient of each row in the transaction,

- a group id to tie together the separate transactions within a 
   commercial transaction pattern or REA duality,

- response codes to indicate the delivery status and ultimate business
   acceptance of a proposed multiparty transaction.

How do you interpret a multiparty transaction in GL format, such as the 
sales example above? Easy:  a debit to receivables by the originator is 
a sale to him.  If you are named as the reciprocal party in the 
"recipiet" field then, to you, it is an expense or purchase.  Your 
application software would flip the context into a sale for you, and get 
the SKUs, descriptions, and other information from fields on the same 
rows.  Thus, CDEA serves unambiguously as an A2A integration format as 
well as a B2B format.

These ideas are explained in greater detail in the research project
on my website, http://www.gldialtone.com/str.htm

Thank you,
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


> From: Bob Haugen <linkage@interaccess.com> 
> To: "'ebXML-BP@llists.ebxml.org'" <ebxml-bp@lists.ebxml.org> 
> Date: Thu, 30 Nov 2000 14:40:35 -0600 
> Subject: Xtreme Ease-of-Implementation 
> 
> One of the stated goals of ebXML is to enable smaller and less 
> technically sophisticated businesses to participate in electronic 
> business.  One of the hindrances to such participation in traditional 
> EDI is the long time and high cost of implementation, getting up and 
> running in the first place.
> 
> Here is an idea for nearly-instant implementation.  It makes use of my 
> companion "Proposal for specifying business collaborations in business 
> terms".
> 
> Here are two scenarios:
> 
> 1. A larger and technically more-sophisticated customer wants to do 
> business with smaller and less-sophisticated suppliers.  
> 
> 2. Two smaller or less-sophisticated (or smarter) companies want to do 
> business together.
> 
> *First, the large-customer scenario:
> 
> The customer uses the ebXML Order-Fulfillment collaboration software to 
> package up the collaboration protocol for the suppliers.  The package 
> could take the form of a Web business service or a download or plug-in.  
> (Actually, most of what the customer needs to do will be preconfigured 
> by the ebXML Common Process Catalog and my upcoming order-fulfillment 
> patterns, so their job is pretty easy too.)
> 
> All the supplier needs to conduct electronic business with the customer 
> is Internet access and either a browser for Web services or whatever 
> kind of computer is required to run downloaded software. 
> 
> The collaboration protocol package contains the following commercial 
> transactions:
> 
> . Order-acceptance, where the supplier receives orders from the customer 
> and the package contains preconfigured acceptance documents.
> 
> . Fulfillment-confirmation, where the package presents preconfigured 
> shipping documents and the supplier can just fill in the blanks and push 
> the Send button. (Think of it as an XML form in a self-addressed 
> envelope.)
> 
> . Payment protocol transactions depending on the trading partner 
> agreements, e.g.:
> 
>  . Pay on Invoice, the package configures Invoice documents for the 
>    supplier to send to the customer.
> 
>  . Pay on receipt, the package receives and acknowledges Receiving 
>    Advice documents from the customer.
> 
>  . Pay on consumption or production, the package receives and 
>    acknowledges the relevant documents from the customer.
> 
>  . Prepayment, either directly or thru a 3rd party as in International 
>    orders.
> 
> The package should also contain terms and conditions and actions for all 
> the possible things that could go wrong.
> 
> The basic idea here is that the more-sophisticated customer packages up 
> both sides of the business process with its less-sophisticated suppliers 
> and all the suppliers need to do is fill in the blanks in some forms and 
> send them back.  The suppliers can extend the packages as much as they 
> want, e.g. connect them to their internal systems, but the basic 
> collaboration will still work correctly and new suppliers can get up and 
> running very quickly.
> 
> *For small customers dealing with small suppliers, the whole 
> collaboration could be packaged up as a Common Business Process and used 
> as-is.
> 
> Comments?  Suggestions? Etc?
> 
> Thanks,
> 
> Bob Haugen
>