[Patch] reworked advanced-portfolio.scm

[Mike Alexander]

--On February 21, 2006 3:54:59 PM -0800 Andrew Sackville-West 
<andrew at farwestbilliards.com> wrote:

> I'm rewriting it so that it tracks two sets of prices in parallel buy
> checking the pricedb and the txn's themselves. Then report back the
> numbers based on whichever of these two prices is "closer" to the
> report date. The idea being that it will provide the latest price
> information we can find relative to the date of the report.
>
> Once that's working, I'll look into currency exchanges. but that's
> another story.

It would be a lot easier in the long run to consider multiple 
currencies while you're doing the rewrite.  It's really not that hard. 
Use a commodity collector (gnc:make-commodity-collector) for 
accumulating values and when you want the actual value in a given 
currency use gnc:sum-collector-commodity to get it.  The last parameter 
to this is a function to do the currency conversion and/or price lookup 
(depending on whether the input commodity is a currency or not).  You 
can get a suitable function by calling gnc:case-exchange-fn.

An example from the existing code is

(let* (((moneyoutcoll   (gnc:make-commodity-collector))

      ...

(moneyoutcoll
       'add commod-currency
       (gnc:numeric-neg (gnc:split-get-value s)))

      ...

(moneyoutcoll 'minusmerge brokeragecoll #f)

      ...

(moneyout (gnc:sum-collector-commodity moneyoutcoll currency
        exchange-fn))

      ...

(let* ((exchange-fn (gnc:case-exchange-fn price-source
        currency to-date))

      ...

One problem with this exact approach is that everything is converted 
using the same exchange rate from the date "to-date".  This is fine for 
some things, but not really for money in and money out where you may 
want to use the exchange rate closest to the date of the transaction. 
The current code doesn't handle this correctly, but I see that you are 
considering eliminating money in and money out from the report which 
would eliminate the problem for them.  Other values used in the report 
(e.g. basis) might have similar problems, but it's probably ok to 
ignore that for now at least.

-- 
Mike Alexander           mta at umich.edu
Ann Arbor, MI            PGP key ID: BEA343A6