qtraca.com

A production plan turns the part of a demand plan you make into a list of works orders: one product, one quantity, one date to start. It also plans the things that go inside those products — the custard in the tart — which the demand plan never mentions, because no customer orders custard.

Where to find it: Production Planning in the Demand Planning section of the main menu, or step 3 of the Planning Cycle.

The words used here

Quick start

1. Activate a demand plan. Production cannot be planned from a draft.
2. Press Generate Production Plan on that demand plan, or Generate production plan on step 3 of the Planning Cycle. A draft plan appears.
3. Read the plan. Check the Notes column and the priorities, and look for anything dated today that should have started earlier.
4. Press Approve plan. That is what lets procurement be worked out from it.
5. Press Generate Procurement Plan (or Work out what to buy on the Planning Cycle) to get the buying side.
6. Use Create Batch on a line when you are ready to make it.

Generating a plan

Nothing creates a production plan on its own. You ask for one, from either of two places:

• On the demand plan, the Production plan card — “Turns planned demand into what has to be made, and when.” — and its Generate Production Plan button.
• On the Planning Cycle, step 3’s Generate production plan.

The demand plan has to be active. While it is a draft the button is disabled and reads “Activate the demand plan before generating production from it.” The work runs in the background: the button reads “Generating production plan…” until it finishes, and a second press answers “A production plan is already being generated for this plan.” rather than making two.

A failure shows “Could not generate.” and the reason. The one that catches people out is “Production planning is switched off in Forecast Settings.” — the switch stops production plans being made at all, by hand as well as on a schedule, and the Planning Cycle shows a blocker saying so. Every reason, and what to change, is in Running your weekly planning cycle.

Generating again is safe. A new plan arrives as a draft beside the approved one, which stays in force. Approving the draft is what replaces the old one. If the generation fails, the approved plan is untouched and the error sits next to it.

Why the early weeks may have grown

A production plan is built from the demand plan’s net requirement, so anything that changes that requirement changes how much you are asked to make. One change in this update does, and it is worth knowing before you compare a new plan with an old one.

An order now counts as supply in the week it arrives, not in week 1. Purchase orders and deliveries used to be counted once, in the first week of the horizon, whatever their expected date — so a delivery due in week 8 made week 1 look covered and nothing was planned for it. Expect requirements to rise in the early weeks on the first plan after this update, and to fall in the weeks the material actually lands in. It is the same supply, put where it can be used.

Three consequences follow from that one rule, and they show up on this plan as works orders appearing, moving or disappearing:

• An overdue order counts now, in the first week — it is not going to arrive any later than it already has. Works orders you expected to see raised against an overdue delivery will not be raised; the overdue warning is raised instead.
• An order landing between two of the plan’s weeks counts in the next week that exists. A plan holds only the weeks a product has demand in, so its weeks are not always one after another.
• An order arriving after the plan’s last week counts for nothing in this plan, so the work to cover that week is planned. Nothing is lost: the order returns to the reckoning as soon as the horizon reaches it.

The full rule is in When an order counts as arriving.

The plan list

Production Timeline (Next 4 Weeks) sits above the list. It shows up to ten works orders due in the next four weeks, soonest first, with the product, the planned date, the quantity and the status, and each row opens its plan. It shows only what this site is actually working to: works orders on the approved plan, and works orders already being made. A draft plan’s lines and a replaced plan’s idle lines are not in it. When there is nothing in the window it reads “No upcoming production scheduled.”, and if the read fails it says “The production timeline could not be loaded.” rather than showing an empty window.

The list below it shows each plan’s Plan Ref, Plan Date and Status. A cancelled plan stays on the list with its badge, so you can see that a plan was replaced rather than wondering where it went.

Reading a plan

Above the table a line reads “Total planned: 1,200 EA · 300 L” — the plan’s non-cancelled lines, one total per unit. Litres are never added to kilograms, because the sum would mean nothing. A cancelled works order is not part of what the plan is making, so it is left out of the total.

What the notes mean

A note with no works order of its own to sit on — a recipe loop is one — is written to the plan’s own Notes rather than dropped. Read the plan header as well as the lines.

How sub-assemblies are planned

This is the part that surprises people, so it is worth reading once. Other articles link here rather than repeating it.

The demand plan only knows what customers want: finished goods. Everything you make on the way there — the custard inside the tart, and whatever the custard itself is made from — appears nowhere in it. So after listing the finished goods, planning walks down the recipes and adds a works order for each made component that is short.

