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

[Andrew Sackville-West]

On Sun, 19 Feb 2006 15:08:55 +0100
Christian Stimming <stimming at tuhh.de> wrote:

> Hi Andrew and Mark,
> 
> Am Samstag, 18. Februar 2006 18:20 schrieb Mark Johnson:
> > >2) you can always come in the next day and record the current price for
> > > the fund so that the pricedb shows the current value. Make sense? the
> > > only thing you'll lose will be the price history. Its okay that you don't
> > > show the current market price at the time of the transfer/exchange. you
> > > can always provide that number later so that your reports show the
> > > current market value.
> >
> > True.  What about the possibility of reports based upon the pricedb
> > entries?  Eg. a graph of the price history.  Such entries would produce
> > unwelcome blips.  I'm just thinking here about possible future features,
> > and, I suppose, the meaning of pricedb entries.
> 
> Just to remind you of the current reports and so that everyone is on the same 
> page: The distinction between prices "from the pricedb" and those calculated 
> "implictly from existing transactions" has always existed and had to be dealt 
> with always. 

Chris, thanks for the background on this. it is helpful. 

I've done some more testing using different options for price source
and whether to show gains or not and the report, as currently modified
in my tree shows no difference between these various settings. I need
to go back to an earlier version of this report and see how it behaves. 

What I'm having trouble wrapping my head around is how it should behave.

In my opinion, it should essentially show a snapshot of the value of
the portfolio at a given point in time. That is, for each stock, it
should provide a a total value of the stock owned at the date specified
in the report. So what is the source of that stock value information?
there are two possible sources 1) the pricedb and 2) the actual
transactions.  In my opinion, the default should be to check both of
these, see which is closer to the specified date and return that value
* number of shares held. All the other computations (% gain, total
return) are completed using that value. 

It seems to me that this should be fairly straightforward and that
there is no real conflict between the two sources of data, unless they
have differing values entered for the same date. In which case, we'd
have to give one a precendent over the other. (IMO, that should be the
transactions. a purchase or sale of a stock at a particular price is
"Real" data whereas a pricedb entry is not). 

So, am I on the right track here? 

And how does what you have said below affect that? It should be fairly
straightforward to search the two sources of price data and pick the
one that more closely matches the date of the report and spew that
information. 

thanks all for your continued help with this.

A

> 
> The report that shows the development of a price over time (the "Price 
> Scatterplot"), as well as all the other reports that depend on exchange 
> prices, has therefore the option of choosing the "price source". I 
> implemented that at the time because to me the only meaningful choices here 
> were 1. either prices from the pricedb, *or* 2. implicit prices, but no mix 
> of both. That's why the option "price source" has one choice to use the 
> "implicit prices" and two other choices that will use prices "from the 
> pricedb". So the solution to this two choices has been to give the user the 
> option to choose between one out of two methods. I'm actually quite sure that 
> any mix between both methods, at least for the same commodity, really doesn't 
> give meaningful results. The "exchange-fn" IIRC should be the abstraction to 
> provide access to both methods the same way. The way the exchange-fn was 
> calculated is probably not the most efficient one, but at least it gave 
> accurate results for the choices that were available. 
> 
> However, although I coded quite a lot of the multi-currency stuff, this is all 
> now quite a long time ago and I don't remember anything I ever did at the 
> time. Hopefully I added enough comments in the scheme code.
> 
> In summary: The question of the price source has been an issue since the 
> introduction of the pricedb to gnucash, and it had to be solved in all 
> multi-commodity reports, not only the advanced-portfolio.scm. If you think 
> the available reportsystem-wide implementation needs changes, you are of 
> course welcome to do them, but please keep in mind that this whole issue is 
> really not trivial. In particular, both price source options are pretty much 
> orthogonal to each other and I haven't heard any convincing proposal to mix 
> them, so I'd rather suggest to continue to treat both separately at some 
> level.
> 
> Regards,
> 
> Christian
-------------- 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/20060219/ec422d42/attachment.bin