pbaldy is quite correct about Louisiana and its Byzantine tax system. We've tried for YEARS to get it fixed but the politicians don't want to do so. It is beyond the scope of this part of the forum to explain why.
The way I look at it, you would have to consider this aspect of the problem: First, taxes change from location to location. Second, they change from one date to another. Third, the actual NUMBER of taxes changes by location and time. To do your customers proper service, you must accumulate EACH TAX separately so that at the end of the month they can file a report showing just how much is paid in each category of tax. By the way, pbaldy, I think you are incorrect. Certain products have federal tariffs that count as a tax in Louisiana. So we can have four tax sources.
Anyway, to build this correctly, you would need a tax table that includes at least the following fields (I think...)
tblTaxRates
ProdCode, showing which type of product is liable to this kind of tax
WaiverCode, showing which type of waiver applies to this product
TaxCode, showing whether this is Fed, State, City, Parish/County, etc.
TaxRate, how much it costs
TaxStart, date at which this tax came into effect
TaxEnd, date at which this tax was superseded or became expired
The ProdCode would have to be part of your inventory of sell-able items. For instance, Milk is not taxed but alcohol is taxed heavily.
The Waiver code occurs when you have special cases - for instance, when a senior citizen purchases certain items, a specific tax is waived or reduced. So this depends on the CUSTOMER as well as the product.
The code types define to whom the tax is owed. This is where YOUR customer will love you if you get it right because... you can produce a report showing the amount of taxes owed each entity. It will also enable you to produce break-out charts of how to distribute the amount of money collected.
The date codes are important for two reasons. First, since taxes change over time, you need to keep history records for tax rates as well as for prices, sales, etc. Second, technically you need to have a date as part of the tax rate table since it is not properly normalized otherwise. See, a record has to have all the keys it needs to be properly identified, and in this model, you have keys of product type, discount/waiver type, tax entity, and date range. The only non-key value in that whole bunch is the tax rate.
