From: Todd Boyle [tboyle@rosehill.net]
Sent: Saturday, December 18, 1999 2:52 PM
To: gnue@gnu.org
Subject: RE: Webledger architecture; avoiding duplication of data

> Todd,
> I like very much your postings and especially this one.
> I believe that matters are that not simple.
> There is some complexity on a side of the buyer
> incurred by problems related to recognition of costs.
> I am not an accountant and don't believe that I have enough
> accounting knowledge. The debit side of buying transaction
> has IMHO to be done inside the buyer's company.
> It can be pre-defined by some means like purchase order to
> properly qualify the cost. 
> 
> Wiesiek

That's right, you're looking at the key problem of WHAT on earth
to post in the shared table.  Numerous solutions exist, of course.
Here are some more ideas along those lines. 

http://www.GLDialtone.com/ptr.htm
http://www.GLDialtone.com/ptrforum.htm

There is presently a great competition between server-based
e-commerce such as web storefronts and portals, and various
geodesic point-to-point models not requiring servers. 


Any EDI or Web-based server in which contracts are executed or 
purchases or sales are completed between unrelated parties, should
be capable of hurling a transaction up into a public shared table.  

Presumeably any system which has been firewalled, maintained,
and robust enough to conduct business would be, similarly, capable
of securely maintaining an instance of the "shared table" or
connecting with remote instances of one.

Do you agree, that it is a fair assumption the entire burden of
negotiating of business transactions might be outsourced to other
software applications?  After all, web commerce does exist.  It
is certainly taking place today without shared transaction tables.

Next fact to consider, is that all of these web business processes
today, are eventually getting posted to accounting systems of 
both parties as a matter of course.  Pure determinism.  Once the
deal is made, it will always get posted, one way or another <G>
So don't worry about how to form the debits and credits. No problemo.

It is interesting, now to consider geodesic point-to-point models 
of internet commerce, not requiring servers. 

Document-based, secure, nonrepudiable e-commerce includes
ordinary email with digital signatures, HTTP exchanges based on 
XML schema like BizTalk, and all kinds of scripted exchanges like 
OBI supported by store-and forward servers, etc.

For each of these geodesic models there is a point at which a
transaction completes.  Let us focus on this point.  You can
either specify that every application involved must perform 
difficult deeds, or, specify that they should talk only with 
transaction repositories and never with each other in isolation.


To me it is implausible that an accounting system of sufficient
reliability could result, if it depended on both parties to a
transaction always doing things correctly.  People are absolutely
intolerant of any errors involving their money.  Absolutely
no transaction is ever allowed to go missing.

So, we would be talking about PC applications which must reliably 
upload the encrypted transaction to a certified, shared
transaction repository on the internet (and tell the other party
where it is), for example.  What if the connection goes down midway,
or the application freezes, or the guy just turns off the PC walks away?

He then has a closed transaction in his PC, let's say, I Accepted
a proposed price and bought something on the web, with Microsoft
Internet Explorer.   Obviously, Microsoft is not going to modify
their browser to make sure a copy of the transaction, with all its
structures and encryption, makes it to the repository.

The whole notion of expecting applications to behave reliably is
out of the question. 

Now, I believe that geodesic commerce is a fine thing, and it is 
likely to continue to grow.  But I conclude, such transactions
will remain un-posted to shared transaction repositories just as
cash register sales, mailorder sales, and everything else in 
meatspace would remain un-posted.   Unless the user is on a 
webledger service, I mean.  Any WebLedger such as NetLedger or
Biztone, or eLedger, etc. is a host capable of posting ALL of
the company's business to the radical new shared table strucs,
because they're robust, persistent, fulltime connected, etc.


Anyay, this is the reasoning that lead Bob Haugen, Mike Clark and I 
to startup the PTR project in August.  It is supposed to provide 
a clear, unambiguous record of transactions, with the necessary 
mechanisms and notifications to keep on track, and some plausible way 
for standalone offline computers to agree on transactions between
unrelated parties on a store and forward basis, not requiring any 
manual work, etc. 

Of course the XML people are getting this down to a science, maybe 
there wouuld not need to be such hardcoded logic as our PTR server,
maybe consensus will form around XML offers, acceptances, digital
sigs, etc.  and that would provide the negotiation logic.  

It is my belief that a public transaction repository could be built, 
today, running wholly on the basis of those XML schema and choreography 
such as eCo,


 * Todd F. Boyle CPA    http://www.GLDialtone.com/
* International Accounting Services LLC    tboyle@rosehill.net
* 9745-128th Av NE, Kirkland WA 98033       (425) 827-3107
* WebLedgers, accounting ASPs, XML accounting, e-commerce
* sending/receiving invoices, orders and payments over the internet