Jump to content
thirty bees forum
  • 0

Wrong amounts when applying discount cart rule


Occam

Question

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 0_1499417053775_2017-07-06 18_54_26-Order -TB-Checkout.png Discount, net totals and totals are wrong

  2. Same in BO order page 0_1499417067571_2017-07-06 18_59_21-Orders _ Order JGXJSSAAW from Gurka Nusseck • TB BO1.png

  3. Further bug in these "mixed" orders: Payment of previous order is "accepted" when you change status to paid, which causes a WRONG warning 0_1499417091955_2017-07-06 19_00_05-Orders _ Order JGXJSSAAW from Gurka Nusseck • TB BO2.png
  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.

Link to comment
Share on other sites

15 answers to this question

Recommended Posts

  • 0

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.

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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: 0_1499688513211_2017-07-10 14_05_19-IN000049.pdf - Adobe Acrobat Pro.png
  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: 0_1499689390868_IN000049.pdf- tax rates.png

Link to comment
Share on other sites

  • 0

@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"} %

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...