Kmymoney allows user to handle multicurrency transactions. That's great. But the problem, every time you update currency prices, you can see the impact of this action on the net worth amount on the Net Worth Report, and that's normal. But you can't see the impact of the same action on the Income and Expenses Report. This results in a discrepancy between these two reports. Thanks Reproducible: Always Steps to Reproduce: 1. Have more than one currency 2. Update the foreign currency by selecting Update stock and currency prices 3. Look at the impact of this action on the net worth amount 4. Look at the impact on the Income and Expenses Report. There will be none. 5 Actual Results: Result: discrepancy between Net Worth Report and Income and Expenses Report Expected Results: There should be an expense category that show the impact of update currency prices on the Income and Expenses Report Solution: Kmymoney should create an automatic expense category that you may call «unrealized gain or loss on reevaluation» in which the software will show the impact of the action of updating currency prices on Income and Expenses Report.
Since income/expense reports list transactions that were already performed at the conversion rate on the date they were performed I think that the current behavior is correct. Net worth changes because it's based on the current balances of all accounts that can change if price changes but a transaction that was performed a month ago does not change it's value.
Please take a look at #138276 which seems to deal with the same issue and the link provided in comment 1 https://bugs.kde.org/show_bug.cgi?id=138276#c1
Created attachment 92079 [details] Example of updating currency prices
OK, I've learned something today, Thomas AFAIK in KMyMoney we have what is called "2.2. Double entry foreign currency accounting, the wrong way" in the attached link, should this issue be marked duplicate of BUG 138276?
I seems to me that we have all the necessary data to compute the balance of a so called "currency trading account". This could be done when generating a report by walking trough the transactions and computing the balance of each involved currency.
I can't tell if you idea will produce the expected result. But you have to test it. We never know.
An old but still relevant bug. My experience with it recently was noticing one ledger entry showed different values in Income and Expenses reports depending on whether it was by Month or by Quarter (for example) - despite both the ledger entry and the report being in my base currency. I suspect this might be because the category that ledger entry is assigned to is in the currency of where I used to live rather than my current base currency. Presumably, the entry is converted to the category's currency at the date of the transaction, but converted back to the base currency at the report's date, and when those conversion rates differ, it fails the accounting equation. I realize the recommended procedure is to make a duplicate, parallel hierarchy of categories for each currency in use (inconvenient as that is): https://bugs.kde.org/show_bug.cgi?id=350905 . Better would be if the trading account concept linked in the other bug ( https://www.mathstat.dal.ca/~selinger/accounting/tutorial.html#4.2 ) was implemented as standard for multi-currency files. (I wish I had time to figure it out write a patch, but best I could offer is perhaps some coding given good direction.) Out of all this, though, what bothers me most is that there is no warning of this accounting discrepancy when categories happen to be set up this way. This is a trap that certain use-cases can trigger, should the user assume KMyMoney knows what it's doing.
Is this related to bug 452026?
It sounds like it is, to me. (Sorry, this older one came up when I searched.) Or at least they're both part of the broader family of bugs due to KMyMoney not really handling multicurrency accounting properly.