openfoodfoundation / openfoodnetwork

Connect suppliers, distributors and consumers to trade local produce.
https://www.openfoodnetwork.org
GNU Affero General Public License v3.0
1.12k stars 724 forks source link

Incorrect Tax refunds (from taxes included in price) #6463

Open filipefurtad0 opened 3 years ago

filipefurtad0 commented 3 years ago

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

  1. Set up a zone.
  2. Set up a tax rate - let's take 20% - to be included in the price, for that zone. Link this tax rate to a tax category.

As admin

  1. Open a shop with a product, associated with the previously set tax category.

Customer A - billing address inside the previously set zone

  1. Place an order of £10, on that shop.

Customer B - billing address outside the previously set zone

  1. Place an order of £10 as well.

Compare the order summary obtained from customer A and B - should look something like the pic below.

Animated Gif/Screenshot

image.png

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

Matt-Yorkley commented 3 years ago

Quick notes:

filipefurtad0 commented 3 years ago

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

image

Tax Category: GST - set as default

image

Set Zone - AU

image

Tax Rates (only this tax rate active)

image

image

Order 1 - Customer from AU (is inside the tax-zone) - GST should and is included in the price - $1.67:

image

Order 2 - Customer from NZ (is outside the tax-zone)- $2 are refunded from the inclusive tax:

image

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?

Matt-Yorkley commented 3 years ago

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.

filipefurtad0 commented 3 years ago

Awesome - thanks Matt. I'll keep this one in mind as a test-case in the context of #6402 :+1:

drummer83 commented 1 year ago

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?