Material Requirements Planning (MRP)

Material Requirements Planning — MRP for short — is the part of Beelocity that answers two questions on a regular cadence:

What do we need to make, given the orders we’ve taken and the safety stock we want to keep?
What do we need to buy, given the components our work orders will consume?

An MRP run is a snapshot. It captures demand and supply at a moment in time, walks every product from the highest level of the BOM tree down to raw materials, and produces two outputs: planned orders (proposals to create new supply) and action messages (advice on existing supply that no longer lines up with demand). The planner reviews the output, converts the proposals they want into real work orders or purchase requisitions, and ignores the rest.

When to run MRP

Most teams run MRP on a regular cadence — weekly is typical, often as an overnight batch. Trigger an ad-hoc run when:

A new sales order with an aggressive due date arrives and you need to know whether you can hit it.
A purchase order is delayed and you want to see which downstream work orders are at risk.
You’ve just released a batch of new BOMs and want to recompute the levels of the items they touch.
A planner is starting a new shift and wants the latest picture of “what’s late, what’s expediting, what’s in surplus”.

By default, a run starts on demand from the Planning Runs page; most businesses schedule it as an automatic overnight task.

Creating and running a run

Beelocity splits run creation from run execution so you can stage parameters, review them, and run later — useful for long runs that need a quiet window or for queueing a Net change run alongside the standard nightly Full one.

Navigate to Manufacturing > Planning Runs.
Click New. The Run page opens with editable defaults pre-filled:
- Run # — auto-generated as MRP-YYYY-MM-DD-XXXX. Override it if you want to group a planned series (e.g. MRP-WEEKLY-2026-W19).
- Type — Full re-plans every item; Net change only re-plans items whose demand or supply has changed since the last run.
- Horizon (days) — defaults to 90. Set it to cover your longest cumulative lead time plus a buffer.
- Demand Time Fence (days) — defaults to 7.
- Planning Time Fence (days) — defaults to 30. Must be at least as large as the demand fence and at most the horizon.
Click Save. The run lands in Pending with no snapshots yet — it is configuration and nothing more, and you can still correct the windows on it.
Open the ⋮ menu and click Execute when you are ready. Beelocity snapshots demand, snapshots supply, recomputes BOM levels and walks every item from the top down; by the time the page answers, the run has finished and the road reads Completed.
The Demand, Supply and Planned tabs are filled by then.
A run that stopped stays Failed, with what stopped it on the Overview tab. Fix the data behind it — a recipe that refers to itself, a missing recipe — and press Execute again: the same run starts over, so there is no second run to keep track of.

The run’s road

A road runs along the bottom of the run’s page: Pending → Running → Completed. It is the one road in Beelocity with no button beside it, because the run walks it by itself — hover Running and it says so. Starting the run is Execute in the ⋮ menu, and that is the only push it needs.

Two statuses sit off that road and are picked from the map behind the current word:

Cancelled is the one a planner takes, and only while the run is Pending or Running. A cancelled run cannot be resumed — raise a new one.
Failed is the run’s own way of saying it stopped. It is not the end of it: Execute takes a failed run again once the data behind it is sound.

Hover a step to read when the run reached it and who moved it. Starting the run carries your name; everything after it is the run’s own work and carries none.

The Planning Runs list filters by Status (the Failed and Running runs are the ones to look at first), Type, Horizon, Active or a Started / Finished date range (Working with lists).

Reading the output

Every tab of the run narrows on its own filter button: Demand and Supply by Source, Product, a Qty range or a Due / Available date range; Planned by Type, Status, Product or a quantity, date, level or priority range — Type = Planned purchase, Status = Open is the set the Promote actions work on.

The summary

The Summary card on the Overview tab is the at-a-glance view:

Demand lines — how many demand records the run snapshotted.
Supply lines — how many supply records the run snapshotted.
Planned orders — how many proposals the engine emitted.
Action messages — how many pieces of advice on existing supply.
Deepest level reached — how deep the BOM tree went. A typical assembled product run reaches level 3–5; raw-material-only runs stay at level 0–1.

