>>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.
>
>
>Terry,
>
>You raise a very good point, however, it does not alter the conversation going on. In your scenario does the taxratecode being in both the customer table and in the invoice table represent duplication of data storage?
No the tax code is only in the taxcode table. Points to the customer (has a tax code key) points to a tax rate (ergo reads) in the tax table. Some rates, like late penalties, or price breaks would be in the customer table since they may be customer specific. List link as much as possible.