A Job Disappeared From the Schedule: Where It Actually Went

A job that vanished from the schedule is almost always hidden, skipped, or fulfilled rather than lost, and the order itself still exists in every one of those cases. Four documented explanations cover it, and they are worth checking in frequency order, because the cheapest one to rule out is also the most common.

EDGEBIC by User Solutions never silently drops an order: a job that does not appear on the Gantt is being hidden by a view, excluded by the run's mode, satisfied from inventory, or failed and waiting in the dialog. This post is the deep version of the "missing from the schedule" symptom in the EDGEBIC troubleshooting guide.

Cause 1: A View Is Hiding It (Check This First)

The most common reason a job is "gone" is that the view is not showing it, not that the schedule lacks it. Two filters do this:

• A Gantt job filter. The Gantt has a job list with checkboxes; unchecking a job hides it. Filters persist with your saved personal layout, so a filter you set days ago is still active.
• A date-range window. The Job View filters to a start and end date range. A job whose schedule falls outside that window simply does not appear, even though it scheduled fine.

How to tell: the order exists in the order list and the run finished without listing it as failed.

Fix: reset the layout to clear saved filters, widen the date range, and look again. This takes seconds and rules out the single most frequent cause. The settings offer a one-click reset of all layouts to defaults if a grid or Gantt looks wrong in general, covered in the settings that change how your schedule looks.

Cause 2: The Mode Did Not Include It

The incremental-new mode schedules only orders with no existing schedule. A job that already has a schedule from a prior run is treated as handled and left untouched. So a job you expected an incremental run to plan, but which was already scheduled, is correctly skipped.

How to tell: the run used incremental-new, and the job already had a schedule going in.

Fix: to re-plan an already-scheduled job, use a mode that includes it or run a targeted reschedule of that specific order. If you cleared the job first and it still did not come back, the clear may not have fully removed the prior schedule; a targeted reschedule forces the engine to consider that one order directly. Reschedule safely covers the modes and when each applies, and why a job jumped after a reschedule covers a job that reappears in a place you did not expect.

Cause 3: It Was Satisfied From Stock

For a stocked product, if on-hand inventory already covers the order quantity, the engine builds nothing, because nothing needs building. The order is fulfilled from stock rather than manufactured, so it legitimately produces no scheduled operations. This looks identical to "missing" on the Gantt but is the opposite: the order is complete, by a different route.

How to tell: the product is stocked, on-hand covered the order, and the inventory ledger shows a draw-down that fulfilled it.

Fix: none needed; this is correct. Confirm it by reading the fulfillment on the order and the ledger entry. The consume-from-stock walkthrough shows the netting logic with numbers, so you can see exactly why no machine time was scheduled.

Cause 4: It Failed, and You Have Not Read the Dialog

Failures do not crash the run; they are collected per job. One broken order never blocks the other forty, which also means a failure is easy to miss if you do not open the dialog. A job that failed to schedule genuinely produced no operations, and the reason is sitting in the failure dialog with a category and a fix hint.

How to tell: the failure dialog lists the job. If you dismissed the dialog without reading it, re-run and read it this time.

Fix: address the named cause. A job missing because it failed is really a job that will not schedule: no routing, an inactive machine, a routing loop, or no capacity. That post covers each failure category and its fix.

The Diagnostic, in Frequency Order

1. Clear filters and widen the date range. Seconds to check, most common cause.
2. Confirm the run mode. Incremental-new skips already-scheduled jobs; use a mode that includes it or a targeted reschedule.
3. Check the order's fulfillment. A stocked product covered by on-hand builds nothing, and the ledger proves it.
4. Read the failure dialog. A collected failure is easy to miss; the reason and fix are in it.

That order is deliberate: the first two are display and configuration and cost almost nothing to rule out, while the last two involve actual order state.

Prevention

• Reset your layout when a view looks wrong before assuming a data problem. A persisted filter is the quietest cause of a "missing" job, and layout hygiene is a ten-second habit.
• Match the run mode to your intent. Daily intake in incremental-new, disruptions in a targeted reschedule, structural rebuilds in a full reschedule during a maintenance window.
• Read the failure dialog every run, even a clean-looking one. A single collected failure is the easiest thing to walk past, and it is the only one of the four causes that is a genuine problem.
• Know your stocked products. A make-to-stock item that builds nothing because on-hand covers it is a feature, not a fault; recognizing it on sight saves a false-alarm investigation.