reports and prices [Patch] reworked advanced-portfolio.scm

[Andrew Sackville-West]

On Mon, 20 Feb 2006 03:45:23 -0500
Mike Alexander <mta at umich.edu> wrote:

> --On February 19, 2006 1:56:38 PM -0800 Andrew Sackville-West 
> <andrew at farwestbilliards.com> wrote:
> 
> >
> > It should IMO also use transactions for current value and make a
> > decision as to which is more accurate, or closer in date to the report
> > date. but only use buy or sell transactions as those are the only ones
> > that provide a "price".
> >>
> >> These two things are, I believe, the correct behaviour.  The
> >> question  comes back to automatically creating a pricedb entry for a
> >> buy and sell,  which looks to be a reasonable thing to do.  The
> >> caveat is that not all  stock transactions should create a pricedb
> >> entry.
> >>
> >> Two options:
> >> 1. Perhaps, one could have a dialog asking the user (with a check
> >> box  for "don't ask again" and an Edit->Preferences check box for
> >> this).  2.  Those transactions that are "buy" or "sell" could
> >> automatically  create a pricedb entry.  Those that are a conversion
> >> from another stock  or a transfer between stock accounts should not.
> >>
> >> Additional thought would have to be given to transactions such as
> >> stock  splits or consolidations that change the number of shares
> >> (and therefore  the price), but not the cost basis.
> >
> > yes yes and yes but, one thing at a time ;). my poor little brain can
> > only take so much!!
> >
> >
> > when I get back to working on this (couple days probably), I'll see if
> > I can generalize the value of the stock so that it can use both
> > properly. I'll ignore the currency conversion for now as that seems to
> > be another monster altogether. Once I get reliable results for value,
> > then I can look into that.
> 
> I finally managed to get around to looking at this again tonight.  The 
> r13293 version of advanced-portfolio.scm contained most of the changes 
> I had made earlier.  I've attached a patch that fixes one problem by 
> converting the gain to the report currency properly.  The patch also 
> adds more debugging output (commented out) since I was having trouble 
> figuring out why the report wasn't working right (turned out to be a 
> bad transaction with no currency in my test file).

hey, thanks for chiming in over here. this report is (has been?) very
sensitive to "valid" accounts. I think I've covered most of the cases
except whatever Eildert's problem is. Things like how to handle
accounts with no shares etc.
> 
> Note that this doesn't address the problems that are the subject of 
> this thread.  I have been assuming that the pricedb is the definitive 
> source of price information.  I can see why this may not always be a 
> good assumption, but I started out with this assumption since I came 
> from the Quicken world and that's the way it works.  I have a cron job 
> that updates price information every day so my pricedb is generally 
> fairly accurate.
> 
> One thing I would add to the discussion is to point out that the 
> pricedb is used for two things in this report (and elsewhere).  It 
> contains prices in some currency for the commodities (stocks, bonds, 
> etc.) that are being reported on and it also contains exchange rates 
> used for converting amounts from one currency to another.  The report 
> can infer the first of these from the transactions, but not the latter. 
> It really needs the pricedb for that.

Yeah, that's definitely a problem. There needs to bhe another
exchange-fn, one that doesn't rely on pricedb. And we probably need to
create BOTH of them in the report simultaneously because we can't know
which "type" of price data we're going to get in advance. 1) for when
the pricedb is our source and 2) for when the txn is the source. The
question is, how can we get currency exchange data? Can we rely on
there being exchange data if someone is working in multiple currencies?


A

> 
> -- 
> Mike Alexander           mta at umich.edu
> Ann Arbor, MI            PGP key ID: BEA343A6
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060220/78698fb2/attachment.bin