OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


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.



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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC