MRP Fails to Create a Planned Order

The planner reports it as the report is wrong, not that a job failed. Typical phrasing: the material shows a shortage in the stock/requirements list but there is no planned order underneath it, or we ran MRP last night and this line still shows zero coverage even though the sales order or the dependent requirement from the parent assembly is clearly there. Sometimes it surfaces as the shortage list stays red across multiple MRP runs, or a buyer notices a purchase requisition never appeared for a component that used to convert automatically. It is rarely reported as an error message, because MRP does not throw an error when it decides not to plan something. It just goes quiet on that material, and the business only notices when the shortage reaches the shop floor or the customer due date.

Pull MD04 for the material/plant and capture the requirement line with its date and quantity alongside the absence of any planned order or requisition beneath it. Cross-check the timestamp in MD21 for that material's planning file entry against the timestamp of the last completed MRP run; a planning file date older than the last run proves the material was never picked up. Where relevant, also capture the MRP type and special procurement key screenshot from MM03 as supporting evidence for the specific branch of cause.

If the planning file entry is missing, this is a data correction: rebuild it via the reorganization program or set it manually and rerun MRP for that material; no transport needed. If the MRP type, lot size, or special procurement key is simply wrong for this material, that is a master data change in MM02, done per material or in bulk via mass maintenance, again no transport. If the firming horizon or planning time fence value itself is wrong at the plant or MRP group level, that is a configuration parameter change requiring a transport and sign-off, since it affects every material planned under that group, not just the one in question. If the root cause sits in the checking group or requirements class setup, that is shared SD/MM configuration; changing it affects availability checks across other materials and order types too, so it goes through the configuration change process with SD involved, not a quick fix owned by the planner alone. Deletion flag or follow-up chain issues are master data corrections but need coordination with whoever set the discontinuation, since reversing it blind can create duplicate demand.

The reflex fix is to manually create the planned order in MD11 or simply raise the purchase requisition by hand, and call the shortage resolved. This clears the immediate red line but leaves the underlying planning file, MRP type, or requirements transfer problem in place, so the same material goes missing again on the next run and every subsequent requirement for it has to be caught manually. A close second is inflating safety stock to force MRP to react, which does not address why the system failed to see the real requirement and quietly builds excess stock everywhere else the buffer applies.

First line ownership sits with the material planner or PP master data team, since planning file rebuilds and MRP type or lot size corrections are within their authority. If the cause traces back to requirements class or checking group configuration, ownership shifts to the SD/MM configuration team because that object is shared across sales order types. The handover note should carry material, plant, MRP area if used, MRP run date and time, planning file entry status, and the MM03 screenshot of the relevant MRP views.