Qty to ship and Qty to invoice are handling decimals poorly

[barbazul]

When working with products set up with is_qty_decimal, getQtyToShip and getQtyToInvoice sometimes return wrong values and cause orders to not be able to be completed

Preconditions

1. Have a product setup to use decimal qty

Steps to reproduce

1. Complete an order with a product using qty = 4.4
2. Create an invoice for qty = 0.4
3. Refund the invoice
4. Create an invoice for qty = 4
5. Create a shipment for qty = 4

Expected result

1. Order is complete

Actual result

1. Order is not complete because there is a qty = 3.3306690738755E-16 (that's 16 decimal positions) pending shipment

Overall float point numbers are handled poorly in all order qty operations

[barbazul]

#distributed-cd

[magento-engcom-team]

@barbazul thank you for joining. Please accept team invitation here and self-assign the issue.

[barbazul]

I am uncertain at the moment if I should go with a simple round()

I'll probably do that but use a larger than usual precision (like 8 decimals) which should prove enough to deal with extremely small decimal numbers

[orlangur]

@barbazul rounding is not a good idea in general as error can accumulate. What should be really avoided is strict comparisons of float.

Order is not complete because there is a qty = 3.3306690738755E-16 (that's 16 decimal positions) pending shipment

Looks like somewhere in Magento there is a check qty == 0 which should actually be qty < EPS, where EPS is some small number like 1e-8.

[barbazul]

@orlangur That would require a much larger change. Becase both getSimpleQtyToShip and getQtyToInvoice are being in several places.

Changing each of the comparissions would hide the underlying problem and is not future proof as some new functionality might use those public methods and repeat the error

[magento-engcom-team]

Hi @barbazul. Thank you for your report.
The issue has been fixed in #14346 by @barbazul in 2.3-develop branch
Related commit(s):

• 7a0534ad48dc33f6edb4f162d80ff12aa3759b30
• 5b58a3424e8896d66c0aff279065943b7e9c35fd
• 3c659994a2aad406af28138a886c6141d134f3ba

The fix will be available with the upcoming 2.3.0 release.

[Top-CMS]

Is the fix available so we can fix this for M2.2.3?
We don't know how long to wait for M2.3, so a quick fix should be great
otherwise it is not possible to invoice with decimals

[barbazul]

It should be relatively simple to build a module with plugins for the 2 affected methods.

Just check the committed code.

[ghost]

@barbazul, thank you for your report.
We've acknowledged the issue and added to our backlog.

[barbazul]

Hey @Top-CMS finally got around to building a module out of this: https://github.com/SemExpert/SemExpert_FixSalesDecimals

Enjoy

[magento-engcom-team]

Hi @TomashKhamlai. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if your 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.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.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. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[TomashKhamlai]

The issue was re-tested and we can confirm that it was fixed on the 2.3 release branch. We closing this issue as fixed due to upcoming 2.3 release that will be available soon.