Invoice Grand Total wrong if discount applied

[HenKun]

Preconditions (*)

1. Magento 2.4.1
2. tax/calculation/price_includes_tax => 1
3. tax/calculation/apply_after_discount => 1
4. tax/calculation/discount_tax => 1

Steps to reproduce (*)

1. Create a product with price 20.50 (including tax as per setting above)
2. Tax is set to 19%
3. Create a cart rule for 100% discount
4. Order the product
5. Create invoice

Expected result (*)

1. Order Grand Total is 0
2. Order Tax is 0
3. Invoice Tax is 0
4. Invoice Grand Total excl. Tax is 0
5. Invoice Grand Total incl. Tax is 0

Actual result (*)

1. Order Grand Total is 0
2. Order Tax is 0
3. Invoice Tax is 0
4. Invoice Grand Total excl. Tax is 3.27
5. Invoice Grand Total incl. Tax is 3.27

Probable Reason

In vendor/magento/module-sales/Model/Order/Invoice/Total/Tax.php on line 121 the invoice grand total is set to:

$invoice->setGrandTotal($invoice->getGrandTotal() + $totalTax + $totalDiscountTaxCompensation);

which resolves to:

$invoice->setGrandTotal(0 + 0 + 3.27);

The usage of $totalDiscountTaxCompensation is IMHO wrong when using these settings.

We now have the scenario that the invoices show a grand total > 0 which is not resolvable for accounting since these amounts were never received from the customer.

Basically the same issue occurs if the discount is not 100%, just the amounts differ of course.

---

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.
• [x] 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[bot]]

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

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

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: 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.

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

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

[HenKun]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @HenKun. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @HenKun, here is your Magento Instance: https://da30135e1013b1413204ea32a3043e27-2-4-develop.instances.magento-community.engineering Admin access: https://da30135e1013b1413204ea32a3043e27-2-4-develop.instances.magento-community.engineering/admin_e274 Login: 01bd3c93 Password: be184a8c3cf7

[HenKun]

Could be reproduced on test instance:

Invoice:

Order:

[willryanuk]

I'm seeing the same thing on Magento 2.4.2 CE. I'm not sure if there is some relation to these issues: https://github.com/magento/magento2/issues/29506 https://github.com/magento/magento2/issues/21456

Smaller discounts actually work fine in my case, but larger discounts (e.g. 90% or 100% off) result in the issue as described as above. If you look below, the Grand Total is £0.00 but the total paid by the customer is £54.17

[HenKun]

@willryanuk I don't think these tickets are directly related. The tax is basically calculated correctly (against the assumptions in the linked tickets). As you see in your and my examples, the tax is 0 which is correct.

However, the invoice grand total contains the hidden tax (which is the tax that would be applied without the discount) that results in

1) the grand total of invoice is greater than 0 2) the total paid amount shown in order is greater than 0

whereas the customer actually (and correctly) paid nothing since the order grand total is 0.

So in my opinion the handling or application of the hidden tax is incorrect.

And this is a large issue for us at the moment.

[HenKun]

@willryanuk are you sure smaller discounts work fine? I think the problem ist just not that obvious

[willryanuk]

@HenKun unfortunately (and confusingly) it does indeed seem to invoice correctly for smaller discounts.

E.g. here is a discount at 10% where the discount is calculated correctly, and the total paid is calculated correctly. So it only seems to happen for me for larger discounts such as 100%.

[HenKun]

Indeed, that seems to be correct. Since you seem to have a test setup at hand, can you check if a 99% discount gives correct or wrong results?

[willryanuk]

Yes, a very high discount e.g. 99% gives erroneous totals. Here is a summary from an order that I performed last week which illustrates the bug...

[HenKun]

OK, that's really weird. Let's wait if a Magento Developer has more insight into the problem. We can see in the last example that the tax calculation is again correct. So it's imho safe that it is not a problem with tax calculation per se.

[JoostWan]

Same problem over here with a coupon with 100% discount on Magento 2.3.6. Total Paid amount is not zero but the amount is the tax of the order.

[barryvdh]

This is probably related to https://github.com/magento/magento2/issues/30853

[HenKun]

@barryvdh Seems to be the same issue, correct. Especially the comment:

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.

indicates why the large amount of 99% fails and the discount of 10% succeeds.

Even more sad that this bug is present since 2.3.6 and known since Nov 2020 and not fixed yet.

[JoostWan]

@HenKun Fixed my issue (100% discount) with the following change https://github.com/magento/magento2/pull/31556/commits/34ecd22341ba95e13c6dd7407dd74d6b20318487

[willryanuk]

Fixed it for me as well. I waste a lot of time on Magento with bugs such as this.

[HenKun]

@JoostWan @willryanuk I applied the patch of https://github.com/magento/magento2/commit/34ecd22341ba95e13c6dd7407dd74d6b20318487 which is the same as PR https://github.com/magento/magento2/pull/31556

However, that does not work for me for discounts smaller than 100%. Given a discount of 90%, the invoice grand total is just 0.

Can you check if this is only on my side?

[barryvdh]

I'm having the same problem with 99% discount rates.

[HenKun]

@barryvdh Did you try the patch proposed by https://github.com/magento/magento2/issues/30853#issuecomment-764582933 ?

[HenKun]

The patch in https://github.com/magento/magento2/issues/30853#issuecomment-764582933 could not be applied, so I created it on my own:

diff --git a/Model/Order/Invoice/Total/Discount.php b/Model/Order/Invoice/Total/Discount.php
index ef7205b..0807c5d 100644
--- a/Model/Order/Invoice/Total/Discount.php
+++ b/Model/Order/Invoice/Total/Discount.php
@@ -71,12 +71,11 @@ class Discount extends AbstractTotal
         $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;
     }

I tested it with discounts of 0%, 40%, 50%, 90% and 100%

All tests worked fine with my setting. (On M2.4.1)

However, I am not sure what the commit https://github.com/magento/magento2/commit/c710c9b38e0bcfbaedc6114bc5b4b9e62df95bbf MC-35554: Orders with Zero Payment Information required are Closed after being invoiced that introduced the bug wanted to achieve with this change, so it might have other side effects reverting this change with this patch.

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

[m2-assistant[bot]]

Hi @engcom-Alfa. 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: :point_down:

• [ ] 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.

[engcom-Alfa]

Hi @HenKun

I have re tested it in the Magento ver. dev-2.4-develop, and it is worked as expected. Below are the screenshots of it.

So, kindly update to the latest version and give a try. If you still face the issue, you may please report a new bug on the same.

[vrielsa]

The fix on develop and the one mentioned here doesn't work if your discount does not apply to shipping costs.

[valguss]

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?

Yeah, just had to apply the patch you mentioned and that has fixed the issue for me