On Mon, 20 Feb 2006 03:45:23 -0500 Mike Alexander <[EMAIL PROTECTED]> wrote:
> --On February 19, 2006 1:56:38 PM -0800 Andrew Sackville-West > <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > Ann Arbor, MI PGP key ID: BEA343A6 > >
pgpFfCJMPBVjy.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
