[GNC] Invoice tax rouding issue in 2.x

[R. Victor Klassen]

I’ve been living with this for years.

The occasional bill has two extra lines (since bills are only internal records it doesn’t matter that they don’t match).

The one is called “Tax Error” and is taxable; containing just enough in its amount field to generate a penny of tax.
The other is called “Accounting Adjustment” and is not taxable, reversing the first one, but leaving in the tax adjustment.

Rarely do I need to have a quantity field of more than one for these.  Occasionally I need to reverse the signs.

> On May 23, 2018, at 4:46 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> Op woensdag 23 mei 2018 03:11:26 CEST schreef Matthew Pounsett:
>> 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.
> 
> The rounding issues are a known bug:
> https://bugzilla.gnome.org/show_bug.cgi?id=502853 <https://bugzilla.gnome.org/show_bug.cgi?id=502853>
> https://bugzilla.gnome.org/show_bug.cgi?id=504954 <https://bugzilla.gnome.org/show_bug.cgi?id=504954>
> https://bugzilla.gnome.org/show_bug.cgi?id=520547 <https://bugzilla.gnome.org/show_bug.cgi?id=520547>
> I once implemented a first fix to handle rounding as you are expecting it but 
> that immediately broke rounding in jurisdictions that have different rounding 
> rules. So that fix got reverted.
> 
> Nothing has changed in this area for gnucash 3 so until the above bugs are 
> fixed the only option is to add a tax correction line. What sometimes does 
> help is entering the amounts as tax included, though in your example it will 
> not work: gnucash doesn't accept 3 decimal places for currencies that normally 
> only have one so it would round anyway even before starting the calculation.
> 
> Regards,
> 
> Geert
> 
> 
> _______________________________________________
> 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.