# Time Fences in Supply Planning

> Site directory and reading guidance: [llms.txt](https://wiki.skusavvy.com/llms.txt).

Canonical URL: https://wiki.skusavvy.com/article/time-fences-in-supply-planning
Published: 2026-11-04T16:08:32.022Z
Last updated: 2026-11-04T16:31:23.273Z
Category: Supply Chain

> This article is AI-assisted reference material. Verify important or time-sensitive claims against the cited sources; AI review does not establish independent factual verification.

## Overview

A **time fence** is a boundary within a planning horizon that separates periods governed by different planning rules. In supply planning, time fences help balance responsiveness to new demand against the cost and disruption of changing production, purchasing, and distribution commitments. The [ASCM supply chain dictionary](https://www.ascm.org/learning-development/certifications-credentials/dictionary/) provides terminology used across the profession, while [Oracle's master scheduling documentation](https://docs.oracle.com/cd/E18727_01/doc.121/e15188/T478564T478850.htm) describes time fences as planning-system controls.

Near-term plans are commonly subject to tighter controls because materials may already be ordered, production capacity reserved, or orders released. Plans further into the future can usually be adjusted more freely. A time fence is not necessarily an absolute prohibition: its effect depends on system configuration, organizational policy, and who has authority to approve exceptions. Product documentation, including [Dynamics 365 coverage settings](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/coverage-settings), shows that vendors may expose several differently named fences rather than one universal control.

## Etymology and Origins

The term combines *time*, referring to a position on the planning calendar, with *fence*, a metaphor for a boundary across which different rules apply. A **demand time fence** generally distinguishes periods in which different demand inputs are used; a **planning time fence** generally distinguishes periods in which the planning system has different authority to recommend or make changes. Exact definitions and system behavior vary, as reflected in the [ASCM dictionary](https://www.ascm.org/learning-development/certifications-credentials/dictionary/) and [Oracle's scheduling terminology](https://docs.oracle.com/cd/E18727_01/doc.121/e15188/T478564T478850.htm).

The metaphor arose in the context of formal production and inventory planning and master scheduling. A definitive first documented use of the phrase has not been established here, so an inventor or earliest date cannot be assigned reliably. It should not be confused with a physical warehouse barrier or with a contractual deadline, although a fence may be designed around contractual commitments.

## Historical Development

Time fences developed alongside master production scheduling and material requirements planning (MRP). Before computerized MRP, planners relied heavily on manual records and periodic calculations to coordinate inventory, orders, and production. In the 1960s, [Joseph Orlicky and IBM's work on MRP](https://www.ibm.com/history/material-requirements-planning) helped formalize computer-assisted calculations of material needs and order timing. Orlicky is widely associated with that development; the work should not be reduced to a single company or a precisely dated invention.

In 1975, Orlicky's *Material Requirements Planning: The New Way of Life in Production and Inventory Management* helped disseminate MRP principles. As computerized planning expanded in subsequent decades into manufacturing resource planning (MRP II) and enterprise resource planning, planners gained more systematic ways to manage the frequency and consequences of schedule changes. Time-fence policies addressed a recurring problem: recalculating a plan can produce different recommendations even when changing an imminent order is costly or impractical.

Warehouse data capture also evolved. The [first commercial scan of a UPC barcode, later administered within the GS1 system, in 1974](https://www.gs1.org/standards/barcodes/history) was an important milestone in automated identification and eventually improved the transaction data available to inventory and planning systems. Modern [master planning systems](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/master-plans) use current demand, inventory, and supply information to generate recommendations, although the names and behavior of their controls differ by product.

## Core Concepts

A planning horizon runs from the current planning date into the future, often in daily or weekly buckets. A fence may be expressed as a number of days from that date or as a calendar boundary. As time advances, a rolling fence moves with it. [Master plans](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/master-plans) define planning scope and horizon; separate item, site, or process settings may determine how specific changes are treated.

A commonly taught master-scheduling arrangement uses two boundaries and three zones:

- **Inside the demand time fence:** booked customer orders generally drive the master schedule. Forecast may be ignored or already consumed, depending on the forecast-consumption rules.
- **Between the demand and planning time fences:** forecast and actual demand are commonly combined by a defined rule, such as using the greater of the two. The master scheduler, rather than an automatic planning run, is typically expected to control changes.
- **Beyond the planning time fence:** the planning system may create or revise planned supply from forecast and other planning data with fewer restrictions.

These rules are a professional convention, not a universal algorithm. [Oracle's master scheduling documentation](https://docs.oracle.com/cd/E18727_01/doc.121/e15188/T478564T478850.htm) and [Dynamics 365 coverage settings](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/coverage-settings) show product-specific controls, which may include freeze, forecast, planning, or other fences. A frozen period is a policy description, not a guarantee that no authorized user can change an order. Planners should check whether a fence applies to creating orders, rescheduling, cancellation, capacity changes, or only selected recommendations.

### Illustrative example

Suppose a manufacturer sets a demand fence at 14 days and a planning fence at 28 days. Under its chosen policy, booked orders drive the schedule through day 14, a defined combination of orders and forecast applies from day 15 through day 28, and the system may replan more freely after day 28. A sudden order due in 10 days may trigger an exception and an approval decision rather than an automatic production change. These numbers are illustrative, not standard settings.

For a concrete decision, suppose the order is for 100 units and only 40 are available. The planner can assess whether to offer a partial shipment, move another commitment, or approve an expedited supply change for the remaining 60. The fence identifies the review requirement; it does not itself create capacity or determine which customer receives stock.

## Applications and Implementation

Manufacturers may protect near-term production schedules where changeovers, labor assignments, or purchased components make revisions expensive. Distributors can use analogous rules to manage replenishment and supplier commitments. Purchasing execution, such as [purchase order management](https://www.skusavvy.com/purchase-order-management), records and processes the resulting buying decisions; it should not be assumed to calculate a time fence merely because it manages purchase orders.

A practical implementation starts by grouping items or supply lanes with similar characteristics, then setting boundaries around meaningful lead times and decision points. Inputs include supplier lead time, production cycle time, transport time, cancellation terms, and the latest feasible date for changing capacity. [Stock replenishment workflows](https://www.skusavvy.com/docs/guides/warehouse/stock-replenishment) act on inventory needs after planning decisions are made; they are related execution processes, not evidence of a particular planning-engine time-fence algorithm.

Planners should document which transactions are protected, which recommendations remain visible, who may override a fence, and how exceptions are escalated. The policy should be tested against late customer orders, supplier delays, and sudden forecast changes. A documented [purchase-order approval workflow](https://www.skusavvy.com/docs/guides/vendors/purchase-order-approval) can govern who may release a purchasing change, but it is not itself a time-fence feature.

Before deployment, agree on the date convention—including working versus calendar days and whether the boundary day is included—and verify it in the chosen planning system. Record whether each test proposes a change, suppresses it, or permits a manual override. A separate execution system's [test mode](https://www.skusavvy.com/docs/guides/test-mode) may support workflow testing where that product provides it; it does not substitute for testing the planning engine.

## Benefits, Limitations, and Best Practices

A well-designed fence can reduce schedule instability, unnecessary expediting, and repeated changes to committed orders. It also clarifies when sales, procurement, and operations must agree on a change. An overly long frozen period can make the plan slow to respond, while an overly short one can generate frequent, costly revisions. [Oracle's planning controls](https://docs.oracle.com/cd/E18727_01/doc.121/e15188/T478564T478850.htm) should therefore be interpreted together with actual operating constraints.

Recommended practices include:

1. **Set differentiated fences.** Long-lead or capacity-constrained items may need different settings from readily available products.
2. **Maintain reliable data.** Review lead times, inventory accuracy, open orders, and calendars before relying on automated recommendations.
3. **Define exceptions.** Specify approval authority and customer-service priorities for changes inside protected periods; record the reason, approver, and resulting action.
4. **Measure outcomes.** Track schedule changes within the fence, override frequency, expedites, service performance, and excess inventory. Distinguish system-generated changes from approved manual changes.
5. **Review settings periodically.** Reassess boundaries when suppliers, lead times, capacity, or demand patterns change.

Inventory records used in these decisions should be reconciled with warehouse execution data. [Cycle counting](https://www.skusavvy.com/docs/guides/warehouse/cycle-counting) can identify quantity discrepancies that would otherwise distort available-to-promise and replenishment calculations. No single fence length is appropriate for every product or organization.

## Source links

- [ASCM Supply Chain Dictionary](<https://www.ascm.org/learning-development/certifications-credentials/dictionary/>)
- [Oracle Master Scheduling and MRP Documentation](<https://docs.oracle.com/cd/E18727_01/doc.121/e15188/T478564T478850.htm>)
- [IBM: Material Requirements Planning](<https://www.ibm.com/history/material-requirements-planning>)
- [GS1: History of the Barcode](<https://www.gs1.org/standards/barcodes/history>)
- [Microsoft Dynamics 365: Master Plans](<https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/master-plans>)
- [SkuSavvy Purchase Order Management](<https://www.skusavvy.com/purchase-order-management>)
- [SkuSavvy Stock Replenishment Guide](<https://www.skusavvy.com/docs/guides/warehouse/stock-replenishment>)
- [SkuSavvy Cycle Counting Guide](<https://www.skusavvy.com/docs/guides/warehouse/cycle-counting>)
- [SkuSavvy Purchase Order Approval](<https://www.skusavvy.com/docs/guides/vendors/purchase-order-approval>)
- [SkuSavvy Test Mode](<https://www.skusavvy.com/docs/guides/test-mode>)
- [Microsoft Dynamics 365: Coverage settings](<https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/coverage-settings>)