GnuCash does **NOT** round prices to two decimals. Prices are always calculated to the full numeric precision of 1/2^64. Amounts and values are what get rounded to the respective commodity/currency's smallest unit. Since 15000 and 137741 have no common factors GnuCash will represent that as 15000000/137741 internally and by default display it as 10 + 50000/137741. The latter irritates some users so we provide a preference that will display it as a decimal with two more fractional digits than the currency's smallest, so in the case of USD it would display as $10.8900, but the full fraction is what gets used for any computations and stored in the pricedb.
Regards, John Ralls > On Oct 7, 2023, at 10:25, David Carlson <david.carlson....@gmail.com> wrote: > > According to my HP handheld calculator, 15,000.00 divided by 1,377.41 > yields 10.8900. According to my hp 49g+ scientific graphing calculator, > 15,000.00 divided by 1,377.41 yields 10.8900037026. I defy anyone to pay > that amount per share in U.S. currency. I am sure the broker's report > showed $10.89 per share and $15,000.00 total paid, which is what GnuCash > would show if the user selected the price to be calculated instead of the > total amount according to the attached illustration because GnuCash would > show the price to the nearest cent . If shares were expressed to three > decimal places as some brokers' statements do, I suspect the missing digit > would still be zero and the result would not change for this example . > Where is the problem? > > On Sat, Oct 7, 2023 at 11:55 AM Bruce McCoy via gnucash-user < > gnucash-user@gnucash.org> wrote: > >> Hi Everyone, >> >> On Fri, Oct 6 at 1:02 PM John Ralls wrote: >>> Book out of balance, meaning that the trial balance >>> report doesn't balance with the Average Cost price >>> source, nearly always results from not computing >>> capital gains/losses correctly. Interpret that >>> broadly:... >> >> The books are out of balance when either the “Computing cost of goods >> sold” calculations or the “Average Cost price source” differ from the “the >> trial balance report” calculations. Both of these are more major points. Is >> our concern here about a relatively major point or about a relatively minor >> point? >> >>> GnuCash's rounding isn't likely to put books out of >>> balance because GnuCash forces transactions to be >>> balance in the transaction currency. >> >> “GnuCash's rounding isn't likely to put books out of balance” is certainly >> true. GnuCash's routines have a high degree of precision. I’d say John >> Ralls’ and Jim DeLaHunt’s work on rational numbers is excellent. GnuCash >> almost always displays an answer correct to two decimals. Can GnuCash ever >> put the books out of balance? >> >>> GnuCash forces transactions to be >>> balance in the transaction currency. >> >> In the transaction currency, GnuCash forces transactions to balance with a >> high degree of precision. This is certainly true. Does GnuCash force >> transactions, in the transaction currency, to balance in all cases? >> >> In previous posts, we have mentioned Jeff Earickson's experience and >> comment. >> >> We mentioned that on a certain day, Jeff entered the number of shares he >> purchased (1,377.41) and the price per share he paid (10.89). GnuCash >> calculated the Value of the transaction. >> >> Jeff expected the numbers in his transaction line to be as follows: >> >> # shares Price-per-share Value >> 1,377.41 10.89 15,000.00 >> >> https://tempsend.com/qekjd has Shares_Price_Value_Calculate_gnu.png. >> Jeff wanted to see something similar. >> >> The numbers GnuCash calculated were as follows: >> >> # shares Price-per-share Value >> 1,377.41 10.89 14,999.99 >> >> Jeff Earickson observed the discrepancy and understood that his books were >> not in balance due to Ghucash’s calculations. So, Jeff contacted GnuCash. >> And Mike Novack noticed. >> >> On Sun Feb 23 10:15:34 EST 2014, Mike Novack mentioned Jeff Earickson's >> comment >>> "1377.41 x 10.89 = $14,999.99 (one penny off, arrrgh...)"[1]. >> >> Jeff seems to want GnuCash to calculate the value of his transaction >> correctly to, using the convention that ignores the first digit if it is a >> one, at least 6 significant digits. In this case, GnuCash’s approximations >> are almost correct. >> >> Jeff wants his transaction line to balance. Jeff states the difference in >> pennies and also states his reaction to GnuCash’s calculations. >> >> Jeff’s situation is the specific example cited for our discussion of a >> general situation with GnuCash. This example illustrates the question for >> consideration. >> >> Our question for discussion is as follows: >> >>> What are the plans to help our users whose >>> books are out of balance by a cent or so? >> >> >> Footnotes: >> [1] >> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053296.html, >> >> https://lists.gnucash.org/pipermail/gnucash-user/2014-February/053299.html >> . >> >> >> >> | | Virus-free.www.avast.com | >> >> _______________________________________________ >> gnucash-user mailing list >> gnucash-user@gnucash.org >> To update your subscription preferences or to unsubscribe: >> https://lists.gnucash.org/mailman/listinfo/gnucash-user >> ----- >> Please remember to CC this list on all your replies. >> You can do this by using Reply-To-List or Reply-All. >> > > > -- > David Carlson > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
