[WMS][13.0] Add stock_dynamic_routing - alpha version #788
Conversation
|
Check this: #639 (comment) |
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
087814d to
8cd53aa
Compare
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
8cd53aa to
8ab3d06
Compare
Detailed commit history for the past developments can be found in https://github.com/guewen/stock-logistics-warehouse/tree/12.0-add-stock_picking_zone
* if the move's dest location is a child of the routing's dest location: it's more precise so change only the picking type * if the move's dest location is a parent of the routing's dest location: change the dest location to the routing's dest location and change the picking type * if the move's dest location is outside of the routing's dest location: add a routing operation before It means, when there is a routing, even if the location was already correct, the picking type is changed so users handle transfers the same way. The same changes will be done on the destination routing
We can probably optimize it by appling the domain only once for all the moves of a routing. The same thing should be applied on destination routing.
when we have to apply a routing instead of using unreserve: any side-effect will be cancelled before doing the routing and calling assign again, thus we avoid leaving things behind.
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
a4618a8 to
6bd18f4
Compare
The relation from the move doesn't always exist, if we delete the package level before the unreserve, they are properly deleted.
Rules can be ordered and excluded by domains. Store the rule chosen for a move to avoid doing it twice.
A split must occur to handle the routing only on the available quantity.
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
745b1f5 to
db5518a
Compare
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
67c425a to
de2417f
Compare
When a move source location changes or a new move is inserted in the chain, reevaluate the routing rules so we can chain several rules.
The _split method expects product_qty, not product_uom_qty. So get the missing reserved quantity and convert it in the unit of product_qty (as done in StockMove._action_assign())
In some conditions, new_moves can contain the same moves as self, so _action_assign() would be called twice on the same move and would have duplicate move lines.
No longer needed after the last refactoring
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
f38c5ad to
6740b48
Compare
There was a problem hiding this comment.
Thanks for the hard work, the module is really flexible and seems quite clean/well done to me!
I like the flexibility and it meets my use case now without need of adding several hooks and so on.
I see you are still working on it, so I keep a complete review for later, but still, there is one thing I have a hard time to understand, why do you have to call an _action_assign (and then roll back it) during the process?
What do we really gain in comparison to not doing it and just call the whole routing process after the _action_assign super, instead of before? (like it was in the previous version)
I think it adds a lot of complexity, and in some case may lead to unwanted/not needed action.
I mean, we could, after a change in the configuration for example, want to call the _split_and_apply_routing method on already assigned moves. Then we do not need to reassign it (and rollback it!)
Also, I wonder if it could be a problem to only call the super and not the whole method. It could probably lead to unwanted behaviors depending on action_assign override by depending modules.
|
todo: rename to stock_dynamic_routing and move to OCA/wms |
We have to "peek" at what will be reserved to know the available quantities in which source location, so we can split the move in the parts that will be reserved and the parts that cannot be reserved and apply different routing rules. The part of the move that will be reserved will have its routing applied, the other part will not change. We cannot do it after the assign is done, because applying the routing may change the source of the moves, change the picking of the move, ...
It wasn't. The previous version had to call action_assign and unreserve before applying the routing.
It's much more simple and clean to release a savepoint that the previous version which was calling super on _action_assign and then calling unreserve -> we are guaranteed that anything done for the first "action_assign" is rollbacked, while in the previous version we could have leftovers, or any action done by another module could be kept. If you think it adds complexity, I think you missed how complex it was before ;)
As for any module overriding a method, the order of the calls to the method could lead to issues sometimes, but I don't see more risk here than any other override. The annoying point is that we have to execute _action_assign twice (only when a routing is applied), which is not great for performance, but I reckon there is no other way. |
* Prevent calling _action_assign() twice in case the savepoint was released * Do not apply routing rules on the move we just routed as the routing rule to apply will be the same and already done * Add comments explaining why they are called
In case of a put-away, when using a push routing rule, we want to keep the expected destination. For instance, we have a move: * Input -> Highbay (draft) It's assigned and the put-away rules compute a move line going to Highbay/X1Y2. When a routing is applied, before this commit, it would add a move at the end, it would look like: * Input -> Handover (assigned) * Handover -> Highbay (confirmed) On reservation of the second move (Handover -> Highbay), it would compute again the put away rules to find a place in the whole highbay. With the change now, the moves would look like: * Input -> Handover (assigned) * Handover -> Highbay/X1Y2 (confirmed) So the move line cannot go elsewhere. To implement this, I decided to remove the 'routing_rule_id' field stored on 'stock.move', as this field is only needed by the methods _apply_routing_rule_pull/push and never afterwards. The original location has to be propagated to these methods as well, so now there is a single dict of values used to apply the rules.
When an ormcache is cleared, it propagates the invalidation to other workers, blowing all their caches for all models. Since we use this cache only for the duration of a method, it's pointless.
By using the parent path of the records, we can avoid many SQL requests to compare children or find parent locations
guewen
changed the title
The picking type must be selected to filter on routing to apply
There is no real reason to force using the exact same location. A sub-location should be fine.
|
@guewen Would be really nice to move it to WMS repo, I'm trying to update the issue to help people followup the overall work done |
On stock.move, the `package_level_id` field did not have a `copy=False` attribute when version 13.0 of Odoo was released. So when we create a new move, the package level of the move being copied was linked as well to the new move. It has been fixed recently in odoo in odoo/odoo@ecf726a but to be on the safe side if the code is not up-to-date, it's anyway better to force a False value.
guewen
force-pushed
the
13.0-add-stock_routing_operation
branch
from
6f0aa91 to
53c0b8b
Compare
|
This PR has the |
Note: |
|
@jgrandguillaume Moved to OCA/wms#31 and changed to Beta. |
Introduction
Port of #639
Detailed commit history for the past developments
can be found in https://github.com/guewen/stock-logistics-warehouse/tree/12.0-add-stock_picking_zone
Additional changes in data model and features to expect, so the PR is a draft now.
Description
Route explains the steps you want to produce whereas the “picking routing
operation” defines how operations are grouped according to their final source
and destination location.
This allows for example:
them in two different picking type
the sub-location waves
Context for the use cases:
In the warehouse, you have a High-Bay which requires to place goods in a
handover when you move goods in or out of it. The High-Bay contains many
sub-locations.
A product can be stored either in the High-Bay, either in the Shelving zone.
When picking:
When there is enough stock in the Shelving, you expect the moves to have the
usual Pick(Highbay)-Pack-Ship steps. If the good is picked from the High-Bay, you will
need an extra operation: Pick(Highbay)-Handover-Pack-Ship.
This is what this feature is doing: on the High-Bay location, you define
a "routing operation". A routing operation is based on a picking type.
The extra operation will have the selected picking type, and the new move
will have the source destination of the picking type.
When putting away:
A put-away rule targets the High-Bay location.
An operation Input-Highbay is created. You expect Input-Handover-Highbay.
You can configure a routing operation for the put-away on the High-Bay Location.
The picking type of the new Handover move will the routing operation selected,
and its destination will be the destination of the picking type.
This is the implementation of "Warehouse operations by zones" RFC: #640 original document is the WMS document:
https://docs.google.com/document/d/1mct6bFFWJqW01wGFcjc-uQNEjyCxvh6Y9TuFdRhe-b0/edit#heading=h.49w4ly4e5y8g
Try on runbot
In Inventory Settings, activate:
The initial setup in the demo data contains locations:
The "Highbay" location (and children) is configured to:
goods are taken from Highbay (using a new picking type Highbay → Handover)
goods are put to Highbay (using a new picking type Handover → Highbay)
Steps to try the Source Routing Operation:
Steps to try the Destination Routing Operation:
In the "WH/Stock" location, create a Put-Away Strategy with:
Create a new purchase order of:
Confirm the purchase
You'll have 2 transfers: