From http://www.openvpms.org/project/add-support-invoice-level-taxation
OpenVPMS currently:
calculates tax per-line; the invoice tax is the sum of the line item tax
assumes product prices are tax-inclusive
This is not sufficient for US-style taxation, where the tax is based on the total invoice amount, and prices are tax-exclusive.
To support other jurisdictions, the following changes are required:
Currently, OpenVPMS supports one taxation rule. This is effectively PER_LINE below.
This needs to be expanded to:
PER_LINE
this is used for Australian/New Zealand style taxation
invoice tax totals are summed from the invoice item tax totals
invoice items amounts are tax-inc
prices are tax-inc
TOTAL
this is used for US-style taxation
tax is calculated per-line but not rounded until the total is determined.
invoice items amounts are tax-ex
invoice amounts are tax-inc. For reporting, the invoice tax total needs to be subtracted
prices are tax-ex
invoice item tax amounts are rounded, and informative only. Summing them will not necessarily add up to the invoice tax total due to rounding.
The Practice archetype will be updated to specify the tax rule
The node will be named "taxRule", and default to PER_LINE
Archetypes calculating tax will be updated to specify the tax rule
the node will be named "taxRule", and default to the Practice taxRule
the node will be hidden and read-only
This applies to the following archetypes:
Customer Invoice
Counter Sale
Customer Credit
Estimate
Order
Delivery
Supplier Invoice
Supplier Credit
The tax-inclusive or tax-exclusive prices will be displayed based on the tax rule.
If the tax rule is:
PER_LINE - inc-tax prices will be displayed, and ex-tax prices hidden
TOTAL - inc-tax prices will be hidden, and ex-tax prices will be displayed
If the tax rule is:
PER_LINE
Ex-tax prices will be:
hidden
initially set to the product ex-tax price
Inc-tax prices will be:
editable. If an inc-tax price changes, the ex-tax price will be derived from it
initially calculated from the ex-tax price
TOTAL
Ex-tax prices will be:
editable
initially set to the product ex-tax price
Inc-tax prices will be:
hidden
derived from the ex-tax price
Invoices, Counter Sale and Credit items will be updated to include the following fields:
Fixed Price (Ex-Tax)
Unit Price (Ex-Tax)
Tax Rule
Estimates will be updated to include the following fields:
Fixed Price (Ex-Tax)
Low Unit Price (Ex-Tax)
High Unit Price (Ex-Tax)
Tax Rule
Orders and deliveries already store prices ex-tax. They will be updated to include the following fields:
Unit Price (Ex-Tax) - this will duplicate the existing Unit Price
Tax Rule
Supplier invoices and credits already store unit prices tax-exclusive. They will be updated to include the following fields:
Unit Price (Ex-Tax) - this will duplicate the existing Unit Price
Tax Rule
In order to support practices that change their tax rule, reports will need to support both PER_LINE and TOTAL tax rules.
This affects:
Customer Invoice
Counter Sale
Customer Credit
Estimate
Order
Delivery
Supplier Invoice
Supplier Credit
This project will require a database schema change to add four new columns to the financial_acts table:
fixed_amount_ex_tax - the fixed price, tax exclusive
unit_amount_ex_tax - the unit price, tax exclusive
total_ex_tax - the total, tax exclusive
tax_rule - one of PER_LINE or TOTAL
The existing columns, fixed_amount and unit_amount will be used to store the tax inclusive fixed and unit prices whilst the total column will store the tax inclusive total.
Existing databases must have the schema changes applied, and the new tax-exclusive fixed/unit price and total columns must be derived from existing data.
Key to the migration is the requirement that existing totals and tax totals must not change.
For existing Customer Invoice, Counter Sale, Customer Credit, Estimate, Order, Delivery, Supplier Invoice and Supplier Credit acts, the tax rule will be set to PER_LINE.
Tax exclusive fixed and unit prices will be derived:
if the tax total is 0:
the exclusive fixed and unit prices are the same as the tax inc prices
the tax exclusive total is 0
if the tax total is non-zero:
the fixed and unit prices will be derived from the product tax rate i.e.
the ex-tax total is:
NOTE: due to rounding, there may be a difference calculating the tax amount using the tax-ex prices.
Estimate tax exclusive prices will be derived using:
Order, Delivery, Supplier Invoice and Supplier Credits tax exclusive prices and tax ex totals will be derived using:
This project will not include the following:
changes to ESCI to support TOTAL tax rules
To date, ESCI has only been implemented by Australian suppliers. Should it be implemented in other jurisdictions, then it will need to incorporate the other tax rules.
region based taxes
In many jurisdictions, the customer's address determines the sales taxes that apply. That is out of the scope of this project.
Country | Currency | Tax Calculation | Rounding mode |
---|---|---|---|
Australia | AUD | PER_LINE | HALF_UP |
US | USD | TOTAL | HALF_EVEN |
UK | GBP | PER_LINE | HALF_UP |
Practices currently using the PER_LINE tax rule can change to TOTAL tax rules.
Charges, Estimates, Orders and Deliveries generated prior to migration will continue to use the PER_LINE tax rule. When printed, these will use the report with the PER_LINE style.
See Also
See https://developers.google.com/checkout/developer/Google_Checkout_XML_API... for a discussion of Google Checkout's approach
Note that Google Checkout specifies a PER_ITEM calculation for the UK, but it appears that PER_LINE is sufficient.
Software Platform
Tony and I have discussed this at length, and I think the consensus is that we need to support:
Data entry inc and ex tax, configured per practice
If ex tax is configured then:
product browser shows ex tax prices
for invoices, fixed and unit prices and totals and discounts are entered ex tax
Zero or more tax rates per invoice item
in the US and other jurisdictions, products may have different sales tax.
in Canada, a product may carry federal and province taxes
tax rates may change over time
Including a link to the tax rates included in the invoice item should meet reporting requirements in the different jurisdictions
The tax rates would need to be configurable per practice, product type, product, and customer, as is the case now
Invoice total or item based rounding
Line based rounding would be used to support the status quo
Total based rounding would be used to round tax calculations based on the total invoice, rather than per item. This would be used in the US
Input tax i.e ability to stipulate whether a product was purchased with any tax component and to utilise this information during orders, deliveries, supplier invoicing etc
Great news. This sounds to me like it would work exactly as we need it to here.
I have downgraded this from critical to major - critical issues should probably be reserved for major bug blockers or functional defects that require a fast patch.
updated to reflect project specification