[Patch] reworked advanced-portfolio.scm

[Andrew Sackville-West]

On Wed, 22 Feb 2006 13:11:44 -0500
Mike Alexander <mta at umich.edu> wrote:

> --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))
> 
>       ...

this caused problems because the exchange-fn doesn't work right without a pricedb, so far as I can tell. i haven't read them in detail yet, but will. 

> 
> 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.

I think this is a really difficult one to judge. I don't use these accounts or reports and definitely don't do currency conversions. I'm hoping others will chime in with how it should behave in this regard. I suspect a lot of it depends on local tax/accounting practices. Its woefully complicated. Basically, i need more information on how the report should behave in all these cases. And should there be options to provide any possible permutation of options. Like for ex. we want money in and moeny out exchanged at the time of transaction, but basis in current exchange rates. or vice-versa. I just don't know enough about these things to want to guess.

Hence my desire to deal with the single currency version for now. I can see certainly using commodity collectors from the get go so that when the exchange portion is spec'ed its fairly easy to work it in. 


A
> 
> -- 
> Mike Alexander           mta at umich.edu
> Ann Arbor, MI            PGP key ID: BEA343A6
> 
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
-------------- 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/20060222/ef6d9e09/attachment.bin