Re: [GNC] Apple Silicon binaries
> On Oct 7, 2023, at 17:47, peterb wrote: > > Is anyone distributing an Apple Silicon (or fat) binary for Gnucash 5.4.2 > on Mac yet, or is building from source my only option? (I know Intel will > work in emulation.) It's unfortunately not an option at all ATM because WebKitGtk still crashes when built for Apple Silicon see https://bugs.webkit.org/show_bug.cgi?id=248802. Regards, John Ralls ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
What you do not understand is that John Ralls and GnuCash recommend entering the total amount and the total number of shares and letting GnuCash calculate the price. THEN there is no error in the account running balance. This is not going to change. On Sat, Oct 7, 2023 at 8:07 PM Bruce McCoy via gnucash-user < gnucash-user@gnucash.org> wrote: > Hi Everyone, > > On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user wrote: > >If I have missed it, please help me. > > > On Sat Oct 7 15:52:28 EDT 2023 John Ralls wrote: > >What you missed is my explanation that if > >user's books are out of balance it's their > >fault, not GnuCash's. The trial balance > >report will help them discover the imbalance > >but it's up to the user to decide whether > >to spend time tracking it down or to create > >a simple correcting transaction to fix it. > >There are no plans to change that. > > Thank you for helping me. It is quite possible I missed something in your > explanation. I do that a lot. It is one reason I appreciate Jim DeLaHunt so > much. > > Let me explain what I think I understand. It was my impression that you > were saying that when either the “Computing cost of goods sold” > calculations or the “Average Cost price source” differ from the “the trial > balance report” calculations the books would be out of balance. I’d agree > with that and that GnuCash should not make any changes in these cases. If > the user's books are out of balance it's their fault, not GnuCash's. > > What I do not yet understand is if GnuCash considers a price per share of > 10.89 to be a precise figure, why GnuCash does not calculate 1,377.41 * > 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider making a > change to GnuCash to allow it? > > Best Regards, > Bruce McCoy > > > | | 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Maf. King, You get the gold star of the day, for the most humerus response. You deserve it. For mistyping “agree” and for poor proofreading, I suppose I’d get the reverse. I deserve it. Best Regards, Bruce | | 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Adrien, I do not know what is happening with the spacing. I do not know what my e-mail client is. And I do not know how to give you a reasonable answer – just to list three things. Best Regards, Bruce | | 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Everyone, On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user wrote: >If I have missed it, please help me. On Sat Oct 7 15:52:28 EDT 2023 John Ralls wrote: >What you missed is my explanation that if >user's books are out of balance it's their >fault, not GnuCash's. The trial balance >report will help them discover the imbalance >but it's up to the user to decide whether >to spend time tracking it down or to create >a simple correcting transaction to fix it. >There are no plans to change that. Thank you for helping me. It is quite possible I missed something in your explanation. I do that a lot. It is one reason I appreciate Jim DeLaHunt so much. Let me explain what I think I understand. It was my impression that you were saying that when either the “Computing cost of goods sold” calculations or the “Average Cost price source” differ from the “the trial balance report” calculations the books would be out of balance. I’d agree with that and that GnuCash should not make any changes in these cases. If the user's books are out of balance it's their fault, not GnuCash's. What I do not yet understand is if GnuCash considers a price per share of 10.89 to be a precise figure, why GnuCash does not calculate 1,377.41 * 10.89 = 15,000.00 for Jeff. If GnuCash doesn’t, would we consider making a change to GnuCash to allow it? Best Regards, Bruce McCoy | | 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.
[GNC] Apple Silicon binaries
Is anyone distributing an Apple Silicon (or fat) binary for Gnucash 5.4.2 on Mac yet, or is building from source my only option? (I know Intel will work in emulation.) -p ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Bruce, On a side note, (I think John addressed your immediate concern) what in tarnation is your e-mail client? Not only does it oddly removing spacing between words for your own replies, but it seems to now eat spacings between words of other people's replies that you QUOTE!!! Really, what gives? I've never seen such a thing. It is of course no serious matter to GnuCash, or this list, but I am genuinely curious! (*note, I left more than necessary quoted below as an illustration) Regards, Adrien On 10/7/23 2:39 PM, Bruce McCoy via gnucash-user wrote: OnSat, Oct 7 at 1:25 PM David Carlson wrote: >Howmany times must you bring up the same >non-point? Youare right in that I am addressing a community of people who areinterested in and actively developing GnuCash. As a community, youuse GnuCash and tolerate some of its shortcomings, while improvingthe program. From that perspective, this issue may seem to be anon-point. It certainly is a small point. GnuCash has developed a lotsince 2000. As GnuCash continues to develop, the major points willhave been all, in general, decided. Until resolved, unresolved pointswill remain. >Manypeople have explained how arithmetic works, AndI appreciate their expertise, but that does not address the questionat hand. >JohnRalls has explained how GnuCash works. Johnhas done excellent work in developing GnuCash and has, graciously, ashave you all, helped me understand GnuCash better. These are justsigns of how nice you all are. >Doyou really think you're going to get a >differentanswer the N+1st time you post? IfI have missed it, please help me. I do not remember getting an answerto the question “What are the plans to help our users whose booksare out of balance by a cent or so?” ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Everyone, On Sat Oct 7 15:48:25 EDT 2023 John Ralls wrote: >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 >1500/137741 internally and by default display >it as 10 + 5/137741. This is just one more example of the excellent work John has done. Another is the outstanding work John did in 2017 developing the rational number portion number in the source code in gnc-rational-rounding.hpp, just to cite one example. I am also impressed by Jim DeLa Hunt’s expertise in using rational numbers. >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, Thank you for accommodating the GnuCash user. That you do it graciously for even the users who are irritated may well be above and beyond the call of duty. >but the full fraction is what gets used for any >computations and stored in The pricedb. This is the excellent precision that GnuCash has. Thank you. > >Regards, >John Ralls Best Regards, Bruce McCoy | | 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
On Saturday, 7 October 2023 20:03:31 BST Bruce McCoy via gnucash-user wrote: > Again,we age. Yes, we do. Too quickly to be going around in circles. ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
> On Oct 7, 2023, at 09:54, Bruce McCoy via gnucash-user > wrote: > 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? Since you're the only one who's concerned only you can answer that question, but you misunderstood "Average Cost price source" with respect to the Trial Balance report: Average Cost is one of four price sources available when running reports. It's the one that's computed from actual transactions so it's the one you *must* use when running the Trial Balance report. Note as well that GnuCash has no support for cost accounting, so users who need to compute CoGS are better served with a proper ERP program like Odoo that does. > 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 did it wrong. Jeff should enter the number of shares and the amount paid and let GnuCash calculate the price, because the price per share he paid wasn't 10.89, it was 137741/150. 137741 is the product of two primes, 181 and 761, so 137741/150 *cannot* be exactly represented as a decimal. It's simpler to enter the amount and value than to enter an exact price. Regards, John Ralls ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
> On Oct 7, 2023, at 12:39, Bruce McCoy via gnucash-user > wrote: > > > IfI have missed it, please help me. I do not remember getting an answerto the > question “What are the plans to help our users whose booksare out of balance > by a cent or so?” What you missed is my explanation that if user's books are out of balance it's their fault, not GnuCash's. The trial balance report will help them discover the imbalance but it's up to the user to decide whether to spend time tracking it down or to create a simple correcting transaction to fix it. There are no plans to change that. Regards, John Ralls ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
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 1500/137741 internally and by default display it as 10 + 5/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 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.4110.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.4110.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, >> >>
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Everyone, OnSat, Oct 7 at 1:25 PM David Carlson wrote: >Howmany times must you bring up the same >non-point? Youare right in that I am addressing a community of people who areinterested in and actively developing GnuCash. As a community, youuse GnuCash and tolerate some of its shortcomings, while improvingthe program. From that perspective, this issue may seem to be anon-point. It certainly is a small point. GnuCash has developed a lotsince 2000. As GnuCash continues to develop, the major points willhave been all, in general, decided. Until resolved, unresolved pointswill remain. >Manypeople have explained how arithmetic works, AndI appreciate their expertise, but that does not address the questionat hand. >JohnRalls has explained how GnuCash works. Johnhas done excellent work in developing GnuCash and has, graciously, ashave you all, helped me understand GnuCash better. These are justsigns of how nice you all are. >Doyou really think you're going to get a >differentanswer the N+1st time you post? IfI have missed it, please help me. I do not remember getting an answerto the question “What are the plans to help our users whose booksare out of balance by a cent or so?” ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
Hi Everyone, David,thank you for responding. I appreciate your input. OnSat, Oct 7 at 1:25 PM David Carlson wrote: >Accordingto my HP handheld calculator, >15,000.00divided by 1,377.41 yields 10.8900. >Accordingto my hp 49g+ scientific graphing >calculator,15,000.00 divided by 1,377.41 yields >10.8900037026. Althoughthose calculators are not available to me, I agree that you are quiteright. >Idefy anyone to pay that amount per share in >U.S.currency. Weagree. We have agreement on a critical point. >Iam sure the broker's report showed >$10.89per share and $15,000.00 total paid Onceagain, we agree. >whichis what GnuCash would show if the user >selectedthe price to be calculated instead >ofthe total amount according to the attached >illustration because GnuCashwould show the >priceto the nearest cent Again,we age. >Ifshares were expressed to three decimal places >assome brokers' statements do, I suspect the >missingdigit would still be zero and the >resultwould not change for this example Onthe Microsoft standard calculator in my windows machine 15,000/10.89= 1,377.410468319559.David, your supposition is correct. We agree. >Whereis the problem? Accordingto Jeff Earickson, the problem is that his books do not balance. Inmy opinion, GnuCash is an excellent program with many experiencedpeople interested in it and many experienced developers developingit. I am impressed that you are so gracious you will discuss it withme. Speakingof $10.8900037026 per share you say, “I defy anyone to pay thatamount per share in U.S. currency.” We agree. At one time in thepast, developers of GnuCash decided to treat price per share as anapproximation and the number of shares traded in a transaction as aprecise number. We agree that no one is going to pay$10.890,003,702,6 per share of a stock. You seem to be saying that,in this transaction, the purchaser paid $10.890,000,000,0 per shareof the stock. If so, that implies that you believe, and we agree, thenumber of shares traded might not always be a precise number. Butregardless of that, the essential issue seems to be, to me, thatGnuCash is not yet using numbers with enough significant digits toalways calculate results sufficient for our users needs. Whatare we going to do for people like Jeff Earickson? ___ 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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
On 2023-10-07 09:54, Bruce McCoy via gnucash-user wrote: > 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? In the name of heaven, will you never let it go? How many times must you bring up the same non-point? Many people have explained how arithmetic works, and John Ralls has explained how GnuCash works. Do you really think you're going to get a different answer the N+1st time you post? Stan Brown Tehachapi, CA, USA https://BrownMath.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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
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.4110.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.4110.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.
Re: [GNC] GnuCash_user: rounding errors and significant digits
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.
Re: [GNC] Reports exist but display blank?
Ah, I had not seen this, thank you. Where do I put this webkit line? The command in the launcher properties I use is /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=gnucash --file-forwarding org.gnucash.GnuCash @@ %f @@ - Elmar On 10/6/23 21:29, David H wrote: Elmar, Read the other thread in the mailing list re "Reports not displaying" for a work around - https://lists.gnucash.org/pipermail/gnucash-user/2023-October/109024.html Cheers David H. On Sat, 7 Oct 2023 at 09:28, Elmar wrote: I'm running Version: 5.4 Build ID: Flathub 5.4.1 Finance::Quote: 1.58 of GC under Linux Mint 21.2 All reports, not only my saved ones, but all of them under the reports tab, now display a blank window. All the options are still set as I had them when I look at the report's options (accounts reported, etc.), but nothing is displayed. Is this a white on white font problem, and if so, where do I correct it? - Elmar ___ 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.
Re: [GNC] Issues Recognizing Account Names When Importing CSV into GnuCash
If I'm not mistaken, you should only have to do this once per account. Now, combining this with your other question, there is reason #2 to break this into smaller import chunks. You don't want to have to manually assign those in a large quantity in a single pass. Regards, Adrien On 10/7/23 12:01 AM, Gio Bacareza wrote: I'm experiencing difficulties when importing a CSV file into GnuCash, particularly when the file contains both "Account" and "Target Account" columns. Despite meticulously encoding the account names in the CSV to match the exact account names as they appear in GnuCash (e.g., “Asset:Cash”), the software does not seem to automatically recognize and match these names during the import process. Instead, GnuCash prompts me to manually match the account names through its import wizard every time, which is unexpected and inconvenient. For instance, even if the CSV file contains the precise name “Asset:Cash”, GnuCash still requires manual intervention to match the names correctly. Is there a specific reason for this issue, or am I possibly making an error during the import process? I would appreciate any insight or advice on how to streamline this process and ensure GnuCash recognizes account names from the CSV file automatically. ___ 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.
Re: [GNC] Issues Importing a Large CSV with Multiple Accounts into GnuCash: Is Duplicated Transactions Normal?
This is one of the reasons why it is not recommended to import a large file, especially one containing transactions from more than a single account on one side of each transaction. Read over the Help Manual & the Tutorial & Concepts Guide concerning imports. The usual recommended procedure is to break the import into smaller chunks depending on how many transactions you have in a month/year, etc. So for example, you might import January 2023 of your checking account. (from whatever other app, or from a bank download) Then reconcile, and repeat for February, then March, etc. As you go, you are training the matcher, so the imports speed up, and duplicates are detected. It is up to you, how big the import chunks are, but bigger is not necessarily faster, and maybe rarely is. Regards, Adrien On 10/6/23 11:57 PM, Gio Bacareza wrote: I've been attempting to import a large, consolidated CSV file containing multiple accounts into GnuCash. Previously, I used to import transaction logs from various accounts individually, which I thought was a cumbersome process. To simplify this, I’ve created scripts to compile all transactions into one comprehensive CSV file for what I thought would be a more straightforward import process. However, I've encountered an issue where GnuCash duplicates certain transactions during the import. Specifically, this happens when a transaction represents a withdrawal from one account and a deposit into another, which are naturally recorded as two separate entries in the CSV. For instance, when money is withdrawn from a bank account and deposited into a cash account, the consolidated CSV file includes one row showing the bank account debit and another showing the cash account credit. I assumed that GnuCash’s import algorithm would recognize and eliminate these duplicate transactions during the import process as it typically does with other duplicates. Unfortunately, my tests indicate that it imports both transactions, resulting in duplicated entries. Is this a mistake on my part, or is this behavior expected from GnuCash when importing a large CSV with multiple accounts? Any insights or solutions to prevent these duplicates would be greatly appreciated. ___ 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.
