| tax | ||
|---|---|---|
 |
 |
|
| tax | ||
|---|---|---|
| |
|
|
Interchange allows taxing in a number of ways.
Sales tax calculation in this simple scheme is performed on a straight
percentage basis,
with certain items allowed to be tax-exempt. Simply initialize the
SalesTax directive to the name of lookup fields. Those lookup fields
are the ones that are available on the final order form and indicate
geographical locality.
SalesTax configuration directive is
set to form fields whose values will be used as keys to look up
the tax rate in products/salestax.asc, based on localities.
salestax is a fixed-format database, and consists
of identifiers that match localities defined using SalesTax.
Locality names are always forced to UPPER CASE, and are usually identified by zip or state codes:
SalesTax zip,state
Each line of the mentioned products/salestax.asc
file should contain a code (again, usually 5-digit zip or 2-letter state
ID), followed by a TAB character and a desired percentage.
default 0.0 45056 .0525 61821 .0725 61801 .075 IL .0625 OH .0525 VAT .15 WA .08
Based on user information given on the order form (and given our
sample SalesTax setting), Interchange will attempt a tax lookup by
zip and state (in that order), and apply the percentage found to the
subtotal of the order.
The subtotal will include item prices, taxes and shipping costs (if
TaxShipping was set up).
It will add the percentage, then make that available with the [salestax]
tag for display on the order form.
If no match is found in CATROOT/products/salestax.asc,
the entry DEFAULT (case-insensitive)
will be applied — which is usually zero.
If some items are not taxable, then you must set up a field in your
database which indicates that. Announce this field name by using the
NonTaxableField directive. If the specified field for that item
evaluates to a true value, sales tax will not be applied to the item.
If you want to set a fixed tax for all orders, as might occur for VAT
in some countries, then SalesTax set to the zip or state codes is
not optimal for the purpose of sales tax calculation. The solution is to
introduce an arbitrary variable that, unlike
zip or
state, does not change from user to user.
Then, you would set that variable in user session to point to a fixed entry
in the
CATROOT/products/salestax.asc file.
Exactly how you're going to set a session variable is not important;
you could use the ValuesDefault directive (
ValuesDefault tax_code VAT), a hidden form variable
(<input type="hidden" name="tax_code" value="VAT" />),
or a simple Perl code block
([perl] $Values->{tax_code} = 'VAT'; return [/perl]).
This is one of the simpler taxing methods as well. A series of Interchange
Variable settings are read to develop a salestax rate for one or more
geographical localities.
With this method, you implement the simple SalesTax method explained above,
but only put one entry in
CATROOT/products/salestax.asc. Then
, TAXRATE
and TAXSHIPPING catalog variables would be used to build
the tax rates.
The single entry in CATROOT/products/salestax.asc
should be default with a value of [fly-tax]:
DEFAULT [fly-tax]
With this method, country and state databases are used to develop complex VAT or salestax rate calculations, based on country and state, possibly with different rates based on product type.
The SalesTax directive must be set to multi, and
then the type of tax to apply will be read from the
country database. Since this is a standard database, to
display taxing for say, Croatia (code HR), you'd
simply call:
[data table=country col=tax key=HR]
We've mentioned some hard-coded values above (the country table, column names
etc.), but this is all configurable using
MV_COUNTRY_TABLE,
MV_COUNTRY_FIELD,
MV_COUNTRY_TAX_FIELD,
MV_STATE_TABLE,
,
MV_STATE_TAX_FIELD,
MV_TAX_TYPE_FIELD and
MV_TAX_CATEGORY_FIELD variables.
So, with this multi approach, Interchange first performs a lookup
in the country database. The default key for the lookup
is, of course, [value country] (value of the
country form variable), and the column retrieved is
tax. At that point, the following rules
are applied:
If no string is found, tax returns 0
If string simple:
is found, COUNTRY_CODE[fly-tax] is used for the appropriate country.
If string state is found, then another lookup
in the country database is done; it's something along
the lines of
select tax from state where country = '[value country]' and state = '[value state]'
The value is then applied as explained in the following steps
If a pure (integer or decimal) number is found (such as
0.05), the rate is applied directly
If a percentage is found, such as 22.2%, the rate is,
obviously, applied as a percentage
If a string category = is found, the
tax_category field in the
products database is used to determine tax rate.
(The default option is there to be applied if the
tax_category for a product is zero
or unspecified.
The special field D%, default = D%mv_shipping is used to set tax rate
for shipping, if shipping is indeed taxed. If shipping is taxed only when
taxable items are in the cart, then use
mv_shipping_when_taxable instead.)
Using Levies and Levy structure, any or all of
the above methods are used in combination to implement the a
taxing scheme of truly arbitrary complexity.
To prevent tax calculation routines from ever applying a negative
tax amount, see pragma no_negative_tax.
| |
|
|
| tarball |
|
time |