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.