Wrong amounts when applying discount cart rule

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 productPreferences > 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.

Shopping cart in checkout
Discount, net totals and totals are wrong 
Same in BO order page

Further bug in these “mixed” orders: Payment of previous order is “accepted” when you change status to paid, which causes a WRONG warning

Invoice with activated AEUC and proportionate tax display in tax details is then totally messed up (wrong amounts marked yellow)
0_1499417112661_IN000004 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.


Thanks for sharing all this. This the kind of information we are looking for. Very nice that you have described the steps as well.

One step closer to a solution now.

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.

1.0.2beta.1?

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

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

Let me tell you a joke (credits go to PrestaShop):
define('_PS_PRICE_DISPLAY_PRECISION_', Configuration::get('PS_PRICE_DISPLAY_PRECISION')); define('_PS_PRICE_COMPUTE_PRECISION_', _PS_PRICE_DISPLAY_PRECISION_);

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).

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 2category 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

Note: there need to be at least two different tax rates before this problem occurs.

_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.

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.

And I think this comment says it all ^^
// since later on we won't be able to know the product the cart rule was applied to, // use average cart VAT for price_wt

@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.

@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!

K, then we can agree on that. I’ve been searching around categories, but found nothing. I’ll stop searching.

In order to fix invoices, discounts, taxes and price displays I have renewed most of the tax and discount system and pushed it to the test environment. Let me know if you can find anything that’s not working, yet. It is a huge revamp.
I have changed:
 cart rule discounts (tied to a tax rate)
 global cart rule discounts (e.g. 10 incl. VAT, no specific tax rate)
 specific prices
 catalog price rules
 ecotaxes
 product tax breakdowns
 the way the round modes are applied
 Replaced the advanced EU compliance proportionate shipping tax (now forced to be the same as
round type
) _PS_PRICE_COMPUTE_PRECISION_
is back to what is was: the same as_PS_DISPLAY_COMPUTE_PRECISION_
. Instead, I have introduced a thirty bees specific one:_TB_PRICE_DATABASE_PRECISION_
 Forced the rounding type and mode when generating invoices from orders (this was often forgotten, forcing the current mode and type to be applied instead of the order ones)
and there’s probably a whole bunch I have forgotten, but I am seeing a huge improvement on my production environment already. Can’t wait to merge this into 1.0.2
** Round on each item, 2 decimals, default rounding mode**

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.

Made some tests. I’m not sure if this is what you really wanted:
 (Average?) tax for products discounted
Order is computed with a tax rate 13% while the tax in fact is 21%  Same on invoice:
 The cheapest product of all ordered products is discounted, no matter if it’s part of the action or not.
 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 = number_format($row[‘tax_rate’], PS_PRICE_DISPLAY_PRECISION);
And btw it looks rather unformatted:
 (Average?) tax for products discounted