Level 1 - public document repository service

Enable any party to any transaction to post an encrypted copy of any transaction or other XML document payload on the internet, where it can be obtained by a designated  reciprocal party or parties to the transaction, at any time they may desire, as a simple mechanism to document the date, time and content of a transaction, and assist in mutual reconciliation and avoid misunderstandings.

Level 2 - message transport and notification service

Provide a store-and-forward service for notifications to these reciprocal parties of existence of a transaction, giving them a key to securely retrieve it.

Level 3 - service for recording replies such as acceptances

Enabling reciprocal parties to post a nonrepudiable acceptance or acknowledgment of the document, witnessed and timestamped by the server to assist in closing of commercial transactions over the internet.

Level 4 - archive and reporting generation service

Provide persistent and responsive storage of inter-party transactions, sufficient to achieve a robust and intrinsic reconciliation of every balance between those parties such as banks, and payables, and receivables.

The STR is a simple thing without much logic, which sits on a network visible to any two or more parties to any transaction, receives a copy of any transaction, and forwards it to the named addressee(s) (reciprocal party) for acceptance.  If the reciprocal party submits an "acceptance" with the appropriate key, the acceptance is permanently stored encrypted, visible to those two parties alone. 

This STR spec has two intended audiences:   

STR Server behaviors

The STR table below attempts to define an essential minimum of data for transaction events.  The table stores "draft" transactions submitted by an originating party, which may be ratified by the addressee (hereinafter called the recipient or reciprocal party.)

If the STR server receives a response to these "drafts" or "offers" from the reciprocal party, the STR updates the shared section of the STR record with the ResponseCode and Signature provided by the reciprocal party, and stores the reciprocal party's private section data such as codes and document associated with the exchange.  The server does little else other than mechanics such as dates and row IDs.

The STR is an infrastructure component which may be implemented as

• an independent server on the network, or
  
• attached to any web-hosted business system such as a web storefront, exchange, marketplace, trading hub, etc., or
  
• integrated with any entity's business system which talks to the internet at least intermittently.

The STR server manages an Offer/Acceptance process.  Offers received from users are filed in the STR table, and forwarded to recipients. That's about all there is to it.  The originating party must complete the "required" fields of the table below, and the other columns are left blank for the system or recipient to complete.

If the recipient agrees, he or she simply fills in and sign their remaining fields of the row, and re-submits the transaction.  This might be done thru an HTML interface on the STR server, or XML document exchange. The server validates  these "acceptance" messages by finding the original offer, and records the acceptance in that row of the STR table.

After validation, rows are posted to the STR table with encrypted, unforgeable timestamps.   Once the offers fields have been recorded in STR table, those fields are  read-only.  Timestamps provide 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 can be encapsulated in the XML file, why are there so many columns?"  --The reason is to provide a minimal set of indexes to enable the STR to respond to queries without parsing XML files. An arbitrary design decision was made to carry an Account Code, Amount, and Currency in separate fields so that you could at least request a report and totals by party, by account, by date.  These are the foundation of 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.  OK? The purpose of the STR is intercompany accounting. 

The STR is capable of recording any type of atomic 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 STR users or trading partners.)   There are 10 fields shared by the two parties, plus 7 private fields for each of the two parties.  (This is a single-entry record-- one row represents one transaction between two parties. The STR table does not balance.)  

STR Client behaviors

The requirements for any client application are as follows:

1.  Originates transactions by creating a compound document, containing the transaction date, two parties' identities and URIs, amount of the transaction, and optionally, a few other data such as a document describing the consideration exchanged for the money. The originator is optionally, capable of digitally signing its submission.   The message may be a multipart MIME email or HTTP post; these are outside the scope of this spec.  This spec assumes transport is available to submit the transaction the STR server.

2.  Accepts transactions received from other parties.  The recipient inserts one additional value into the transaction document; the UserID.  Optionally the recipient will digitally sign the completed doc. before resubmitting it to the STR. 

