What Multi-Level MRP Does That Reorder-Point Planning Cannot

Multi-level MRP plans a component against the demand its parents place on it, which is the one thing single-item reorder-point planning structurally cannot do. A reorder point watches an item against its own on-hand and its own consumption. It has no way of knowing that three open jobs are about to draw the same plate, because on that plate's own calendar the requirement does not exist yet. In EDGEBIC by User Solutions, the multi-level run closes that gap by exploding every parent's plan down the bill before any item is netted.

This post explains the blind spot, where dependent demand comes from, and what reorder-point planning is still good for. It sits under the EDGEBIC planning guide and builds on netting gross requirements to net requirements.

The Blind Spot in Single-Item Planning

Take one stocked item and roll its balance forward bucket by bucket. Net demand against on-hand and scheduled receipts, apply a safety buffer and a lot rule, and the calendar tells you when that item runs short. Per item, the arithmetic is correct and complete.

The problem is what counts as demand. For a purchased component, single-item planning has only the item's own history to work from. A job that is about to consume 60 of them next Tuesday is not on that item's calendar, because nothing has told the calendar about it. The component shows a gross requirement of zero, its projected balance walks along flat and healthy, no trigger fires, and no suggestion is raised.

The demand becomes visible at exactly the wrong moment: when the engine draws the stock. That is not planning. It is arithmetic on a transaction log, reported after the fact.

Independent and Dependent Demand Are Different Animals

The distinction that fixes this is old and precise.

Independent demand comes from outside the plant. A forecast for a finished good is independent demand. It is negotiable in the sense that you can argue with it, revise it, or ring a customer.

Dependent demand exists only because something else is being made. "The plant plans to start 30 pumps that day, so it needs 60 housings" is not an opinion or a forecast. It is multiplication. The only way to change dependent demand is to change the parent's plan.

Reorder-point planning treats every item as though its demand were independent, inferring it from history. For a finished good that is reasonable. For a component two levels down a bill, it is guessing at something that could simply be calculated.

Where the Requirement Actually Comes From

A multi-level run assembles component demand from three sources, and all three matter.

Planned orders explode down the bill. When the run decides a parent needs an order, that order's quantity multiplied by the quantity-per becomes a requirement on each component. Covered in detail in exploding a parent's demand into component demand.

Released orders place an allocation. A job already on the floor will draw its components whether or not the plan created it. Leaving those out would understate demand for exactly the work most certain to happen. Material already issued to the job is netted off, so a job that has drawn 20 of the 60 it needs demands the outstanding 40, not the full 60.

Committed master-schedule rows explode too. When a planner levels a build across two weeks, that commitment is as real a demand on the components as a released job. The quantity is inflated for yield first, because a plant committing to 120 shippable units at 96.5 percent yield must actually start around 125, and the components for those extra units have to be demanded or the shortfall reappears at the end of every job.

A Worked Comparison: The Plate Nobody Was Planning

One plate, 50 on hand, safety stock 25. One open, scheduled manufacturing order for 30 widgets, each widget taking two plates. Twenty plates have already been issued against that job.

Nothing about the physical plant differs between those two columns. The only difference is whether the plan knew what the job was going to take.

Two Details That Make the Allocation Trustworthy

The 40 in that table is honest for two specific reasons, and both are worth knowing.

Issued material is netted off. The 20 plates already issued to the job have left on-hand. Counting the full 60 would demand the same material twice and buy stock the plant does not need.

The date comes from the schedule, not the request. The job is dated at its earliest scheduled operation, not at the start date the planner originally asked for. When congestion pushes a job from the 2nd to the 7th, its components are needed on the 7th. Dating from the request would pull material in five days early on every job the scheduler had moved, at every level beneath it. That is the same schedule-versus-request discipline behind why material planning and finite scheduling are two passes.

What Reorder Points Are Still For

None of this makes a reorder point wrong. It makes it a policy rather than a calculation.

For consumables, fasteners, and shop supplies where the cost of holding a buffer is trivial and the cost of computing exact requirements is not, a min-max or reorder-point rule is the cheaper and better discipline. Compare the two methods in min-max vs reorder-point replenishment.

The two run side by side in EDGEBIC and can size an order differently, because they answer different questions. Net requirements answer "what does the plan actually need." A reorder point answers "what level do we like to keep." The suggestion never asks for less than the real shortage, but any excess above it is stocking policy, not a requirement. For an item you want planned purely on demand, leave it with no reorder method so the requirement stands alone.

The Change This Makes to a Planner's Day

The practical difference is when you find out. Reorder-point planning tells you an item is low. Multi-level MRP tells you an item is going to be low, names the parent that will take it, and gives you the release date you need to act on. That is the whole value: the shortage moves from something you discover to something you decide about.

To see the ordering rule that makes a multi-level run correct, read low-level codes and why every item is planned exactly once. For the fundamentals of the method itself, start from what is MRP.