[GNC] Invoice tax rounding issue in 2.x

[Adrien Monteleone]

Just out of curiosity, how many possible rounding rules can there be? I shouldn’t imagine more than a handful. I don’t remember where I saw it, but some application I used in the past had options to choose which of several rounding rules you wanted to use. (I also don’t recall if this was financial software or not, sorry.)

I would think the solution (if the set of rules is in fact small) is to implement them all and let the user choose the one they wanted/needed. Thus it isn’t ‘impossible’ to solve, just as usual, not as easy as it first looks.

Regards,
Adrien

> On May 23, 2018, at 7:39 AM, Mike or Penny Novack <stepbystepfarm at dialup4less.com> wrote:
> 
> There is no solution to this. Among other things, it would be dependent on the rules of the jurisdiction whether the tax is supposed to be figured per item or on the total of all taxable items. So what would fix it in one case would break it in the other. It simply is true that rounded(a) + rounded(b) may not equal rounded(a+b). One of the things I used to do in my working days was to calculate the correct "fuzz" (maximum discrepancy) for comparison tests << effective equality >>
> 
> It is not only with this that we have a problem. Those of us who keep books to exact amounts but must file with governmental agencies on a whole dollar basis know how much "fun" it is deciding which amounts to juggle up or down (what is the LEAST alteration) as necessary to the book amounts to make the whole dollar report come out right. This this year, for one organization, fudging two amounts by a few cents was enough to make the 990-EZ come out right.
> 
> BTW, there are analogous problems with things like figuring amortization tables for loans )) how much of each payment is interest and how much principle). There is no "right" way to do this and so any function used by a program might not match what the particular bank says. In cases like these we can't ask that the program be "fixed" to agree.
> 
> Michael D Novack
> 
> 
> On 5/22/2018 9:11 PM, Matthew Pounsett wrote:
>> I've got an off-by-a-cent error on an invoice due to the way taxes are
>> calculated.  GnuCash (2.6.21) is calculating the tax on each individual
>> taxable item, then summing that up, and adding that value to the subtotal.
>> This causes an error because each individual tax calculation is rounded
>> prior to subtotalling.
>> 
>> Given a tax rate of 13%, GnuCash is doing this:
>> 
>>             Item     Tax
>>           277.50   36.08
>>            92.50   12.03
>> Subtotal: 370.00 + 48.11 = 418.11
>> 
>> When the real calculation should be:
>> 
>>             Item      Tax
>>           277.50   36.075
>>            92.50   12.025
>> Subtotal: 370.00 + 48.100 = 418.10
>> 
>> This could be fixed by GnuCash not rounding tax amounts until the final
>> total, but typically I believe the calculation done is to add up all the
>> taxable items and apply the tax calculation to that subtotal, so that it's
>> not necessary to track many decimal places to avoid a rounding error.
>> 
>> I did some searching through the mailing lists and I see a lot of reported
>> issues about rounding errors in GnuCash 2.x.  I can work around this by
>> putting in an extra line item to correct the taxes, but it would be nice
>> not to have to do that.  Is this something that's been fixed in 3.x?  I've
>> been avoiding the update because I haven't had time for a careful
>> migration, and testing whether I'm affected by any of the various issues
>> that have been reported since its release.  But, this might be a reason to
>> set that time aside.
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>> 
> 
> 
> -- 
> There is no possibility of social justice on a dead planet except the equality of the grave.
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>