I have to manage item locations and life cycle as a new requirement. I'm not familiar in warehousing/inventory/storage systems, so maybe my question is trivial.
We have original items that will be processed multiple times. In case of some processing steps the original item will be divided into multiple sub items.
As storage location we have cabinet, shelf and box. The box can store multiple items, it has rows and columns.
We have to manage not only the current position but the complete location lifecycle even after the item was sold.
Technology: Java, Spring, Hibernate, MySQL
Question: How to manage connection between item and location? I have 2 solution in my mind:
- Store the location attached to the item: So
Itemhas a boxId, row and col. In this case no dedicated
Locationobject is created.
- When storage boxes are registered in the system it automatically creates
Locationobjects and the
Itemis associated to this
Location. For example if the admin adds a new 5x5 box to the system it will create 25
Locationobjects in the background.
As I have no experience in this topic so I'm not sure what hidden pros and cons each solution have. Maybe there are other,better ways to solve this problem.
To give more details I try to summarize what we know at the moment.
- Only relatively small amount of items will be stored that means 5-10.000/year. At the beginning even less. Very few user (maximum 1-2 in the same time) will use the system and response time is not critical.
- There are multiple size of items, but all of them are stored in boxes.
- Item can be: processed, splited, stored, moved, sold
- Item has a type that can be: ingredient, pre-processed item and finally it will be a product to sell.
- The history must contain the final product complete location history. Not only its own, but its parent items location history as well.
- Of course we need to know the item current location, or the fact that is already sold.
- It's also required to see how many empty location we have, just to know when to buy new boxes, cabinets.
- There are storage requirements like humidity, light, temperature. Depending on the item lifecycle it varies. The cabinet determine these conditions.
- There are also size constraints. The original ingredient item is bigger so a box can hold less item as in case of the final product.
- Cabinets and boxes have their own unique identifiers.
- All stored item - independent from the actual life cycle - has its own unique identifier. This will probably change in the future if new item types without UID will be introduced.
- The storage hierarchy is fix at the moment: Cabinet -> shelf -> box. However this will - almost sure - change in the future if the first version works well. So it can be more and also less levels for other items.