AbleCommerce Shopping Cart Software

We have had two calls in the past two days from customers concerned that we are charging tax for orders outside of our state. I stepped through an order to a 'new' customer, and found that the system does add tax at the checkout if no address is entered. This means that all new customers with taxable items in their cart will suddenly see a jump in the basket total when they enter the checkout. For those that then enter their address it disappears, but there are obviously those that see this and just abandon their cart. Tax simply should not show until a shipping address is entered, and then based on the address it should add tax if the criteria is met. It should not default to adding tax.

How can we go about correcting this? Obviously this is something that we want fixed quickly, as sales are surely being lost. And, we cannot be the only one experiencing this- we may just be the first to have had it brought to our attention.

Which version are you running? (See help -> about ablecommerce in the merchant menu.)

We are running 7.0.2

I have the same issue. I have invoice summary set to "show as separate line items". With that setting the errant tax appears in View Cart way before the user even gets to checkout. I thought there was a different post about this somewhere discussing how to handle it but I can't find it now.

My thought is to add a SQL trigger that just deletes the tax line item if the basket item doesn't have any shipment assigned to it or if the shipment's destination address isn't specified. Logan, do you think that would work?

Thanks.

I believe this issue is a known bug: http://bugs.ablecommerce.com/show_bug.cgi?id=8141. That bug report refers to this work-around: viewtopic.php?f=42&t=10958&p=46859&hilit=taxes#p46859 but there's a comment that there was a bug in the posted patch:

Mazhar's patch has at least one minor bug... it appears possible in a
multi-shipment scenario for the isTaxVisible variable to have the wrong value.

• Has the final patch ever been posted?
• Does the final patch apply to the separate line item issue I see or just to summary display?
• Is that final patch available for VERSION: 7.0.2 BUILD: 11659?
• Was the final patch included in 7.0.3?

Thanks.

ZLA wrote:I have the same issue. I have invoice summary set to "show as separate line items". With that setting the errant tax appears in View Cart way before the user even gets to checkout. I thought there was a different post about this somewhere discussing how to handle it but I can't find it now.

My thought is to add a SQL trigger that just deletes the tax line item if the basket item doesn't have any shipment assigned to it or if the shipment's destination address isn't specified. Logan, do you think that would work?

Thanks.

You could probably work up some piece of code that deleted all existing tax items if the user did not have an address. The trick is you have to make it call after the Basket.Recalculate() command. Sure, it would work if you called this in the correct places.

ZLA wrote:

• Has the final patch ever been posted?
• Does the final patch apply to the separate line item issue I see or just to summary display?

We were supposed to publish the 7.0.2 service pack. I am not sure of the status and I will check. In the meantime, I have attached the final version of the patch to the bug you listed above. However it only addresses the summary issue. It does not work with line item display.

The issues with tax addresses was properly solved in 7.0.3 as we added some new options for tax display. You can now specify whether or not taxes are calculated for anonymous users. This is for international purposes, where you can opt to display taxes inclusive of VAT to all users until you determine that they should not have VAT included.

Logan_AbleCommerce wrote: The issues with tax addresses was properly solved in 7.0.3 as we added some new options for tax display. You can now specify whether or not taxes are calculated for anonymous users. This is for international purposes, where you can opt to display taxes inclusive of VAT to all users until you determine that they should not have VAT included.

• Is the ability to specify whether or not taxes are calculated for anonymous users separate from the international purposes?
• Am I correct in assuming that if a customer chooses to remain anonymous and not create a user account, that taxes will still be calculated during checkout?

ZLA wrote:

Logan_AbleCommerce wrote: The issues with tax addresses was properly solved in 7.0.3 as we added some new options for tax display. You can now specify whether or not taxes are calculated for anonymous users. This is for international purposes, where you can opt to display taxes inclusive of VAT to all users until you determine that they should not have VAT included.

• Is the ability to specify whether or not taxes are calculated for anonymous users separate from the international purposes?
• Am I correct in assuming that if a customer chooses to remain anonymous and not create a user account, that taxes will still be calculated during checkout?

Let me rephrase. We enable the ability to include taxes for unregistered (anonymous) customers for international merchants that need to show prices inclusive of VAT by default. Any merchant could enable or disable the feature, whatever best fits what they like to see. My anecdotal observation is US based merchants and customers would not want to enable this option.

Anonymous isn't the best term to use but it's easier to write than "users with invalid addresses". Once a user progresses to the checkout and fills in the billing (and possibly shipping) address, they are no longer anonymous for purposes of tax calculation. We don't care about whether they create a user account, we only care about whether a valid address is available to determine tax liability. So to summarize, yes your users will still have taxes calculated.

Thanks Logan.

At this time, implementing an upgrade to fix this bug is not feasible. Fortunately, we don't use integrated shipping. So we'll just change the default warehouse address to Fiji or something like that and hardcode any address references in the email templates.

Now I'm completely stumped.

I wrote a trigger that removes the tax line item from ac_Baskets if the state (province) and country are null. When I add a taxable item to the cart, the tax item is deleted from ac_Baskets. However, the tax line still shows up when viewing the cart!

Does AC7 store tax line items in memory? If not, can someone suggest how this can happen?

It could be one of two things. The first would be if the in-memory collection of objects (order line items) were established prior to database modification. The second is that any time the basket is recalculated (via basket.Recalculate() method) the tax line item will be reestablished. I mentioned above, deletion of tax items would have to take place after this call. The trigger sounds like it's taking effect immediately after the product is added?

It must be the first. The trigger is for INSERT or UPDATE. So the tax line never exists in the database beyond the code to insert or update it. That means that the display of data on the page is object based since the trigger takes place before the code could even read the data back.

Since it's part of the object, that makes it a lot more difficult to handle since there are so many places to track down. This is probably a primary reason to upgrade to 7.0.3. As far as I know, no one has publised the fix for this for 7.0.2 that handles displaying tax as individual line items. Please correct me if I'm wrong.

Since we don't use integrated shipping, I came up with using an incomplete default warehouse address: viewtopic.php?f=42&t=12376. I just left the province / state code field blank.

ZLA wrote:It must be the first. The trigger is for INSERT or UPDATE. So the tax line never exists in the database beyond the code to insert or update it. That means that the display of data on the page is object based since the trigger takes place before the code could even read the data back.

Yes. So the in memory object already exists... it's trying to persist itself to the database. And as far as it knows, it's successful. There's really only one thing to track down in code though. Any call to basket.Recalculate(). You could create custom .NET code to be pasted immediately following this and remove all tax items (if it was prior to the final payment page). I think there are only a handful of locations.

Or your workaround seems appropriate also, given your shipment situation.