If you work on ERP integrations, you will meet MRP sooner or later. It is worth understanding exactly what it computes, because its blind spot explains a lot of support tickets from the shop floor.
Take an illustrative snack maker. The master production schedule says week 3 needs 11,000 cases of a 200 g pack. That figure came from a 12,000-case forecast, minus 2,000 in stock, plus a 1,000-case buffer.
MRP now runs three steps:
- Explode the BOM. Each case needs 24 pouches of film, so 11,000 cases need 264,000 pouches.
- Net against stock. There are 64,000 pouches on hand, leaving 200,000 to buy.
- Offset by lead time. The supplier needs two weeks, so the purchase order releases two weeks before week 3.
Clean, deterministic, and correct. Now notice what is missing. Nothing in that calculation checks whether the packing line can run 11,000 cases in that week alongside everything else. Nothing knows that two big orders share a due date and pile onto Tuesday. Nothing prices the changeovers between flavours. MRP assumes infinite capacity and fixed lead times, on purpose.
Most ERPs add a rough-cut capacity check by work center and week. It might say packing is at 90%, which looks fine, while one day inside that week is badly overloaded. RCCP tells you a week is too full. It does not tell you which order to move.
Takeaway for developers: if you are building reports or alerts on ERP data, do not treat MRP planned orders as a schedule. They are material timing. A schedule needs a finite model where every resource has a calendar and setups are sequence-dependent. Label your dashboards accordingly and you will avoid a whole class of confused users.
That finite layer is what our finite capacity production scheduling accelerator adds, reading from the ERP and writing back only approved plans.
Full comparison of MPS, MRP and APS: MRP vs APS vs MPS: What Each Layer Decides
Top comments (0)