---
title: "Material Requirements Planning (MRP)"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Material Requirements Planning (MRP)

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

1. **What do we need to make**, given the orders we've taken and the safety stock we want to keep?
2. **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.

1. Navigate to **Manufacturing > Planning Runs**.
2. 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.
3. 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.
4. 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`.
5. The **Demand**, **Supply** and **Planned** tabs are filled by then.
6. 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](../getting-started/working-with-lists.html#narrowing-the-list)).

## 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.

Source: https://docs.beelocity.com/en/manufacturing/mrp/index.mdx