Re: Auto-reconciliation - the killer app - go for it!

[Mike Rawlins <rawlins@metronet.com>]

Todd,

Thanks for the thoughtful posting.  However, I find it out of place in our
team's current work plan.   You speak at a level that involves
implementation and design details that we are not dealing with within  our
requirements work.  Your comments could be made on track if you could
summarize them to a few bullet points of requirements (not solutions), and
suggest the section(s) and paragraph(s) where they need to be inserted
into the current version of the requirements specification.

Thanks,

Mike

Todd Boyle wrote:

> Businesses would derive great value from ebXML if it enabled
> systems which automatically identify differences between their
> accounting detail and banks, customers, and vendors.
>
> There are two broad choices: systems where you send a CC: of each
> transaction for reference, but continue with redundant tables in
> each trading partner, and, systems intended to replace those
> redundant local tables with centrally stored tables.  Internet enables
> a real breakthru on this problem, in either case.  Your system
> should be designed to deliver incremental benefits immediately to
> trading partners who implement it, without requiring an impossible
> leap to universal adoption.
>
> Business transactions are always owned by two parties.  They should be
> stored in encrypted rows within a database on secure hosts on the
> internet, visible to the two parties to the transaction.  Accounting
> systems could continue to maintain detail, or they could consist
> only of indexes or pointers to all the encrypted rows we own, on
> various hosts, and the encryption keys to read them.  The elimination
> of data duplication will achieve billions in cost savings,
> surrendering nothing in privacy.
>
> Here is a conceptual approach you might find useful.
>
> You need functionality that enables unrelated companies to form shared
> accounting entries.  Let's call this a "Public Transaction
> Repository".  The PTR server manages two tables to provide an
> "Offer/Acceptance" process: open items, and completed transaction
> or "PTR" table.
>
> Offers received from users in valid ebXML are filed in the Offers
> table,  and copies are simply forwarded to recipients.
>
> If the recipient agrees, they simply fill in and sign their fields of
> the row, and re-submit the transaction.  The server validates  these
> "acceptance" messages, and stores the resulting "Contracts" in the
> permanent PTR table with encrypted, unforgeable timestamps.
>
> The PTR table is almost a read-only table. It provides a true,
> unforgeable record of a variety of reciprocal relationships such as
> Payor/Recipient, Accounts Receivable/Accounts Payable, and so forth,
> described in its XML field and limited only by the users' imagination.
>
> For example, the PTR would enable wholesale, ubiquitous supply chain.
>
> By maintaining indexes, the PTR would respond to queries. The user
> could obtain sets of rows necessary for reports such as aged
> receivables/payables by customer or vendor, or cash balances, etc.
> which are automatically reconciled with  the records of their trading
> partners.
>
> Here is an open source discussion and project outline if interested.
> http://www.gldialtone.com/ptr.htm
>
> Here is why you must do something about the redundancy mess.
> http://www.gldialtone.com/endredundancy.htm
>
> If you're going to have this big, fancy Registry /repository scheme,
> why not enable it to do something *really* useful, at least
> on an optional basis.
>
> * Todd F. Boyle CPA    http://www.GLDialtone.com/
> * 9745-128th Av NE, Kirkland WA 98033       (425) 827-3107

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/