The purpose was to provide an end to redundant storage between trading partners. This is an architecture which moves the participant from company-centric to network-centric storage and execution models:
The PTR would provide a simple, universal, low-cost accounting system, accessible by two modes of access:
- interactively via browsers, or
- programmatically, via XML documents over Internet.
This was to be a double entry WebLedger, capable of running a small business, designed from the ground up to enable posting intercompany transactions (journal entries) between unrelated parties running the software in different businesses, by using a simple, shared transaction repository.
The WebLedger itself is a complete, self-contained multi-company accounting system, consisting of a single transaction table. The WebLedger will be immediately understood by anybody familiar with low-end DOS/Windows accounting systems. The table consists simply of a flat file of debits and credits which total zero. Every row is marked with the transaction date, transactionID, etc. However, the descriptions, inventory items, payroll details, etc. are stored in an XML document, encrypted within a single field. This makes the WebLedger extremely simple-- it will have no functionality in V 1.0 except General Journal.
SMEs will use multiple BSPs or ASPs (dotcoms for payroll, billpayment or purchasing, webstores for selling, and so forth.)
There is no way to conduct business over the internet
from a windows application on drive C:, and anyway, the quality and power of large-scale hosted applications is better and development cycles shorter.
Here is another fantastic attempt at a root ledger
interface.
In any case --there will certainly be a root ledger or consolidated GL someplace, for purpose of producing entity's financial statements etc. Regardless of who "controls" the root ledger, it will need to support the posting of transactions from subsystems or subledgers on DotComs/BSPs to the root, or master, general ledger.
This project is an example of a root ledger.
Users will generally leave their transaction detail on the ASP or BSP
hosts. In such cases, they will require drilldown from their root ledger to the detail on originating ASP or
BSP.
The WebLedger therefore, will be nothing special, and not very useful. It's main purpose for existence is to run alongside a whole new experimental piece of software called a PTR, which is a shared public function for unrelated companies to submit documents to each other on an accountable, store-and-forward basis. (Yeah, I know, this is like a biztalk server.) The users of the PTR may, but are not required, to be companies running within the WebLedger. In other words the PTR will accept submissions of XML documents from anybody, addressed to anybody. If the addressee happens to be found within the same server, it performs settlement functions immediately. Otherwise, it tries to dispose of the transaction by finding the addressee in other PTR servers, over internet.
The PTR server manages four tables:
Tables maintained by the PTR modules:
Offers
open transactions received, addressed to other, unrelated companies (awaiting approval)
PTR
Public Transaction Repository of closed contracts (accepted transactions) (a single entry table)
Tables maintained by the PTR modules:
WebGL
a basic 6-column General Ledger table (classic double entry)
COA
a basic 3-column Chart of Accounts table (to support the WebGL)
All of these tables contain the transactions of multiple, unrelated companies. Users are only allowed views of their own transactions.
The server software has two modes of operation:
- Offer/Acceptance mode,
in which any authenticated user can submit a proposed monetary transaction, naming one or
more other registered users of the PTR as the other party to a Contract, and
- WebLedger mode, in which a user (or bot) posts transactions directly into the PTR table for their own company (i.e. balanced multi-line journal entries),
The Offers and PTR tables function independently of the WebGL table. They provide functionality that enables unrelated companies to form shared accounting entries. The PTR server manages an Offer/Acceptance process. Offers received from users are filed in the Offers table, and 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 PTR table.
Entries are accepted by the PTR, through one of two interfaces:
- Digitally signed XML documents, or
- Interactively thru browsers, with SSL connections.
After validation, rows are posted to the Offers table or PTR table with encrypted, unforgeable timestamps. The PTR table is 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.
You might be asking, "If the whole content of the offer is contained in the encrypted XML file, why are there so many columns?" --The reason is to provide a minimal set of indexes to enable the PTR to respond to queries. An arbitrary design decision was made to carry the Account Code, Amount, and Currency in unencrypted, indexed fields.
By querying the PTR table, the user can 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.
The PTR is capable of recording any type of business transaction by providing XML data fields to contain business documents, within each row of the database (e.g. invoices or POs for use by the local systems of PTR users or trading partners.) There are 8 fields shared by the two parties, plus 5 private fields for each of the two parties. (This is a single-entry record-- one row represents one transaction between two parties. The PTR table does not balance.)
Here is a preliminary version of the PTR table:
If you are not interested in multi-company splits, skip to WebLedger Mode, below.
For multi-company splits in Offer/Acceptance mode, the server accepts balanced sets of Debit(s) and Credit(s) involving more than one company ID. An example of a transaction follows, where CompanySeller sends an invoice to CompanyBuyerA and CompanyBuyerB. This would happen in a joint venture in which each party may allocate expenses to multiple other parties in N-way splits --
---------------------------- Record #1 DateTime PTR Server assigns TransactionNo PTR Server assigns XMLstring-Contract XML Invoice including remittance instructions Amount Amount greater than or equal to zero PayorUserID empty o PayorAccountID empty o PayorXMLstring empty o PayorSignature empty RecipientUserID ID of CompanySeller (the company to be credited) o RecipientAccountID CompanySeller's private GL Account code o RecipientXMLstring CompanySeller's private XML String o RecipientSignature CompanySeller's digital signature ---------------------------- Record #2 DateTime (Identical to the above record) TransactionNo (Identical to the above record) XMLstring-Contract (Identical to the above record) Amount Amount less than zero, if this company pays. PayorUserID ID of CompanyBuyerA (the company to be Debited) o PayorAccountID CompanyBuyerA's private GL Account code o PayorXMLstring CompanyBuyerA's private XML String o PayorSignature CompanyBuyerA's digital signature RecipientUserID ID of CompanySeller (the company to be credited) o RecipientAccountID empty o RecipientXMLstring empty o RecipientSignature empty ---------------------------- Record #3 (same as record #2 except that CompanyB's UserID and amount would be recorded.)
The PTR Server sends each open record to each recipient. PTR's directory contains various paths for billing/communicating with registered members. If the recipient had not been a registered member the PTR would not have accepted the initial posting.
When the recipients agree by digitally signing the invoice, the closed transaction would be moved from the Open table to the final PTR table, and timestamped.
Much of the economics of this PTR project depend on achieving adequate security to enable the parties to rely on it as a single, master system. In other words, it should be sufficiently secure to be used for payments. By signing and approving an Invoice, PO, Bill, etc. the actual money could potentially be settled within the same transaction (or more likely, netted between all members periodically, and the net balances aggregated into periodic totals for which checks would be printed and mailed to the banks monthly. This establishes the first model of a webledger with Intercompany Journal Bus. This establishes a low-cost model eliminating data redundancy and inconsistency between trading parties.
That is one scenario which creates big economic incentives for any small business, for joining the PTR and running it as a subledger.
WebLedger mode manages the WebGL table and COA table independently from the above PTR tables. The WebLedger mode manages rows very similar to a traditional General Ledger. It provides read, write and update services to remote WebLedger interfaces, to an unlimited number of unrelated companies. Transactions are balanced journal entries (traditional double entry accounting). This is nothing but a bare-bones multi-company ledger, no different than any midrange accounting system, except for the special controls and security and workflow.
Here is a preliminary version of the WebGL table:
This is intended to operate just like any General Ledger, large or small. Most or all of the fields could have been stored within the XML document. Native fields were defined in the table for dates, account codes and other keys to improve query performance, reduce the logic required on the client and server, and keep the data structure understandable and manageable by users not skilled in XML.
All queries and reports delivered from the WebLedger will be delivered in XML format. Initially the WebLedger will include screens and functions to maintain its own chart of accounts, and a primitive Journal Entry interface to add/edit/delete transactions consisting of 2 or more rows. The XML Doc for those rows can be of arbitrary complexity. For example any XML editor may be used to create invoices for submission with a journal entry, or, to create entire journal entries with such invoices nested within them. A set of plain-vanilla XML Schemas will be developed, with content models validating every requirement of a journal entry into the WebLedger and PTR.
See also, text FAQ
Thanks for listening. I'm looking for some commentary or
participation from developers on this. I am not a developer.
Todd Boyle Kirkland WA 425-827-3107