Ubercart

I can confirm this still occurs with Alpha 8.

I have GST (6%), HST (14%), PST (8%) set up in admin/store/settings/taxes.

I've added an action for each of the taxes to admin/build/workflow-ng:
Zones: AB, BC, MB, NT, NU, ON, PE, QC, SK, YT -> Apply GST
Zones: ON -> Apply PST
Zones: NB, NL, NS -> Apply HST

If I set the province to Alberta it will correctly show GST in the payment section, however if I change it to Newfoundland it will now show both GST and HST when it should only show HST.

The correct taxes are shown by the time you get to the review stage.

A similar problem for me. I have taxes set up to charge only when items ship to my state. If the user picks my state for his shipping address, the tax shows up. So far so good. But if the user now changes the state to be anything else, the display of the tax doesn't go away - it still shows as my state tax.

Reloading the page fixes the problem - after a reload everything displays correctly.

A little more detail, looking at my server's access logs:

On the /cart/checkout page, when the user selects any state in the "Delivery Information" pane, that action causes an HTTP request "POST /taxes/calculate" to be generated (the code that makes this happen is in uc_taxes.js). When the state is my state (the only state with a tax rule), an additional HTTP request "POST /cart/checkout/line_items" is generated. The callback for line_items is the routine "uc_payment_get_totals" in uc_payment.module, which draws the "Subtotal", "Tax", "Order total" fields.

When the user's state is changed or set and it is NOT my state, the second HTTP request never happens. So far I haven't figured out where this decision is made in the code. However, it appears that this is why the display of the tax amount on the order doesn't go away. On a page reload, "POST /cart/checkout/line_items" *does* happen, which is why a reload solves things.

As I have wrote in this other thread, I have the same problem.

> If you reload the page in your browser after you modify the zone to StateB, do the taxes now show up properly?

Simple reload just clears all the user data and starts with no taxes, as well as no entry in the address at all, so it is not really a useful step. "Review Order" however does clear the old tax and so just the new tax.

However, the expected behavior is that when you change the zone (state), the old tax should go away and the new tax should appear.

I wrote some code which addresses this problem. I added some javascript variables to track which line items needed considered for removal each time the Order Total Preview was generated. I added a parameter to the set_line_item() javascript function which is called from modules outside of the payments module, but the default behavior should remain from the existing calls.

Using this patch I was able to setup taxes for 2 different zip codes and while switching the zip code on the checkout page it would show Tax A, Tax B, or no tax.

I couldn't get the patch to remove all of the taxes when none applied to an order.

I finally decided it was better for the tax module to remove those line items itself. When uc_taxes_javascript() returns no taxes, getTax() will set an empty, fake line item so that the line items will be refreshed. The payment checkout pane doesn't notice this extra line item so it doesn't get displayed.

This patch has been committed to the Bazaar repository.

Ah...that is much cleaner. I was getting line items with no description and $0.00 cost when I tried to go the route that you did, but I must have been doing something different. I also wasn't sure if using "tax_" was going to be a sufficient and non-conflicting identifier which is why I was doing the odd calculated item and show stuff.

I think the trick to it is that the key in the line item array is an empty string. At least my version of PHP doesn't load that into the $_POST variable.

I thought about whether there would be conflicts using "tax_", but I figured, the only other line items showing up were discounts and shipping quotes. If someone wants to write another line item module, I think they'll know not to name theirs "tax_".

Looks like this patch has a debug line in it spitting stuff out on pre tags?

Yeah, the patch does, but I fixed the Bazaar.