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