Re: Proposal: Outline of financial table schema for 1.4

[Herb Richter <..hidden..>]

Chris Travers wrote:
> This is offered in the interest of getting discussion going before we
> start to implement.  It is not a final proposal and one will probably
> be offered after 1.3 splits off from trunk.

First let me apologize for "lurking intermittently".  I had thought of 
entering the (structure re-think) discussion some time ago.  Sorry if 
I'm re-visiting previous discussion/consensus.

Having now committed three of five of our companies' books to LSMB I do 
have some concerns and suggestions.  Particularly: 1) a journal vs GL 
driven accounting system and  2) expanding the accounting system into 
include other business functions (as opposed to co-operating with those 
functions).


1) Journal vs GL:

I'm not sure that I know what is meant by "journal" in the proposed 
schema.  I think of journals as being part of a businesses' "Books of 
Original Entry" i.e. General Journal, Sales Journal, Receipts Journal, 
Purchase Journal, Disbursements Journal and perhaps other special 
journals such as a Wage Book.  In a data system, I think of these as 
views of the more basic atomic data.  I wonder if "journal" means 
General Journal (though it actually looks a lot like a General Ledger).

The big advantage to centering the accounting system around the GL is 
that all businesses have relatively similar GLs while the Sales, 
Receipts, Purchase and Receipts Journals can be very different from one 
business and another or from one industry and another.  The GJ is (as is 
the GL) quite consistent across businesses but it would quickly become 
cluttered if used to record all transactions.

I think any auditor would have a big issue if a business had no GL! 
When assessing a company, I think, most people would look first at the 
financial statements, then the trial balance and GL and then at 
individual transactions via any journals.


2) Accounting system and other business functions:

It is very tempting to add stuff to an accounting system but can end up 
mixing apples and oranges.

I see these business divisions: Accounting, Operations, Management, 
Marketing and perhaps others such as Human Resources. i.e:

Accounting:
	- journals: GJ, SJ, RJ, PJ, DJ etc
	- GL and sub-ledgers: A/R, A/P, Trust accounts, portfolios etc
	- reporting: financial statements, tax returns and remittances

Operations:
	- point of sale / order entry / invoicing
	- purchasing / receiving
	- production / expedition
	- customer relations

Management:
	- costing
	- budgeting
	- forecasting
	- performance (department, branch, individual)

Marketing:
	- pricing
	- advertising
	- mailing lists / prospect lists

Security, HR, System, etc.

Items in one division need to communicate with other divisions and data 
naturally flows from certain divisions to certain others (ie order -> 
invoice -> sales journal -> A/R)

[ ...these divisions would make good top level LSMB menus ;-) ]

Accounting and Operations that have these two profound distinctions:
1) they have different tolerances for errors and
2) operations vary drastically from one business to another while the
   accounting does not.

Without getting into too much detail (one could write a whole paper on 
this) let me point out:

Tolerance for errors:
The Accounting division of course needs to balance to the penny (which 
is easily enforced) but the accuracy of the entries needs to be achieved 
 in other ways.  But lets say that the books need to be 99.9% correct. 
 It would be a mistake to try to impose this accuracy onto say 
inventory or onto the front line sales staff or order pickers.  In my 
previous retail business (of 25+ years) I considered that if inventory 
was more than 97% correct (that is in line items - not total value) that 
my staff was waisting time and money being too careful.

Operations vary drastically:
Among the millions of points here would be that one business might need 
to handle only a few invoices and sales per period while another might 
need to be very efficient at handling many sales of small dollar amounts 
and margins.

Notice that "invoicing" is in Operations not in Accounting.

Lets take as an example a retail operation where a customer walks in and 
orders a $30. item that is not in stock and needs to be ordered.  It is 
the store's policy to require a deposit on any to-be-ordered item.

1) the order is entered in Operations (not in Accounting):

2) the deposit needs to be recorded so an invoice (or voucher) is 
generated to pass this to Accounting.  The invoice would result in the 
following:

  db	cash/bank/credit-card	  10.00
    cr	  customer deposits		10.00

Note:
a) This would leave an open order in Operations
     Q-ordered: 1  Q-shipped: 0	Q-backordered: 1  Q-committed: 0
     deposit:  $10.00
b) if the customer also purchased some items, this invoice would record
   the sale and the deposit
c) a policy decision would be needed as to whether or not any
   outstanding customer deposit could be applied to to any future sale
   or just this order.

3) Operations would now acquire/prepare the item - when available and 
the customer receives his order and another invoice is generated:

  db	cash/bank/credit-card	  24.20
  db	customer deposits	  10.00
    cr    sales				30.00
    cr    taxes				 4.20

the (now-not-so) open order now shows:
   Q-ordered: 1  Q-shipped: 1	Q-backordered: 0  Q-committed: 0
   deposit:  $0.00

--------

With a proper partitioning of the different functions, especially the 
Accounting and Operations; users, hackers and developers could better 
customize LSMB to their particular industry without risking the 
integrity of the basic accounting system / function.  Also partitioning 
along functional lines would allow better separation of responsibility 
and access by employee or operator.

--------

My interest in a specialized LSMB would be for multi-tenant commercial 
property rentals.  This involves:
- mostly re-occurring entries but also
- many disbursements that need to be allocated to some or all tenants in
  a particular property based on a formula
- budgeting

-------

I think the proposed schema and LSMB and SL often add Operations type 
features to the Accounting system.

-------

Herb Richter
Toronto.