It's been rumoured that Matt Sisk said:
> 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?
The current engine design has a single, uniform, unified way of
recording all four.
> Clearly, the first two must be. Just as clearly, the last is
> not.
If you personally do not want to record price data, that is your
prerogative. The engine doesn't care. It'll store it if you ask it to.
> 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.
You raise a very interesting point: someone (e.g. you) may want to
merge, on the fly, gnucash data stored in a file with data from the
outside world, e.g. prices sucked down off the net. There are any
number of ways to do this, and at least some of the ways require
no changes whatsoever to the engine, and these same ones might take
only a small impact to non-engine code.
> 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.
I apologize, but I completely fail to understand what you are getting
at.
> 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.
And of course, I completely fail to understand why I need a new engine
as a result.
> 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.
Huh? New reports do not require the engine to be tweaked.
--linas
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
