Long-Term Planning
PP / M2Dintermediate

Long-Term Planning: Simulative Evaluation, Transfer to Operative Planning, and Production Support

Learn how to evaluate LTP simulative results, transfer selected data into operative demand management or purchasing, and troubleshoot the most common configuration and data issues that break planning scenarios in production support.

Explanation

Long-Term Planning only delivers business value if planners and MRP controllers can trust its output and act on it. This lesson focuses on the operational middle of the LTP lifecycle: evaluating simulative results, deciding what to transfer into operative systems, and keeping planning scenarios healthy over time. After a planning scenario has been created and an LTP run executed against a simulative planning version, the first responsibility of the planner is evaluation, not transfer. Stock/requirements list and MRP list style evaluations exist in a simulative-version variant so planners can inspect exception messages, coverage gaps, and capacity overloads exactly as they would for operative MRP, but scoped to the chosen version. This is critical because simulative runs frequently surface exceptions that would never appear operationally yet (for example, a new product's BOM component that has no source of supply configured only in the simulative environment). Evaluation should always precede any transfer decision, and the planner should document why a scenario is or is not ready to move forward, because that decision often feeds sales and operations planning (S&OP) sign-off meetings. Capacity evaluation in LTP typically uses the same capacity planning table and load reports used operationally, but pointed at the simulative version. Rough-cut or detailed capacity leveling can be simulated here so bottleneck work centers are identified before real orders are created. This is one of the most valuable production uses of LTP: testing whether a proposed sales plan is even executable given current or planned capacity, and doing so without generating a single planned order that operative MRP would have to unwind later. Transfer to operative planning is the step that must be handled with the most caution. SAP provides mechanisms to copy selected simulative planned independent requirements into the active (operative, version 00) demand management, and separately to transfer simulative purchase requisitions or planned orders into operative purchasing/production as a form of early procurement commitment. These are two distinct decisions: transferring demand (so operative MRP will now plan against it) versus transferring specific supply elements (so a vendor negotiation or capacity block can start immediately, ahead of the full operative MRP cycle). Many implementations only ever use the demand transfer path, running LTP purely as a feasibility and rough-cut capacity tool, and never transfer planned orders or requisitions directly; this is a deliberate design decision that should be documented in the process design, not left ambiguous, because it changes who is accountable for the resulting operative orders. Production support issues with LTP tend to cluster into a few repeatable categories. First, planning scenarios silently producing near-empty results usually trace back to a mismatch between the strategy group or planning strategy of the affected materials and what LTP requires; materials not relevant to independent requirements planning, or missing an LTP-relevant strategy, will not generate meaningful simulative demand. Second, BOM and routing selection differences between simulative and operative runs are a frequent source of confusion; LTP uses the same BOM/routing selection logic as operative MRP (validity dates, usage, alternative BOM selection ID), so a scenario created with the wrong key date or plant will pull unexpected structures. Third, planning scenarios that are never deleted accumulate over time and can cause performance and clarity problems; a housekeeping discipline of archiving or deleting obsolete scenarios after each planning cycle should be part of the standard operating procedure, since simulative data has no independent business value once its planning horizon has passed. Fourth, when a scenario run appears to hang or run unusually long compared to prior cycles, checking whether the background job scope, MRP list creation, and low-level code determination are consistent with prior successful runs usually isolates the cause faster than assuming a system-wide performance problem. In S/4HANA, classic LTP based on MRP-style simulative planning versions remains available, but organizations using PP/DS or advanced planning capabilities may perform equivalent long-range feasibility and capacity simulation using different tools; the two approaches are not automatically synchronized, so a consultant must confirm, scenario by scenario, which planning engine actually produced a given simulative result before advising a client on transfer decisions.

Real project scenario

A discrete manufacturer runs a quarterly S&OP cycle. The demand planning team submits an aggregated forecast, which is disaggregated into a simulative planning version and exploded through LTP against current BOMs and routings. The PP consultant is asked to confirm that a planned 20% volume increase on a flagship product family is executable. After the LTP run, capacity evaluation on the simulative version shows two paint booths already projected to overload in month two. The consultant works with the planning team to test an alternative simulative scenario with a shifted ramp-up curve, re-runs LTP, confirms the overload disappears, and only then transfers the demand from that approved scenario into operative demand management. No planned orders or requisitions are transferred; procurement is told separately to begin vendor discussions manually because the transfer-to-purchasing feature was deliberately not used per the client's process design.

Common mistakes

• Transferring simulative demand into operative demand management without first resolving capacity overloads flagged during LTP evaluation. • Confusing 'transfer of requirements' with 'transfer of planned orders/requisitions' and assuming one implies the other. • Leaving obsolete planning scenarios in the system indefinitely, causing confusion about which scenario is current and degrading list/report performance. • Running LTP with a key date or plant scope that silently changes BOM/routing selection compared to the intended operative baseline. • Assuming PP/DS-based long-range simulations and classic MRP-based LTP scenarios are interchangeable or automatically reconciled. • Not documenting, per implementation, whether procurement/planned order transfer is in scope, leading to inconsistent use across planning cycles.

Best practices

• Always complete stock/requirements and capacity evaluation on the simulative version before deciding to transfer anything to operative planning. • Explicitly document, per project, whether only demand transfer or also planned order/requisition transfer is in scope for LTP. • Build a recurring housekeeping task to archive or delete expired planning scenarios after each planning cycle closes. • Verify key date, plant, and BOM/routing selection settings on every new scenario to avoid silent structural mismatches versus the operative baseline. • When PP/DS or other advanced planning tools are also in use, clarify with the client which engine's simulative output is authoritative for a given decision before advising on transfer. • Capture evaluation results (exceptions, capacity overloads) as part of the S&OP sign-off record so transfer decisions are auditable later.

Interview angle

Interviewers use LTP evaluation and transfer questions to see if a candidate understands that simulation without a disciplined transfer and cleanup process creates more risk than value. Strong answers distinguish between transferring independent requirements versus transferring planned orders/requisitions, explain why capacity evaluation must happen before transfer, and describe a concrete housekeeping practice for obsolete scenarios. Being able to state, without overclaiming, how classic LTP relates (or does not automatically relate) to PP/DS-based long-range planning in S/4HANA signals genuine production experience rather than textbook knowledge.