Re: [GNC] Invoice tax rouding issue in 2.x

[Mike or Penny Novack]

On 5/23/2018 9:17 AM, Nathanial Jones wrote:

The "It can't be fixed," attitude is just wrong, since there is a
conceptually simple fix.

It may take a while to code, but why not just put a check box or option
group into the tax rate setup that defines whether it is a "per item" or
"total" rate.
I did NOT mean "uncodeable" for some specific jurisdiction/situation. I 
meant a GENERAL fix (work for all the possible rules). Yes a "switch" 
between two rules would of course be possible. Keep in mind that users 
who only have to deal with the rules of one jurisdiction are going to 
see the problem as much simpler than those who have to deal with many.


But I think time for an "aside" on the term "bug". A "bug" is an error 
in a program where the program is not doing what it should according to 
the formal definition of what it should do. A bug is NOT "program does 
not do what the user expected it to do" where there was no formal 
decision on the matter. So in this specific case, would be a bug if/f 
the program was supposed to figure the tax on the total but was doing it 
per item or was doing it on the total when supposed to do it per item.


It is a FEATURE request "provide a switch" to allow both methods. It is 
the lack of USER commitment to the development process for the phase 
"define what the program is supposed to do" that is the reason why I am 
not helping with development. In my working days (design/implementation 
of financial systems software) that initial "formal definition" phase 
was >20% of the total development time charges << and then more user 
commitment for the testing phase >>


Michael D Novack

PS: Take something as simple as a "meals tax" on a restaurant bill. Here 
we have a state one and MAY have a local one. These are almost always on 
the total pre-tax amount but there is the rule question "apply 
separately or one on top of the other? and if one on top of the other, 
which first?" So more switches. Similarly with things for which there is 
Federal excise and state sales tax. Rules about whether figure 
separately or one on top of the other. LOTS of switches. POS systems are 
usually doing these calculations for the accounting system, not the 
accounting system itself. That isolates the problems. I don't know if 
anybody has tried to come up with a universal POS << have 
provisions/tables/switches to deal with the rules of every jurisdiction 
on the planet >>

___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Geert Janssens]

Op woensdag 23 mei 2018 15:17:52 CEST schreef Nathanial Jones:
> The "It can't be fixed," attitude is just wrong, since there is a
> conceptually simple fix.
> 
> It may take a while to code, but why not just put a check box or option
> group into the tax rate setup that defines whether it is a "per item" or
> "total" rate.
> 

I love the "just" in there...

For the record I agree it can be fixed. Otherwise I would have closed the old 
bugs a long time ago. But until now nobody stepped up to provide an adequate 
patch.

Regards,

Geert


___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Nathanial Jones]

The "It can't be fixed," attitude is just wrong, since there is a
conceptually simple fix.

It may take a while to code, but why not just put a check box or option
group into the tax rate setup that defines whether it is a "per item" or
"total" rate.

On Wed, May 23, 2018 at 8:46 AM Matthew Pounsett  wrote:

> Thanks for all your replies.  If just the people who have replied in the
> last 12 hours is any indication, then a lot of people are "living with" a
> fairly annoying bug.
>
> In my case, this is on an invoice I'm generating, not a bill, so I don't
> feel like I can mess with the data too much.  Fortunately (or not) I'm not
> using GnuCash to actually generate the invoice that goes to the customer,
> since I find them poorly implemented as well... so the invoice is just for
> internal records.  But that means it needs to match what I actually send
> the customer fairly accurately, or things get "off".
>
> My workaround is to add -$0.01 item that is non-taxable but is posted to my
> tax table's liability account.
> ___
> gnucash-user mailing list
> gnucash-user@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.
>
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Matthew Pounsett]

Thanks for all your replies.  If just the people who have replied in the
last 12 hours is any indication, then a lot of people are "living with" a
fairly annoying bug.

In my case, this is on an invoice I'm generating, not a bill, so I don't
feel like I can mess with the data too much.  Fortunately (or not) I'm not
using GnuCash to actually generate the invoice that goes to the customer,
since I find them poorly implemented as well... so the invoice is just for
internal records.  But that means it needs to match what I actually send
the customer fairly accurately, or things get "off".

My workaround is to add -$0.01 item that is non-taxable but is posted to my
tax table's liability account.
___
gnucash-user mailing list
gnucash-user@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Mike or Penny Novack]

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@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@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Deva -]

For rounding adjustments like these, I typically use the discount columns.

In your example, you can do the following to get the final total right -

Discount Type = “$"
Discount How = “=“
Discount = 0.01

The Tax Invoice report allows you to change some column headers, so I just 
change the discount column names to “Adjustment”. It would be nice to be able 
to hide those columns through option settings, so no one needs to see these 
adjustments…

On some occasions, you may end up with a final total that is less than the 
amount received (in your case, say it shows 418.09). In that case, you would 
simply make the discount as -0.01.

Not a pretty solution, but I get by with these adjustments.

Cheers.

On 23-May-2018, at 4:47 PM, 
<gnucash-user-requ...@gnucash.org<mailto:gnucash-user-requ...@gnucash.org>> 
<gnucash-user-requ...@gnucash.org<mailto:gnucash-user-requ...@gnucash.org>> 
wrote:

Date: Tue, 22 May 2018 21:11:26 -0400
From: Matthew Pounsett <m...@conundrum.com<mailto:m...@conundrum.com>>
To: Gnucash Users <gnucash-user@gnucash.org<mailto:gnucash-user@gnucash.org>>
Subject: [GNC] Invoice tax rouding issue in 2.x
Message-ID:
<caaiteh-dky0gqufsyy5by9_drstef1yt77oiy_r3cwqw3iu...@mail.gmail.com<mailto:caaiteh-dky0gqufsyy5by9_drstef1yt77oiy_r3cwqw3iu...@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

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@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.

Re: [GNC] Invoice tax rouding issue in 2.x

[Geert Janssens]

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=504954
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@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.

[GNC] Invoice tax rouding issue in 2.x

[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.
___
gnucash-user mailing list
gnucash-user@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.