In order to illustrate the STR operation, this paper describes as its participant, a simple webledger: a double entry general ledger which runs over the internet in a browser, having additionally, a capability to send and receive STR transactions.  (Webledgers are a server application, which are clients from the viewpoint of BSPs)

A webledger generally manages a Chart of Accounts table and other mechanics we don't need to discuss here. It is not essential that this particular webledger be supported by the STR, or that it be a dedicated client of the STR. It is just an example of an asynchronous consumer of the STR's services.  The STR could have other types of clients. 

The interface to the webledger will be immediately understood (and hated!) 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, which emulate an old paper-based general journal.  Every row is marked with the transaction date, transactionID, and other columns such as those described in rootledgerXML (http://www.gldialtone.com/rootledgerXML.htm#fields) 

In addition to the native database fields described in this STR spec and in the rootledgerXML, business documents of arbitrary complexity such as invoices, orders, inventory movements, payroll details, etc. are stored in an XML document, as a hunk of text, within a single field.  Users could go hog wild and transport xCBL messages, or EDI or ebXML core components in the payload field of the STR if desired.  But the webledger client itself would have no functionality except General Journal.

Let's revisit why a webledger, rather than a compiled client, was chosen to illustrate the STR architecture: SMBs will use multiple business service providers (BSPs) for payroll, bill payment,  purchasing, webstores for selling, banks for receiving payments, and so forth. Most small businesses will not conduct business over the internet from a windows application on drive C: for two reasons: lack of security, and inferior functionality and integration compared with hosted applications.  

Here is a visual model of a root ledger or master general ledger, in an environment where the small business uses several different BSPs.  Clearly, every company will continue to require a summary view of all of their dealings, for fiscal control, taxation, cash management, etc.  Root Ledgers apparently will continue to require the CDEA model. There is no other semantic or processing model for the 7 requirements of a root ledger.

The webledger component of this project is an example of a root ledger because it can maintain records of transactions executed on multiple hosts.  Regardless of the location of the root ledger or who "controls" it, there will be a root ledger someplace, accumulating records of transactions from subsystems, sub-ledgers, DotComs and BSPs, etc. 

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.  Drilldown is addressed by the STR design, below.

This particular webledger therefore, is nothing special.  It is a theoretical client, running alongside this whole new experimental piece of software called an STR.  The webledger  enables a user (or application) to posts transactions directly into the webledger table for their own company (i.e. balanced multi-line journal entries).  It also provides some minor logic to receive transactions in XML form, from the STR, for review before posting, and to transparently submit copies of transactions to the STR whenever a transaction is recorded for any other party on earth. 

STR User accounts 

Anybody on earth can submit a proposed document, i.e. a monetary transaction, naming one or more other parties to a sale, contract, etc.  The STR server accepts rows from any party but the rows are orphaned and irretrievable until a user record is created in the Users table of the STR.  

If the originating party is not authenticated as having an account on the STR server, it first goes into a process creating an account, before processing the transaction.  ("Processing" means little more than passing the record to the reciprocal party.)  An alias is created, and a dialogue initiated with the originating party to gather a password and optionally, other data according to the policy of the STR operator.

Reciprocal parties named in Offers, may be users having an account on this STR or other STRs conforming with this specification, or, they may be non-users having at least an email address.  Similarly to the Offers processing, if a reciprocal party initially has no account, an alias is created, and a dialogue initiated with the originating party to gather a password and optionally, other data according to the policy of the STR operator.

If a row is received by the STR with empty reciprocal party fields, it is stored in the table anyway, under an assumption the originator is using the STR as a host for webledger GL entries.  In that case, obviously, no forwarding etc. is performed.

Here is the STR table: (Blue is shared, Yellow is Originator's private data, and Green is Reciprocal Party's private data.)

Additional fields may optionally be supported by an STR within Originator's private data or Reciprocal Party's private data areas.  For example, any subset of the fields of  rootledgerXML may be implemented, making the STR into a basic webledger host.

You will notice that none of the Originator nor Reciprocal private data fields is mandatory.  It is logically crazy that anything private be required in this spec, since those fields cannot have any function for the other party.

How entries are formed: 

Accountants will get this immediately: you just post the part of a double-entry transaction which hits your AR or AP.   Visualize the STR as your balance sheet (payables, receivables etc.) and create debits or credits into the STR whenever there is another party associated with a transaction.

As promised in the first page of this spec, the STR serves as a full webledger host if both sides of a general ledger transaction are submitted to the STR by an Originator.  The STR will accept stewardship for any row, even if it lacks a recipient.  Thus, nothing stops a user from submitting large number of rows, even their their entire GL, up on the STR and querying it by account, by date, and so forth.

Multi-party use cases

One of the primary objectives of the STR is to enable lightweight commercial dealings by partnerships and collaborations of greater than two parties.

For multi-company splits, the Offer/Acceptance service accepts sets of rows involving more than one company ID. An example of a transaction follows, in which an independent insurance agent works out of her home and sells a policy. She logs into the insurance agency's system as a user and uses an application to book the business. Lets imagine this General Journal entry results:

Example multipary transaction:

Now, suppose the Agency's computer is all tricked out with an STR interface.  It would submit five liabilities up there and one receivable, a total of six rows*.  The STR associates the six rows using the Originator's transactionID and the external GroupID, 
to tie my rows together.  As the ResponseCode values are received from multiple parties, the STR dutifully updates ResponseCode on each row, and the TransactionResponseCode and GroupResponseCode for the highest level of agreement reached by all the rows of the associated groups.  Other use cases exist in the STR discussion forum.

Implementing an application program interface (API) to an STR
(tag snatching.  value snatching.)

The STR enables a lightweight B2B by sharing four clusters of information:

1. date/time,
2. amount,
3. identities of the parties, and
4. description of the service or goods.

Shared transactions (STs) can be implemented easily and transparently by any true webledger such as NetLedger, BizTone, IntAcct, BAPort, eLedger, etc. Webledgers are in a unique position of avoiding all the logic of encryption and key management because you already control permissions on the STR table. Here is how you do it:

1. In the subscriber's preferences, ask whether they want to implement transaction sharing. (let's assume, yes)

