MD62 — Change Planned Independent Requirements
MD62 is used to create, change or delete planned independent requirements (PIRs) for a material at a plant, entering forecast or planned quantities against dates in a requirements schedule. These records feed MRP as demand and are consumed by sales orders depending on the material's strategy group. The critical structural fact: PIRs live under a specific version, and only the active version is read by MRP.
This page covers MD62, the transaction planners use to maintain planned independent requirements that drive MRP demand for make-to-stock and planning-with-final-assembly scenarios. It focuses on the version, requirements type and consumption logic that most often makes entered quantities silently invisible to MRP, and on the tables to check when a planner insists numbers were saved but nothing happened downstream.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,188 words
Purpose
MD62 lets a planner create, change or delete planned independent requirements for a material-plant combination, entering quantities against dates in a requirements schedule (daily, weekly, monthly or individual dates). These PIRs represent forecast or planned demand that is not tied to a specific sales order and gets picked up by MRP as gross requirement. The structural fact that causes most confusion: every PIR belongs to a version. Version 00 is normally the active version that MRP actually reads; inactive versions exist for simulation and are invisible to the planning run. A planner can enter and save perfectly valid-looking quantities in MD62 against the wrong version, or against a requirements type that no longer matches the material's current strategy group, and see nothing happen in MRP or in the stock/requirements list.
When it is used
MD62 sits at the front of the demand-to-supply cycle, before the MRP run. Planners use it to load a sales forecast, a production plan or a rolling demand signal for materials produced to stock (strategy 10/40 and variants) or for planning with final assembly. It is also used after go-live corrections, when actual consumption diverges from plan and PIRs need adjusting or reducing rather than left to expire naturally. Reach for MD61 instead when creating a brand-new plan from scratch across a wider horizon in one shot; reach for MD04 afterward to see whether the PIR actually reduced or increased the requirements picture. On S/4HANA, the Fiori app for managing planned independent requirements covers the same function with a different entry layout, but the underlying logic is identical.
How to use it in practice
- Enter material, plant and the requirements plan (version) to work against
- Choose the entry mode: total requirements per period, or a detailed requirements schedule with individual dates
- Select the period pattern (day, week, month) matching how the planner wants to see the horizon
- Enter or adjust the quantity in each period column, or edit existing schedule lines directly
- Save; the system writes or updates the independent requirement header and schedule line records for that material, plant and version
Key data objects
- PBIM - header record per material, plant, version and planning strategy; one row identifies the independent requirement object that the schedule lines hang off
- PBED - the requirements schedule lines themselves, holding the date and quantity fields for each period entered against a given PBIM header
- Material master (planning views) - supplies the strategy group and requirements type default that determines how a new PIR is classified when created
- MRP live cache / planning file entries - the material-plant combination is flagged for the next MRP run once a PIR changes, so the run picks it up without a manual net-change flag
How to prove it in the data
In SE16, pull PBIM filtered on material and plant to find the header rows and note which version and requirements type each one carries. Join to PBED on the internal key from PBIM to see the actual dated quantities. If a planner claims an entry was saved but MRP ignored it, compare the version on the PBIM row against the version MRP was run with, and compare the requirements type on the row against the requirements type currently implied by the material's strategy group in the material master planning view. A mismatch on either explains the symptom without needing to touch the MRP run itself.
ECC vs S/4HANA
The underlying tables and consumption logic are unchanged on S/4HANA; MD62 still works as a classic GUI transaction. A Fiori app for managing planned independent requirements provides an alternative entry screen for the same function, generally preferred in new implementations for its list-based editing, but it writes to the same header and schedule line structures. Organizations running an external planning tool such as IBP typically stop maintaining PIRs directly in MD62 and instead let the integration write them, which changes the operational habit more than the transaction itself.
Common pitfalls and how to diagnose them
- Wrong or inactive version: the planner enters and saves against a version that is not the one MRP reads. Check the version field on the PBIM header before assuming the MRP run is broken.
- Requirements type mismatch: the strategy group on the material was changed after older PIRs were created, so surviving records carry a requirements type that the current strategy no longer consumes. Old PIRs sit unconsumed while new sales orders behave as if no forecast exists.
- Zero instead of delete: setting a period quantity to zero leaves a schedule line record in place rather than removing it; some downstream reports still count a zero-quantity line differently from an absent one. Use the explicit delete function on the line, not a zero entry, when the intent is to remove demand.
- Consumption not happening: sales orders are not reducing the PIR because the consumption mode, consumption period (backward/forward) or the strategy's consumption indicator is not set the way the planner assumes. This looks identical to a version problem in MD04 but the fix is in the strategy configuration, not in MD62.
- Wrong planning object: for configurable materials or planning at a higher-level planning material, PIRs entered directly on the sales material never reach the components because planning is meant to happen against the planning material or a characteristics-dependent object. Confirm which object the strategy expects before assuming the entry itself is at fault.
- Closed period or planning calendar gaps: MD62 will refuse or silently skip periods outside the maintained planning calendar or a closed fiscal period; check the calendar assignment before assuming a data entry error.
Whose problem this is
Functional, owned by demand planning or PP master data. ABAP involvement is rare and limited to custom validation logic on save. A clean handover states the material, plant, version and strategy group involved, the period range affected, and whether the issue is an entry that did not save correctly or one that saved but was not consumed or picked up by MRP.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/md62ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.