Wrong amounts when applying discount cart rule

[Occam]

Tax and price computation in checkout and invoices were a mess in PrestaShop 1.5 and 1.6, when applying cart rules with discounts. But I'm afraid that thirty bees as well did not yet resolve the problems.

Example, tested on thirty bees 1.0.2 beta:

Cart Rule: 3 for 2 Conditions: Product selection for 1 category, The cart must contain at least 3 product Action: Apply discount of 100% for cheapest product

Preferences --> General: Round mode: Round half even (as recommended) Round type: Round on the total AEUC activated, Rounding method "Round on the total" (this dropdown for options is new in 1.0.2), anyway, same result with option "no rounding"

Result is a bit disappointing so far, no matter if with activated or deactivated AEUC.

1. Shopping cart in checkout Discount, net totals and totals are wrong

2. Same in BO order page

3. Further bug in these "mixed" orders: Payment of previous order is "accepted" when you change status to paid, which causes a WRONG warning
4. Invoice with activated AEUC and proportionate tax display in tax details is then totally messed up (wrong amounts marked yellow) 01499417112661IN000004 -TB order Invoice.pdf

It took me some time to realize that the errors are mainly caused by the fact that every other product in cart from a different category (which is not included in the applied tax rule) diminishes the discount, increased by units.

Is the initial discount e.g. 19,98, it decreases - to 19,10 if you add one more other product - to 18,96 if you add 2 more other products and so on.

Obviously the cart rule thus has an impact on the computation behavior for other products in the cart which is not correct. It works perfect as long as you just buy products from the discounted category. Same behavior btw in tb 1.0.1.

[Occam]

Maybe this is a helpful hint: It seems that all this only happens when you have products in the cart with different tax rates. As long as the products share the same tax rate, the discount does not change when you increase or decrease any quantity.

[Occam]

Your demo and my own test environment 1.0.1. - same results.

[Occam]

I'd suggest you have a close look into function getContextualValue in /classes/Cart.php. I mean, just a gut feeling ...

[Occam]

Not really a joke, this was just a touching up. PS_PRICE_COMPUTE_PRECISION is used in several functions and classes, but initially with a fixed value. Later on PrestaShop added this new input field for price precision in the preferences menu, which was stored under the new name PS_PRICE_DISPLAY_PRECISION in the ps_configuration table. The line you quoted saved a lot of code changes, but caused new problems ( see my pm).

[Occam]

One more experience I made:

Given, the cart includes products with different tax rates, the cart discount (as applied above) - decreases with every added product with a different taxe rate, and - increases on the other hand with every other product with the same tax rate as the discount products, no matter if it's belonging to the 3 for 2-category or not.

I would exclude the possibility that all this happens because of the rounding methods in Tools.php, because I get the same results when overriding all this with the function I introduced in September 2014 in the PrestaShop forum: banker's rounding reworked function ps_round

[Occam]

@mdekker said in Wrong amounts when applying discount cart rule:

_PS_PRICE_COMPUTE_PRECISION_ [..] Not really a joke, this was just a touching up.

The define is now going to be used to determine the amount of decimals to save in the database (6). Rounding should only occur on the configured places.

I totally agree, though simplifications like this seem to be the Preston hallmark since 1.6.1, undermining the main code.

[Occam]

@mdekker said in Wrong amounts when applying discount cart rule:

The contextual value function takes the average tax of the cart. This is why you see different discounts when changing the other product. It seems like it has nothing to do with the category in which the discount is valid.

It has definitely nothing to do with any category!

[Occam]

Great! Really a tremendous effort. Anyway, take my advice and don't work through all day and night, you don't need to set a new speed record after all. ? Eager to walk through the code and do some testing, but later in my leasure time.

[Occam]

Made some tests. I'm not sure if this is what you really wanted:

1. (Average?) tax for products discounted Order is computed with a tax rate 13% while the tax in fact is 21%
2. Same on invoice:
3. The cheapest product of all ordered products is discounted, no matter if it's part of the action or not.
4. I had my reasons when I convinced the PrestaShop team to show the tax rate without decimals in tax details. I'm sorry, but in my view this change in OrderInvoice.php is not a real improvement, but a step back: You replaced $rate = sprintf('%.3f', $row['tax_rate']); with $rate = numberformat($row['taxrate'], PSPRICEDISPLAYPRECISION_);

And btw it looks rather unformatted:

[Occam]

@mdekker said in Wrong amounts when applying discount cart rule:

Order is computed with a tax rate 13% while the tax in fact is 21%

Actual tax is still set to 13% I think, due to the tests, which makes the tax rule's name confusing.

???

The cheapest product of all ordered products is discounted, no matter if it’s part of the action or not.

Yes, it's been configured like that Where? Not in the cart rule.

And btw it looks rather unformatted:

Strange, that must be a template problem. I could have left an extra 0 in it. This was problem in former releases of PS 1.6.1 One fo the reasons why it was changed to a rate without decimals.

Taxes can be entered with three decimals (both db and admin pages handle it like that), so we should format all the percentages like that, I guess. number_format is basically the same function, except it's a raw PHP function rather than a ported C one. Ok, no problem for me. For users in Germany and all other countries where tax decimals are uncommon on invoices I'd recommend to change /pdf/invoice.tax-tab.tpl, line 71, from * {$line.rate} % to * {$line.rate|round:"0"} %

[Occam]

Oops, I didn't check the tax page, sorry.

And, yes, discount on the cheapest product, but with the condition just one specific category. The condition is ignored now. It wasn't like this before.

[Occam]

Perfect! And the changed CSS class like in my post above provides the correct alignment on the invoice:

[roband7]

Remember to also test all this on a product with attributes and then change attributes on-the-fly.

There's a lot of funky dodgy looking stuff in the updatePrice() function in community-theme-default/js/product.js

[Occam]

@mdekker said in Wrong amounts when applying discount cart rule:

Sure, we'll have a look with 1.0.3

The cheapest product calculation has been fixed, too. My guess is that PrestaShop skipped it, because they couldn't register the data for the order detail table. Even after validating the order with a correct cheapest product calculation there is no way you can later access the data for generating the invoice.

Did not realize it, but I can confirm this for 1.6.1x. However, it worked properly in 1.5 (and I guess until 1.6.0.14) The only problem were the wrong net prices and tax amounts on the invoice then. All cart rules including cheapest product by percentage are correctly applied in a PrestaShop 1.5 shop.

[Occam]

If shipping is 12.50 and given a small rounding effect, I would agree.