IFS Cloud Warehouse Structure: Design It From the Floor

An inventory location in IFS Cloud sits in a hierarchy: a site contains warehouses, and a warehouse contains bays, rows, tiers and bins. The IFS documentation on inventory locations and warehouse structure describes the levels and how an inventory location maps to the bin. The table gives the physical meaning of each level.

The page on entering inventory locations describes how a location is created. The team decides how many levels it actually uses on the floor: a warehouse can be modelled as one open area or down to the individual shelf.

The location model should be as fine as the operator needs in order to find stock without asking anyone, and no finer. Two failures mark the ends of the scale.

• Too coarse: stock is “in the warehouse”. The system says the part is on hand, and the operator searches for it. Counts become approximate because the count unit is a whole hall.
• Too fine: every shelf is its own bin and every move needs a scan, a transaction and a check. The transactions are correct and the floor stops following them.

The method to find the right level has four steps:

1. Walk the floor with the warehouse team from goods receipt to dispatch.
2. Watch a pick from the pick list to the packing area, and note each point where the picker hesitates or searches.
3. Count the touches for one typical receipt, one pick and one stock count under a coarse model and under a fine model.
4. Model the level at which the extra detail removes a search and stop where it only adds a scan.

Fast-moving parts and slow-moving parts are not equal here. The pallet in the corner shows what slow stock does to prime picking space, which is a layout question as much as a master-data one. The receipt side of a poor model, where goods arrive and cannot be placed, is covered in goods receipt, inspection and put-away in IFS Cloud.

Route order sets the sequence in which locations are visited; check its default and where it is maintained in your release before you rely on it. A pick list built on route order follows that sequence, so the picker’s path is only as good as the order of the IDs.

The order hurts when IDs were chosen for another reason: the order in which racks were bought, a number from the old system, or a label that makes sense to the person who typed it. The sequence then no longer matches the way a picker walks, and every pick list zigzags across the floor. The cure is to decide the walking order first, name or number the levels to match, and correct the route order where the floor has an exception such as a one-way aisle.

Shop order pick lists can be grouped by warehouse, bay, row, tier or bin, as the IFS documentation on shop order pick lists describes. The level you model therefore also decides how pick lists can be split between pickers. The setup of picking strategies themselves is a separate topic.

A put-away rule set at a higher level of the structure applies to the levels below it, and a lower level can override it. The IFS documentation on inventory put-away describes this inheritance. A rule defined on a bay therefore covers its rows, tiers and bins, and one bin in that bay can have its own rule.

The design consequence is to set the general rule high and exceptions low. A rule repeated on every bin is hard to change, and a rule scattered at random levels is hard to read. When the structure is built, copying a bin layout saves typing for repeated rows, and it also repeats any mistake in the original, so check the first row before you copy it.

What stagnant stock costs once it is stored is the subject of the anatomy of stock aging.

Four decisions come before locations are loaded, because a loaded location is hard to rename once stock sits in it.

• Naming convention: how bays, rows, tiers and bins are numbered, and whether the walking order can be read from the name.
• Location groups: which locations share a purpose, such as picking, bulk or quarantine, so that the team can treat them as one when it designs put-away and counting.
• Bin meaning: what one bin number stands for, a shelf, a pallet position or a block, and what happens when a shelf is split in two.
• Stable names: which levels will never be renamed, because other systems, labels or scanners refer to them.

Counting depends on the same decisions. A count schedule works on the locations you define, so a model that groups unlike stock together produces variances that are hard to trace, as described in cycle count variance reconciliation. A multi-site layout adds its own question of which warehouses belong to which site, treated in site cluster functionality.

Test the location model with the operators who will use it daily, on a mock-up of the real floor, before the data is migrated. Give a picker a pick list and ask them to walk it on a floor plan. Give a receiving clerk three deliveries and ask where each goes. A stock controller gets a count list and says whether it matches the way the shelves are laid out.

Each point at which the operator asks “where is that?” is a defect in the model, not in the person. Record it in the test log, adjust the structure, and repeat. Posting consequences of these movements are a finance topic; see posting control in IFS Cloud for how location and transaction design feeds the ledger.

A location model is ready for migration when each of these checks has evidence.

Dariusz Myśliwiec: 18 years hands-on with IFS, including IFS Cloud. Based in Kraków, delivering remotely across Europe and globally through an independent practice. You talk to the consultant who does the work, not a sales layer.

IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.