Finer grain management for storage location

(Cédric Krier) #1


Some warehouse management strategy need to store the place of product with a very fine precision, for example the Chaotic Storage strategy.
This can not be modelled using the existing “Stock Location” for performance reasons because a nested structure will cost too much for the computation.


So we need to introduce a flat design under the storage location, let’s call it “Storage Unit”.
The idea is to manage it as new fields on stock move quite like the “Lot” but with a constraint that the “Storage Unit” must be one of the unit of the “Location”. It will only be visible for “Location” of the type “Storage” and required when “doing” the move.
We should be able to see the quantity of a “Unit” just like for “Location” and a relate action should allow to “open” a “Storage Location” to see the linked “Unit” with quantities.
The inventory should be extended to include the “Unit” field thanks to the grouping property.
Finally, the Move.assign_try should be extended to add the unit to grouping (note: it seems the assign_try method is not yet fully ready for such design) and so it should set a valid unit value on assigned moves.


Location as pallet/package
Location as pallet/package

Sounds like a good idea. Those storage units in a warehouse are mostly called ‘bin locations’. They can have characteristics (storage types), like cold- or toxic store, pallet store, high-rack etc.
They may as well be included in a bin search strategy (stow-away resp. stock removal).
Just as some additional ideas :slight_smile:

(Cédric Krier) #3

I think this constraint should only apply on draft and assigned move. Once the move is done, there is no need for this constraint.
I think there is a use case for those “Storage Unit” where it will simulate for example “Pallets”. Those “Storage Unit” could move from one location to another. In this case it should only be allowed if there are no draft/assigned moves using it.

(Cédric Krier) #4

I started to work on this and I have few changes to propose.

The flat design is still an important part of the design but I think it will be better to reuse the location model because it will avoid inconsistency when the “Storage Unit” is moved.

Indeed if we keep a single location, we must just improve the computation of the stock quantity. For that we must improve the loop when ‘with_childs’ is True. I propose to add a join on the query for location with only “Storage Unit” children so the move on those children location will be counted as from the parent location. And we will remove such location from the children query.

(Sergi Almacellas Abellana) #5

Link is broken. here is a new one:

(Cédric Krier) #6