Tax based on ZIP code issue

[FredW]

Hello folks,

I wanted to share something we found that may be considered a ShopSite anomaly. It has to do with how sales tax is determined if you use ZIP code to do so.

We charge sales tax for orders shipped to a ZIP code in PA. The other day, we received an order where there was no sales tax charged and it was shipped to ZIP code in PA.

After a fair amount of testing I found out how this order was placed and uncovered more anomalies in trying to correct or overcome it.

The ZIP code 18901 is in PA. If the customer enters just the five digits, the order gets charged PA sales tax. If one enters "18901 5253", the order gets processed without charging sales tax. I think ShopSite checks the full 10 digits against one of the masks of "18???" in the default zip codes for PA and it determined it did not match and charged the default sales tax of 0%. In my earlier tests to reproduce the problem, I found any extra digit after the first five ZIP codes digits, (for example: "189012") gets seen as no sales tax. However, the digits of "189012" gets flagged as a invalid ZIP code during checkout. But the digits "18901 5253" passes the ZIP validity tests and fails the sales tax test of a valid ZIP code in PA.

My software career tells me that this is a bug, but I'll defer to the ShopSite developers to determine that.

I then set about to see if there was a configuration option that we failed to set up correctly or one I could use that would circumvent this 'issue/bug'. I noticed that the ShopSite > Commerce Setup > Order System has a default length for the ZIP code to be 10 characters. "Haha!" I said to myself. I'll just limit it to five characters. No! Make it six characters, for we have lots of Canadian customers.

So I did.

When I reran the test of "18901 5253" through the shopping cart, it made the ZIP code entry box smaller, showing eight characters, but still allowed the full 10 characters to be entered, passing the valid ZIP code test for PA and did not charge sales tax.

So, now, after banging my head against the configuration wall all morning, I ask for ShopSite help. How can we stop this from happening or is it a bug your developers can fix in a short time?

I will be pleased to provide more data, give you pointers to our demo test environment, or help in any way I can. I'm also open to having my attitude adjusted if you can point out some stupid error I have made.

I also find it interesting that we have been running the ShopSite shopping cart since June of 2012 and this is the first time we saw this error.

Thanks in advance.
FredW

[FredW]

Sorry, forgot to say, the tests were ran using ShopSite® Pro 12 sp1 r2,

Our production where the problem first happened is ShopSite® Pro 12 sp1 r2 also.

Thanks
FredW

[Jim]

The "default length" value on the address fields is just for how big the box displays it does not limit the number of characters that can be entered in the box.

It would be possible to add some custom javascript the checks the country and zipcode entered. Then if the number of characters entered doesn't match the normal syntax for that country (5 for US, 7 for Canada) to put up a message alerting the shopper to the proper format for how you have the zip/postal code pattern configured.

[FredW]

The "default length" value on the address fields is just for how big the box displays it does not limit the number of characters that can be entered in the box.

It would be possible to add some custom javascript the checks the country and zipcode entered. Then if the number of characters entered doesn't match the normal syntax for that country (5 for US, 7 for Canada) to put up a message alerting the shopper to the proper format for how you have the zip/postal code pattern configured.

Thanks Jim for the reply,

I agree some custom Javascript could be entered to check the ZIP code, but I'm not sure where one would add it. There is a place on the Shopping cart for Javascript check out code, but the variables for the ship to ZIP code say:
" ss_shippostalcode
The shipping zip/postal code. Only on the Thank You screen."

What does the 'Only on the Thank You Screen" mean?

Also, what is ShopSite's position on the use of the 5 digit ZIP plus the 4 digit extension? Don't you think if a customer enters the full 5+4 ZIP that is for a state where Sales tax is defined, the order should be charged sales tax?

Thanks for your time and help,
FredW

[Jim]

Since the final shopper zipcode isn't know until the order is completed the ss_shippostalcode is only available on the thankyou screen. But that doesn't mean that you can access the data field on the shopping cart directly. Here is a section of code that has the input field for the zip.

Code: Select all

input name="zip_code" value="" size="10" maxlength="20" onchange="zip_changed();...

So you could access the zip_code value field similar to how it is done in other the javascript already in the cart.

Code: Select all

function promptCallback(val) {
      if(val) { document.order.zip_code.value = val; zip_changed();
      }
   }

of course you would have to create your own function but that should give you an idea of how it would be accessed. Lexiconn, one of our partners, has some good sample code for doing different things in the cart. You might check their forum and see if they have anything specific to zip codes. Here is a link to where they are limiting checkout based on certain shipping options. http://support.lexiconn.com/news/forums/topic/restricting-shipping-options-in-shopsite-using-javascript/ Something similar could be done for zip code values.

You can add formatting for various types of zipcode combinations for each state. We provide a basic format with a couple of numbers followed by question marks. For example Alabama has
350??,351??,352??,35???,36??? You could extend those to include 9 or ten digits by adding extra ? characters. The problem is how do you force them to enter 5 digits and some separator and then 4 digits instead of just all 9 digits in a row. and what separator are you going to force a + or a space etc. Whatever the shopper enters must match the format that you have specified so if they enter 99999+9999 you must have a 99???????? but if they leave out the + you would have to have 99???????.
So it is possible to extend the zipcode checking to more digits but it will take some work on your part. If you have a case where people are getting by without any tax because the value they enter doesn't match one of the states zip syntax you could always put your states tax rate in the "No Match" tax zone rate. Then any zip that doesn't find a match will use that value for the tax rate of the order.

Note that ShopSite is integrated with AvaTax and they have much more robust validation. So you might want to check out their offering.