--On February 22, 2006 11:44:26 AM -0800 Andrew Sackville-West
<[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Ann Arbor, MI PGP key ID: BEA343A6
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
