Subject: Auto-reconciliation - the killer app - go for it!
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
Powered by eList eXpress LLC