My MPS Firmed Quantity Did Not Become a Job

A master schedule quantity becomes a job only when you firm it, and only for a make-to-stock product, so a quantity that did not turn into an order was usually saved rather than firmed, or belongs to a product that does not qualify. Once you read the row's status and the product's build method, the fix is one action.

EDGEBIC by User Solutions uses the master production schedule as the planner-editable bridge between demand and the scheduling engine: you set a build quantity in a time bucket, then firm it into a build-to-stock order that the engine schedules against real capacity. The gap between "I entered a quantity" and "there is a job" is where this symptom lives. This post sits in the EDGEBIC troubleshooting guide and pairs with master production schedule explained and how to add a product to the MPS grid.

First, Read the Row's Status

A master schedule entry moves through three states: suggested, firm, and released. Suggested is a system recommendation the planner has not acted on. Firm is your committed build quantity, saved but with no order behind it yet. Released means the quantity has been firmed into an actual order, with a link to that order. The single most common cause of "no job" is a row sitting at firm when you expected released. Read the status before anything else. Once a row is released, the order it created is the scheduled receipt, and the master schedule overlay stops driving the projected balance for that bucket directly, so the released state is also the point at which the build becomes real supply rather than a plan.

Cause 1: Saved, Not Firmed

Saving a build quantity records your decision and leaves the row at firm. Firming is the separate action that creates the order. A saved row shows a build number with nothing scheduled behind it.

How to tell: the row's status is firm, not released, and there is no linked order.

Fix: firm the row. That converts the committed quantity into a build-to-stock order, sets its start date by working back from the bucket's date by the product's lead time, and moves the row to released. The order is stamped as having come from the master schedule rather than being created by hand, so you can tell firmed builds apart later. Firming also rounds a fractional build up to a whole number, so a small excess over the bucket is expected, and a firmed job quantity higher than the MPS bucket covers when the gap is real. The action is atomic and idempotent: it either creates the order and releases the row together, or leaves the row at firm if it could not complete, so you never end up with a released row and no order from the firm action itself.

Cause 2: The Product Is Not Make-to-Stock

Only make-to-stock products source firm demand into the master schedule and produce a build-to-stock order on firming. A product built strictly to order does not participate. How that sourced firm demand nets against a forecast for the same period is covered in when a forecast and a firm order are both counted.

How to tell: the product's build method is make-to-order rather than make-to-stock, and the bucket will not firm as expected.

Fix: if the product should be planned through the master schedule, set its build method to make-to-stock, and confirm it is flagged as stocked so its build can post a receipt and consumers can net against it. If it is genuinely make-to-order, plan it as an order directly rather than through the master schedule.

Cause 3: The Order Exists but Is Not Scheduled

Firming creates the order; it does not schedule it. A released row can have a real order that simply has not been placed on the Gantt yet.

How to tell: the row is released and links to an order, and that order appears in the job list but not on the Gantt.

Fix: run scheduling. The engine places the build-to-stock order against capacity on the next run, using the start date firming set from the product's lead time.

Cause 4: The Firmed Order Was Removed

A released row can point to an order that was later cancelled or deleted, leaving an orphan. The master schedule view demotes such a row back to firm when it rebuilds, but the stored row still reads released until you act.

How to tell: the row reads released but the linked order no longer resolves. The plant-wide anomaly report flags a released entry whose firmed order no longer exists.

Fix: re-firm the row to create a fresh order, or delete the row if the build is no longer needed. Run the anomaly report on a full scan (no job filter) to catch these, since the check is plant-wide.

The Reconciliation, in Order

1. Read the status: firm means saved, released means firmed.
2. Firm the row if it is only saved.
3. Check the build method; only make-to-stock products firm into build orders.
4. Run scheduling so a released order lands on the Gantt.
5. Run the plant-wide anomaly report for orphaned released rows whose order is gone.

Prevention

• Firm, do not just save, when you want an order; the two actions are distinct.
• Set make-to-stock and stocked on products you plan through the master schedule.
• Run scheduling after firming so the new order gets placed rather than sitting unscheduled.
• Re-firm rather than resurrect a deleted order, and clean up orphaned released rows the anomaly report surfaces.

One detail worth knowing: firming converts a decimal build quantity to a whole-number order quantity, so a difference of a unit or less between the master schedule figure and the order is expected rounding, not a fault. The projected balance that drives suggestions is covered in projected available balance explained. A reschedule that seemed to move completed work is covered in a completed job moved when I rescheduled.