>John,
>
>The relation of the customer to the tax rate is simply that very often the customer's location determines which tax rate applies. That is in many areas there are local taxes which apply to certain municipalities and if the customer live sin that location then they pay that tax rate. If the customer is lcoated elsewhere then the tax rate is different.
>
>Now you are perfectly correct in thinking that, "well then we need a tax rate table for the locations and not have the tax rate in the customer table". However I was trying to simplify for the sake of discussion of the point that the tax rate for the invoice is NOT the same thing as the current tax rate for a customer or location.

Consider building a rate table that the user could maintain. Like a rate keyed to a rate code. Some items could be associated with specific codes. Some customers may be associated with specific codes. A zero rate code for a code description like "Non Profit" could be echoed to the invoice and the code could be forwarded to the sales transaction. Everytime a code rate is needed, it may be better to read it from the rate table. There may also be circumstances where operator may need to enter a rate or overide a default rate, but those kinds of changes would update the rate table, but they may write something other than the rate table default to the transacxtion records. Things like taxes are paid off the total sales, regardless of what the software reports them to be. The user would be liable for the tax due. Any method to assure whats due is being charged would work.