Tutorial: Catching shopper address alternatives in the calculation framework
The calculation framework uses a shopper's address to provide order calculations for tax and shipping costs. If a shopper does not provide the correct city or state or country as input text, you can use the default implementation to catch any address differences.
Before you begin
- Download the Jurs Mapping Text example which contains the alternative address entries for the jurisdiction mapping.
- Download the zip file containing all the code related to this tutorial.
About this task
In the default implementation of WebSphere Commerce, the checkout billing and shipping pages prompt the shopper for input, using text entry fields. The instances where the state/province, city, or country is not input as expected result in spurious order calculations for tax and shipping costs. To compensate for faulty shopper input, we can load the jurisdiction mapping to allow for those alternative address inputs.
There can be multiple mapped jurisdiction representations to the same calculation rule. Therefore, the calculation rules can be independently defined apart from the multiple jurisdiction references. The alternative address inputs can then be defined for a single rule by mapping to several jurisdiction references.
The following section explains how to set up a Canadian tax implementation. It also includes excerpts that you can use to provide alternative jurisdiction mapping to prepare for calculating based on shopping input.
- Open the tax.xml file and add extra alternative jurisdiction mappings
- Run idresgen utility on the tax.xml file
- Run Massload on the resolved tax.xml file
- Test some data using the above tax matrix