Hello, I have found some behaviour which seems strange:
Create new product A
Create 2 new storage zones under STO zone:
Zone 1 (non lot)
Zone 2 (lot)
Create move for product A to zone 1
Create move with lot (LOT1) for product A to zone 2
Create a shipment to send product A with LOT1.
On the assign_try step when computes the from location it sets the location to Zone 1 instead of the Zone 2 where it’s the one which there is the lot.
Tested on demo.tryton.org, 6.0, with product.id = 18
Yes it is expected. By default lot does not provide any constraint. The usage is to register which lot was taken and not to request a specific lot to be picked.
If you want to have such constraint, you need to add lot to the grouping of Move.assign_try. But you should has strong arguments to decide in advance which lot to pick.
Indeed in the scenario the user is registering that has picked lot 1, but doing before the shipment assignation makes the system compute the wrong location.
Why does not make sense to have the lot as default grouping?
Won’t be better if the system uses this grouping at least for the moves that have a lot set?
Maybe but there is nothing telling the user that it should set the lot before assigning. So I do not think we can blame them for this.
I’m thinking in just adding this to stock_lot:
@classmethod
def assign_try(cls, moves, with_childs=True, grouping=('product',)):
lot_result = True
if 'lot' not in grouping:
lot_grouping = grouping + ('lot', )
lot_moves = [m for m in moves if m.lot]
if lot_moves:
lot_result = super().assign_try(lot_moves, ..., grouping=lot_grouping)
moves = [m for m in moves if not m.lot]
return lot_result and super().assign_try(
moves, with_childs=with_childs, grouping=grouping)
I do not really like neither because it will make the code of assign_try more complex for no real benefit.
Indeed I think it will be better to have a kind of hook method to group moves per kind of assignation.