Inventory / Stock in multiple locations

Question

I am working on a warehouse management system (WMS) that needs to support having stock in multiple locations. Could be in a different building, could be stored in n* places in a building (quick example would be stock, overflow, or fast moving slots all containing a qty of the same item).

Where I am, they have always used one SKU assigned to one bin with paper notes pointing to overflow. Obviously they have grown beyond this and it's causing some serious issues. No one here can help me when I try to get what the best practice should be.

I am having trouble conceptualizing how to setup the structure.

I am thinking ...

• Warehouse (virtual or physical) Warehouses can belong to warehouses.
• Location - Anything really could be a pallet, box, or just a taped off area on the floor. Locations belong to warehouses.
• Rows - can be in locations
• Shelves can be in rows
• slots(traditionally called a bin here) the smallest unit that can be a location.

Then a SKU could be in any one or many of these locations (except the virtual warehouse - used only from grouping physical locations but allowing a sales order to process them internally as if it shipping from one space).

Locations (are their children) could be given priority. So if a SKU is in 2 locations, the systems knows which slot(bin) to empty first before routing to the next.

I code it so that the structures above can be handled by the warehouse since i don't care physically about them only that the process makes sense and then give them a tool to mark a sort order so that they can determine the best routes through the warehouse with batch picking an order.

I guess I just wanted to get this out of my head and get someone elses eyes on it before I wrote a single line of code.

Does this structure make sense? Is it a best practice? If not what is and if that question is outside the realm of the site could someone point me to it?

Answer 1

Encapsulation is going to be the key for making sure you start with the right structure.

I would have a primary entity for the salable good (widget), of which the SKU is an identity type property. The salable goods or widgets are your base objects as that's what's being sold. SKUs can change although it's somewhat rare.

Each widget can have zero or more locations, so I would have a collection of locations within the widget.

Each location is going to have a relative weight representing the availability or location cost for that set of widgets. I would recommend making the location cost a first class object, and not just a value. Location cost is a relative term based upon where the caller is located. If I'm at one site then I want the back-of-store widgets instead of the widgets at another physical location. At a minimum, you need to hide the implementation of location cost to external callers so you can more easily adapt it in the future.

To support referential integrity, I would make the widget.count() method iterate over all of the locations and count those. Otherwise you end up doubling the amount of stock keeping you have to do - once for the widget and again for the location.