Total amount mismatch with external tax providers

[niklaswolf]

We have a US-shop, that needs to use an external tax provider service (in this case Avalara) because of the crazy complex tax rules in the US. There is a problem with Mollie and this external tax provider, but I think this is not only scoped to this specific provider, but more general.
We have for example this case: for the shipping costs, the external tax provider returns this:

taxAmount: 0.0
taxRate: 6.25

This may seem strange on the first look, but is totally valid, because there are tax exemption limits that can come into play. So the general taxRate in this case is 6.25, but because of the tax exemption limit the amount is 0.0.

This is now where the trouble with the Mollie plugin starts, because the plugin calculates the taxAmount for every lineItem again (would be nice to know, why this is necessary in the first place).
See:

Shopware6/src/Service/MollieApi/Builder/MollieShippingLineItemBuilder.php

Line 52 in 7127b7f

$price = $this->priceCalculator->calculateLineItemPrice($shippingPrice, $totalPrice, $taxStatus, $isVerticalTaxCalculation);

and:

Shopware6/src/Service/MollieApi/PriceCalculator.php

Line 27 in 7127b7f

public function calculateLineItemPrice(CalculatedPrice $price, float $lineItemTotalPrice, string $orderTaxType, bool $isVerticalTaxCalculation = false): LineItemPriceStruct

Because Mollie calculates the taxAmount again based on the taxRate, of course there is a mismatch which results in the following error during order creation:

[2023-08-22T09:28:11.603351+00:00] Mollie.ERROR: Error when starting Mollie payment: Could not create Mollie order (Session: ...) {"function":"order-prepare","exception":"[object] (RuntimeException(code: 422): Could not create Mollie order at www/vendor/store.shopware.com/molliepayments/src/Service/MollieApi/Order.php:184)\n[previous exception] [object] (Mollie\\Api\\Exceptions\\ApiException(code: 422): [2023-08-22T09:28:11+0000] Error executing API call (422: Unprocessable Entity): Order line 2 is invalid. Total amount is off. Expected total amount to be $37.13 (1 × $37.13), got $34.95. Documentation: https://docs.mollie.com/overview/handling-errors. Field: lines.2.totalAmount at www/vendor/store.shopware.com/molliepayments/src/Service/MollieApi/Client/MollieHttpClient.php:151)","session":"","processors":{"uid":{"uid":"4a686af"},"web":{"url":"....","ip":"...","http_method":"GET","server":"...","referrer":"..."},"introspection":{"file":null,"line":null,"class":"Kiener\\MolliePayments\\Handler\\PaymentHandler","callType":"->","function":"pay"}}} []

Now the question is, how to solve this. Personally, I think the recalculation of the taxAmount in the Mollie plugin is not right, why not use the taxAmount present in the CalculatedTax-Object? But there may of course be good reasons unknown to me why this is necessary.
Nevertheless this will be a problem in the future for such cases, especially in the US and with external tax providers.

[fjbender]

Hmm, IIRC the exact reason why we recalculate the tax amounts is to prevent this type of thing from happening. But as you explained (and thanks for that!) there are edge cases we didn't take into account (like 6.25% tax rate for anything above amount USD n).

Maybe it's best to wrap that calculation into a toggle and explain the scenarios in which a merchant would be using it or absolutely should turn it off?

[niklaswolf]

Maybe this would be an option yes, but maybe also worth investigating why the calculated tax amount from shopware is not used in the first place.

I understand that it's for sure a tricky topic to satisfy all edge cases. But I think this can pop up more often in the future, if there are more and more international shops that use an external tax provider.

[fjbender]

I think there are multiple edge cases tied into this, from net price consumer groups, vouchers/discounts etc.

https://github.com/mollie/Shopware6/blame/7127b7f50e00f69cf992482bcd3de863723c17d7/src/Service/MollieApi/PriceCalculator.php#L27 points to two particular cases - one with a classic rounding problem using vertical tax calculation, and one with promotions with mixed tax rates where we need to recalculate a fictional tax rate and amount.

@boxblinkracer will have all the details I'm sure, and probably has an idea as well on how to proceed here.

[BlackScorp]

@niklaswolf

so i talked internally with @boxblinkracer the answer for the question why we do an extra calculation:

1. In Shopware we can setup vertical and horizontal tax rates. Mollie Order API Supports only one way, so we have to adjust it
2. voucher/discounts may have different taxes while one line item in mollie supports only one tax. so we calculate the taxes there as well
   we could use separat mollie line items but then we have to change many things in the refund manager in order to refund items with voucher etc.

now back to the problem.

i think it is not that hard if we just check the total amount and if it is set to 0.0 we can exclude the item from calculation. how ever this check also protects us that orders are not created with invalid data.

is there a reliable way to find out that the case is valid if the tax rate is set but not the amount? i just need a way to verify somehow that the amount is valid because of tax exemption limits vs someone inserted wrong data into order.

can you help me out there?

[niklaswolf]

@BlackScorp unfortunately I don't think that there is a reliable way to verify this. At least with the external tax provider we're using, they do not use the official TaxProvider-Interface (https://developer.shopware.com/docs/guides/plugins/plugins/checkout/cart/tax-provider.html) yet, but modify the tax using event subscribers. I don't know if by using the newish interface there would be a way to determine from the cart/order if the taxes were set externally. If it was, it would at least be clear, that 0.0 is valid in this case. If I were you, I'd rather research in this direction, because it's the fault of the Tax-Plugin if it is not using the official interface.

But if there is also no way to determine validity using the interface, then I don't know either what to do without further looking into this. Maybe go with the suggestion from @fjbender and make the check configurable and turned on by default.

[BlackScorp]

@niklaswolf thanks iam going to checkout. but disabling the calculation is not an option, we have then add vouchers as own items and modify the refund manger. it is sadly no only a problem of disable/enable