2. Most user interfaces capable of generating transactions in the webledger can potentially name external party as reciprocals to the transaction.

Obviously any purchase, sale, payment or receipt always involves a reciprocal party. General journal also may involve a reciprocal party and is very important to include in your transaction sharing.

Each customer, supplier and bank maintenance screen will require additional fields. 

a. enable ST's (boolean) b. party's URI or username on the webledger, to send transactions to, c. URI of the external STR if not this webledger.

Each transaction screen will also require the same fields, to apply them on a transaction by transaction level.

3. Obviously, when entering any invoice or other external transaction, the user will ensure the fields are completed properly, and upon posting the transaction it will be transmitted to the STR as an "Offer" or unratified transaction.  Webledger hosts already have all necessary data.  An STR interface is trivial for a Webledger to implement. The XMLpayload will be the invoice or other transaction doc. formatted in your proprietary interface XML (which webledger hosts must publish or perish.)

4. If the reciprocal party is a user on this host, the "Invoice" from the other user will need to be flipped to become a "Bill".  If the party is not one of your users, then, the XMLpayload may be difficult to transform.  In any case, the amount, date and party are seldom ambiguous, and at this point, the AR, AP, and bank balances potentially begin to reconcile. 

The challenge of metadata mapping

The mapping of XML elements and attributes that exist in foreign XML documents (not in your native XML format) is apparently done by XSLT transformations, by most internet business systems.  In future it will apparently be done by reference to registries and repositories whose address is stored in the XML document.  

Webledger developers should meanwhile, consider tag snatching code that runs thru likely words and tags that might contain party, address, product, etc. information and maps them into your webledger.  Any true geek could get a 80% hit rate with some of this code in a few days, because there just aren't that many different strings used to label the key data in a Purchase Order or invoice.  Alternatively, any incoming XML document may be presented in a user interface, in which the user can point and associates any particular element or  structure with accounting functions in the webledger-- teaching the webledger the meanings of the tags.  Webledger host could "cheat" by remembering each XML schema it runs across, and the associated handful of tags mappings it learned in previous encounters.  

