GNOME Bugzilla – Bug 408444
"Smallest fraction" disregarded
Last modified: 2018-06-29 21:26:54 UTC
I created an account in TRL and set "Smallest fraction" to 1/100. However, when I manually enter a transaction directly in that account, everything gets rounded to whole numbers. Derek Atkins wrote on gnucash-devel: > Hmm, looks like it's pulling the SCU from the wrong place. > Can you file a bug report on this, please. I dont think this > has anything to do with multi-currency but is just a bug in the > register code.
I can't reproduce with svn/trunk@15951. I couldn't find TRL; I changed an account to TRY (Turkish Lira) and (even though the commodity is already 1/100), explicitly set it so. 0.01 -> 0.01 0.001 -> [blank] 123.01 -> 123.01 123.001 -> 123.00 Is this not what you're seeing?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Just to make sure you test the same thing I did, here's the steps again (for gnucash-2.05 -- if you still have that version it might be good if you could try reproducing there to make sure it's the same): Create two accounts, one in EUR, one in TRL/TRY (TRL was the obsolete name still used in 2.05, that bug is fixed in the mean time) If not already set that way, set the "smallest fraction" to 1/100 for TRY. Open the TRY account. Add a transaction to the EUR account with a non-integer value and see it rounded to an integer as soon as you press 'tab' to leave the number window. E.g. I enter "2.01" and when I press 'tab' it gets replaced with "2.00".
It's 2.0.5, not 2.05. Even in 2.0.5, it's "TRY", not TRL. You don't mention the transfer dialog coming up, or what you enter. Any chance you could start with a new file, create the accounts as you describe, and attach it to this bug?
Created attachment 87611 [details] gnucash file demonstrating the problem File demonstrating the problem.
Sorry about the missing "." :) TRY was fixed for 2.0.5: "Merged into 2.0 as r15597. Will be fixed in 2.0.5" This bug was originally filed for 2.0.4. Now for the important part :) The transfer dialog doesn't come up, the value is corrected before I finish the transaction. I tried starting with a new file, but couldn't reproduce the problem there. So I took the file where I have the problem and started removing information from it, until I was left with a minimal file that still shows the problem. I've attached it. Looking inside, I see <gnc:commodity version="2.0.0"> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>TRL</cmdty:id> <cmdty:name>Turkish Lira</cmdty:name> <cmdty:xcode>792</cmdty:xcode> <cmdty:fraction>1</cmdty:fraction> <cmdty:get_quotes/> <cmdty:quote_source>currency</cmdty:quote_source> <cmdty:quote_tz/> </gnc:commodity> In particular, fraction seems to be "1". Could that be the cause? I wonder how that happened. I don't even know where I can change this in the GUI.
Re comment #6: I can reproduce this bug. Confirming. So I think there are two bugs here: 1. The account's "smallest fraction" setting is being ignored. The currency's "smallest fraction" setting is being used instead. 2. According to Wikipedia the TRL fraction should have been 100. However, I think this is an obsolete bug because this currency definition no longer exists in current releases of GnuCash. It is now replaced by TRY. The reason you see TRL rounding to whole numbers is because your data file contains a definition of TRL with a fraction of 1. If you edit the data file and change the fraction to "100" instead of "1", it will work like you expect. So I think we should leave this bug open until #1 is fixed.
Created attachment 116590 [details] Sample file using JPY To reproduce the bug in 2.2.6, create an account denominated in JPY and set the account's fraction to 1/100. Open the account's register and attempt to enter an amount of 2.41. The amount will be rounded to 2.00, showing that the account's "smallest fraction" setting is being ignored in favor of the currency's setting of 1. The attached data file is provided as a convenience.
FYI: Bug 427948 - Precision cut off at 2 digits for USD transfer between two 6-digit accounts is related, but tries an transaction between 2 accounts of the same currency with the same number of additional digits.
I can confirm that the first bug from comment 7 (The account's "smallest fraction" setting is being ignored. The currency's "smallest fraction" setting is being used instead) is still happening in version 2.4.4.
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=408444. Please continue processing the bug there and please update any external references or bookmarks.