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