Hi Dragan,

- each item sold has to have all the rates and indicators copied into its record for historical reasons; if later you need to recalculate or revert anything, you can't rely on the lookups anymore, as the values and conditions there have probably changed already

Yep - got that covered, storing the total tax in the invoice header, line item tax in the details. If I can't recalc it after the fact - well, sue me :>)

- the item record has to have the date on it, so if there's some change somewhere in the rules, you can apply them starting with the date the rule is effective

On the line item itself? Guess I don't quite understand this point.

- round each value before you add; don't calculate the total tax rate and multiply by it, calculate the amout of each tax then round them to cents and add them. That's the way the accountants calculate, and if they ever want to check, they'll check the adding and not the total roundoff error. They don't care about the roundoff, they want it added precisely to the cent.

Yep Yep. I did figure that one out a while ago :>)

As to table-driven, you can have a memo with the expression in your rules table, and eval() the expression as needed, so your "saleitem >$110" can be such an expression; you can fire the rules one by one until you get the rule with no expression or an expression which returns .t.

This might be useful. I'll take a look.

Also, why not

totaltaxrate=iif(state_exempt, 0, staterate)+iif(county_exempt,0,countyrate)+...

That's the one which will surely fire and you don't have to have all the combinations in separate case statements.

Now this might be useful also! I really want to get rid of the monster CASE thing. Thanks for a couple of nice tips.