GNOME Bugzilla – Bug 683222
Rounding Error in Trading Accounts
Last modified: 2018-06-29 23:10:25 UTC
I just found the book of an old saving account and entered the currency change from 5,31 DEM to 2,71 EUR @ 1,95583 DEM/EUR in 2002. When I finished the transaction in the old DEM account, Gnucash added CURRENCY:DEM 5,30 Imbalance-DEM 0,01 CURRENCY:EUR -2,71 I assume this happened, because the conversion was done in the wrong direction. 5,31/1,95583=2,7149598892 2,71*1,95583=5,3002993
Mike, can you have a look at this?
Unlikely I can help here. Not at all my area of GnuCash knowledge.
I need some help. I've never dealt with pre-Euro European currencies in Gnucash. What do you mean when you say you "entered the currency change"? Does Gnucash have some tools for converting old accounts to Euros? If so where are they? I tried just entering a transaction to move the 5.30 DEM to a EUR account as 2.71 EUR and it worked fine. I also tried entering this transaction from the DEM account and that also worked. I presume the "CURRENCY:DEM" and "CURRENCY:EUR" accounts are Trading Accounts.
> I've never dealt with pre-Euro European currencies in Gnucash. It doesn't matter it is just the example where I found this issue. A more extreme example can be constructed with the living currencies 10 000,00 IDR ~ 1,00 EUR > Does Gnucash have some tools for converting old accounts to Euros? Around 2002 there was one, but it was never ported to GnuCash 2.x Currently there is only a table with the frozen rates to display the equivalent e.g. of your mint collection in src/app-utils/gnc-euro.*. > I presume the "CURRENCY:DEM" and "CURRENCY:EUR" accounts are Trading Accounts. Yes. > What do you mean when you say you "entered the currency change"? I moved the old entries to savingsbook:DEM and set EUR as currency of savingsbook. To close the DEM account I created a transaction, where the first split debited the remaining 5,31 DEM and the second credited the EUR account with 5,31 / 1,95583 = 2,7149598892 => 2,71 EUR Then Gnucash - as always - sorted the credit split before the debit split. Now the mechanism starts, which adds the trading account splits. It sees 2,71 and does the conversion 2,71 * 1,95583 = 5,3002993 => 5,30 DEM and adds the trading-accounts:CURRENCY-* splits while the origin was 5,31 DEM. Finally gnucash adds 0,01 DEM as imbalance. In other words: If the exchange rate is close to 2:1 two old values are mapped on one new value. So the inverse is not unique. I suggest to add a test, if the by converion calculated numbers are the same as the previuos stored numbers. If they differ, redo the conversion starting with the debit splits. Or just start with with the currency with the smallest - don't forget the probably different decimals - unit as suggested in Bug 598228 - transactions should be handled/stored in the currency with the lowest value to avoid rounding errors.
This isn't really related to trading accounts, and I'm not entirely sure there is a bug here although the exchange rate dialog and related code could certainly use some work. I reproduced the problem by creating a file with DEM and EUR bank accounts with an initial balance of 5.31 in the DEM account. I then opened the DEM account in transaction journal mode and entered a new transaction where the first split took 5.31 out of the DEM account and the second split added 2.71 to the EUR account. When I tabbed out of that second split I got an exchange rate dialog that offered an exchange rate of 1.95583 and a debit amount of 5.30 (although the debit amount didn't show until I tabbed through the dialog). This created a transaction that was unbalanced before trading accounts were considered. I think that GnuCash pretty much did what it was told to do. I did make one minor fix. The exchange rate dialog didn't properly populate the "Debit Amount" field when the dialog was initially displayed. This made it less than obvious that anything was wrong if you just checked that the exchange rate was correct and clicked OK. I checked in a fix that fixes that minor problem, but it doesn't change the basic behavior. The situation is not ideal, but I think it will get better if and when the new register code is finished. Part of the problem now is that the register has only one field for each split to show either the value or amount from the split. If trading accounts are on it consistently shows the amount (if they are off it mostly shows the value but I think it sometimes shows the amount). The new register will allow both to be shown which will make this sort of issue more obvious.
Just for the records, your changeset was r22383. Thanks, Mike! Because I have a fixed rate I do not get the exchange rate dialog. So I mark this as depended on Bug 598228 and try to link that on the register rewrite. But your change might probably fix parts of Bug 658494 - Multi-currency splits don't work with Trading Accounts.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=683222. Please continue processing the bug there and please update any external references or bookmarks.