Interchange allows taxing in a number of ways.

Simple "salestax.asc" Method

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]).

"Fly Tax" Method

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]

"Salestax Multi" or "VAT Taxing" Method

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:COUNTRY_CODE is found, [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 = D%, default = D% 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 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.)

"Levies" or "Multiple Tax" Method

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.

DocBook! Interchange!