I've just started working on a project that uses the Mauritanian ouguiya (MRO) as its currency. In some sources, ouguiya is said to have a subdivision called "khoum" or "khoums", whose value is one fifth of an ouguiya, making it one of the very few currencies that has non-decimal subdivisions. In fact, ouguiya doesn't have any subdivisions at all but the smallest coin that has been issued for it is a fifth of an ouguiya. In Arabic, which in the official language of the country, "fifth" is called "khoums". The coin itself says 1/5, so it is not perceived as a subdivision of the currency but just a value that is less than 1. GnuCash seems to think that all amounts in MRO need to be rounded to the next fifth, so if I input 35.3, the system automatically changes it to 35.4. This is probably correct if you're dealing with cash. In banking, however, other figures up to two decimals do occur, so e.g. on your bank account, you can have a bank fee of 35.17 MRO. Right now, I have no way of inputting these amounts, as GnuCash automatically rounds them up to 35.2. Since January 2018, Mauritania launched a new currency with the same name but a different code MRU (see the separate report I filed at https://bugs.gnucash.org/show_bug.cgi?id=797316), and what I just described applies to both the old and the new currency. The smallest coins are 0.2 MRO and 0.2 MRU respectively, and in banking, both currencies use 2 decimals.
Just to clarify what I said above: In my mind, the default display value for MRO and MRU should be no decimals for round figures and up to two decimals for figures typed in as such: 35, 35.3, 35.31. In cash, the 0.2 coins are quite rare, so apart from banking fees, almost everything else (purchases, salaries, taxes) should be full ouguiyas. If the user can change the amount of decimals displayed for a specific account, that would be ideal but underlyingly at least, two decimals should be supported.
GnuCash thinks that the MRO's smallest currency unit is 1/5. That's based on ISO4217 from some years ago. Unfortunately the current ISO4217 "First List" has only MRU (with 2 "minor units", meaning a smallest currency unit of 1/100); MRO has been moved to the "Third List" (Historical Currencies) and that doesn't include minor units. I've changed the smallest fraction for MRO to 100. That will get rid of the bogus rounding. If you set the smallest fraction on the account to 1 it will mostly display the way that you want... "mostly" because not all code checks that value. It does work correctly in the register. The change will be in the next GnuCash release, or you can try tomorrow's nightly build at https://code.gnucash.org/builds/win32/maint.
Thank you for your swift reaction to this and the other problems I reported. I downloaded the nightly build, and it seems that if I create a new accounting file, both of the currencies now work as expected. However, files I've created before still display some of the same behavior as before the nightly build, i.e. rounding to the next fifth and amounts in zero displayed in fractions. What should I do to update an old project to work as expected?
New transactions in the old files should behave properly. Existing transactions won't change, as the amount itself has been rounded. You'll have to edit those to recreate the correct values.
I tested adding new transactions to an old file with MRO as currency. 40 MRO is still displayed as 40 + 0/1 and 35.12 is automatically converted to 35.20. In a brand new file, this problem doesn't occur. Another, possibly unrelated problem is that now if I type 40, it's automatically converted to 4.0. If I want 40, I need to type 40.0. Even for decimals, typing 32 gives 3.2.
What is shown in Edit-Preferences->General:Numbers? See https://www.gnucash.org/docs/v3/C/gnucash-help/set-prefs.html#prefs-general
Thanks for the pointer. I found I had enabled a setting which in French is called "Forcer le nombre des décimales", i.e. "Force the number of decimals". By disabling that, typing returns to normal. Apparently in English, the checkbox is called "Automatic decimal point", which sounds much more like what the button actually does. In French, it sound like it would keep the number of decimals the same throughout all the accounts. For the problem of rounding and fractions with old files, I think I'll just try exporting and reimporting the data, since new files seem to work fine.
What's the smallest fraction setting of one of the accounts where it's rounding?
If you have a suggestion for a better message, contact the translator La Boussole <yoann@laboussole.coop>.
(In reply to John Ralls from comment #8) > What's the smallest fraction setting of one of the accounts where it's > rounding? It was set to 1. I see that the files where it's not rounding has the value set to "Use Commodity Value", so I changed it in both Assets and Expenses, and now even the old file seems to be working fine. Changing it on only one account results in an error message saying "The current transaction is not balanced" but if I change the two, it works correctly. Thanks for your help!
