[FW][FIX] product: Warning when setting a UOM more precise than Decimal A…#58126
Closed
fw-bot wants to merge 1 commit intoodoo:saas-11.3from
Closed
[FW][FIX] product: Warning when setting a UOM more precise than Decimal A…#58126fw-bot wants to merge 1 commit intoodoo:saas-11.3from
fw-bot wants to merge 1 commit intoodoo:saas-11.3from
Conversation
Contributor
Author
|
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. |
…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 _generate_consumed_move_line, 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: 39c0c7e
1518a7f to
5535110
Compare
|
@amoyaux working on resolving the conflicts, hope I didn't forget anything (all the product.uom should be replaced with uom.uom). |
Contributor
|
robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
Sep 22, 2020
…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 _generate_consumed_move_line, 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 closes #58126 X-original-commit: 39c0c7e Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…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: #54935