The Public Transaction Repository (PTR) project

Home

The PTR project ran from Oct-Dec 1999. This has been superceded by the STR Project July 2000

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),

Offer/Acceptance mode

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:

PTR.jpg (87219 bytes)

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

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:

WebGL.jpg (56647 bytes)

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