[GNC] Invoice tax rouding issue in 2.x

Mike or Penny Novack stepbystepfarm at dialup4less.com
Wed May 23 10:29:53 EDT 2018


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


More information about the gnucash-user mailing list