Subject: Complex ERP Apps over Internet?
Date: 1999/06/23
News Group: alt.accounting
Author: Todd Boyle <tboyle@rosehill.net>
  Posting History Home
(edited version of the original:)

What's needed is just one, single, mega-transaction accounting site which
would be no different than Hotmail or anything else on the internet, except
that the "users" would be any financial entity such as a person or a company.
 
The MegaTransactionSite would maintain the following table:
 
  Date/Time        The precise date and time the deal was agreed.  
  TransactionNo    Unique transaction id number.
  UserID-Payor      Any registered user
  PayorSignature   Payors' digital signature.
  UserID-Recipient  Any registered user.
  RecipientSignature   recipient's digital signature
  Description   Optional text usually XML that the participants agree to.
  Amount    (i.e. money.)

When you login, you have to login to an SSL connection.  The site would
require decent passwords.  They might have some additional feature
like reverse DNS, etc. etc. or perhaps not. 
 
Anybody could post a request to pay somebody or a request to be
paid by somebody.  Then you logoff.
 
Pretty soon comes a PGP message from the MegaTransactionSite by
email, sent to you and the other guy.  If you both agree and send a 128-bit
encrypted reply back to the MegaTransactionSite the transaction would be posted,
and it would send another PGP message back to you, containing
the precise instant it was posted, and the TransactionNo.
 
That is all it would do.  <g>  Other e-commerce applications use email
for transaction-oriented applications.  Check out Tumbleweed email technology.
 
Then, just stand back and watch the fireworks.  You could use
this as a "good enough" data backbone for all kinds of stuff.....
What I'm suggesting is becoming a high-speed,
secure intercompany journal for the entire world.  Any
company could login, post any type of purchase,sale or
journal entry to any other company. 
 
My idea would be impractical if you had to have tunneling,
secure connectivity with every user or even presume to be
secure yourself.
 
What makes it practical is that it's based on a slow, meticulous
after-processing with encrypted timestamps.  This converts
the ultra-high-tech internet security problem to become instead,
a plodding matter which can be performed by clerks of low
intelligence who always win. Kind of like IRS audits of the
Withholding tax reported at source.

Note this is cheap to run: no human intervention.   Just a bunch
of perl scripts.
 
My idea also becomes realistic by the fact that the table itself is a
narrow flatfile, which can be immediatly deployed with
MySQL or lowend database.  It can be very easily be scaled
upwards to infinity, as an ISAM table on any RAID, cluster
or mainframe.
 
Note that the huge narrow table is never edited, after written!
You would have small tables of open items, not yet closed,
but the closed table would be final and read-only except at
the bottom of the file where records are added.
 
The security is awesome.  It can only be written by the original process after
blessing by the two agreeing parties by PGP email.  And even then, after
being posted and becoming READ ONLY, the confirmations are sent.
And anyway--the MegaTransactionSite does nothing. It is the users'
job to interpret and use the data.
 
There simply isn't any weak point on security.  When PGP email
is compromised you'll hear about it in the newspapers.  It hasn't happend.
 
There is massive redundancy everywhere you look
in todays computer technology. For example, accounting
systems have long been quadruple entry systems. You maintain
a debit or credit for representing your customer or vendor's
side of every transaction, plus a credit or debit classfying
your own side of the entry. The other person does the same
thing, hence, double-entry accounting times 2.

This creates a huge industry of tens of millions of people to
chase down and reconcile differences. Accountants live off
this problem and fear anything that is self-reconciling.

A true transaction infrastructure would consist of a single
record or row in a shared database, defining the transaction.
That's single-entry and if you even bothered
to keep any accounting records of your own, it would just contain
foreign keys (pointers) into the rows in this tall, thin,
public table. (Ordinarily your bank or other asset/liability
custodian would be the ones maintaining the extended data. )

The information content of much of the economy has been vastly
underestimated. This is one reason the bull market keeps running,
and we look at each other in amazement as life gets easier and
easier, we can't understand why. The reason is that machines
fueled by oil perform the physical work and computers now perform
the mental work. Pray tell-- what other kind of work is there?

It will take humans a long, long time to fully hoist this in,
and learn to enjoy it. When someting doesn't fit on deck, they
throw it over the side.

Look at the millions of people employed in transportion for
example. Their job is 100% an informaiton process and one
for which humans are poorly adapted anyway: scheduling,
communicating and piloting vehicles. There is hardly any
industry or occupation that isn't either Physical work, or
Mental work, both of which would better be done by machines.

 
* 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
* XML Accounting Web ledger ASP netledger, web GL Dialtone, whatever