Demand and Supply tabs

Two read-only views of the snapshots.

The Demand tab shows what the org owes the world: open sales-order lines, safety-stock targets, and dependent demand from manufactured items at higher levels. Each row carries a source (Customer order, Safety stock, Dependent), a quantity, and a due date.

The Supply tab shows what the org expects to have available: on-hand stock (less reservations), open purchase-order lines, active work orders, and in-transit transfers. Each row carries a source (On hand, Purchase order, Work order, Transfer), a quantity, and an available date.

Planned tab

This is where the work happens. Each row is one of two things:

A planned order — a proposal to create new supply. Planned production for items with an active BOM (we’d manufacture); Planned purchase for items without (we’d purchase from a supplier).
An action message — advice on existing supply: Reschedule earlier (move it forward), Expedite (pull it in inside the planning fence), Cancel (no longer needed because demand evaporated).

The grid is sorted by level (lowest first — the deepest raw materials) and then by priority score (lower = more urgent). Convert the rows you want at the top of the list first.

“Why was this proposed?”

Every planned order carries a pegging trace — the chain of demand records that drove it. Click the why? button on a row to open the trace. You’ll see the sales orders, safety-stock targets, or dependent-demand records (from higher-level planned WOs) that contributed to this need, with their own quantities and dates. This is the answer to “why is the engine asking me to make 47 of these?” — it’s the literal demand chain.

Time fences

Two fences guard short-horizon stability. Both are configurable per run.

Demand-time fence (default 7 days)

No demand record dated inside the next 7 days produces a new planned order. Sales orders dated this week are still satisfied from on-hand stock if available, but they don’t create new work orders. The reasoning: anything that close to today is execution territory, not planning. If you need to react to a same-day order, do it manually through the Work Orders page.

Forecast demand inside the fence is dropped entirely.

Planning-time fence (default 30 days)

Existing supply (POs, WOs) inside the next 30 days is held constant. The engine may emit Expedite action messages — “your supply is too late, try to pull it in” — but it will not propose Reschedule earlier or Reschedule later against a supply record inside the fence. The reasoning: rescheduling something already in execution is more disruptive than the demand savings, so the engine should be quiet about it.

You can shrink either fence per run if you want a more aggressive plan. Most teams leave the defaults alone.

Converting plans

Once you’ve reviewed the Planned tab and decided which proposals to act on, click the Promote button on each row you want. There’s no target-type picker — the engine already knows what the row should become:

Planned purchase rows become a draft Purchase Requisition (one requisition per Promote click, one line on it). The line copies the planned quantity, unit, and due-date hint; the suggested supplier on the plan brings an estimated price from the last purchase price recorded for that supplier, so the planner has a starting number to refine. The requisition is created with priority Normal — edit it afterwards if you want to bump it up.
Planned production rows become a draft Work Order using the BOM and routing the engine suggested. The work order’s source reads Planning run, so you can trace it back to this run.

You don’t pre-create the destination — the requisition or work order is created in the same step and the promoted plan is back-linked to it. The plan row flips from Open to Converted and the Document column on that row becomes a link straight to the new document.

Rows on the Planned tab are listed alphabetically by product name across all pages, so suggestions for the same item stay together as you scroll. Use the search box to jump to a specific product.

Promoting several proposals at once

Fifteen components proposed from the same supplier do not need fifteen requisitions. Tick the rows instead — the checkbox on each row, or Select all rows on this page in the header row — and the top edge of the tab counts what you have picked and puts the two promotions beside the count:

Promote to requisition gathers every planned purchase in the selection into one draft purchase requisition, a line per proposal. Each line carries the quantity, unit, due-date hint and estimated price a row-by-row Promote would have written; the header takes the earliest of their due dates as its required date — today, if that date has already gone by — and the same Normal priority. Header and lines are written together: if anything stops the requisition, nothing is created and every row stays Open.
Promote to work orders creates one draft work order per planned production row in the selection, each on the BOM and routing the engine suggested — the same documents as promoting the rows one at a time. A proposal whose BOM has no routing attached is passed over, so read the count Beelocity reports back rather than assuming one work order per row.

