[Patch] reworked advanced-portfolio.scm

[Mike Alexander]

--On February 22, 2006 11:44:26 AM -0800 Andrew Sackville-West 
<andrew at farwestbilliards.com> wrote:

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

If you don't have a pricedb you don't have currency exchange rates so 
you can't do currency conversions.  The best thing to do in this case 
is flag an error if someone tries to do currency conversions.  You need 
to check the result of each conversion since some may succeed while 
others fail.  It currently does this in some, if not all, cases since I 
was getting currency conversion failures recently and it didn't crash 
the report.  Instead I got some "N/A" values in it.

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

I still think it's best to do currency conversions the way the current 
report does them.  This covers enough of the cases to be useful and 
will provide a basis for doing more in the future if deemed 
appropriate.  It's only a few more lines of code.  If you don't do it, 
I'll have to add it since I need it so try to make it as easy as 
possible.

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