GNOME Bugzilla – Bug 309863
Balance Sheet: Rounding errors with prices from pricedb
Last modified: 2018-06-29 20:52:44 UTC
Please describe the problem: On an account with fractional shares, GnuCash calculates the balance in the Balance Sheet incorrectly. The console sometimes displays the message "Warning: PrintAmountInternal: Bad numeric" The transaction in question was for 53722.78 shares at $.3722815536/share. The price editor also rounds this even though the commodity fraction was set to 1/100000000000000. Steps to reproduce: 1. Create a new file with checking and investment accoungs 2. Create a new subaccount of Stock called bug with a new commodity, bug 3. Create a new transaction debiting bug, crediting checking, buying the above number of shares for $20,000. Let GnuCash calculate the price. 4. Run a balance sheet. Actual results: Balance sheet shows: Current Assets -$20,000.00 (okay) Investments -$291.42 (totally wrong) If I change Price Source to Nearest in time, I suddenly get a $291.42 unrealized gain (still wrong). If I enter a price in the price editor for the date, the Investments value becomes $20,000.02. Closer, but still wrong. Expected results: Current Assets: -$20,000.00 Investments: $20,000.00 Does this happen every time? An error occurs every time, but the PrintAmountInternal message does not. Other information: Financial applications demand accuracy in the figures. Not having a gui is forgiveable. Not having piecharts is forgiveable. Having incorrect figures is not. Porting to Gnome2 is of no value if the numbers don't add up. As is, for me, the program is totally unuseable because I can't trust it.
In the "steps how to reproduce", do you also set the "smallest fraction of this commodity" to the value that you said above, i.e. 1/100000000000000 = 10^-14 ? In that case, please use a not so large exponent, because this fraction value is stored as an integer value, and the value range for integers only goes up to approx. 2*10^9. In other words, your entered "smallest fraction" will cause an internal integer overflow -- which of course the application should catch but currently it doesn't. Can you verify what happens when you choose a value inside this range, e.g. 10^9 ? Thanks.
When I set the commodity scu to 1/10000000 I get the same result. I believe the account scu should be set to whatever commodity scu the account uses. I'm not sure if that's the problem, though.
Created attachment 49136 [details] Saved XML for this problem
This seems to be related to bug#122878
Does this problem still occur in the new 2.0.x versions? Development on 1.8.x has halted, so we cannot fix anything there anymore.
Under 2.0, the Balance Sheet is correct when using "Weighted Average" for commodities. When "Most recent" or "Nearest in time", however, the value of the investments is $0.00 and the total assets is -$20,000.00. If no quote is available for a commodity, the value should be the purchase price. The value of the investments in this case should always be $20,000.00 and the total should be $0.00. This is important because there are many commodities for which there is no quote available since they are not publicly traded. If anyone has stock options, or shares in a private company, this problem renders all the reports in GnuCash less than useful, since all the figures will be incorrect. There are still rounding errors elsewhere, but I'll log those as separate problems.
*** Bug 406567 has been marked as a duplicate of this bug. ***
I like the pricing idea in comment 6. I might take a shot at that, now that some code to compute the cost of holdings is available to reports.
Regarding the originally reported problem: As of r17402, the balance sheet looks perfect for the attached example when using the "Weighted Average" or "Average Cost" price sources. However the price editor currently rounds all prices to the nearest 0.000001, so the price of 0.3722815536 is rounded to 0.372282. This is the source of rounding when using the "Nearest in time" or "Most recent" price sources. I'll see if I can get that rounding behavior removed so that the EXACT price is stored. By the way, the "smallest fraction" stuff doesn't affect the problem; rounding to the nearest 0.000001 is hard coded.
Fix committed in r17421 and r17429. Requesting backport for 2.2.
Suggestion about Comment #1: shouldn't we at least warn the user, if he is in danger to run in an integer overflow? Or disable settings, where this can happen? Which normal user has has an impression about "The program is running on a x bit system, resp. is compiled with INTEGERy, which results in max. z decimals."
Re comment #11: In 2.2.6 you are not allowed to set "smallest fraction" anything smaller than 1/100000000, so I think comment #1 is no longer a problem.
(In reply to comment #10) > Fix committed in r17421 and r17429. Requesting backport for 2.2. Applied to branches/2.2 as r17512 for inclusion in GnuCash 2.2.7. Thanks a lot!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=309863. Please update any external references or bookmarks.