A selection can hold both kinds — a run over an assembly and its components produces both — and then both buttons are there. Each acts only on the rows it applies to and leaves the rest Open, so you can gather the purchases into a requisition first and come back to the production proposals. Action messages, and rows already Converted or Ignored, are passed over.

Promotion rules

A few details that aren’t obvious from the button:

One row, one downstream document — with one exception. A single Promote creates exactly one requisition (for a planned purchase) or one work order (for planned production). Only Promote to requisition, on a selection, gathers several proposals into one document; planned production becomes one work order per row however you promote it.
Requisition priority is always Normal at creation. If you need a different priority, open the requisition afterwards and change it on the header. Per-line urgency stays driven by the planned order’s due date regardless.
Action-message rows aren’t promotable from here. They’re advisory — the engine is telling you to expedite, reschedule, or cancel an existing purchase order or work order, not to create a new one. Act on the underlying document directly, then mark the action message Ignored if you want it off the list.
Partial-quantity conversion is not supported. A plan is converted in full or not at all. If a planned purchase of 1000 units needs to be split between two suppliers, promote it once, then edit the resulting requisition (delete the line or change its quantity); the next MRP run resurfaces the uncovered remainder.
Plans don’t carry priority into promotion. The Planned tab is sorted by level ascending then priority score ascending (lowest score = most urgent), but Promote does not enforce that ordering — you can promote a low-priority row before a high-priority one. The sort is a recommendation; the planner can override it using domain knowledge MRP doesn’t have (a flagship customer, a long-lead supplier).
Pegging is purely informational. Clicking why? on a row shows the demand records that drove the proposal but does not affect promotion mechanics — it’s there to help the planner decide whether the proposal makes sense.

A promotion is one-way — once a plan is Converted, subsequent runs treat the linked work order or requisition as supply (so duplicate plans don’t appear) and the planner can’t unconvert. To redo a promotion, cancel the downstream document first; the next MRP run will surface the demand again.

What about the proposals you don’t want?

Each Open row has an Ignore button in the Decide column (next to Promote, when promotion applies). Click it to drop the row to Ignored. Action-message rows only show Ignore — they’re advisory, so you act on the underlying purchase order or work order directly, then Ignore the advisory to clear it from the list.

For planned orders you’ve decided not to act on, the same Ignore action works. Be aware that the next run will likely propose them again — MRP is stateless across runs, so unless the underlying demand changes, the same plan will reappear. Use Ignore for one-off rejections, not as a way to permanently squash a recurring proposal.

Expired is not a user action. The engine stamps it automatically on a previous run’s plan when a later run supersedes it. You’ll see Expired rows when browsing historical runs, but no button on the Planned tab produces this state.

Common pitfalls

Forgetting to keep BOMs up to date. MRP only recurses through manufactured items that have an active BOM. If a part has no BOM, the engine treats it as purchased and emits a Planned purchase even when the team intends to make it. Activate the BOM before running.
Running before the supply snapshot is settled. If you trigger MRP just before goods receipts complete, the in-transit stock won’t be counted yet and you’ll see false Planned purchase rows. Save the run for after end-of-day stock processing.
Ignoring action messages without reading them. Expedite and Cancel are advisory — but they’re advisory because the engine spotted a real misalignment between supply and demand. Always read the message before clicking Ignore.
Treating MRP output as gospel. MRP is a planner’s tool, not an autopilot. The engine has limited context (no supplier capacity, no machine breakdowns, no holiday schedules), and its proposals are starting points. Expect to ignore 5–10% of rows in any run.
Running too aggressively on the time fences. Shrinking the demand fence to 0 days will cause MRP to propose work orders for tomorrow’s sales orders — which is rarely realistic given lead times. Keep the fence at or above your shortest cycle time.