On Mon, 03 Jul 2000, Robert Graham Merkel wrote:
> It has occurred to me that we really need some account-level
> meta-information beyond the fixed fields and ...
> make our reporting
> a whole lot more powerful and easier to use - as a simple example, if
> somebody specified a "project" field, we could provide summary reports
> sorted on "project".
I think that this suggestion is similar to some of the thoughts that I have
been having.
Let me propose a different logical framework and let's see where it leads.
I think we have all accepted the fundamental model of GUI - Engine -
DataStore. I'd like to examine that "data".
The fundamental thing that the accountants do is "count". Well, actually, it
is more a case of organizing the records of things counted.
I propose that the fundamental "item" is a record that a certain number of
"beans" were added to, or subtracted from, a certain "pot" (Account). This is
what we call the "LedgerEntry". Now there are a number of additional pieces
of information attached to that record. First, the accountants require that
we record the date on which the transfer occurred. Second, the "law of
conservation of 'beans'" requires that "beans added" equal "beans removed".
We group the set of entries into a "Transaction". Further, we must note which
"pot" received (or furnished) the "beans". Now, in addition, if the "beans"
are money and the account involves a bank, we are likely to want to record
information about a cheque such as the "Cheque Number" and the "Payee".
If the item is, for example, a "dividend paid" on a particular "stock" held
in some account at a "brokerage", we would want to record the those properties
as well as the fact that this amount will be "taxable", etc.
So, each "item" has an amount and a number of other properties. Given a
number of such items, we start organizing them according to common properties.
For example, it is usually the case that we assume (require) that all items
which make up a transaction occur on the same date. Rather than record the
date with each item, we can attribute the "date" to the "transaction" and let
each item in that transaction inherit the common property. Similarly, we know
that all dividends on a particular stock holding are "taxable". But so are
the dividends on most of the other holdings in that brokerage. This common
property can be factored and attached to the common element, in this case,
the brokerage account.
Further, I can make a "rule" that when I describe the "receipt of dividends"
activity in some brokerage account, the generated item will be posted to the
ledger which has the properties "brokerage", "security", 'INCOME',
'DIVIDEND', and "taxability". But this rule is probably quite common and can
be factored also.
Let me now try to describe this in OO terms.
First, we have LEDGERS (accounts). These are organized in some recursive
hierarchy. Associated with each LEDGER is a set of attribute-value pairs.
These attributes can be either
classification strings (eg. SecurityName="RedHat"
or Taxability="Non-Taxable")
or rules for locating related ledgers (Post StockActivityActions to
"${Income({Action})}/{Brokerage}/{Security}/{Taxability}/{Action}/")
or preferences to the GUI (Display as a ConsolidatedBrokerageAccount)
Each LEDGER inherits all the properties of its parent unless it has
overridden them.
Then we have TRANSACTIONS which have classification attribute-value pairs.
The engine enforces the "conservation of beans" requirement. One of the
properties would always be the "kind-of-transaction" (Normal, Closing,
Reconciliation, etc). This would be used by the report generators to help to
decide whether or not the items get selected.
Next, we have ITEMS (ledger entries) which inherit properties from their
parent LEDGER and posting-TRANSACTION and reconciliation-TRANSACTION.
Finally, let's discuss reports. In my view, every display of the database is
a "report" and follows the same rules.
To generate a report, you must first establish a selection criteria and "sort
order" over ALL of the classification attributes, many of which will be
"don't care". Then you view the collection of ALL items filtered, sorted, and
summarized. Finally, there is some formatting for display.
Now, I recognize that this description cannot be implemented as described
because it would be too inefficient. Optimizations and shortcuts will be
necessary. However, I present it as a framework in which we can describe a
system.
Comments ....
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
