Material planning (MRP)

Watch the lesson: Run material planning and raise work orders (2:00).

Answers one question for every item you stock: given what is on the shelf, what is already on order and what has been promised to customers, what must I make or buy, and when.

Plan.

Material planning is included from Manufacturing upwards. See pricing.

On Business and Professional it can be bought on its own as the Bills of materials, planning & production add-on at R899/mo, which covers recipes, work orders, routings, WIP and standard costs. Procurement and the supplier workspace stay on Manufacturing.

Before the first run

MRP is arithmetic over your own data, so it is only as good as three things you set up first:

Recipes for everything you make
See bills of materials, and clear the Issues tab.
Item planning on every component
Make or buy, lead time, safety stock, order multiple. Without these MRP has no basis for a date or a quantity.
Demand it can see
Open quotes are firm demand automatically, dated by their expected delivery date, and so are the components of work orders already open. An invoice is not: by the time one is sent it has already taken its stock, so planning to replace it would buy the goods twice. A request a customer sends from the ordering portal counts as soon as it arrives, before you have priced it, and the plan marks it customer request, not yet priced. Your own unsent draft quotes count only when you tick Count your own draft quotes. Anything you expect but have not quoted yet goes in on the Demand tab as a forecast — see below.

Run the plan

Material Planning → Options, then Run plan
Options sets the horizon — how far ahead to plan — the bucket size and what the run includes. Run plan runs it. A run does not change anything on its own; it produces suggestions you then accept or ignore.
Read the planned orders
Each row is "make this / buy this, this much, starting this day". The start date is the need date less the lead time, so an order dated in the past is telling you it is already too late — that is a signal, not a bug.
Check the time-phased grid
Per item, per period: opening stock, demand, supply and projected closing balance. It is the clearest place to see a shortage building three weeks out while today still looks comfortable.
Use pegging to ask "why"
Every planned order can be traced back to the demand that caused it — Why on the row, or the Pegging tab. Before you commit money to a suggestion, peg it — the answer is sometimes a single quote you already know has fallen through.

Act on the suggestions

A planned order is a suggestion. Each row on Planned Orders carries its actions.

Pin freezes the order so the next run leaves it alone. Do this when the decision is made but the paperwork is not raised yet.
Convert — tick the rows and press Convert — turns them into the real thing: a work order for a make item, a purchase request for a bought one. From there it lives in procurement or on Production.
Drop dismisses a suggestion you have judged wrong. It will come back on the next run if the underlying demand is still there, which is usually the right behaviour.

Work orders

Converting a make recommendation raises a work order. From that point it belongs to Production — its Work orders tab is where it is released, worked and completed. Material Planning shows the open count, not the list.

Release
The order moves from planned to released — it is now expected to happen, and the recipe is pinned to it so a later change to the bill does not silently rewrite an order already on the floor.
Complete
Enter how many were actually built. Ledgr consumes the components from stock and receives the finished units in, at the rolled-up cost. You can complete part of an order and come back to the rest; it stays in progress until the full quantity is done.
Cancel
Abandons an order that has not been completed. A completed one is reversed rather than cancelled, so that the stock movements it made are reversed too.

A completion you do not have the components for is refused.

Ledgr names each short component with what the order needs and what is on hand, and the whole completion is unwound — no stock moves and nothing is received in. It is a refusal rather than a warning because the alternative is worse than negative stock: the finished units would be created in full while the missing components were costed at list price, parting the stock valuation from the inventory account by the difference, with no entry that could ever close it. Adjust the components in, or complete the quantity you actually built.

Make it or buy it

Each product carries the answer, and MRP reads it rather than deciding: a make item becomes a work order and consumes its recipe's components, a buy item becomes a purchase requisition against its approved suppliers. Two things about the buy side change the quantity MRP suggests, and both come from the supplier rather than from you:

Minimum order quantity and order multiple. Suggesting 30 of something sold in cases of 24 is suggesting something nobody can buy, so the quantity is rounded up to something orderable and the row says what it was rounded to.
Lead time. The start date is the need date less the lead time, which is why a supplier whose lead time is wrong produces a plan that is wrong in a way no amount of re-running fixes.

A product with no recipe and no approved supplier can be planned for and not sourced: MRP will tell you what is needed and has nothing to convert the suggestion into. That is the commonest reason a firmed order produces nothing.

Forecasts

Demand you expect but have not sold. A forecast is entered per item per period and is treated as demand by the run, which is how a seasonal build-up gets planned before the orders arrive. Forecasts are yours to maintain — Ledgr does not invent them, because a number the system made up is worse than no number when it drives purchase commitments.

Run history

Every run is kept on the Run History tab with its horizon, what it included — including whether it planned from unapproved recipes — and how many orders it recommended. Open an older run to see what it recommended then; comparing it with today's is how you find out why the plan moved.

Common problems

What you see	What to do
A run produced nothing	MRP plans from demand. With no open quotes, no forecast and no reorder points, there is nothing to plan for — which is the honest answer rather than a fault. Check the horizon covers the dates your demand sits in.
A planned order is dated in the past	A signal, not a bug: the start date is the need date less the lead time, so a past date is telling you it is already too late to order normally. Expedite, or move the promise.
A suggestion you dropped came back	The demand behind it is still there. Drop dismisses the suggestion, not the reason for it — usually the right behaviour, and pegging tells you which order is driving it.
A pinned order converted into nothing	A make item needs an active recipe, and a buy item needs an approved supplier. Ledgr names which is missing. A draft or pending recipe is refused — see bills of materials.
MRP planned from a recipe you have not approved	Only if you asked it to — Options → Plan from unapproved recipes, and the run's history row records that it was ticked. The option covers drafts and recipes submitted for approval, because a planner ticking it would otherwise get a plan missing exactly the ones somebody is waiting on. Converting such a suggestion into a work order still needs the recipe approved.
A work order was raised for more than you planned	Correct. The planned quantity is what the job must deliver; the route's expected yield decides how many to start, applied once, at release. See Production.
The open work order count does not match what you can see	Material Planning shows the count; the list lives on Production. There is deliberately one list rather than two — two lists are two numbers to reconcile.
Capacity is not considered	By design. MRP plans infinite capacity: it tells you what is needed and when. Whether the factory can do it is Production's Capacity tab, which is a separate question with a separate answer.