Supply Chain & InventoryFree calculatorPDF, Excel, Word export

MRP Planning Time Fence Calculator

Time fences stop MRP from rescheduling work that is too close to execute. Set them too short and the plan nervously churns; set them too long and you cannot respond to demand. This calculator gives a defensible starting point from your lead times.

Your numbers

28 days
10 days
5 days
days
days

Your results

Cumulative lead time (stacked)
45 days
Longest path assumed to be sequential; use the critical path if parallel
Suggested demand time fence
7 days
Inside this, MRP ignores forecast and only uses firm orders
Suggested planning time fence
45 days
Inside this, MRP does not auto-create or move planned orders
Demand time fence in weeks
1 weeks
Planning time fence in weeks
6.4 weeks
Share of horizon inside the planning fence
25%

A starting point. The right fences reflect how changeable your orders are, supplier flexibility and how much planner attention you have. Test any change in a simulation plan first.

Save results:

Time fence review

Optional: have your item level fences compared with real lead times from your ERP.

Optional. The tool and every export work without this. No spam.

How to use it

Enter the lead time of your longest purchased component, your subassembly manufacturing time and final assembly time, plus any ship and test buffer. The calculator adds them into a cumulative lead time, suggests a demand time fence from the final assembly stage, and a planning time fence as a share of the cumulative lead time. Pick 100 percent for stable supply chains, lower values where suppliers are flexible.

What the fences do

The demand time fence separates the period where only actual customer orders drive MRP from the period where forecast also counts. The planning time fence separates the frozen zone, where planners must manually change orders, from the zone where MRP can create and reschedule planned orders on its own. Many ERPs call these the firming, frozen or fixed zone, and apply them at item or MRP group level.

  • Inside the demand fence: firm orders only.
  • Inside the planning fence: manual changes only.
  • Beyond the planning fence: MRP is free to move planned orders.

Reading the output

If the planning fence covers most of your horizon, MRP will not generate new orders for most of the plan, so planners must act on exception messages by hand. That is correct for long lead time items but burdensome for short ones. If the demand fence is shorter than the real production time, last minute orders will disrupt the shop floor.

Common mistakes

Setting every item to the same fence ignores lead time differences. Using calendar days for fences while lead times are in working days shifts the numbers by about 40 percent. And leaving fences at zero in ERP is common: MRP then reschedules everything on every run, causing nervousness that planners learn to ignore.

Frequently Asked Questions

What is the difference between a demand time fence and a planning time fence?

The demand time fence controls which demand MRP considers, firm orders only versus orders plus forecast. The planning time fence controls whether MRP may create or reschedule supply orders automatically inside that window.

How long should a planning time fence be?

A common rule is the cumulative lead time of the item, or a percentage of it for flexible suppliers. Items with fixed tooling or long supplier commitments often use the full cumulative lead time.

Do time fences affect forecasts?

Yes. Forecast consumption and inclusion generally stop at the demand time fence, so only customer orders count inside it. Beyond the fence the larger of forecast and orders, or the sum, applies depending on your setup.

Where do I set time fences in my ERP?

In most systems they live on the item or material master or an MRP group: for example the planning time fence field in SAP MRP views, or the time fence fields on the Oracle item planning attributes. Check your own version.

Netray can review exception message volumes in your ERP and show where fences are too tight or too loose, using read-only queries.