Bug 118159 - currency conversion uses wrong rates
Summary: currency conversion uses wrong rates
Status: RESOLVED FIXED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-12 05:19 UTC by Michael Sims
Modified: 2017-03-25 18:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Sims 2005-12-12 05:19:27 UTC
Version:            (using KDE KDE 3.4.3)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Kmymoney's currency conversion uses the wrong rates.  What it does currently: always use the online lookup value in preference to any user-entered rates, even for ancient data.  For example, a transaction occurred in a foreign currency in 1985.  I enter a rate for conversion between that currency and my base currency, dated 1985.  I do an online lookup for that same exchange rate, and get a current conversion rate, dated December 2005.  (So now I have two entries in the prices table...)  Kmymoney uses the 2005 rate instead of the correct 1985 rate when it displays the 1985 data.  WTF?  Convert currencies using the rates in effect at the time the transaction occurred.  Do not give automatic priority to the looked-up rate over user-entered rates - the user may have perfectly good reasons for entering rates, and besides, since there can only be one looked-up rate, there's no *rate history* of looked-up rates, so user-entered rates need to exist for historical exchanges.

Specifically, when doing one's taxes, the tax authority will publish an average rate for currency conversions for the entire year.  Here are Canada Revenue's rates, for example:

http://www.cra-arc.gc.ca/tax/individuals/faq/exchange_rate-e.html

It is thus quite useful to be able to say, "For all the transactions that occurred between January 1, 2004 and December 31, 2004, use this rate; then starting January 1, 2005 until December 31, 2005, use this rate."  And so on.  Kmymoney should use the last rate available in its database, whether user-entered or looked-up automatically, that was PRIOR to the date the transaction occurred.

I believe KMymoney has a sort of conceptual failure here.  For securities, one may be most interested in the current value of any securities owned.  However, when securities are BOUGHT or SOLD, and when transactions occur in a foreign currency, one is rarely interested in the CURRENT value of those, but in the value AT THE TIME THE TRANSACTION OCCURRED.  Kmymoney needs to be less interested in the CURRENT value of foreign currencies and more interested in the conversion value at the time of the transaction.

So, my suggestions:
1) when the user gets a new online quote, keep the old online quote in the rates table.  Just keep growing the table.  This will create a day-by-day record of the exchange rate in effect on particular days, which is great.
2) Always use the last rate PRIOR to the transaction, if there is one, even if it's far in the past; otherwise use the first rate AFTER the transaction, and treat user-entered rates and online-lookup rates as having the same priority.  This will let users properly specify year-long conversion rates for tax purposes.
Comment 1 ace jones 2005-12-12 17:53:32 UTC
KMM maintains all the historical prices.  Please provide more
information.  Where specifically are you seeing an incorrect price?
Ideally, please provide a reproducable set of steps to recreate the
behaviour you're describing.

</Ace>

On Mon, Dec 12, 2005 at 04:19:28AM -0000, Michael Sims wrote:
[bugs.kde.org quoted mail]
Comment 2 Michael Sims 2005-12-12 18:59:34 UTC
Create a new account (I choose an asset account named TEST.)  Denominate the new account in a different currency than the one you generally use (I use CAD, and denominate the new account in USD.)  Set the account to begin some time in the past (I choose 2005-01-01.)

Click Accounts on left-hand menu.  Click Asset.  See TEST account, with balance of US$0.00 and Value of CAD$0.00.

Create a transaction in the TEST account.  Use a USD-denominated Category for the split.  I enter a $100 deposit to this asset account, dated 2005-01-02, and offset it against a USD Expense account.

Click on Tools->Prices.  Click Show All Stored Prices.  Add a User exchange rate, dated 2005-01-02 for, say, 1 USD = 1.18 CAD.  Click Online quotes.  Get today's quote, which happens to be 1.1567 CAD = 1 USD.

Now, examine that account/transaction in various ways.  Click  Accounts on left menu, and Asset.  See TEST account, with balance of US$100.00 and Value of CAD$115.67.  (uses 2005-12-09 exchange rate).

Click Reports and display an income/expense report for that account.  Shows a CAD $118 expense in January - uses 2005-01-02 exchange rate.

Click Reports and display a Transactions by Account report for this account.  Shows a $115.67 transaction in January - uses 2005-12-09 exchange rate.

Click Reports and display a Transactions by Category report for the split category.  Shows a $115.67 transaction in January - uses 2005-12-09 exchange rate.

So which is it?  Is it a $118 expense or a $115.67 transaction?  I can see the argument for displaying the current value of the account as $115.67 (it's US $100 in the account today, that's a real tangible asset with a value, today, of CAD $115.67), but any report that purports to display the transaction, rather than today's balance, should use the exchange rate in effect at the time.

If you really wanted to get into it, the program might account for currency gains and losses - buy US $100 for CAD $118, hold it, sell US $100 for CAD $115.67, record a CAD $2.33 currency loss.
Comment 3 Alvaro Soliverez 2008-02-07 22:24:01 UTC
The reports had several issues when dealing with foreign currencies. Most of them have now been fixed in the CVS version.
As for the new features you mention, please log a feature request here: http://sourceforge.net/tracker/?group_id=4708&atid=354708

That one is the correct wishlist for KMyMoney
Comment 4 Cristian Oneț 2014-08-20 20:30:54 UTC
Moving this wish to kmymoney4.
Comment 5 NSLW 2017-03-25 18:02:39 UTC
Transactions by Account
Transactions by Category
Income/expense by Year
all show transaction as $118 in 4.100.0-98af682