GNOME Bugzilla – Bug 406127
Multi-currency transactions can result in incorrect decimal places displayed (and used in calculations?)
Last modified: 2018-06-29 21:26:06 UTC
Please describe the problem: When a transaction is entered with splits to accounts of currencies with different "smallest fraction" values, the "smallest fraction" of the transaction currency is used even in the account of the other currency. Selecting the split seems to result in the number being truncated to the number of decimals of the transaction currency. Steps to reproduce: 1. Create a new file with default currency Japanese Yen 2. Use the simple Simple Checkbook default account setup 3. Create a Canadian Dollar bank account under the Current Assets account (alongside the Checking Account) 4. Open the JPY account, enter a transaction for 10000 JPY mapping to a value of $90.40 in the Canadian account. 5. Jump to the Canadian account. 6. Show splits for the transaction (in the Canadian account) -- The transaction line shows 90.40 but the splits show 90.4 6. Select a split. -- The value in the split line changes from 90.4 to 90.00 7. Unselect the split. -- The value in the split goes back to 90.4 8. Close the account windows - go to the Accounts tab. 9. Note the balance against the "Current Assets" account is -44 yen, when it should be 0. Actual results: The value in the split line doesn't show the full decimal places expected for a CAD transaction. The value in the split line changes from 90.4 to 90.00 (drops decimal place values) when the split is selected. Expected results: I would expect the split to always show 90.40 when viewed from the CAD account, and the two sides of the transaction to balance to 0, rather than -44 JPY Does this happen every time? Yes Other information: While I did not see it in this case, it seems this might affect the Balance Sheet report as well; I see this in my own accounts.
Created attachment 82229 [details] Screenshot of unselected split
Created attachment 82230 [details] Screenshot with split selected
After looking at the raw data file, it appears that because the transaction currency is JPY, the splits on the CAD side are displaying with no decimal places (as JPY amounts do). If I change the transaction currency from JPY to CAD, everything is calculated correctly, but the JPY-side splits display with the two decimal places associated with CAD.
I think, I can confirm this as one aspect of the investigations on bug 547335.
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=406127. Please continue processing the bug there and please update any external references or bookmarks.