It goes all the way down, not one level

• Each ingredient that is something you make and that has a current recipe is opened up into its ingredients, level by level, until only bought items are left.
• A made component with no recipe is neither made nor bought. A finished good or work-in-progress item is something you make here, so with no active recipe there is nothing to explode and nothing to order: the plan records “CUSTARD is made here but has no active recipe, so it can be neither made nor bought” and leaves it out. Buying it, which is what earlier releases did, raised a purchase order for something nobody sells you. Publish a recipe, or set the item up as a stock item with a supplier if you really buy it in.
• Up to ten levels. A recipe that reaches itself, directly or through another, is walked once instead of looping for ever — and the plan now names the product in its notes rather than quietly coming out short. See A recipe that contains itself.
• If the plan already has a line for a component in its own right, that line is opened up instead, so its ingredients are never ordered twice.

A component used at two levels is made once, for both parents

Some components appear more than once in the same tree. A base is an ingredient of the tart, and it is also an ingredient of the custard the tart takes — so the tart needs it twice over, once directly and once through the custard.

Such a component is now planned at the deepest level it is used at anywhere on the plan. By the time it is opened up, every parent above it has already added its need to the one figure, so it is made once, in the quantity the whole plan wants, netted once against the one tank of stock, and its own ingredients follow from that single figure.

What you may have seen before. Components used to be opened up as they were met. The first parent’s need produced a works order and the component was marked done; the second parent’s need for the same thing arrived afterwards, found it already dealt with, and was left in the requirements looking like something to buy. The symptom was unmistakable once you knew it: a part-made product of your own on a purchase order, a works order sized for one parent out of two, and none of that component’s own ingredients ordered for the half that had gone missing. Worse, whether it happened at all depended on which ingredient the parent’s recipe happened to list first — not something a planner sets, or can see. If you recognise that, it is fixed, and it was this.

A recipe that contains itself

Where a recipe reaches itself — directly, or through another recipe that comes back round — the explosion stops at the loop rather than following it. It has to: there is no bottom to reach.

That means whatever sits under the loop is planned once, and the quantities above it are whatever the loop happened to allow. Nobody can tell that from the numbers, which is why the plan now says it in as many words. Look for this in the plan’s notes:

CUSTARD is an ingredient of itself, directly or through another recipe: the explosion stops there rather than following the loop, so the recipe needs fixing

Treat it as a data fault, not a warning to live with. Until the recipe is corrected, that branch of the plan is understated by an amount nothing on the screen can tell you. Previously it produced no message at all — the sub-assembly simply came out short.

A sub-assembly is netted across the plan, and made a week at a time

Two works orders each wanting 900 litres of custard in the same week, against 1,249 litres in the tank, are short 551 between them — not covered twice over. Requirements are added up across the whole plan first and only then netted against stock; netting line by line is the mistake that makes a material requirements calculation quietly under-order, and it stays invisible until a second line appears.

What comes out of that netting is then split into one works order per week its parents need it, rather than one enormous batch for a whole horizon of custard nobody can store:

• A week at a time. Each week’s parents get their own works order, dated to start before the first of them that week.
• Never more than its shelf life keeps. A works order is never made to cover a need further ahead than the product stays good for. Where a week’s batch makes more than that week needs, the surplus carries into later weeks — but only while it is still in date, and the week that benefits says so: “Less 40 L made by the batch for w/c 14 Sep.”
• Stock covers the earliest weeks first. What you already hold is spent on the nearest need, not spread thinly across the horizon.
• A sub-assembly you also sell is sized from what is left after its own sales. It gets its own demand plan lines like any finished good; the works orders for its parents are sized from the stock those lines have not already claimed, so it is neither planned twice nor left short.

Make Time chains the dates down the levels

A sub-assembly’s works order is dated the date the level above needs it, less that product’s Make Time. Its own ingredients are then wanted by that date, not by the finished good’s — which is what makes a chain sequence itself however deep it goes:

A tart wanted on the 20th, with a 2-day custard inside a 3-day base: the base starts five days before the tart. Nobody had to enter that; it falls out of the two Make Times.

This is also why Make Time matters on the buying side: the ingredients of a sub-assembly inherit the sub-assembly’s start date as their Required By, which then sets their Order By on the procurement plan. A Make Time left at zero on a product that takes a week to make pushes every order for its ingredients a week too late.

Nothing is ever dated before today