Obviously, everybody's party code and products codes will massively collide if nothing is done to map the metadata.  So, you must create mapping solutions (below). What you want is something that is like a neural network that enables all the users on this host, inexorably, to use the same party IDs and product IDs if they want to, and, to give them incentives to want that.

Users on a webledger host will resist automatic, programmatic posting of business transactions arriving from outside into their company on a webledger host. Developers must create "Inbox" or "Unposted Batch" screens for users to review and "Accept" incoming transactions. This is inevitable, regardless of the STR interface and must be built by any webledger or BSP who enables their users to conduct business over the internet.

PartyIDs:  The first time the webledger user receives a document from another party who is not in his customer or supplier list, the inbox screen will prompt the user to associate (map) this new party with a customer or supplier (or import the party record directly off the arriving XMLpayload) From that point onwards, you have either got equality, or mapping, with respect to this particular party. A new field will be required in each party record (and maintenance screen): "His code for Me." Most accounting software already has this in both AP and AR screens.

Note SMBs do not need universal, converged party codes such as DUNS numbers. They only need to map ONCE with each party because they only have one relationship with that party. Directory schemes and portals on the internet are aimed at many-to-many markets and that's fine-- those IDs will neurally propagate into the webledger population in due course.

ProductIDs: similarly, the first time your webledger user receives any XMLpayload having an unfamiliar productID, the import screen will prompt the user to map the product with his existing inventory item, or, import it straight away if it's new.

Here is the value-snatching button:

