Richard Wackerbarth writes:
> 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 ....
I kind of like the idea, actually - it's tremendously flexible, and
solves the "meta-information" problem by making meta-information just
another data type.
Two problems rear their ugly head again, though. As well as the
inefficiency problem you've described, there is the problem of making
the expressiveness of the back end available through the GUI.
Can we put this discussion on hold somewhat until the rest of the
developers get back from holiday? I think we've posed some concrete
problems, which have led to some rather interesting suggestions
improving the engine.. However, I believe some work has been going on
in this area and I'm sure that Dave and Rob will have
quite a bit to say on this.
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