Working back from a date that is already close can land a start date in the past, which is a date nobody can work to. Those are pulled forward to today, and the line says so in its Notes rather than looking like an ordinary plan that happens to make the custard after the tart. When that happens the ordering the plan was built to guarantee no longer holds, so read those notes before you start the week.

Separately, a works order whose planned date passes while it is still unstarted raises a warning on the Planning Cycle — “N works orders are already late” (or “CODE is already late”), with “Wanted 10 Sep. Make these first.” That is about time passing since the plan was made, not about how the plan was built.

How many lines a plan has

One line per product, per period of the demand plan, plus one line per short sub-assembly. A twelve-week horizon covering six products produces around seventy-two lines — not one line per batch you will eventually run.

This matters because a line is a unit of work, not a unit of recipe. A line asking for 400 kg of a product whose recipe makes 4 kg a run is one batch with a recipe multiplier of 100, not a hundred separate batches. The multiplier is worked out for you when you create the batch.

The exception is equipment capacity. Where the product’s stock policy sets a Max Batch Qty, the requirement is split into as few batches as that limit allows — filling each to the limit, with the remainder in a final batch:

Split lines for a finished good are spread across the days of their period, so they do not all land on the Monday. A limit below the recipe’s own yield cannot be honoured without a fractional recipe, so the yield becomes the floor and the line says so.

A plan running to thousands of lines is a sign something is wrong — most often a max batch size set far below what the equipment really holds, or a recipe whose yield is a fraction of a real run.

Creating a batch from a line

Use Create Batch on a line. QTRACA builds the batch for you rather than opening an empty form: it takes the line’s product, the recipe the line was planned against, the packaging and process currently set on the product, and works out the recipe multiplier from the planned quantity — converting the line’s stock unit into the recipe’s unit on the way.

Three things then happen together:

• The new batch opens.
• The line is linked to that batch and moves to scheduled.
• If the plan was approved, it moves to in progress — the first batch starts the plan.

Create Batch is offered only on an approved or in-progress plan, and only for a works order that is still planned and has no batch yet. On anything else the server refuses:

• “PP-P1000004 is draft; batches can only be created from an approved or in-progress plan.” — a batch from a draft pre-empts a decision nobody has made, and a batch from a cancelled plan duplicates what its replacement is already planning.
• “This works order was cancelled; a batch can only be created for a planned works order.” — approving a newer plan trims the old one by cancelling its unstarted works orders while the plan itself stays in progress for the batches already running, so a live plan can hold a cancelled works order. Making it would bring back production the new plan already covers.
• “Batch already exists for this production plan line” — a line produces one batch, and Create Batch stops being offered once it has.

After any refusal the screen shows the reason and re-reads the plan, so what you are looking at is the server’s version rather than a stale one.

From there you are in the batch, picking its ingredients. If your site takes ingredients from more than one location — a freezer as well as the production floor — see Where a batch takes its ingredients from.

If the line’s unit has no conversion to the recipe’s, the batch is refused rather than scaled by a guess: a batch built on the wrong multiplier is a wrong batch on the floor.

Approving a plan

Approve plan is on the plan itself. Approving means two things:

• This is the plan the floor works to, and batches can be created from its lines.
• Procurement can now be worked out from it. Nothing else is triggered — approving is approving.

One approved production plan per site. Approving a draft never fails because of another plan. Every other approved or in-progress plan on the site is resolved in the same step, and what happens to it depends only on whether anything is actually being made from it:

The confirmation says exactly what will happen before you agree to it:

Approve PP-P1000006
“PP-P1000006 becomes the production plan in force. PP-P1000004 is cancelled. PP-P1000005 keeps 2 works orders already in production; its 10 unstarted works orders are cancelled. Their procurement plans that have not raised purchase orders are superseded.”
Buttons: Approve plan / Cancel

The old refusals — “is already in production; complete or cancel it first” and “is already completed for this demand plan” — are gone. They asked you to tidy up an old plan before you could act on the new one, which in practice meant the site worked to a plan nobody had approved. Real production is never taken off the floor: a works order with a batch keeps going whatever happens to the plan around it.

One refusal remains, and it is about the demand plan behind the draft: a production draft generated from a demand plan that is no longer active cannot be approved, because it was worked out from demand nobody is planning to. Activate that demand plan, or generate a fresh production plan from the one in force.

On the Planning Cycle, a newer draft waiting beside an approved plan shows as “A newer draft (PP-…) is ready to approve”, and the step’s Approve plan acts on the draft, with the same confirmation.

Cancelling a plan

