>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 point is that you never have to recalculate - all the calculated values (rates, amounts) are stored in the record. You just add the results. I've spent a few evenings with my customer's accountant because the tax totalled from line items didn't exactly equal the tax totalled from the parent records (it was off by about $0.12 on a $2000 total) until I introduced this rule.

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

I've had a case, but can't remember exactly, so let's make it hypothetical: the $110 rule changes to $135 as of August 14th. What do you do? What do you do when they ask you later for totals on this particular tax case before and after the change? You go by the date on the line item. You can actually store it in the parent record - I was storing this date in the line item because of the incredible speed of the damn 286es in those times (boy, is it more than 10 years already?). It'd also be useful to store the rule key in the line record (for reports on specific taxes, if needed, and for debugging as well), and to have the "rule is effective start-end" dates in the rules table. That way you can, someday, write a rules editor and hand the hassle to your customers and simply forget about taxes.

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

Hey, what's the point in experience if you don't share it?