Open filipefurtad0 opened 3 years ago
Quick notes:
I'll try to explain below:
We should make an issue for the missing translation
The missing translation is this one - #6414
This probably isn't something new in the release
This is good news, I was not so sure about that :+1:
I'm not sure how common it will be in practice for an instance to have inclusive GST and non-inclusive VAT at the same time?
This case only deals with one inclusive GST tax. No VAT tax is applied.
It's not clear what all of the variables are in relation to the zones and rates in this example scenario...
Let's look at the current configurations on staging-AU:
Created product Carrots - Tax Category: GST
Tax Category: GST - set as default
Set Zone - AU
Tax Rates (only this tax rate active)
Order 1 - Customer from AU (is inside the tax-zone) - GST should and is included in the price - $1.67:
Order 2 - Customer from NZ (is outside the tax-zone)- $2 are refunded from the inclusive tax:
I would expect the same amount ($1.67) to be refunded, for Order 2. So, to me, it looks as if the GST-refund is being calculated as a VAT. I think this not the correct behavior, at least I have no explanation for this.
This may be relevant when a hub is shipping to other countries - perhaps not a very common use case? If it is indeed a bug, then maybe an S4?
Cool, thanks for clarifying. I'm pretty sure this will be fixed in the adjustments work, there are various improvements to the way inclusive and exclusive tax are recorded and also to how they are applied or refunded when the zones are different.
Awesome - thanks Matt. I'll keep this one in mind as a test-case in the context of #6402 :+1:
Looking at the comment regarding adjustments above, we should check if the issue described here is still in production. Also there might be a relation to #9548, which might even be a duplicate?
Description
If an enterprise has a tax set to be included in price (GST) for a given zone, and is selling produce to customers whose billing address is outside of that zone then, after checkout, the customer will be refunded with the value corresponding the included tax, for the respective order total.
Currently, it appears that the calculation of the amounts to be refunded is incorrect. See the explanation and pics below for an concrete example, reproduced in two different staging environments.
A customer A (pic below, left side) whose billing address is inside a GST (20%, included in tax) zone, is charged £1,67, on a £10 order, as seen on the order summary. On the other hand, customer B which is outside of this zone (pic below, right side) checks out with the same items and order total, but gets refunded for £2. If they place the same order, and no other tax is acting, the refund for Customer B be equal to £1,67, following the relation to calculate included tax:
Order Total (£) - (Order Total (£) / [100% + GST%] ) (£) = Included GST (£) <=> <=> 10 - (10/1.2) (£) = 1,67 (£)
The refunded amount of £2 appears to indicate that a simple proportion is being used for the calculation: £10 x 20% = £2, which is incorrect in this case.
Expected Behavior
Tax refunds, which were included in the price, are correctly calculated and returned to the customer.
Actual Behaviour
Tax refunds, which were included in the price, currently are incorrectly calculated and returned to the customer.
Steps to Reproduce
As superadmin
As admin
Customer A - billing address inside the previously set zone
Customer B - billing address outside the previously set zone
Compare the order summary obtained from customer A and B - should look something like the pic below.
Animated Gif/Screenshot
Customer A - left - https://staging.openfoodnetwork.org.uk/admin/orders/R444860410/edit Customer B - right - https://staging.openfoodnetwork.org.uk/admin/orders/R280606583/edit
The pic also shows missing translation #6414
Workaround
Adjusting the order, in the backoffice.
Severity
Are GST refunds being used at all?
Your Environment
Possible Fix