Open dathwa opened 6 months ago
Hello,
thanks for your message. To be honest, I wasn't quite sure if taxes are calculated "per line" or using the net-worth of "all lines" within the same rate.
Thus, I tried "professional" invoice experts, such as Invoice Ninja and PayPal Business. However, in your case, you've 5 products, not stackable, each one as a separate invoice item. According to both, PayPal and Invoice Ninja, the calculation per line is correct.
Invoice Ninja (5 lines) | Invoice Ninja (5 quantity) | PayPal (5 lines) |
---|---|---|
Well, that doesn't have to be right for sure... Thus, I consulted the internet. Since I'm Austrian, I tried to find a correct answer according to Austrian / German laws (we've pretty much the same, just different tax rates). And ended up with bare hands and even more questions...
Well.. last but not least, I asked ChatGPT (I know, that's pretty much worthless in front of any judge, but anyways)
First of all, it's not a rounding error, it is a deliberate and correct calculation. Which makes me happy, since I did code this part of my PriceBag class right. YaY
Of course, that doesn't help you any further. So my suggested solution would be to configure this calculation as a additional setting. This way everyone can decide for themselves whether the calculation should be made per invoice item or per tax-rate stack. However, this will take some time, since PriceBag only supports the first way atm.
Is there any chance this will be fixed in 3.2, and do we have a time-line yet for this?
This part of the calculation / PriceBag system was supposed to be shipped in 3.2 (as this was also the most problematic part of the mall extension). However, since 3.2 has been delayed due to the release of OC v3.6 anyway, I guess I'll try to find some time adding the "configurable" tax-calculation part.
So yes, should be fixed in 3.2.
~ Sam.
Since, I'm not running a company / writing invoices myself...
@tobias-kuendig How is this regulated in Switzerland? Tax calculation per invoice line or per "tax-rate stack" (net value of all products of the same VAT regulation)?
I'm pretty sure that this part of the law is similar for all three DACH countries.
Hi @SamBrishes Thanks for the analysis. Much appreciated. It's a whole can of worms, I know. FWIW, our client is UK based in the UK, and leans towards a "tax-rate stack". I'll feed this post back to them. Certainly, an option to switch between either approach would be ideal.
Hi @SamBrishes.
Using the out of the box, 'tax per line' approach , I think the totalPreTaxes
and totalProductPreTaxes
in offline_mall_orders
must be wrong. The "total pre taxes" should be 41.65. Make sense?
Hello,
sorry for the long wait. I fell ill and then sank into work after.
Anyways, I could ask a professional accountant how VAT is calculated correctly and the sad truth is, that there is no correct way... or too many correct ways... depends on how you want to see it.
So both "VAT per line" and "VAT based on total" are valid. There is no preferred solution in any way, and rounding errors due to different calculations are accepted by state tax authorities. Thus. as already said, the best way is to support both, VAT-per-Line and VAT-on-Total calculations. In addition to both, we may can also add an additional option which prevents labelling VAT at all, as necessary for (at least) all DACH* countries under certain conditions.
However, the calculation of this itself is not really difficult, but the calculation of discounts requires a little more work, especially when different VATs are used.
Sincerely,\ Sam.
*DACH stands go Germany-Austria-Switzerland
Hi @SamBrishes. I hope you've made a full recovery. Yes - it's not a perfect science. I look forward to any improvemnts on this, especially with discounts. Cheers.
Hello. Looks like we still have tax calculation issues. E.g. Cart value is £50.00. Tax is 20%.
Tax seems to be calculated per line, introducing rounding errors. See image below... 10 / 1.2 = 8.33 5 items 8.33 = 41.65 pre-tax value 10 - 8.33 = 1.67 5 items 1.67 = 8.35 Tax (wrong)
The correct calculation should be...
50 / 1.2 = 41.67 pre-tax value 50 - 41.67 = 8.33 is the correct tax value
Is there any chance this will be fixed in 3.2, and do we have a time-line yet for this?
Still a great plugin. Thanks all for the work.