[16.0][ADD] stock_location_orderpoint_change_priority V2 #55
Conversation
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
The unit test `test_stock_location_orderpoint_priority_change` was failing in `stock_location_orderpoint` because the associated logic was moved to `stock_location_orderpoint_change_priority`. This commit removes the now-obsolete test from `stock_location_orderpoint` as an identical test already exists and passes within the `stock_location_orderpoint_change_priority` module, where the relevant priority change logic now resides.
…e in replenishment logic. This commit delays the priority update to occur *after* moves have been merged. This ensures that the function merging replenishment moves still has access to the "not yet updated" priorities preventing information loss.
Some test was failing because the code saying "day +1" fails if we are the last day of a month.
Some test was failing because the code saying "day +1" fails if we are the last day of a month.
…replenishment moves
…ng logic to main replenishment method
…6.0-imp-stock-location-orderpoint-priority-nde
…te the priority of the ongoing replenishment moves to the priority of their orderpoint.
Contributor
|
Hi @mt-software-de, |
…lenishment move priority Previously, when a replenishment move's priority was updated, the `stock.move` record's priority did not change. This was because `stock.move.priority` is a computed field that depends on the associated `stock.picking`'s priority. This commit fixes the issue by updating the picking's priority as well. This also includes: - Passing the `product` argument to the `super().run_replenishment` method. - Updating the module's manifest description.
…by product The `run_replenishment` method was incorrectly returning all replenishment moves for a given location, regardless of the products that triggered the replenishment. This could lead to unexpected behavior and confusion.
… orderpoint when merging. The previous implementation linked merged moves to the first orderpoint's ID (see `_merge_moves` function from odoo.addons.stock.models.stock_move.py), which lead to incorrect priority. This change ensures that the merged move inherits the location orderpoint with the highest priority.
nicolas-delbovier-acsone
force-pushed
the
16.0-imp-stock-location-orderpoint-priority-nde
branch
from
7d6b742 to
d9c3105
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
This PR is a rework of #20 now based on #52.
Using the fact that replenishment moves are now returned by the replenishment method (#52), this rework allows to simplify the code.
Compared to #20, the logic changed a bit: Beforehand, the priority update would only target some moves in case of 'auto' orderpoint whereas it would update all ongoing moves in case of 'manual' orderpoint (see the removed unit test). The logic is now simpler: always update all ongoing replenishment moves priority when replenishing.