Problem with taxes (Canada)

Hi,

Well, you need to check your tax rules in the menu System>Taxes.
Something must be wrong there.
Please provide a screenshot of that page and we should be able to tell you what's wrong.

Hi,

First, make sure that the product you're testing with has its "tax category" setting set to "default tax category".
Second, I would say that the issue might be with the "EU" and "Outside EU" zones.
The EU zone should be of the type "tax" and contain all the EU countries except the netherlands.
The "outside EU" zone should also be of the type "tax" and contain on the other countries, not in the EU.
Also, in your shipping methods, there is a setting "override tax zone". If you set this setting, it will use the zone selected here instead of the zone of the shipping address when the shipping method is selected. So it could potentially come from there too.
Please check all this.

Hi,

You didn't provide any screenshot regarding your EU zone and outside EU zone.
These can be found in the menu System>Zones. When you edit them there, you'll see a "type" setting where you should have "tax" selected instead of "country" or "state".
I am not talking about the customer type setting of your tax rules.
While you can select each individual country in a tax rule, you can create a tax zone with all the countries you want as sub zones of that tax zone, and then select that tax zone in your tax rule. Either way is fine.

If you believe that everything is setup properly, please provide a backend access along with a link to this thread for reference via our contact form and we'll look into it:
www.hikashop.com/support/contact-us.html

Hi,

I got your backend access.
I've made a mass action with an action "display the results" to check the data of your addresses in the database, and I can see that all the addresses end up with the "malta" state selected automatically when I edit / create an address on your website.
I don't see how that's possible.
I've even disabled the custom state field in HikaShop and it's still happening.
So I'm thinking you must have a custom plugin doing that for some reason. And that's why the system sees all the addresses as being in the EU because the address_state of the addresses is forced with "malta" which is in the EU.
Do you know what it could be on your end ? Because there is no such thing in HikaShop by default.

Hi,

Yes. I've done these tests already before my previous message.
And you can note that the custom field address_state is unpublished. I've unpublished and made that test, after fixing the address_state of all the addresses in your database to make sure that it was not HikaShop doing it since HikaShop won't take into account unpublished custom fields for the saving of the address.
Regarding Malta being a country, you're correct that Malta is a country.
But In HikaShop we have both Malta as a country and Malta as a state of that country, being the main island of Malta. There is another state named "gozo" for the two northen islands of the country.
Anyway, there is no reason why HikaShop would set that state in the address_state column, since that not even the default value of the state field.
Besides a custom plugin, I don't see what it could be.
Further steps will be painful if you don't know where this comes from. It requires adding logging of data in the code.
The first step is to edit the file administrator/components/com_hikashop/classes/address.php and in the save function there, you can see the function triggerEvent being called 4 times.
Before and after each of these lines, you need to add something like that:
hikashop_writeToLog($addressData, 'xxx');
where "xxx"to be replaced by some text describing the location being logged (for example: 'before onBeforeAddressCreate' or 'after onBeforeAddressCreate').
Once that is done, the "payment log file" in the HikaShop configuration needs to be checked after the issue has been reproduced once.
What you'll see there should be that the address_state attribute is empty before a triggerEvent and then filled with state_malta_2408 after it, confirming that the issue comes from a plugin.
Then, to know which plugin does that, similar debug needs to be added to the function trigger of libraries/joomla/event/dispatcher.php
However, you want to do it only if the $event is equal to the name of the event for which you found the address_state being set to state_malta_2408.
Once you analyze the log data after reproducing the issue again, you should find the name of the plugin doing it and from there you can unpublish it or disable it to check that you don't have the issue without it.

We can do all that for you if you want. However, please understand that I've already spent 2 hours in your backend looking at your HikaShop and testing things and replying to you. We'll charge you for the time spent working on this if this is not a bug in HikaShop (which it won't be as there is no reason HikaShop would set that specific state in the addresses on your website while it doesn't for everyone else).
If you're interested, you can use our contact form to provide a FTP access and a link to this thread.

Hi,

Maybe you deleted the state of malta at some point, thinking it would solve the problem ? That state_malta_2408 zone is there by default in HikaShop. you can go in the zones listing and search for "MLT" to find it normally, along with the Malta country zone as both have the same 3 letter code.

It will depend on the time I have to spend on it.
I'll charge 80€ per hour of work. I expect the time I will take to be between 1 and 3 hours. It depends what I find during the debugging.

Hi,

Since you don't have the state in the address object in "after onAfterAddressUpdate", it means that it's not HikaShop core doing this. It's highly likely that it is a plugin implementing the onAfterAddressUpdate trigger event running its own MySQL query to directly set that in the database.

in the trigger function of libraries/joomla/event/dispatcher.php you'll want to add several logging commands.
You'll want one after

$value = $this->_observers[$key]->update($args);

$this->_observers[$key]

if($event== 'onAfterAddressUpdate'){ 
$db = JFactory::getDBO();
$db->setQuery('SELECT * FROM #__hikashop_address WHERE address_id = '.$args[0]->address_id);
$address = $db->loadObject();
hikashop_writeToLog($address, 'xxx');
hikashop_writeToLog($this->_observers[$key], 'xxx');
}

$value = call_user_func_array($this->_observers[$key]['handler'], array_values($args));

Hi,

It's almost certain it doesn't come from Joomla core plugins.
The most likely would have been the massaction address plugin, because of a mass action you configured wrong. But I didn't see such a mass action.
If you don't want / can't do the debug in the Joomla library files as I indicated in my previous message, you can also find which plugin is the culprit by disabling the plugins one by one and each time reproducing the issue. And I would start with the mass action address plugin, just in case. That way, you can identify which plugin is causing the issue, but it might take a while, especially if you have a lot of plugins.

Hi,

Yes. We'll need a FTP access, on top of the backend access you already provided so that we can modify the files to add the debug ourselves
You can provide that via our contact form:
www.hikashop.com/support/contact-us.html