Bills of materials

Watch the lesson: Build a bill of materials (2:46).

A recipe for something you make: what goes into one unit, what that costs, and how far ahead each component has to be ordered. Everything the planner does downstream reads from here.

Plan.

Bills of materials 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.

This is not the same as inventory assemblies.

If you are on Business or Enterprise you already have simple assemblies under Inventory — one level, build on demand. Nothing about that changes. Bills of materials is the deeper thing: many levels, planning parameters, where-used, and a cost roll-up that MRP and procurement both read.

Create a recipe

Bills of Materials → Recipes → New recipe
Pick the product this recipe makes. A product can carry more than one recipe — an older revision and its replacement, or a variant built from different parts — so use Make default on the one MRP should plan against. The Issues tab names any product with two recipes in force and no default.
Give it a version and an output per run
Output per run is how many units the listed components produce. If the sensible way to write your recipe is "this makes 100 litres", say 100 rather than dividing everything by a hundred to make it read per-unit.
Add the component lines
Each line is a stock item and a quantity per output. A component may itself have a recipe — that is what makes the bill multi-level, and Ledgr follows it down.
Set the build lead time on Item Planning
How long the make itself takes, in days, is the finished product's Lead time (days) on the Item Planning tab. MRP subtracts it when it works out the date a job has to start for the finished goods to exist when they are needed. It lives there rather than on the recipe so there is one lead time per item for MRP to read.
Date a component line if a part changes
On the Explosion & Cost tab, Edit line gives each component line a Used from and Used until date. Use them when a formulation or a supplier part changes on a known date: end the old part's line the day before and start the new part's line on the day, and planning before that date uses the old part and after it the new one.

Approval and change control

A recipe decides what every build consumes and what every finished unit costs, so putting one into force is a second person's decision rather than the author's. A recipe carries one of four states:

State	What it means
Draft	Being written. Nothing can be built from it, and MRP does not plan from it unless a run is explicitly told to include unapproved recipes
Awaiting approval	Submitted, and in somebody's queue. Its own state rather than just "draft", so a workshop with forty recipes can tell half-finished from ready-for-review
In force	The one builds consume and MRP plans against
Archived	Retired. A recipe that has been built from is archived rather than deleted, because it is the record of how those units were costed

The author writes it and submits it
Creating one straight into force is refused unless you hold the approve permission. The trail records who submitted it and when.
Somebody holding the approve permission on bills of materials decides
A rejection needs a reason, and the recipe goes back to draft carrying it. A rejection with no reason is what makes an approval step resented — the author learns only that somebody said no.
Changing what a live recipe consumes needs approval again
Editing the components, the output quantity or the labour and overhead of a recipe that is in force is refused — otherwise the step is bypassed in three ordinary edits. Fixing its name or its notes is not, because refusing a typo fix would teach people to archive and recreate, which destroys the costing history.
Taking one out of force needs approval too
Which looks odd until you notice that an author who could de-activate a recipe could take it out of force, change it freely and submit it back.

There is deliberately no rule against approving your own.

A three-person workshop with one engineer would never get a recipe into force, and a control that makes the product unusable gets switched off rather than obeyed. The answer is not to grant the approve permission to the person who writes them — see roles & users. Both actors are recorded either way.

Simple assemblies are unaffected.

This step exists because you have the Manufacturing plan. On Business or Enterprise the Assemblies editor under Inventory behaves exactly as it always has, and a recipe you already had in force is left as it was — Ledgr does not stamp an approver on it, because that would be inventing a signature.

Explosion & cost

The Explosion & Cost tab answers two questions at once: what does one unit actually consume once every sub-assembly is followed down, and what does it cost.

Explosion flattens the whole tree. A component that appears at three different levels is shown at each, and totalled.
Cost roll-up prices that explosion from each component's planning cost on Item Planning — or its cost price, where no planning cost is set — and adds the labour and overhead on the recipe, giving a unit cost you can compare against the price you sell at.
Where used is the same question backwards — given a component, which recipes consume it. Run it before you discontinue a part or accept a price increase.

Circular recipes are refused, not tolerated.

If A is built from B and B is built from A, exploding either would never terminate. Ledgr detects the cycle and names the products in it rather than running out of memory.

Item planning

The Item Planning tab is where each stock item is told how it should be replenished. MRP plans from these, so a blank planning record is the usual reason a planned order does not appear where somebody expected one.

Make or buy — whether a shortfall becomes a work order or a purchase.
Lead time — days from ordering to having it on the shelf. For a bought item this is the supplier's; for a made item it is how long the build takes.
Safety stock — the cushion you never intend to eat into. MRP plans to stay above it, not to reach it.
Reorder point — the product's own reorder point, the same figure as on the product in Inventory. For an item with no safety stock set, a run keeps projected stock above it (the Treat reorder points as safety stock run option, on by default).
How much to order — exactly what is short, a fixed batch, up to a maximum, or several periods at once; then the supplier's minimum order quantity and order multiple on top, so a plan does not ask for 7 of something sold in boxes of 12.

While items are still unconfigured, Set all as bought and Set all as made classify them in one go rather than one at a time — on a first setup that is the difference between an afternoon and a week. An item that has a recipe of any status is left for you to decide rather than set as bought.

Issues

The Issues tab is the pre-flight check. It lists what would make a plan wrong before you rely on it: items marked "made in-house" with no recipe to make them from, loops in the structure, items in a recipe with no planning record, products with more than one recipe in force and none marked default, and lead times of zero that will quietly plan everything for today.

Fix issues before the first MRP run, not after.

An MRP run against an incomplete bill does not fail — it produces a confident plan that is missing things. The Issues tab exists so the first run is worth reading.

Common problems

What you see	What to do
"Putting a recipe into force needs approval"	Submit it instead, and somebody holding the approve permission puts it in force. A recipe decides what every build consumes and what every finished unit costs, so crossing into force is a second person's decision.
Taking a recipe out of force is refused	That needs the approve permission too, and the reason is not symmetry: an author who could de-activate a recipe could take it out of force, change it freely and submit it back — the approval step bypassed in three ordinary edits.
"This recipe is in force, so changing what a build consumes needs …"	The components, the output quantity and the labour and overhead are substance. The name and the notes are not — you can always fix a typo in a recipe's name without re-approval.
Editing a submitted recipe sent it back to draft	Deliberate. The approver must not end up approving something other than what they were shown, so an edit clears the submission and the signature it no longer describes.
"Say why you are sending it back"	A rejection needs a reason. Without one the author learns only that somebody said no, and resubmits the same recipe — which is how an approval step comes to be resented.
"A recipe with no components cannot be put into force"	Add at least one component. The same applies to submitting for approval.
"That would make the product a component of itself"	The chain is printed for you. A cycle would make the cost roll-up recurse for ever.
"… is not stock-tracked, so a build has nowhere to put …"	The finished good has to be a stock-tracked product, because a build produces units that go somewhere and are valued.
A build is refused for stock	A short build is refused rather than costed at list price, and the refusal names what is short and how many can be built now.
The finished good cannot be changed on an existing recipe	Correct — moving a recipe to another product would silently restate every build already costed against it. Raise a new recipe.
"in force since before approvals existed"	Nothing was backfilled, because backfilling an approver would be inventing a signature. The recipe works exactly as it did; the next change to its substance goes through approval.
A submitted recipe is missing from a planning run	It should not be — Plan from unapproved recipes under Material Planning's Options means draft or submitted. If a component is genuinely absent, check the Used from and Used until dates on its line.