Add hook to retrieve location routing op~eration type

[florian-dacosta]

Hello @guewen
I'd like to add one small hook.
In my use case, we could want a different source routing picking type for the same location.
That is why, I'd like to be able to get information about the move, in the _find_picking_type_for_routing method.

With this small refactore, I'd be able to override the stock.move _find_picking_type_for_routing method to pass a context and do whatever we want to, in the stock.location _find_picking_type_for_routing method.

In the use case I meet, we may have, for the same procurement group, different picking, going from the same source location to different output. When these picking will be splited/routed, they could be merged into the same picking and it is not wanted.
Exemple :
Picking 1 contains 3 Product A. From WH/stock To WH/output
Picking2 contains 2 product A From WH/stock to WH/Assembling

They both reserve stock in a location like WH/My location with routing operation type
Then we will have
Picking 1 = 5 product A from WH/My location with routing operation type to wh/transit location
Picking 2 = 3 Product A from WH/transit location to WH/output
Picking 3 = 2 Product A from WH/transit location to WH/Assembling

And what I actually want is :
Picking 1 = 3 product A from WH/My locatio nwith routing operation type to WH/Transit location for output
Picking 2 = 2 product A from WH/My locatio nwith routing operation type to WH/Transit location for assembling
Picking 3 = 3 Product A from WH/transit location to WH/Transit location for output
Picking 4 = 2 Product A from WH/transit location to WH/Transit location for assembling

Indeed, As 3 product have to go to Output and 2 product have to go to Assembling, I don't want to mix them into the same picking. Because, when the guy take the products from WH/My location with routing operation type
He puts the product into a box. Then, on the next picking, the worker will just take the box and take it to the next location.
So if my 5 products are in the same picking, they will end up into the same box, and then, we won't be able to just move the box in the 2 next pickings...

I am not sure I am clear enough, but it actually seems pretty normal that we want to avoid merging moves from different pickings into the same picking when they are splitted/routed

[guewen]

As 3 product have to go to Output and 2 product have to go to Assembling, I don't want to mix them into the same picking. Because, when the guy take the products from WH/My location with routing operation type
He puts the product into a box. Then, on the next picking, the worker will just take the box and take it to the next location.

IANAL (I'm not a logistician) but looks like exactly what I would expect: the operator puts the 5 products on a roller cage to go from "WH/My location with routing operation type" to "WH/Transit location", in one operation (so one picking) rather than doing the work twice (2 pickings). Then, you should have 2 different pickings following this one, the first to take 3 products from "Transit to output" and the second taking 2 products from "Transit to assembly". Actually, that's also a reason for this module to exist: we want to limit the number of operations.

If you really want to keep them split, shouldn't you customize the _assign_picking method?

[florian-dacosta]

but looks like exactly what I would expect: the operator puts the 5 products on a roller cage to go from "WH/My location with routing operation type" to "WH/Transit location", in one operation (so one picking) rather than doing the work twice (2 pickings)

The thing is, during the first picking, the products are put in a PACK.
As the 5 product won't be going to the same location at the end, we don't want to pack it together.
If we got only one picking with 5 products, then we will have to add a new step to unpack it, and repack putting 2 products in one pack and 3 products in another pack so we are able to put the products in different locations during the next picking.

Also, the 2 picking may not need to be done at the same time. One maybe planned for today, the other in a week. That also make sense to have different pickings for same src/dest location, even if for this case, the picking type would be the same.

So, to limit the operations, we need to split the picking into 2, even if they go from the same src location to the same dest location.
I agree that in most case, we want to have only one picking though, but there are exceptions where source and destination location are not enough to want to put in a same picking.
And I guess, when the final destination (in chained picking) is not the same, it may be really important and logical to consider having 2 pickings, with 2 picking types.

Also, I believe that this kind of hook (allowing to override _find_picking_type_for_routing with information about the move) may also be useful in differents cases. It make the module more flexible.
But as far I am concerned, the hook could be different, the goal beeing to be able to modify the result of location._find_picking_type_for_routing depending on some stock.move related information.
Is it an issue?

If you really want to keep them split, shouldn't you customize the _assign_picking method?

Actually, from what I saw, there has been an improvement on _assign_picking in version 13, and it now takes into account the picking type.Meaning that if we have moves with same group, src, dest location, it could still be splitted into multiple pickings if the picking type is different.
Which is exactly one of the purpose of the hook I want to add.
I want to be able to put a different picking type in some case, depending on the stock.move

So, I guess it could be done customizing _assign_picking method, but I believe, this method should not really be customized as it is very generic and already do the job I want. It make more sense to be able to pass the right picking type and leave the method do its job.

[guewen]

It already does in 12.0: https://github.com/odoo/odoo/blob/bf81e38f685abbd4632c7be5cc381dfa38a9b7b8/addons/stock/models/stock_move.py#L681-L690

Anyway, as said on the original PR, please wait a bit, because that will change.
The next changes I'll do are to replace the fields on location by a model stock.routing.operation as:

• sequence
• picking_type_id M2o to picking.type
• location_src_id M2o related picking_type_id.default_location_src_id
• location_dest_id M2o related picking_type_id.default_location_dest_id
• direction selection (in, out) (applied when entering in src, or exiting from dest)
• domain: domain widget, applied on 'stock.move'

The model will act as a sort of mini rule engine which returns the picking type based on some conditions such as a domain. You should probably be able to use the domain, and if not let's this at this point how to integrate your use case.

[florian-dacosta]

Oh, yes it already does, did not see it looped on moves.

Anyway, no problem, I'll wait and follow the evolution and will continue the discussion at this time!
Thanks a lot @guewen