I am working to update our xTuple system to produce a complete and accurate EU VAT return.
I currently calculate tax using a separate set of queries that read all the SO and PO tables (and similar) to calculate the various tax figures. These numbers are placed in spreadsheet where errors (incorrect/missing tax zones and similar can be easily fixed).
The trouble with the current xTuple system is that:
- EVERY setting must be perfect for the tax due and total sales/purchases to be calculated
- It is not possible to 'fix' a posted transaction that went through with the wrong tax setting
- Any changes to the tax code/rules must be made in the tax setup on the exact day is happens, and again, there is no way to fix mistakes if you are wrong!
With my own system, I can tweak and rerun a tax report if there is an issue, but with xTuple there is no second chance (and as I noted, no way to fix mistakes)
1) Why does xTuple use the 'separate tax ledger' system, rather than calculating tax directly from the main tables (which would allow greater flexibility, improve handling of mistakes and avoid duplication of stored data)
2) I think xTuple needs some tidying up of the tax setup on vendors/items/customers/vouchers.
- All vendors and customers should require a tax zone (and not save until it is set)
- All vouchers should require a tax zone and tax type
- Items should at least warn if no tax type is set
SOME of these checks are made currently, but not all. It is easy for an inattentive user to miss a selection, which means tax will be miss reported. (For example: Tax history report on sales within a 'zone'. Even if the SO has the tax zone set, the sale will not register on the tax report unless the sold item ALSO has an appropriate tax type set, which may have been missed).