Cancel plan is offered on a draft, an approved plan and one in progress. It asks first:

Cancel production plan
“Cancel PP-P1000004? Its works orders that have not started are cancelled, and its procurement plans that have not raised purchase orders are superseded. Purchase orders already raised stay open.”
On a plan in progress, one more sentence: “Batches already started from this plan are not cancelled.”
Buttons: Cancel plan / Keep plan

• Works orders that have not started are cancelled with the plan. There is nothing to make them for.
• Its procurement plans go with it. Draft and approved procurement plans generated from it are superseded, so nothing goes on buying for production nobody is making. A procurement plan that has already raised purchase orders, or has been completed, stands — those orders exist, and the confirmation names them on the procurement side.
• Batches already started are not cancelled. Cancelling the plan is a planning decision, not an instruction to the floor. Deal with the batches themselves — and they keep reporting back to their works orders, so the plan goes on showing what was really made.
• Cancelled is terminal. A cancelled plan cannot be reopened, and batches cannot be created from its lines: the server answers, for example, “PP-P1000004 is cancelled; batches can only be created from an approved or in-progress plan.”

Line capacity

Each works order is planned on the production line its product’s stock policy names at this site; a product whose policy names none keeps no line. The Line column shows it. On a draft plan you can move a works order to another line, or to No line, with the drop-down in that column. Once the plan is approved its lines are fixed like every other field, and the server says so: “PP-P1000011 is approved; its lines can only be changed while it is a draft.” A line belonging to another site is refused with “Production line is on another site”.

The Line capacity panel adds up, for each line and each day, what the plan asks that line to make, and compares it with the line’s Capacity per day. It is worked out fresh each time the plan is read, so moving a works order changes it at once. Only lines that this plan actually puts work on are listed, and cancelled works orders are left out.

Under those messages is a table with Line, Capacity a day, Day, Planned and the over-by badge — one row per line per day it has work on. A line whose works orders were all undated or left uncounted has no day to show, so it appears only in its sentence above the table, not as a row in it.

A capacity check that could not be read says so. Where the panel cannot be loaded it is replaced by “Line capacity could not be checked, so overloads and uncounted works orders are not shown here.”, or by the server’s own reason where it gave one. A missing panel would read as “no capacity problems”, which is a different thing entirely — every overload, refusal and uncounted works order above would be hidden at once. Assigning a line still works while the panel is down: the Line drop-down is loaded separately.

The line follows the work: a batch created from a works order is recorded against that works order’s line as its scheduled production line.

Exporting a plan, and its activity

Export CSV in the plan’s toolbar downloads the plan as a spreadsheet file named for the plan (for example PP-P1000011.csv), one row per works order, quantities in each line’s own unit. The file is built on the server, so it is the same file whichever screen asked for it, and a line the grid has paged past is still in it. Quantities are rounded to three decimal places and dates written as 2026-10-06, so a spreadsheet sorts them correctly. Accented product names survive being opened in Excel, and a text value that starts with =, +, - or @ — even behind a leading space — is written with a leading quote so the spreadsheet reads it as text instead of running it as a formula. Numbers are never touched, so a negative adjustment stays a number you can add up. If the download fails the screen says “The CSV could not be exported. Try again, or ask your administrator.”

The production export carries Product, Description, Planned date, Week start, Week end, Planned qty, Actual qty, Unit, Production line, Priority, Status, Batch and Notes, ordered by planned date.

The Activity panel at the foot of the plan lists When, Who and What — newest first, and in your account’s time zone rather than the reader’s, so an entry reads the same for everyone:

Generating a plan runs as a background job, so its Created entry shows System in the Who column rather than the person who pressed Generate. Everything done on screen — approving, starting, completing, cancelling and assigning a works order’s line — names the person who did it. A plan with nothing recorded reads “Nothing recorded yet.” — which is what a plan made before this release shows, because the trail starts when it was built and is not filled in backwards. A panel that could not be read says “Could not load the activity:” with the reason. The panel shows a plan’s history, not a paged log: the most recent 200 entries.

Plan status

Start and Complete in the header are record-keeping. They move the plan along so the list reflects reality. Completing a plan — by hand or by itself — also supersedes its draft and approved procurement plans: purchases worked out for production that is finished are stale.

Works orders follow their batch

Once a works order has a batch, it reports what the batch is doing rather than waiting for somebody to type it in:

