100% Discount cart rule results in Tax invoiced

[OldPlanets]

Preconditions (*)

1. Magento 2.3.6
2. Magento 2.4-develop
3. Free shipping is enabled

Steps to reproduce (*)

1. Navigate to Stores / Settings / Configuration / Sales / Tax
2. Set Catalog Prices and Apply Discount on Prices to Including Tax
   
3. Navigate to Sores / Tax Rules / Add New Tax Rule
4. Create a rule for all USA with 10% tax rate and apply it
5. Navigate to Marketing / Cart Price Rules and Add New Rule
6. Create a rule with 100% discount for all users
   
7. Make an order on Storefront:

• choose Free Shipping
• apply coupon code

8. Navigate to Sales / Orders and open your order
9. Create an invoice for the order and open it

Expected result (*)

1. An invoice is created over 0,00$

Actual result (*)

1. An invoice with the Grand Total of the tax amount is created
   
   

I'm suspect this bug was introduced in this commit (MC-35675):
2dbab41

It doesn't allow GrandTotals to go below zero, but the Tax Totals will add the discounted Tax, expecting that it was deducted before, resulting in a Invoice which is never smaller than the tax amount (instead of being 0)

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @OldPlanets. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[m2-assistant]

Hi @engcom-Delta. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 5. Add label Issue: Confirmed once verification is complete.

• 6. Make sure that automatic system confirms that report has been added to the backlog.

[magento-engcom-team]

✅ Confirmed by @engcom-Delta
Thank you for verifying the issue. Based on the provided information internal tickets MC-39052 were created

Issue Available: @engcom-Delta, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[paulvandermeijs]

I noticed in app/code/Magento/Sales/Model/Order/Invoice/Total/Tax.php that the discount tax compensation is added to the grand total; if I'm right that is the amount that is removed from the tax by a discount. In that case shouldn't it be excluded from the grand total?

magento2/app/code/Magento/Sales/Model/Order/Invoice/Total/Tax.php

Lines 121 to 122 in 445b0f1

	$invoice->setGrandTotal($invoice->getGrandTotal() + $totalTax + $totalDiscountTaxCompensation);
	$invoice->setBaseGrandTotal($invoice->getBaseGrandTotal() + $baseTotalTax + $baseTotalDiscountTaxCompensation);

[ThomasNegeli]

@paulvandermeijs
Until 2.2.11 the $invoice->getGrandTotal() was a negative value in that case.
In 2.3 something happenend so that the $invoice->getGrandTotal() returns 0 (which is logically right, but wrong when adding tax compensation).

[chequille]

Hi All,
this is not only tax problem, this is general problem with generating the invoice if there is discount applied. If there is no discount, the invoice is correct.
The new code from the classes in Magento_Sales/Module/Order/Invoice/Total is not working as expected.

As I think it was correct within Magento 2.3.5, I made a new module overriding the classes Tax.php, Subtotal.php, Shippment.php and Discount.php and took the code from Magento 2.3.5

The result of it is, that everything works as it should.

Therefore, there must be some bugs in the new classes.

As this is a mandatory and needed functionality, please be so kind and fix this as fast as possible and especially provide a patch because waiting for releases might be to long.

Thanks and best regards,
Jürgen

[chequille]

Hi
additional information about what I found on this issue.
As I said in previous comment, I override all classes in Magento_Sales/Module/Order/Invoice/Total and used the code from 2.3.5
I compared the code and found, that the only real difference is in Discount.php and this is causing the problem.

        $grandTotal = $invoice->getGrandTotal() - $totalDiscountAmount < 0.0001
        ? 0 : $invoice->getGrandTotal() - $totalDiscountAmount;
        $baseGrandTotal = $invoice->getBaseGrandTotal() - $baseTotalDiscountAmount < 0.0001
        ? 0 : $invoice->getBaseGrandTotal() - $baseTotalDiscountAmount;
        
        $invoice->setGrandTotal($grandTotal);
        $invoice->setBaseGrandTotal($baseGrandTotal);