[Adopt my Suppliers' product ID as my product ID, and retroactively renumber my data.]

Over time, the B2B codes adopted among webledger populations will converge. And everybody who has an email address will be getting these XML STR messages as mime attachments, and the ISV market will start to integrate to them.

Please note that this scheme immediately unleashes the fabled intercompany payments and settlements, outside the fees and reconciliation costs imposed by banks: http://www.GLDialtone.com/journalbus.htm

This scheme also realizes a vision in which individuals may promiscuously form and join partnerships and JVs with ease, http://www.GLDialtone.com/hypercub.htm

The internet changes our AP/AR cycle, that the AR/AP can be converged to a shared table. The cluster of four items must be shared, the economics are too compelling and it is too viral.

Settlement (payment) mechanisms through an STR

Much of the economics of this STR project depend on achieving adequate security to enable the parties to rely on it for conducting business.  In other words, it does not reach as much economic net gain as a mirror or archive which requires dealings to be conducted elsewhere.  The STR should be sufficiently secure to be used for bids and  offers etc. which stand on their own, and for settlements.

For example, if an Offer is posted containing a purchase order, its Acceptance by the seller completes the first stage of an exchange.   The STR facilitates settlement of outstanding balances in two ways:

1.  Any digitally signed obligation or evidence that buyer owes seller effectively transfers some of the buyer's credit to the seller because the obligation can be sold to intermediaries.  This is not new or different from traditional notes or accounts receivable which may be sold to third parties.   What is very new, however is the electronic efficiency with which identities, signatures and amounts can be examined and transferred.

2.  Intermediaries such as collection agents, factors etc. subscribing to this host might purchase such  receivables thru an Offer/Acceptance exchange with the seller, and deliver cash (or digital cash, or bank transfers, or book entry credits on other hosts) to the seller.  

3.  Buyers may pay intermediaries prior to intermediary paying seller, establishing a kind of escrow service, eliminating credit risk to the seller. The point is that delivery of cash is uncoupled from the passing of credit, to some extent. 

The creation of these liquid markets within the STR create conditions for efficient, low-cost services for remittances, settlement and cash management outside the fee structures of banks.  Actual money settlement  might be netted for a subscriber by a service provider, or for groups of subscribers, or all members periodically, and the net balances aggregated into periodic totals for which checks would be printed and mailed to banks. This establishes a model of a webledger with Intercompany Journal Bus.  This establishes a low-cost model eliminating data redundancy and inconsistency between trading parties.  When settlement transactions flow through the STR as well as orders and invoices, the STR becomes a complete record of the dealings between two trading parties, and differences become impossible. These are scenarios which achieve economic returns for any small business participating in STRs and running their STR commerce as a sub-ledger.

Further advocacy and rant on STR Client behaviors

The is table contains fields sufficient for storage of many types of transactions in CDEA rowsets.  Use cases are available on request; they are nothing surprising.  Intermediate accounting textbooks contain the CDEA formulas for every type of transaction that is possible in the economy; additional attributes provided below are sufficient to enable a star or snowflake storage schema that would handle 99.7% of businesses (WAG). No logic is provided however, for all those diverse transactions; it would reside in BSPs, or XSLT transforms, or in the bookkeeper's head.

The structure and DTD for the Webledger table is at http://www.gldialtone.com/rootledgerXML.htm

This is intended to operate just like any General Ledger, i.e., transactions consist of 2 or more rows which sum to zero.  10 million low-paid accountants and bookkeepers already deeply understand this. The last field is an optional string space for XML documents such as POs, Invoices, etc. Most or all of the other 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 would be delivered in XML format. The webledger would need only minimal logic and interfaces necessary to maintain a chart of accounts, and a primitive Journal Entry interface to add/edit/delete transactions consisting of 2 or more rows.  The XMLpayload field for any given row 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.  

It is suggested that the rootledgerXML schema is an appropriate lingua franca for recording in the webledger, the financial result of any ecommerce conducted on the STR with 3rd parties. rootledgerXML is a superset of STR. It overlays the STR table, drops right on top of it.

The rootledgerXML schema was designed as a flat, single-dimension to take it as far as possible down the spectrum so that every little GL in the country can integrate with it. Any programmer of moderate skill would be able to convert to and from flatfile data formats, such as comma delimited files, to conduct business over the internet with this schema.

XML files in rootledgerXML format can be imported almost directly into Peachtree and a number of other low-cost  ledgers, because it is a flat XML schema. Conversion from a flat XML file into a Peachtree comma delimited file can be done as simply as a macro in Excel replacing tags with quotation marks and commas.

Note that it is a red herring, worrying whether to publish an XML standard for General Ledger as a flat schema or a hierarchic one. They can be translated back and forth by a large number of applications, including XSLT. For a collection of XSLT translations between hierarchic and flat schemas, see http://www.gldialtone.com/stupidTricksWithXSLT.htm

We all know that General Ledger transactions can be transported equally well in a flat schema or complex hierarchic schema.  Choosing a complex, hierarchic schema needlessly breaks compatibility or import/export from legacy PC software.

Normalization of data structures has been a hammer for anything that looks like a nail, for over 30 years.  One result has been a complex ERP software model and proliferation of data structures that are not optimal for search and query speed.  SQL-2 was significantly upgraded to SQL-99 by IETF.ref ref  ref ref   RootledgerXML is adopted harmoniously alongside ERP as well as among BSPs on the internet, providing a star or snowflake schema for data warehouse applications. The flat General Ledger structure is also well suited for OLTP within small and midrange accounting systems.  This topic has been hotly argued on FERMS developers list Sep 10-15, 2000 at http://www.egroups.com/messages/free-erp-dev/ .   

See also, text FAQ.  Uniform Electronic Transaction Act, Electronic Signatures in Global and National Commerce Act (E-SIGN)

Todd Boyle Kirkland WA  425-827-3107

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Quiz

1.  What are some irreducible minimum data elements in any e-commerce exchange? 

2.  What are the four clusters of information that 3rd parties always share, in any transaction and might as well be on a shared host?  

3.  What are the five data elements that are the minimum facts necessary for individual personal finance programs, record keeping for income tax deductions, and small business general ledgers?  

4.  What organization is working to establish standard names for all the data elements defining  "Who, What and How" classifications in e-commerce?  

5.  You can buy and sell, pay and receive, and conduct business successfully using several unrelated BSPs (business svc. providers)  What are the seven things you cannot get from multiple BSPs? 

6.  If conducting business over the internet is this simple, why is it taking so long?