GNOME Bugzilla – Bug 100295
Only 2 decimal places possible for number of shares
Last modified: 2018-06-29 20:22:36 UTC
Running GnuCash 1.6.6. When entering transactions for account type of Mutual Fund, only 2 decimal places are tracked, regardless of the number of decimal places entered. For example, if I am buying 3.258 shares, it rounds to 3.26 after tabbing to the next field. This is the case even when you setup the commodity to handle 1/1000 units. This can cause eventual inaccuracies in the number of shares tracked, if the brockerage account is actually tracking shares in 1/1000 units, e.g. in a 401k with several funds. I did a search for similar bugs and could find none. I have not tested other types of commodities to check if this is also the case.
I can't recreate this problem here using 1.6.6 or any later version. I created a mutual fund with a smallest fraction of 1/10000 and then created an account with this mutual fund as the security. All my share amounts in this account are correctly rounded to four decimal places. Do you have the security field set correctly in the Edit Account dialog for this account. The currency should be USD (or some other currency) and the security field should be set to the Mutual Fund you own. Your problem sounds like one of these fields is not set correctly.
Created attachment 12754 [details] account heirarchy representation
I checked the security field setting on the account as you note above. It is correct. What is peculiar is that when I create a new file and even setup a duplicate of my account structure, I cannot reproduce the problem either. However, in my main file that contains all my accounts, every account that uses any of the approximately 10 different securities I have setup automatically rounds the shares to 2 decimal places. It actually does this rounding as soon as I tab out of the shares field in teh register. Now, what is more peculiar is that changing the Fraction Traded value in the Commodity Editor for any of my securities actually has no effect - it always rounds to 2 decimal places. For example, if I change one security to trade in 1/10, it still puts everything in 2 decimal places. A partial view of my account heirarchy is attached. The "a1", etc. are accounts and sub-accounts, and the account types are listed below. As I mentioned, though, I am not able to reproduce this problem by setting up a new file with the account structure below. Are there any other settings I am possibly missing? Thanks.
Would you post the definition from your data file for one of these broken mutual fund accounts. Everything between the <gnc:account version="2.0.0"> ... </gnc:account> Thanks.
Here's the definition for one of the accounts from the .xac file in which I'm seeing the problem: </gnc:account> <gnc:account version="2.0.0"> <act:name>401k:Fixed Income Fund</act:name> <act:id type="guid">8d5b9f950c6aa55bedb20dbadf42979c</act:id> <act:type>MUTUAL</act:type> <act:currency> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>USD</cmdty:id> </act:currency> <act:currency-scu>100</act:currency-scu> <act:security> <cmdty:space>NYSE</cmdty:space> <cmdty:id>401k:Fix_Inc_Fnd</cmdty:id> </act:security> <act:security-scu>100</act:security-scu> <act:slots> <slot> <slot:key>notes</slot:key> <slot:value type="string"/> </slot> </act:slots> <act:parent type="guid">91c54e37fb6323b2abbe091e7426c9fa</act:parent> </gnc:account> Here's the definition of the commodity: <gnc:commodity version="2.0.0"> <cmdty:space>NYSE</cmdty:space> <cmdty:id>401k:Fix_Inc_Fnd</cmdty:id> <cmdty:name>401k:Fixed Income Fund</cmdty:name> <cmdty:fraction>1000</cmdty:fraction> </gnc:commodity> I see the line <act:security-scu>100</act:security-scu> I manually changed this line in the file to <act:security-scu>1000</act:security-scu> and it did not change the behavior, i.e. the register still forced the shares field to 2 decimal places. In my test file that I created, in which the behavior is correct, I have the following definition for an acouunt: <gnc:account version="2.0.0"> <act:name>fund_2</act:name> <act:id type="guid">5e3be96751b93a254777b8efd3c6228e</act:id> <act:type>MUTUAL</act:type> <act:currency> <cmdty:space>ISO4217</cmdty:space> <cmdty:id>USD</cmdty:id> </act:currency> <act:currency-scu>100</act:currency-scu> <act:security> <cmdty:space>NYSE</cmdty:space> <cmdty:id>nt</cmdty:id> </act:security> <act:security-scu>1000</act:security-scu> <act:slots> <slot> <slot:key>notes</slot:key> <slot:value type="string"/> </slot> </act:slots> <act:parent type="guid">481f19ed119701e13e930de1b2bf81b2</act:parent> </gnc:account> and the commodity: <gnc:commodity version="2.0.0"> <cmdty:space>NYSE</cmdty:space> <cmdty:id>nt</cmdty:id> <cmdty:name>nortel </cmdty:name> <cmdty:fraction>1000</cmdty:fraction> </gnc:commodity> Thanks for any help. Let me know if I can provide any more info.
mwh> I see the line mwh> <act:security-scu>100</act:security-scu> mwh> mwh> I manually changed this line in the file to mwh> <act:security-scu>1000</act:security-scu> mwh> mwh> and it did not change the behavior, i.e. the register still mwh> forced the shares field to 2 decimal places. Did you do this without gnucash running? Gnucash reads this file in its entirity at startup and then doesn't read it again. I can recreate your problem by changing this value to 100. Changing it to 10000 allows me to enter stocks 4 decimal places.
I changed the value on the line <act:security-scu>100</act:security-scu> to <act:security-scu>1000</act:security-scu> in the file and it now is working correctly. In my attempt noted in my notes above from 08-Dec, I was changing the value in the ".xac" file, not in the main file. Is the .xac file a backup? I changed all occurrences in the main file and it is functioning correctly. I'm curious if there is an error that caused the security-scu tag value to be 100, or if I somehow caused this through a setting of some sort. I know I did not manually edit the file before now. Thanks.
Yes, the .xac file is a backup. What likely happened is that you created the security with a scu of 1/100, created the account referencing the security (which copies the scu to the account), and then later changed the security scu to 1/1000. This would produce exactly the problem you saw as there is no way to change the scu on an account after it has been created. Because of your problem, I am in the process of changing how the account scu works in CVS (aka 1.8), making it either a reference to the currency scu (so that the account scu will track changes to the currency scu), or an explicit user set fraction (that does not track the security scu).
Changes committed to CVS add a new field to the Account Edit widget.
I am having a very similar problem using GnuCash 2.0.1 (compiled from r14585 on 2006-09-21, Ubuntu package). After creating my account hierarchy, I manually change the smallest fraction in one assets account (Skype credit) and in one of my expenses account (telephone expenses), from the default of my currency (EUR) to 1/1000. However, whenever I enter transactions from one account to the other, numbers get rounded to 2 decimal places. This causes inconsistences (e.g. entering two commodities, 0.153 and 0.034, should result in a total of 0.187 rounded to 0.19; however input is rounded to soon, actual result 0.15+0.03=0.18 which is wrong). I cannot follow the workaround proposed by mwh@swbell.net because there are no <act:security-scu> or similar tags in my .xac files. I attach the relevant pieces of the .xac file, showing an incorrectly stored transaction.
Created attachment 75609 [details] Extract of .xac file showing transaction incorrectly rounded The amount typed in the field was 0.034 EUR (written 0,034 using a correctly configured locale). However, the file shows the amount 0.03 EUR, fraction 30/1000, which is wrong.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=100295. Please update any external references or bookmarks.