[FW][FIX] product: Warning when setting a UOM more precise than Decimal A…#59718
[FW][FIX] product: Warning when setting a UOM more precise than Decimal A…#59718
Conversation
|
Ping @fah-odoo, @amoyaux stderr: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?). In the former case, you may want to edit this PR message as well. |
bca8ad8 to
ecff018
Compare
|
Cannot reproduce the issues for _prepare_move_line_vals and _update_reserved_quantity (the tests in test_move2 always pass) Not sure it can be merged straight away, to recheck next week. |
|
Hello @amoyaux I'll be away for a bit, should we check it when I return? Or do you think these changes can still be done without breaking something elsewhere? |
|
At the move line creation. The value contains 0,1498 instead of 0.15. The use case still failing in reality. Probably need to check with framework team why the cache is not truncate to the digits (as in 12.0). |
addons/stock/tests/test_move2.py
Outdated
There was a problem hiding this comment.
Never compare floats like that, use float_compare!
|
@fah-odoo @amoyaux I think that the difference between this version and the former ones comes from the ORM-pocalypse. Lines 2971 to 2972 in fe75ca9 In 13.0: Line 3082 in 7a9aa30 The conversion used to "fix" the bad rounding from the database, and it is no longer the case. Note that there are raw float comparisons in your tests (see comments above); if you use float_compare, things should work as expected.
|
When modifying a field's decimal precision, the caches are cleared in order to retrieve the new value from the database. As the new value is retrieved in pure SQL, one has to flush the updates before doing the query!
…on issue One can set a Unit of Measure precision rounding more precise than the overall Decimal Accuracy. This can trigger the error 'It is not possible to unreserve more products', as there will be inconsistencies on reserved quantities due to decimal roundings. We add 2 warnings on Units of Measure and Decimal Accuracy. Therefore, users are warned when their UOM/decimal changes can cause inconsistencies in quants reservation. Also, we want to prevent the issue at the root by ensuring that both the move and the quant have the same reserved quantity. The contrary can happen e.g. when a product is defined in Liters (rounding .001) but used in an operation in ml (rounding .01, so e.g. 187.5ml). The conversions between the 2 UOM can cause the differences of reservations. In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom is not more precise than the overall Decimal Accuracy. That way, if the reserved quantity changes between UOM conversions, the move line created is in the quant/product UOM, and we do not have move line's reserved quantity > quantity in stock. We do the same for _update_reserved_quantity (stock.move), when updating a move line. In _update_move_lines, because of UOM conversions, new_quantity_done can differ from ml.product_uom_qty, which triggers the creation of an extra move line, leading to reserved quantity > quantity in stock. To prevent that, we compare the reserved quantities in the product UOM. opw 2206902 (Example 1) opw 2171541 opw 2221227 opw 2233937 opw 2198775 and many more X-original-commit: 9131852
|
@robodoo r+ |
…ccuracy
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add a warning, so that the users who make the change are aware of the
impact of modifying their UOM precision.
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: #58762
Forward-Port-Of: #54935