[GNC] Invoice tax rounding issue in 2.x

Adrien Monteleone adrien.monteleone at lusfiber.net
Wed May 23 13:13:53 EDT 2018


That PS highlights I think the biggest challenge with the Business Features. As long as they are a means to enter business transactions, no major issue arises. But start trying to use them (and GnuCash in general) as a substitute for a POS system...

Regards,
Adrien

> On May 23, 2018, at 9:29 AM, Mike or Penny Novack <stepbystepfarm at dialup4less.com> wrote:
> 
> 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 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.
> 




More information about the gnucash-user mailing list