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


  • administrators

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


  • administrators

    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.


  • administrators

    1.0.2-beta.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 …


  • administrators

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


  • administrators

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


  • administrators

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


  • administrators

    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.


  • administrators

    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!


  • administrators

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


  • administrators

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

    0_1499656832268_shoppingcartsummary.png
    ** 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:

    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 = number_format($row[‘tax_rate’], PS_PRICE_DISPLAY_PRECISION);

    And btw it looks rather unformatted:
    0_1499689390868_IN000049.pdf- tax rates.png


Log in to reply
 

Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.