The picker is standing at the bin. The screen says pick forty. The bin says otherwise.
At that moment, three replenishment methods have already had their chance and taken it. Order-based looked at the open deliveries. Automatic waited for a confirmation that never came, or came too late. Planned swept through at four in the morning and found the bin above minimum, because at four in the morning it was.
None of that helps the person standing there now.
Direct replenishment is what EWM does about it — and it is the only one of the four methods that does not watch anything at all. It has no threshold to monitor, no schedule to run on, no demand to add up. It waits for a human being to report that reality and the system have parted ways, and only then does it move.
That makes it useful in exactly one situation and dangerous in most of the others. This post is about telling those apart.
The Method With No Sensor
Every other replenishment method in EWM is a form of monitoring. Each one reads a number and compares it to another number: stock against minimum, stock against demand. They differ in when they read it, which is what Post 3 was about. But they all read.
Direct replenishment reads nothing. It is started during a bin denial — when a warehouse worker at the bin reports that the stock is not there — and only when the exception code raised at that moment refers to the internal process code for replenishment.
That is the entire trigger. Not a level, not a job, not a delivery. An exception, raised by a person, routed by a Customizing entry.
Bin Denial and Pick Denial Are Not the Same Event
This distinction is worth thirty seconds because getting it backwards makes the whole mechanism unreadable.
A bin denial is what happens at the bin: the worker confirms the picking warehouse task short, or with nothing at all, because the stock the system expected is not physically there.
A pick denial is the business consequence: EWM concluding that the requested quantity cannot be fulfilled from this warehouse, and telling the ERP system so, so the open quantity can be handled somewhere else.
One does not automatically become the other. Between them sits a search — and direct replenishment is what happens when that search succeeds.
Read the fork in the middle of that diagram carefully, because it is the part most people have never seen drawn. The same event — a worker saying «it is not here» — produces a replenishment or a cut order depending on whether the system can find stock in the storage types it is allowed to look in.
The Assumption That Decides How Much Arrives
Once direct replenishment fires, it has to decide a quantity. And here it does something none of the other methods do.
It calculates against the maximum and minimum quantity in the usual way — and it assumes the quantity at the storage bin is zero.
It does not go and look. It does not read the current stock figure and work out the difference. The bin was just denied, so as far as the calculation is concerned the bin is empty, and what gets built is a full top-up. The result is then rounded down to a multiple of the minimum replenishment quantity, the same rounding behaviour as the two minimum-quantity methods.
Why that assumption matters on the floor
A bin denial does not always mean an empty bin. A worker can raise one because the stock there is damaged, because the batch is wrong, because a pallet is blocking access. In those cases the bin still physically holds product — and direct replenishment will still build a quantity as though it held none. What arrives is a full load onto a bin that was not empty. That is not a malfunction; it is the documented behaviour meeting a situation the method was not designed for.
Where It Sits Against the Other Three
Put all four side by side and the shape of the family becomes obvious. Three sensors and one exception handler.
That last row is the whole post. Direct replenishment is not a fourth flavour of the same idea. It is a different category of thing that happens to produce the same kind of warehouse task.
There is one line worth carrying out of this series, and it is in the rounding column: only order-related rounds up. It is the only method answering a demand that has to be met, so it is the only one allowed to overshoot — and, as Post 2 covered, the only one that may legitimately exceed the maximum quantity. The other three round down, because they are protecting a level rather than filling an order.
Picker-Directed Replenishment: The Task That Jumps the Queue
Direct replenishment can be handed straight back to the person who raised the denial. This is picker-directed replenishment, and it is the version most people actually mean when they describe the method.
In that case the replenishment warehouse task is displayed as the next item to be processed in that picker’s warehouse order. The worker who just reported the empty bin is the one sent to refill it, immediately, before continuing with the rest of the order.
Two conditions have to hold for that to happen, and both of them fail quietly:
The system must already have found stock in the permitted storage types. If the storage type search sequence behind the replenishment process type comes back empty, there is nothing to hand the picker, and the path ends in a pick denial instead.
Picker-directed replenishment is only possible in radio frequency scenarios. There is no desktop equivalent. If the operation is not on RF, this half of the method does not exist for it.
The Prerequisite You Cannot Configure Around
The RF constraint only limits who gets the task. There is a harder one that decides whether the method exists for a product at all:
It is only possible in fixed storage bin scenarios. Not «works better with», not «recommended for» — only possible. If a product is not tied to a fixed bin in the picking area, this method has nothing to replenish, because the concept it depends on is a bin that belongs to a product permanently enough to have a minimum and a maximum of its own.
Teams building a dynamic picking area sometimes plan direct replenishment into the design and discover this after the storage type is already modelled. It is not a Customizing gap you can close later. It is a consequence of how the picking area was laid out.
Where teams get burned
Direct replenishment is the most satisfying method to demonstrate — the picker reports an empty bin, a task appears on the gun, the bin gets refilled, everyone nods. So it quietly becomes the primary mechanism instead of the safety net. Six months later the pick face is being kept alive entirely by workers reporting problems, every replenishment costs an interrupted order, and the minimum quantities nobody has maintained since go-live are irrelevant because nothing reads them any more. The method works perfectly. The warehouse is running on exception handling.
What Has to Be in Place
The configuration chain is longer than for the other three, because it crosses from replenishment into exception handling. Every link is somewhere a silent failure can hide.
On the exception codes themselves
The four-character codes a worker sees on the RF screen are yours, not SAP’s. What is delivered is the set of internal exception codes; the external codes and their texts are defined per warehouse, and two systems doing the same thing will very often spell it differently. Do not go looking for a specific code you read somewhere — go looking for the entry whose internal process code is replenishment, and read off whatever your system calls it.
When a Bin Denial Should Not Trigger Replenishment At All
Replenishing is not always the right answer to an empty bin, and EWM does not assume it is.
If the items are being released in waves, the wave template itself carries a control for bin denial, with three genuinely different responses: leave the item in the wave so it can be released again later, remove it from the wave so it can be reassigned, or have the system immediately create a warehouse task with an alternative source bin.
That third option is worth sitting with. If the same product is available in another bin right now, sending someone to fetch a pallet from reserve is the slower answer. Replenishment is the correct response to a pick face that is genuinely out of stock — not to a pick face that is out of stock in one bin.
This is one of the places where wave configuration and replenishment configuration overlap and nobody owns the seam. If your waves are set up to reassign on bin denial, direct replenishment may be configured perfectly and still almost never fire.
The field next to it that gets confused with it
The same wave template also carries a wave release retry interval — a value in minutes that schedules a fresh release attempt when a wave could not create all of its warehouse tasks because the stock was not there. It is not a fourth option of the bin denial control; it is an independent field, and it does nothing at all unless you give it an interval. Leave it empty and there is no automatic retry. A team that has thought carefully about bin denial behaviour and still finds waves sitting half-created is usually looking at the wrong one of these two settings.
Diagnosing It When It Does Not Fire
The complaint is always the same sentence: «direct replenishment is not working». Work through it in this order and it usually resolves before step four.
1. Is the product on a fixed bin at all? If not, stop — the method does not apply, and nothing you configure will make it.
2. Is the strategy activated on that storage type, with a warehouse process type against it?
3. What exception code did the worker actually raise, and does its internal process code point at replenishment? A worker choosing the wrong code from the list produces exactly this symptom.
4. Did the storage type search find stock anywhere it was allowed to look? If the answer is no, you are looking at a pick denial, not a failed replenishment.
5. If you expected the task on the gun: is this an RF scenario, and did the picker have an open warehouse order for it to be inserted into?
Steps 1 and 3 account for most of it. The configuration is rarely the problem; the preconditions are.
The Four Methods, One Decision
Across this series the four methods have turned out to be four answers to a single question: when should the system be allowed to notice that a pick face is running out?
Planned notices on a schedule. Automatic notices at the moment of a confirmation. Order-based notices when demand appears. Direct notices when a human tells it. Each one buys a different amount of warning, at a different cost, and the right design usually runs more than one of them at once.
The failure mode is not choosing wrong. It is choosing once, at go-live, and never revisiting it while the warehouse changes underneath. A pick face that was moderate-turnover in year one and is now the busiest aisle in the building does not tell you that its replenishment strategy has stopped fitting. It just runs out more often, and everyone gets a little better at firefighting.
Which is where this series started.
Part of the Replenishment Mastery series
Start of the series
Deja un comentario