• Actual Qty shows what was made, and follows the batch — including a release that is later undone and re-made at a different quantity.
• A works order with a batch is never “already late” on the Planning Cycle. It is being made; the warning is for works orders nobody has started.
• A plan completes itself when its works orders finish. You do not have to remember to press Complete.
• Once a plan is completed its works orders stop following their batch. A completed plan is the record of what that week made, and it must not change afterwards. A cancelled plan is different: its batched works orders are real production on the floor, so they go on reporting until they finish.

Working out what to buy

The Procurement plan card at the top of the plan reads “Explodes the production plan through recipes into what has to be bought.” Press Generate Procurement Plan — or Work out what to buy on step 4 of the Planning Cycle.

• The plan must be approved. On a draft the button is disabled and reads “Approve the production plan before generating procurement from it.”
• The button reads “Generating procurement plan…” while it runs; a second press answers “A procurement plan is already being generated for this plan.”
• Pressing it again later creates another draft beside the approved procurement plan. Approving that draft supersedes the older one.
• A plan that has been completed or replaced cannot generate procurement, and neither can its procurement plan be approved or turned into purchase orders. The answer names the plan to use instead — “PP-P1000004 is completed; generate procurement from the production plan in force.”, or “PP-P1000004 has been replaced by PP-P1000006; generate procurement from PP-P1000006.” Work from the plan in force, or the same need is bought twice.
• Generation gives up after ten minutes rather than spinning for ever: “Generation did not finish within 10 minutes. Try again.”

What it then does with the recipes — the netting, the safety buffer, the order multiples and the minimums — is in Procurement Plans.

Availability and permissions

• Production Planning is part of the Demand Planning module, which requires Manufacturing and Orders. See Getting started with Demand Planning.
• Plans are scoped to your current site.
• A site is not a security boundary. The site selector decides which site’s plans you are looking at and working on, and it keeps another site’s out of your way. It is a working scope, not a wall: a user who can open this screen and change site can read that site’s plans. The real boundary is the account — nothing belonging to another account is reachable at all. Do not use sites to keep figures from a colleague; use roles.
• Viewing is open to administrators, production managers and users, QA managers, dispatch managers, demand planners and production planners.
• Approving, cancelling, editing and creating batches need an administrator, production manager or production planner.
• Generate Procurement Plan is checked against procurement instead: an administrator, production manager or procurement planner.
• Generate production plans must be on in Forecast Settings, or generation fails with the reason.

Things to know

• Only draft plans can be deleted. Once approved, a plan is part of the record — cancel it instead.
• Expect the early weeks to ask for more, once. Orders now count as supply in the week they arrive rather than all in week 1, so work that a distant delivery used to hide is planned where it is needed. See Why the early weeks may have grown.
• A component used at two levels is made once, for both parents. If you have ever seen one of your own part-made products appear on a purchase order, with none of its ingredients ordered, that was this — and it is fixed.
• Countable products are planned in whole units. A product measured in each or cartons is never planned as 12.4; and where a batch has to over-make to reach a whole run, the surplus is carried into later weeks while it is still within shelf life, with “Less 40 EA made by the batch for w/c 14 Sep.” on the week that benefits.
• Lines are edited only while the plan is a draft, and only a works order that is still planned. Once the plan is approved it is what the floor is working to, so the figures stay put; the plan’s own Notes can still be changed while it is live.
• The recipe version is pinned to the line. Publishing a new recipe version later does not retrospectively change a plan built against the old one.
• Priority is advisory. Nothing sequences batches from it. What does carry real sequencing is the planned date, which Make Time sets.
• A finished good with no recipe is still planned, with “WARNING: No active recipe found for this product” on its line. It can be neither made nor bought until a recipe exists — nothing is ordered for it — so treat that note as a setup problem rather than a plan problem.
• A shelf life shorter than the Make Time is named on the works order. “CUSTARD keeps 2 days but takes 3 days to make: it will have expired before it is used.” The works order is still planned; the note is there because the recipe or the policy is wrong, not the plan.
• When a plan cannot be loaded the screen says “The production plan could not be loaded.” with a Try again button, rather than an empty page.
• Products you buy in and resell are not planned here. They have no recipe to make, so they are bought — they appear on the procurement plan instead, from the demand plan’s own figures.
• Two plans for one demand plan is normal while you are comparing a regenerated draft with the approved one. The list shows both, with badges.
• Capacity is checked per calendar day, weekends included — the work calendar is not read — and counts only this plan’s own works orders, not anything already running from an older plan. It warns; it never stops you approving a plan.