Create a currency account in a currency who's SCU is 100, e.g. EUR. Set the smallest fraction to something larger than 100, e.g. 1000. Create a transaction in the new account for 1.005 and commit it. The amount will display in the register as 1.010 and will be saved in the XML backend as <split:value>1/100</split:value> <split:quantity>10/1000</split:quantity>
I am also observing this behaviour. When changing the smallest fraction of a currency account to a smaller-than-default (fraction), only more "zeros" are displayed at the end but it is not possible to include smaller fraction numbers. It gets rounded to the default fraction of the currency. In my case, I have some brokerage accounts that should represent the value in EUR with more than 2 decimals precision in order to match the bank's provided statements. I am running: - Gnucash 3.8 - Ubuntu, Gnucash 3.8b+ (2019-12-29)
I know you're not going to like this, but your bank is screwed up. If you were to close out one of those positions they'd round the amount they paid you to whole Euro-cents so their presenting you with a fraction-of-a-cent value on your statement is stupid. Setting that aside, you balance and reconcile accounts in the commodity that the account is denominated in, not in the priced-out currency value at some random instant so it doesn't really matter that your bank is giving you statements with silly values on your investment accounts.
Hi John, just a small correction for my message because I used the wrong/misleading terms. I wrote "bank" but the issue was actually with a Crypto-currencies exchange. And then, both the online statements or the transaction export (ledger) show the EUR account with up to 6 decimals, if I recall correctly. Due to the way that these exchanges work, some small transaction do exists (sometimes there are several transactions per order, and the orders do not necessarily need to be big). For these operations, I have even seen fee entries for the EUR accounts for something like 0.0019 EUR (And they do compute it with that precision). Of course, you can always ignore the fee and assume zero, but a number of these operations will end up adding-up and leading to discrepancies between the balance reported in the "web/platform/bank/whatever" and GNUCash. But going back to the "problem at hand", at the moment I don't see any reason for the software not to comply with the higher than default precision for currencies. If it is decided that this should not be allowed for ISO currencies, then the drop-down menu should be disabled for currency only account types. But if not this should be implemented properly, IMHO.
The problem at hand is that accounts can be set to smaller fractions than is legal, but don't actually display the smaller fractions just extra meaningless zeroes. Your problem is a separate one and would be a lot of work to fix because the commodity SCU is widely used for rounding. I'm in favor of removing the account fraction box and data field entirely and always rounding amounts to the SCU. What you describe surprises me, I'd thought that all transactions in a crypto-currency wallet would be in the crypto-currency and aside from a "this is how much your account is worth" displays would worry about real currencies only when you converted the crypto-currency. Do they actually maintain separate accounts in the crypto currency and the user's home currency?
It is not always like this, but many crypto exchanges work the following way: - The user transfer FIAT currency from his Bank to the exchange. This amount of money shows then in the exchange's control panel in the form of an account* - The user puts orders for buy/selling crypto currencies against that account. - When the user want the money back in the "real" bank, requests the money to be transferred from the exchange. *This is the account that is being tracked with higher precision. Of course, it is purely virtual but in my case I do have it included in GNUCash. There are other exchanges in where the users can directly buy Crypto with Credit card, etc. The money does not go to an intermediate account. Of course, the aforementioned issue does not apply for these cases. An alternative "approach" to address this would be to allow the user to have user-defined currencies. This would allow potentially to define a "EUR_higher_precision" that would be used only for this exchanges' accounts. When the user decides to transfer the money from/to the "real" bank, the exchange rate between EUR and EUR_higher_precision currencies can be entered as "1". But anyway, I am well aware that this approach was rejected in the past (requested by some users in order to have cryptocurrencies treated as other currencies instead of commodities) But it would be nice feature to have, in my opinion. And it is more a "philosophical" question rather that code difficulty.
Thanks for the explanation. It seems pretty similar to a normal stock brokerage cash account except for the part about tiny fractions. It would be more philosophical if one was starting from scratch. With GnuCash's 20-year accumulation of spaghetti code where even what is a currency and what isn't is hard-wired in many different places there are real technical challenges to that kind of change.
