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?

  • 1
    I see similarities to the types of optimization which disks perform in order to load files. Fragmented files may be in several spots on the disk, and the disk attempts to optimize the proper order to fetch these fragments. Perhaps you could look into that.
    – Neil
    Commented Sep 13, 2013 at 14:33
  • Do you have a specific question about the data structure? It sounds like you are asking about what the business process or workflow should be. Commented Sep 13, 2013 at 16:59
  • needs to support having stock in locations with no record to where that location is. - Do you mean no record of where the physical location is, or no specifics (i.e. "In this row, but we don't know which bin")?
    – Bobson
    Commented Sep 13, 2013 at 17:06
  • @Bobson The language didn't make sense I rewrote the line.
    – Ominus
    Commented Sep 13, 2013 at 17:43
  • 1
    I think you might be solving the wrong problem - when I read your question the main problem I see is this: "No one here can help me when I try to get what the best practice should be." You can't magic up a solution if your BAs and users can't help you find it. Commented Sep 15, 2013 at 13:23

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.