Closed chocolata closed 9 months ago
@chocolata the tax calculation is pretty complex and differs from country to country. You'll find sources that tell you to use the shipping address for tax calculations, others recommend to use the billing address.
If you change to using the billing address here and here, does it work for you?
Hi @tobias-kuendig ,
Thanks for your insights about taxes being dependent on shipping / billing country. I guess that setting is fine as it is then.
I've did some more digging and I found out that when a user is not logged in and is ordering for the first time, i.e. enters his billing / shipping address for the first time on the quick checkout page, there is no Ajax request that refreshes the page to recalculate the taxes. Whatever shipping or billing country I choose, the taxes stay the same...
Might this be something we missed? Or did I overwrite too much in my custom partial?
Hi, I've done some more digging and I've found this:
1) Changing the shipping adress to the billing address for the tax calculation doesn't resolve the issue unfortunately.
2) In the partial quickcheckout/countrystate.htm, there does seem to be an Ajax request tied to the country dropdown:
{% set id = type ~ '_country_id' %}
<div class="mall-form-control">
<label for="{{ id }}">{{ 'offline.mall::frontend.form.country' | trans }}</label>
{{ form_select_country(id, countryId, {
id: id,
emptyOption: ('offline.mall::frontend.select' | trans ),
'data-request': 'onInit',
'data-request-data' : ("type: '" ~ type ~ "'"),
'data-request-success': '$.publish("mall.address.update")',
'data-request-update': {
(__SELF__ ~ '::countrystate'): ('#countryState_' ~ type)
}
}) }}>
<div data-validate-for="{{ id }}"></div>
</div>
When I investigate the sourcecode though, it seems that the output might be malformed:
Do you think that expressions like "quickCheckout::countrystate":"#countryState_billing"
might be the cause?
I've reverted to the default quickCheckout partials that are shipped with Mall, but I am getting the same results.
3) When users are logged in or have an active session after checking out as a guest and make a second purchase, everything works as it should and the appropriate taxes are applied.
Could you kindly have another look? Most people are running into this issue now, as most don't yet have an account...
P.S.: One important thing to mention. The product in my cart does not require shipping, as it is a virtual product, but as stated the tax is applied correctly when the users are logged in.
Hey @chocolata, give version v3.0.28 a try. I have added a workaround to calculate taxes for unregistered users based on their QuickCheckout country selection.
See https://github.com/OFFLINE-GmbH/oc-mall-plugin/commit/47c34553bce866b47615c2cf9ca331207663079a
Hi Tobias, this works perfectly! This solves it completely. Thanks for your great work, appreciate it!
Hi,
I just saw something worrying in a production environment we launched a couple of weeks ago.
It's an international shop, allowing users from all countries to purchase tickets. It works well, apart from the tax application based on the country.
If a customer has a Belgian billing address, 21% VAT should be applied. This seems to be the case.
If a customer is a European customer, but not a Belgian customer, the 21% VAT should not be applied, as they are exempt from this tax. This seems to work at first glance, but we just had a non-Belgian customer that paid 21% VAT...
This is how the taxes are applied in the store:![image](https://github.com/OFFLINE-GmbH/oc-mall-plugin/assets/3584586/b619e543-e0e1-4d1a-8d93-c0fc2bf3278a)
This is how the taxes are applied on the product:![image](https://github.com/OFFLINE-GmbH/oc-mall-plugin/assets/3584586/24c998df-c183-47b2-bf11-af227f233d52)
A secondary issue appeared aswel: Also, in the QuickCheckout component, having for example a Belgian address and a German address and switching them, does seem to enable / disable this tax, but only upon selecting the shipping country, not the billing country. I would think that the billing country would be the determining factor in the application of the tax.
P.S.: I am aware of certain tax calculation errors as presented here in the past, but this issue deals with the application of the tax as a whole instead of errors in the calculations.
Can you kindly look into this as customers are actively paying the wrong amounts as we speak?