Stock "price" transactions

Bill Carlson wwc@wwcnet.nu
Tue, 5 Dec 2000 08:15:00 -0500


On Tue, Dec 05, 2000 at 12:50:38AM -0800, Dave Peticolas wrote:
> 
> I am going to hold off on putting this patch in because I think it
> needs more discussion. Our plans for stock prices in GnuCash 2.0 are
> to store them separately from the register (and from accounts), and to
> use them for reporting/graphing purposes, but not to store them as
> 'real' transactions the way they are in GnuCash 1.4. Part of the old
> format import process would be to convert these old price transactions
> into entries in the price database.

Fine, except do you have any idea of when some of this support will be
put in?  If I (and I suspect others) are going to realistically try
to work on the new stuff, this is necessary.  

I would point out that one of the main reasons I use gnucash (or any 
such program) is to keep track of "where I am" financially (with history).
This means that eventually things like the account table gnucash shows 
on startup need to reflect the "current" value of a stock, and there 
need to be mechanisms to produce a history of that.  I can do all that 
just fine with the current mechanisms.  Just want to make sure that 
whatever you are thinking of for this area reflects these "requirements".

One more thought on this.  Whatever "register" display you have for
stocks should (I think) reflect the values of the stock at that time
of each given transaction.  I think that means that if you don't
have the "price transactions" the redisplay mechanism would need to
consult the "price database" every time you opened/refreshed the 
"register" for the stock account.

Just some thoughts.....

> 
> The other part of the patch, which prevents normalizing the damount
> and value parts of a split for stock-type accounts with no security,
> also needs to wait. It is true that GnuCash 1.4 allows stock-type
> accounts with no security, but this is really a bug. A stock-type
> account is supposed to be counting *something* and thus every such
> account really must have an actual security specified. The old-format
> importer needs to be modified to prompt the user to specify an actual
> security for such accounts where none exists. That should eliminate
> the need for the patch.

Again, fine.  I certainly recognize this as a "hack" and would be quite
willing to work on such an importer at the apropriate time.

> 
> thanks,
> dave

And thank you for all your gnucash efforts.  I am very impressed by
the results your efforts!

Cheers,

Bill