What is MRP? Material requirements planning explained

What MRP actually is

MRP — material requirements planning — is the calculation that turns what you have promised to deliver into what you must buy and make, and when. It starts from demand (released sales orders and plans), explodes the multi-level bill of materials to find the gross requirement for every component and raw material, nets those requirements against stock on hand and supply already on order, and outputs a time-phased answer: purchase requisitions for the bought-out shortfall and production demand for the items you make yourself.

Without MRP, planning is guesswork dressed as experience: the storekeeper buys what ran out last time, production discovers a missing bracket the morning it is needed, and working capital sits in material nobody currently needs. With MRP inside an integrated ERP, every requirement descends from a real order through a real BOM and is netted against real stock — so the purchase list is exactly the gap between promise and possession, no more and no less.

The three inputs MRP needs

MRP is only ever as good as its three inputs, which is why it belongs inside the ERP rather than beside it:

• Demand — the released Order Acceptances and the sales plan: what has been promised, in what quantity, for when.
• Structure — the multi-level BOM and BOR for each ordered item, including which lines are made and which are bought, with lead times from the item master.
• Supply — free stock on hand from the store ledger, plus open purchase-order quantities not yet received (pending = ordered − received on each PO line).

Notice that all three already live in the ERP: demand in sales, structure in the BOM, supply in stores and purchase. That is why an MRP run in Fast ERP needs no imports and no reconciliation — the calculation reads the same tables the transactions wrote.

Step one: the BOM explosion

The explosion walks the BOM from the ordered finished item downwards, multiplying quantities at each level. An order for 100 assemblies where each assembly carries 4 brackets generates a gross requirement of 400 brackets; if each bracket consumes 0.5 kg of sheet steel, the explosion carries on to 200 kg of sheet — level by level, down to raw material. Every figure it produces is traceable upwards: this sheet requirement exists because of that bracket, because of that assembly, because of that order.

Because the explosion is level-wise, intermediate stock matters. If 30 of the brackets are already on the shelf, the explosion does not need to plan sheet for them — which is where the second step comes in.

Step two: netting gross to net

Netting converts gross requirements into net requirements by subtracting what you already have or have already arranged:

Netting is the step that separates MRP from naive list-multiplication. It is also why stock accuracy is a planning issue, not just a stores issue: if the ledger says 30 brackets exist and the bin holds 12, MRP will under-buy with complete confidence. One store engine recording every receipt, issue, transfer and reservation — as in the Fast ERP Production & Planning and stores modules — is what keeps the netting honest.

Step three: the outputs — buy and make

What comes out of the run splits along the make-or-buy character of each item:

A worked example, end to end

MRP vs reorder-level planning

MRP is not the only way to trigger buying, and it is not always the best one. The older, simpler mechanism — the reorder level — watches stock instead of orders: when an item falls to its reorder point, a requisition fires. The two suit different kinds of demand, and a real factory runs both.

The practical rule: put standard hardware and consumables on reorder levels so nobody plans them at all, and let MRP govern everything whose demand descends from orders. Both mechanisms end in the same place — a purchase requisition entering the same approval chain — so purchasing sees one queue regardless of which logic raised it.

From plan to schedule: machine loading

A material plan says what and when; it does not say where the hours will come from. That is the bill of resources' half of the story. Because Fast ERP carries the BOR and process sheets alongside the BOM, planned work lands on real machines and the Gantt-style machine loading view shows each resource's committed hours against its capacity. A plan that overloads the VMC by forty hours next week is visible before the week starts — and the planner can shift, split or subcontract while it is still cheap to do so.

This is also where MRP quietly improves delivery honesty: when sales asks for a date, the answer can come from a plan that has already seen material lead times and machine load, rather than from optimism.

How Fast ERP runs MRP

Fast ERP implements the whole loop described above inside one database:

• Demand from released orders — the approved Order Acceptance, with BOM-against-OA explosion carrying the order's identity through every requirement.
• Plans as working documents — production plan, sales plan, raw-material plan and component plan reports that state requirement, coverage and shortfall.
• Two buying triggers — PR-against-BOM from the explosion, and reorder-level driven PR generation for run-rate stock, both feeding one approval chain.
• Capacity on a Gantt — machine loading against the resource master, so the schedule respects hours as well as material.
• Closed loop — goods receipts, inspections and work-order completions post back to the same ledger the next run nets against.

Because planning, purchase, stores and production share the schema, an MRP shortage does not become an email — it becomes a requisition with an approval trail, then a purchase order, then an inspected receipt, with quality gates standing between the calculation and the shelf. That is MRP as a working nervous system rather than a monthly report.

Frequently asked questions