When designing a stock management database system for sales and purchases what would be the best way to store the various taxes and other such amounts?
A few of the fields that could be saved are:
- Unit price excluding tax
- Unit price including tax
- Tax per item
- Total excluding tax (rounded to 2 decimals)
- Total including tax (rounded to 2 decimals)
- Total tax (rounded to 2 decimals)
- Tax Percentage
- Fk link to the Tax % (and not store the tax amount)
Currently the most reasonable solution so far is storing down (roughly) item, quantity, total excluding tax (rounded), and the total tax (rounded).
Is there a better way of storing these details for a generic system?
Given the system needs to be robust, what should be done if there were multiple tax values which might need to be separated (e.g. state and city)? In this case a separate table would be in order, but would it be considered excessive to just have a rowID and some taxID mapping to a totalTax column?
To clarify: Asking how to store the data about individual transactions and that side; not so much the details about the tax specific rates.
The problem with approach is if the tax changes, VAT (sales tax) in the UK has changed twice in the last 12 months.
When I worked in ECommerce websites we had a table
Tax_Ratewhich held the different tax rates a shop would deal with eg.and then your stock table fields may have
your invoice_detail row table will be
your invoice table will be
Where fk_denotes a foreign key. Note that OrderId will not be unique in your invoice row table.
EDITS: Head’s all over the place today.
You need to denormalize the invoice row total and the tax rate total because you don’t want future changes in an item price or tax rate to affect the historical invoices.