The invoice is wrong because $invoice->getGrandTotal() contains the amount without tax, but $totalDiscountAmount is with tax.
Therefore, as long as GrandTotal is less than TotalDiscountAmount it is getting wrong.

Using the code from 2.3.5 at that point, invoices are correct again.

    	$invoice->setDiscountAmount(-$totalDiscountAmount);
    	$invoice->setBaseDiscountAmount(-$baseTotalDiscountAmount);
    	
    	$invoice->setGrandTotal($invoice->getGrandTotal() - $totalDiscountAmount);
    	$invoice->setBaseGrandTotal($invoice->getBaseGrandTotal() - $baseTotalDiscountAmount);

I hope this helps to fix the this bug.

Best regards,
Chequille

[m2-assistant]

Hi @engcom-Hotel. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
• 2. Verify that the issue is reproducible on 2.4-develop branch
     Details

     - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
     - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
     - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[engcom-Hotel]

@magento I am working on this

[angelomaragna]

I might guess that this is of big concerns when discount is greater than 50%, as, if the GrandTotal gest negative along the overall computation, a recent Magento update f**s it up.

Thanks to @chequille I've narrowed it down to this commit, which is completely wrong, and inside Magento since 2.3.6

c710c9b

The grand total is supposed to be negative as it's not concern of the discounting class to ensure it is greater than zero, as that is later used to calculate correct amounts.

Statistically speaking, we've never had problems up to 2.3.5, and now both 2.4.1 and 2.3.6 reports computational problems.

Quick solution for us, it's been patching the file directly, as the blame show no further modification was applied to it: https://github.com/magento/magento2/blame/2.4.1/app/code/Magento/Sales/Model/Order/Invoice/Total/Discount.php

Here the patch for magento/module-sales:

--- Model/Order/Invoice/Total/Discount.php
+++ Model/Order/Invoice/Total/Discount.php
@@ -71,12 +71,12 @@
         $invoice->setDiscountAmount(-$totalDiscountAmount);
         $invoice->setBaseDiscountAmount(-$baseTotalDiscountAmount);
 
-        $grandTotal = $invoice->getGrandTotal() - $totalDiscountAmount < 0.0001
-            ? 0 : $invoice->getGrandTotal() - $totalDiscountAmount;
-        $baseGrandTotal = $invoice->getBaseGrandTotal() - $baseTotalDiscountAmount < 0.0001
-            ? 0 : $invoice->getBaseGrandTotal() - $baseTotalDiscountAmount;
-        $invoice->setGrandTotal($grandTotal);
-        $invoice->setBaseGrandTotal($baseGrandTotal);
+        // Lines reverted from 2.3.5 as https://github.com/magento/magento2/commit/c710c9b38e0bcfbaedc6114bc5b4b9e62df95bbf
+        // bogs it up. Ref: https://github.com/magento/magento2/issues/30853
+        //
+        $invoice->setGrandTotal($invoice->getGrandTotal() - $totalDiscountAmount);
+        $invoice->setBaseGrandTotal($invoice->getBaseGrandTotal() - $baseTotalDiscountAmount);
+
         return $this;
     }

Hope this helps to better identify and put a containment to the original problem (which is how can these commits occur in the first place...)

[barryvdh]

@angelomaragna Thanks, I will try this patch. The solution in #31556 does not work for us unfortunately.
The issue is indeed also present with other values then 100%, eg we had weird results with 99% also.

[HenKun]

@engcom-Hotel Is there any ETA or progress?

[HenKun]

I can confirm the proposed change in #30853 (comment) works for discounts of 0%, 40%, 50%, 90% and 100% on M2.4.1. While the given patch could not be applied in my case I created a new (identical) one, see #32270 (comment)

The here mentioned fix in PR #31556 does work for discounts of 100%, however, not for discounts less than 100% and larger than 50%. (Tested on M2.4.1)

[DJB95]

@engcom-Hotel is there any ETA on this issue? Looking forward to hearing from you!

[hostep]

This is probably fixed by: MC-41438: 100% Discount cart rule results in Tax invoiced, which I'm guessing is going to be included in Magento 2.4.3

Maybe somebody can confirm this?