Hi all.. I've seen some things... But this one is new. This is the OrderConfirmationMail, 3 items of

ULL0N440J

Hi all..
I've seen some things... But this one is new.
This is the OrderConfirmationMail, 3 items of the same type.
I directly access the items within the orderEntity and access all of them with the same method. Can anyone explain, why they are varying? 🙄

I wouldn't expect that the calculation varies at the same calculation (in every case +19%)

Alberto Reyer

Spryker has a pretty uncommon summing, where it tries to distribute the tax evenly and keeps a rest if that is not possible, which gets added add the end. I don’t remember if the rest was distributed among items as well.

But the sum should be correct.

It’s just a blind guess as the whole calculation stack is pretty complex and hard to diagnose without debugging through it.

ULL0N440J

That's indeed uncommon, but would explain it. Thank you!

Andriy Netseplyayev

@ULL0N440J the reasons most likely are following:
1. Tax distribution is needed, to handle returns/refunds properly. If one item out of 3 is returned, you would want to refund 1/3 of a tax as well
2. The difference you see is explained correctly by Alberto, the reason is - the so-called “missing cent” issue, when you try to divide let’s say 10$ between 3 items, you will get 0.33 after rounding and 0.01 will be missing, so you gonna get total mis-match. That’s why the left-over will be either distributed also evenly, until total matches

Andriy Netseplyayev

you can check

TaxFacade::getAccruedTaxAmountFromGrossPrice()

for more insights