Formulas in transactions

Mike or Penny Novack stepbystepfarm at mtdata.com
Wed Mar 26 07:17:44 EDT 2008


I hate to keep harping on this but NOT so simple.

>  
>
>>>>For example to add 8.5% tax on a $23.85 item.
>>>>
>>>>1.085*23.85
>>>>
>>>>The difference in gnucash is that only the result is stored not the actual formula.
>>>>        
>>>>
In what jurisdiction, and what is the rule/law of that jurisdiction with 
respect to that tax? Maybe I better give a concrete example? Take the 
state in which I live which applies a 5% sales tax to many (most) things 
BUT the calculation of that tax is NOT "multiply and round off". The 
rule is that the state gets any fractional cents. In other words, the 
tax legally due is an amount payable in  existing currency units that is 
at  least 5% of the amount.

Of course that could be programmed (if amt * rate - truncated to 
hundredths > 0 then truncated to hundredths + .01 else truncated) but 
that's not the point. The point is that this is the rule for THIS 
jurisdiction. Perhaps the rule for another jurisdiction specifies 
rounding and perhaps the rule for yet another jurisdiction specifies a 
different rule for rounding, maybe even a "tax table". The question 
people are asking is whether there could be ONE provision made at the 
application level and what I am saying is that won't help much unless by 
chance the one the developers picked matched the rule for YOUR jurisdiction.

Custom coding. All the developers could do is to isolate "tax 
computation" as a function say of three parameters (amt, rate, method) 
with the initial behavior of say tax(amt, .05, round.01) being to 
multiply amt by rate and round off by normal mathematical rules to 
hundredths). Then as need arises other "methods" can be coded as user 
demand and their pocketbooks (to hire the work done as a custom mod) or 
their abilities to convince somebody to donate their time allow.

Michael


More information about the gnucash-user mailing list