Material Requirements Planning (MRP)

Software that runs material requirements planning: it explodes the production plan through multi-level bills of material, nets the result against stock on hand and open orders, and turns what remains into purchase and production proposals with dates, using each item’s lead time. MSF MRP takes its dates from the finite-capacity APS schedule rather than fixed lead times, and the proposals your buyers approve flow to the ERP as purchase orders.

Classic ERP MRP uses fixed lead times and infinite capacity. MSF MRP is driven by the finite-capacity APS schedule, so dates are realistic.

It creates proposals that your buyers approve, and approved proposals flow to your ERP as purchase orders.

Yes, subcontracted operations and materials supplied to subcontractors are fully supported.

Five things: bills of material that match what is actually built, on-hand stock that matches the shelf, lead times that were measured rather than inherited, open purchase and work orders with due dates somebody still believes, and scrap, yield and lot-sizing rules. Stale open supply is the quiet one, because it covers a requirement that is not really covered. Before go-live, list every open order due in the past and force a reschedule-or-close decision.

Not in the way you need it to. MRP nets requirements against on-hand and open supply, so if on-hand is wrong the answer is wrong in both directions at once: ordering material you already have, and staying silent about material you do not. Cycle counting on the items that carry most of the value is a prerequisite and cannot wait for a later phase.

A full run overnight, plus targeted re-runs after a schedule change or a late delivery. More frequent is not automatically better: every run re-plans against new information, and a required date that moves every morning gives a buyer nothing to act on. Inside a frozen horizon, settle whether proposals stop being recalculated at all or are still recalculated and merely flagged when they drift, because the two behave very differently for the person working the list.

Yes, standalone against your ERP. You keep multi-level BOM explosion, netting against on-hand and open supply, supplier calendars and minimum order quantities. What you lose is schedule-driven dates: requirement dates fall back to fixed lead-time offsets, so they are exactly as good as the lead times somebody typed in, and they do not move when the shop floor slips.

It makes no commercial decisions. It proposes quantities and dates; it does not negotiate price, it does not choose between suppliers beyond the inputs you configured (preferred supplier, price break, lead time, minimum order quantity, calendar), and it does not forecast demand, which has to come from your sales plan. It also cannot see material consumed on the floor but never booked, which is the usual reason a proposal looks wrong.

A daily pass over the exception list, sized by how many items you plan and how wide you set the exception horizon. A glance at a dashboard is not enough. The run produces expedite, de-expedite and cancel messages, and the value lives in someone deciding which of them matter and acting the same day. Where that step is skipped, the list grows until nobody opens it and the system gets called noisy.

Effectivity dates govern what new explosions use; orders that are already open are not affected. A released order carries the component list it was issued with and is not re-exploded, so pulling a change into it means re-issuing the order or amending it by hand. Check which date drives the effectivity test (creation, release, planned start or required date), because that choice decides whether a change lands on a given order at all.