10 Master Production Schedule Mistakes That Wreck the Build Plan

Master production schedule mistakes rarely announce themselves. The grid keeps loading, the numbers keep looking plausible, and the shop keeps building the wrong quantity a week late. These ten are the ones that come up repeatedly in the planning layer of EDGEBIC by User Solutions, each with the symptom you would actually notice first.

For the module itself, start with the MPS explained. For the screen-by-screen loop, see how to work the grid. For the underlying rules, firm demand, forecast, and time fences covers the mechanism.

1. Leaving the Sales Order in Draft

Symptom. The firm demand column reads zero for a product you know has orders on the books. The plan is driven entirely by forecast, and the suggestions look far too small.

Cause. Firm demand is sourced from open lines on confirmed sales orders. A line entered onto a draft order contributes nothing to the grid, no matter how real the customer commitment is.

Fix. Confirm the order. The line's open balance (ordered quantity minus quantity already shipped) then appears in the bucket matching that line's due date. Make confirmation part of order entry rather than a monthly clean-up, because the gap between entry and confirmation is exactly the window in which your plan is wrong. Sales orders in EDGEBIC covers the entry workflow.

2. Setting Half of the Product's Stock Flags

Symptom. One product never receives a build suggestion, however negative its projected balance goes. Or the item appears in a data-quality report you had not looked at before.

Cause. Stock planning needs two settings that people set one at a time: the build method has to be make-to-stock, and the item has to be flagged as stocked. The projection's stock path activates on the build method, so a make-to-order item is simply not planned for stock. A make-to-stock item left unstocked is a half-finished setup, which is why a dedicated check flags it.

Fix. Set both, on every item you intend to plan. Treat a mismatch between the two as a data error rather than a preference. Products and planning attributes lists every field the planning layer reads.

3. Expecting a Committed Quantity to Close the Hole

Symptom. You type 110 into the build column, save, and the projected balance still shows the stockout. It looks like the save did not take.

Cause. It took. A committed build quantity lives in its own column and does not roll into the projected available balance until the bucket is firmed and a real manufacturing order exists as a scheduled receipt.

Fix. Understand why the design refuses to do it. Rolling an uncommitted number into the balance would show supply for an order nobody created, and once the bucket was firmed the same quantity would appear twice: once as a committed number and once as a real receipt. Firm the bucket, run the schedule, and the balance moves because something real moved it.

4. Reading the Fence as a Lock

Symptom. A near-term bucket changes, or somebody releases a build inside the frozen window, and the fence apparently did nothing.

Cause. The planning time fence flags near-term buckets as frozen. Inside it, automatic suggestions are suppressed and committed quantities are not automatically overwritten. It does not prevent a human from firming a bucket inside the window.

Fix. Treat the fence as planner discipline made visible. If near-term releases are a real governance problem, the control is a process one: agree who may firm inside the frozen window. And check the fence days themselves, because a planning fence shorter than your planning cycle protects nothing at all.

5. Reading the Projection Before Running the Schedule

Symptom. You firm a build and the receipt lands in a bucket that makes no sense against your real lead times.

Cause. Before the scheduler has run, the firmed order has no scheduled operations, so the projection has to fall back to the order's target end or due date to place its receipt. That is a placeholder, not a completion date.

Fix. Adopt the sequence: firm, schedule, then re-read the projection. Only after a scheduling run does the receipt carry a date the finite capacity engine actually produced. This matters most when somebody is about to promise the resulting stock to a customer.

6. Deleting the MPS Row Instead of the Order

Symptom. A build-to-stock job is on the floor and nothing in the plan explains it. Nobody can say who asked for it or why the quantity is what it is.

Cause. Deleting a master schedule row removes the planning record. It does not delete the manufacturing order that row created. You have removed the explanation and kept the build.

Fix. Reverse the order of operations. Delete or cancel the manufacturing order first. On the next load, the grid demotes the row back to Firm because its order no longer resolves, which is your cue to revise the quantity and firm again. If a stale released row survives somewhere, the anomaly report surfaces it so it does not sit unnoticed. The troubleshooting guide covers running that report.

7. Trying to Revise a Released Bucket in Place

Symptom. You change a quantity on a released bucket, save, and nothing changes.

Cause. Once a bucket is Released, a real order carries that quantity. The save path will not silently revise a number that already exists as a job.

Fix. Cancel or delete the order, let the row demote to Firm on reload, revise, and firm again. It is three steps rather than one, and the extra steps exist so that a planning number and a shop-floor job never quietly disagree.

8. Treating a Firmed Build as a Reserved Slot

Symptom. Builds firmed on Friday routinely finish after their own due date, even though the grid looked healthy when you released them.

Cause. Firming creates an order. It does not reserve capacity. The new order joins the queue and competes for work center time against every other job, and when the shop is full it can slip past its due date. That is finite capacity behaving correctly rather than a planning failure.

Fix. Two habits. First, run the schedule after firming and read the resulting dates rather than the planned ones. Second, check the product's lead time: a lead time of zero puts the start date on the due date and leaves the order no runway, while a very long one can push the start into the past. The lead time is the runway you are giving the engine to work with.

9. Choosing a Horizon Shorter Than the Lead Time

Symptom. The grid always looks calm, and stockouts arrive as surprises from outside the window you were watching.

Cause. The horizon covers less ground than the product needs. An item with a 30 day lead time viewed across a 30 day horizon shows you only the period in which a new build can no longer arrive in time. Everything actionable happens beyond the last visible bucket.

Fix. Set the horizon to the product's lead time plus at least one full planning cycle. The point of a projection is to give you time to act, and a horizon shorter than your lead time gives you none.

10. Letting the Bucket Size Hide the Problem

Symptom. Weekly buckets show a healthy projected balance, and the shop still runs out on a Tuesday.

Cause. A bucket aggregates. One week bucket showing a positive closing balance can contain a mid-week trough that goes deeply negative before a Thursday receipt arrives. The row is honest about the week and silent about the days inside it.

Fix. Match the bucket to the item's demand rhythm. Day buckets for fast movers with daily order flow, week for most items, and the 28 day period for slow, high-value items ordered monthly. Remember that commitments are stored against the product, the bucket type, and the bucket date together, so switching granularity mid-cycle changes which commitments you are looking at.

A Note on Quantities That Do Not Match

Two rounding behaviors look like errors and are not.

Firming rounds the committed quantity up to a whole number, so 30.4 becomes 31 and 99.5 becomes 100. Manufacturing order quantities are whole units, and rounding up is the deliberate direction.

The realised production can also come in below the committed quantity, legitimately. When stock covers part of the demand at schedule time, the engine builds only the shortfall. A data check exists to compare the plan against what the ledger actually received, but its purpose is catching divergence nothing explains. Netting is an explanation.

The Short Checklist

Work that list once per product and most of these problems never appear. For the full platform map, see the EDGEBIC complete guide, and for the planning layer this module sits inside, the inventory and planning pillar.