A supply planner sees a forecast of 100 units and sales orders for 35 units. Should the system plan for 135 units? Sometimes those orders are already represented in the forecast. Forecast consumption is the mechanism that can prevent counting the same expected demand twice, when the selected planning strategy and settings support it.
This fictional SAP SCM exercise separates the arithmetic from system configuration. Start with the existing SAP APO demand-planning guide for planning areas and forecast creation. Here the question is what happens when an actual order arrives after a forecast has been released to the receiving planning process.
Establish the planning context first
“SAP SCM” can describe different products and planning landscapes. APO Demand Planning, APO supply planning and ERP or S/4HANA planning do not share one universal screen or consumption rule. SAP IBP also requires its own model and configuration. Name the product, receiving planning application, model or version, requirement type and strategy before applying a formula.
For this exercise, assume one product P-100, one location VIZ-01 and one planning period. The selected strategy allows eligible customer orders to consume the released forecast for that product-location within an agreed date window. All quantities use the same unit. No safety stock, stock on hand, receipts, scrap or lot-sizing constraints are included.
These assumptions make demand arithmetic visible. They do not describe a confirmed production configuration or calculate the final procurement proposal.
Worked example: thirty-five ordered units within the forecast
The original forecast is 100 units. A customer order for 35 units is eligible to consume it. The consumed portion is 35; the remaining forecast is 100 minus 35, or 65. Total demand considered in this simplified case is the 35-unit order plus the 65-unit remaining forecast: 100 units.
Adding the full 100-unit forecast to the same 35-unit order would produce 135 units and overstate this case by 35. Deleting the entire forecast would leave only 35 units and omit the 65 units still expected from other customer demand.
| Scenario | Order quantity | Consumed forecast | Remaining forecast | Combined demand |
|---|---|---|---|---|
| Eligible order inside window | 35 | 35 | 65 | 100 |
| Eligible orders exceed forecast | 120 | 100 | 0 | 120 |
| Order intentionally additional | 35 | 0 | 100 | 135 |
The second scenario uses a separate 120-unit order total. It does not add 120 to the first row’s 35. The third row assumes the business requirement and selected strategy treat that order as additional demand. A higher total is then intentional, rather than a double-counting error.
Why a sales order may not consume a forecast
Check eligibility before changing the forecast. The order may belong to another product, location, requirement category or date outside the configured consumption window. A unit conversion can also hide a mismatch. For example, a forecast in pieces and an order in boxes require the approved conversion; comparing their raw numbers is misleading.
Backward and forward consumption settings can permit demand to consume forecasts in neighbouring periods. If that is enabled, a period-level total may change while the wider horizon still reconciles. Inspect dated requirements across the relevant window instead of assuming each calendar bucket is independent.
Keep simulation and operational demand apart
Record the planning model or version containing the forecast and the version used by the receiving planning run. A forecast shown in a simulation does not prove that operational customer orders consumed it. Likewise, a copied version may contain different requirements or settings from the operational version.
When a forecast is released or transferred, record its identifier, timestamp, product-location and receiving quantity. Establish whether a subsequent release replaces, adjusts or adds requirements under the configured process. Repeatedly releasing the same plan without understanding that behaviour can create a reconciliation problem independent of consumption.
Acceptance checks for the exercise
- The 35-unit eligible order leaves 65 forecast units and combined demand of 100 under the stated assumptions.
- The independent 120-unit case leaves zero forecast units and combined demand of 120.
- The intentionally additional 35-unit order retains the 100-unit forecast and produces 135 combined units.
- A changed-date case records whether the configured window allows consumption, including any neighbouring period.
- Every result names its product-location, unit, date window and planning version; supply proposals are reconciled separately.
These are expected results for a training design, not executed system findings. Use an authorised practice environment to record actual outcomes. Discuss this case alongside Softenant’s SAP SCM training in Vizag, and confirm the products and planning scenarios covered by your batch.