GNOME Bugzilla – Bug 648829
Mutual Fund accounts losing precision when converting backend to SQLite
Last modified: 2018-06-29 22:57:22 UTC
When converting from a XML backend file to a sqlite backend file the mutual funds account loses decimal places in every entry because the smallest fraction of the related security changes to 1/100. Steps to reproduce 1. have a mutual fund account with the field 'smallest fraction' set to 'use commodity value' 2. set the related commodity fraction to 1/100000000 3. enter some transactions 4. save the file using the sql backend option 5. close gnucash and open it again pointing to the new sql file 6. close gnucash again and open it again pointing to the new sql file See attached screenshots for details.
Created attachment 186790 [details] original_xml_backend_1
Created attachment 186791 [details] original_xml_backend_2
Created attachment 186792 [details] converted_sql_backend_1
Created attachment 186793 [details] converted_sql_backend_2
So it seems to be a problem with the SQL backend.
Maybe, however I also noticed that it happens when using the Check & Repair function under the Actions menu for all transactions. Hope this helps a little further.
No, the problem is in the definition of the "fraction" property, PROP_FRACTION, in src/engine/gnc-commodity.c: The maximum value is 1E6. There was a similar query on gnucash-user in February... in that case it appeared that some boneheaded mutual fund was sending statements with ridiculous values. Maybe that guy and Gilberto have the same fund... The only good reason for such a tiny fractional unit would be if the mutual fund is priced in some hyper-inflated currency like the defunct Zimbabwe Dollar, but even then, what's the point of keeping track of pennies when a loaf of bread costs $1E6? I'm not inclined to change this.
I understand. I'll try to change the precision of the security denominator to the limit of 1E6 and see if that works. As a measure to avoid future problems like this I ask you to please consider limiting data input in the security editor to the maximum value. I mean the system should not accept data input above the maximum value. Thanks again for all the help.
(In reply to comment #7) Sorry for the delay, somehow I didn't catch it. > No, the problem is in the definition of the "fraction" property, PROP_FRACTION, > in src/engine/gnc-commodity.c: The maximum value is 1E6. 1. May be, it should round to 6 decimals, but the screenshots after show only 2. Gilberto, reduced you one in the account settings? The other still uses the commodity value, but only shows 2 decimals. 2. In Bug 657402 the Bitcoin guys are also asking for 8 decimals, their official notation. There is also an example file with 8 decimals. 3. As you can see in my attachement there, I was able to store "12345678/100000000" using the xml backend. Edit Security allows an unlimited number of digits, but if you store they are truncated without warning to 9, e.g. 100000000. So 8 significant digits are possible. Hm, I find it strange, that we do not have a global declaration of the max number of decimals. IIRC SQL has a type with a default value of 10 decimals. So I would suggest to use that for the next years. 3. To clarify this: g_object_class_install_property(gobject_class, PROP_FRACTION, g_param_spec_int ("fraction", "Fraction", "The fraction is the number of sub-units that " "the basic commodity can be divided into.", 1, 1000000, is the default value, which is shown in the GUI. You can extend the number as described above. > There was a similar query on gnucash-user in February... in that case it > appeared that some boneheaded mutual fund was sending statements with ridiculous > values. Maybe that guy and Gilberto have the same fund... > > The only good reason for such a tiny fractional unit would be if the mutual fund > is priced in some hyper-inflated currency like the defunct Zimbabwe Dollar, but > even then, what's the point of keeping track of pennies when a loaf of bread > costs $1E6? Hm? Wrong direction? If the fraction is 1E6, the value of a part is 1E-6. I think, we should not try to define the world. When I visited Indonesia, 10 000 IDR were less than 1 EUR, the smallest coin was 100 IDR, but later I learned, accounting is still done in Sen = 1/100 IDR. Bug 642176 c2 shows the relation between inflation and real values. 3% inflation requires every 60 years a new digit. > I'm not inclined to change this. Do you fear some hidden implications?
I'm worried about overflow. See bug 665707.
(In reply to comment #10) > I'm worried about overflow. See bug 665707. Meanwhile bug 665707 has been closed with final statement: "I'm going to stop worrying about this and consider it a testing issue." Does that mean you no longer worry about overflow if we increase the maximum value of the fraction property ? Or is this something that is better left as is until we have switched gnc_numeric to work with boost::rational<boost::multiprecision> internally ?
Not yet. I'll stop worrying about overflow when gnc-numeric has been reimplemented as an instance of boost::rational<boost::multiprecision>. Closing bug 665707 as a testing-only problem is predicated on limiting the number of denominator digits. Consider Frank's IDR example in comment 9: €10K is > IDR 1E10; buy that much Bitcoin and, if GnuCash supported it, calculating the exchange rate might overflow because the combined number of digits would exceed 18.
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. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=648829. Please update any external references or bookmarks.