How to Run the Pre-Flight Check Before Scheduling in EDGEBIC

The pre-flight check in EDGEBIC by User Solutions runs automatically before the scheduling engine starts, and it validates the structure of your master data: order, product, routing, routing steps, work centers, machine instances, and shifts. If anything in that chain is missing, the run stops and a failure dialog opens with one row per problem, before any schedule is generated. This is how to read it and clear it.

Every task in this library is mapped on the EDGEBIC how-to hub. For the wider concept of what finite capacity scheduling is actually solving, start with what production scheduling is.

Before You Start

• You have manufacturing orders selected and you are about to schedule them. Pre-flight only inspects the orders in the current request.
• You have permission to edit master data, since almost every fix lands on a product, a routing, or a work center rather than on the order.
• You are not looking for a capacity answer. Pre-flight is a wiring check, not a load check.

Step 1: Select the Orders and Schedule as Normal

Open the Manufacturing Orders view, select the orders you want to schedule, and start the scheduling run the way you always do. There is no separate button labeled pre-flight. The check is part of the request.

If everything validates, you see no dialog and the engine proceeds. That silence is the pass condition.

Step 2: Read the Failure Dialog

When the check finds a problem, the Scheduling Failure Dialog opens instead of a schedule. Each row carries four useful fields.

Pre-flight rows are marked as pre-flight, which distinguishes them from failures the engine raised later during actual scheduling. That flag matters: a pre-flight row means nothing was scheduled at all, so no partial plan was written.

Step 3: Work the Six Checks

Pre-flight inspects six things in order. Reading them as a chain makes the fix obvious.

1. The order exists. A stale selection can reference an order that was deleted in another session.
2. The product exists. The order points at a product record that is present and readable.
3. A routing exists for that product. No routing means no operations to schedule. Build one, or copy one from a similar product.
4. The routing has steps. An empty routing shell passes the previous check and fails this one.
5. Every routing step points at an active work center. Deactivating a work center does not rewrite the routings that use it, so this is the most common single cause of a wave of failures.
6. Each of those work centers has at least one machine instance and at least one shift. A work center with zero instances has no capacity bucket to book into, and one with no shift has no working hours at all.

Step 4: Fix in Master Data, Not on the Job

Every pre-flight failure resolves upstream of the order. Add the missing routing to the product, reactivate or replace the work center, set the machine count above zero, or assign a shift. Details for the two most frequent fixes are in how to add a work center and how to add a step to an existing routing.

Editing the order itself almost never clears a pre-flight row, because the order is rarely what is broken.

Step 5: Copy the Rows if You Need Help

If a row does not make sense, use the Copy button in the dialog. It builds a text block containing category, summary, detail, affected entity, and fix hint for every failure, ready to paste into a ticket or an email. Occasionally another application holds the clipboard and the copy quietly does nothing, so paste to confirm before you close the dialog.

How to Check It Worked

Re-run the same selection. Three outcomes are possible.

• No dialog. Pre-flight passed and the engine ran. Open the plan and confirm the jobs you selected are on it.
• Fewer rows. Your fix cleared some causes. Read the remaining rows, which are now easier to group.
• Different rows, no pre-flight flag. Pre-flight passed and the engine then hit a real scheduling problem such as no available capacity. That is progress, and it is a different investigation.

Common Mistakes

• Reading pre-flight as a capacity verdict. It never inspects load or calendars. A run that clears pre-flight can still fail on capacity a second later.
• Fixing rows one by one from the top. Nine rows are often three causes. Group by affected entity first.
• Reactivating a work center as a reflex. If a station is genuinely retired, the correct fix is to repoint the routing steps at its replacement, not to bring the retired station back into the plan.
• Assuming a passing run means good data. Pre-flight proves the routing is wired, not that the hours on it are right. Bad hours schedule perfectly and produce a plan nobody can hit.

See how EDGEBIC turns validated master data into a finite capacity plan on the EDGEBIC product page.