Rob Browning wrote:
> I think perhaps you (and Matt?) are missing one bit of information
> about the engine and the way we handle transactions/je's. While you
> are correct that in the end, when you're trying to see what happened
> at the top-level to your finances, only the purchases and sales are
> relevant, there is a lot of other information that is at least
> *useful* that you might want to record in the (stock) account in the
> interim.
>
> So we record a bunch of non-purchase/sale events in the stock account
> to keep track of this information: price changes (if requested),
> splits, merges, etc.
I don't think we've missed this bit of information -- this cuts right to
the heart of what I was wondering about. Is this within the scope of the
core engine, or should these sort of events be pushed into another
engine or layer that is involved in generating the reports? Especially
in cases where the events can be reconstructed.
Imagine a scale of stock "events", ranked by how germane they are to
your personal account:
1) Buy/Sell transactions
Very intrinsic. Reconstruction by personal/broker records.
2) Dividends
Very intrinsic. Reconstruction by personal/broker records.
If automatically reinvested, this generates #1 as well.
3) Splits
Public Domain, but fairly rare. A pain, but not impossible,
to reconstruct.
4) Daily/Historical quotes
Public Domain, common. Easily avaiable/automatable.
So how many of these are within the "event scope" of the core accounting
engine? Clearly, the first two must be. Just as clearly, the last is
not. All are useful for generating various reports. Splits seem to be in
a grey area, by this metric.
Nathan's suggestion of keeping the split events in some other table, and
merging later as needed for reports, gets back to this idea of having a
"meta engine" for reports and analysis of an account; this could
communicate to the core accounting engine via some API for the
absolutely essential transactions such as #1 and #2 above.
If I may quote one of my prior emails, I offered the following analogy:
Matt wrote:
> Just for kicks, let's say we're talking about an investment
> in rabbits. The central accounting engine should really only
> be concerned with transactions involving a) cost of initial
> rabbits, supplies, maintenance, and b) proceeds from rabbit
> sales. It really doesn't need to be able to make statements
> about how many rabbits you own at any given time, or the worth
> of all of your rabbits at that time, or rabbit losses from
> rabbit plagues or neighborhood dogs; the "rabbit accounting
> engine" should take care of those messy details.
If you extend this idea, what we're really talking about is coming up
with a "transaction editor" that is completely customizable, and
communicates with the core engine as necessary. The new, meta engine can
answer the questions is is designed for; it is modular, and the minutiae
of the particular realm it applies to need not concern the core engine.
Rob Browing further wrote:
> You seem to be arguing that je's (or transactions) and transactions
> that don't affect other accounts (i.e. non-purchases/sales) shouldn't
> be stored in the normal account event stream, but I don't understand
> the reason for that.
Modularity -- each time we come up with a new report for some account
that requires information other than what the core engine stores, it
should not require that the core engine be tweaked.
Take it a step further, and start using ORB style interfaces for these
report engines, and you could plug custom reports into gnucash all day
long and the core engine would remain happy.
--
Matt Sisk
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
