How to Configure Scheduling Policy in EDGEBIC: Seven Decisions, One Screen

Scheduling policy configuration in EDGEBIC by User Solutions is seven decisions on one screen. They are not preferences: each one changes what the next scheduler run produces for the whole site. This post walks every group with its options, its default, and the case for changing it, then shows the save behavior and a worked example of a just-in-time plant setting all three of the decisions that matter to it.

The wider map of where settings live is in EDGEBIC configuration options explained. Everything here lives in one place: Settings, then the Schedule sub-tab.

Before You Change Anything

Two prerequisites, both practical.

You need permission to open the Settings tab, which is permission-controlled and hidden entirely from users whose roles do not include it. See EDGEBIC users and roles explained.

And you need to know the difference between policy and display. Policy settings change what the scheduler computes. Display settings, which live in a different screen, change only what you see. Confusing the two is the most common source of "I changed a setting and nothing happened."

1. Default Scheduling Direction

What it changes. The direction stamped on every newly created job and quote. Existing orders keep their own direction, and each order can still be overridden individually.

When to change. Flip to Backward in a just-in-time shop where finishing weeks early only builds inventory. Forward suits shops where earliest completion is the priority and inventory is not the constraint. The trade-off between them is covered in forward vs backward scheduling, and EDGEBIC's implementation of the just-in-time direction in EDGEBIC backward scheduling explained.

2. When a Backward Job Doesn't Fit

What it changes. Whether you are interrupted when a just-in-time plan is impossible. Backward scheduling never fails outright, because the forward fallback always exists. This setting decides whether you get asked first.

When to change. Choose the popup when a missed promise date must never slip through unnoticed. Leave it silent when your planners review dates anyway and would rather not be interrupted mid-run.

3. Optimizer Engine

What it changes. Which engine runs when you use the Optimizer tab. Both are propose-only: nothing changes until you accept, and neither can make the schedule worse than what you had.

When to change. Pick the solver when you want the optimality guarantee attached to the proposal. If the solver is not available in your installation, EDGEBIC quietly uses the multi-run engine instead, so selecting it can never break scheduling.

The goal preset and the time budget are not here. They are chosen per run on the Optimizer tab, because they are decisions about one optimization rather than about the site. See EDGEBIC optimizer goals and presets explained.

4. Partial-Confirm Behaviour

This one is subtle and it matters more than its screen space suggests. It governs what happens when an operator marks an operation finished but logged fewer hours than planned: a short confirm.

What it changes. Where the next reschedule places downstream work. Trusting the stamp pulls work earlier. Forward-shifting keeps the unfinished hours visible in the plan.

When to change. Choose trust in a custom job shop where the operator's close-out is the ground truth. Choose the flagged variant to be strict on a few critical operations while treating the rest as closed on the stamp. The default matches how mainstream APS systems behave.

5. Capacity Search Window

When to change. Rarely. Lower it only if you want scheduling to fail fast rather than plan far into the future on a hopelessly overloaded work center. The minimum is 30 days. Most installations never touch this.

6. Job-Level Hours

What it changes. Hour roll-ups, not the plan. Three mirrored drill heads working one operation genuinely log 24 machine-hours between them, while the job consumed 8 hours of elapsed work. With this setting off, the job total reads 24. With it on, the job total reads 8, everywhere hours roll up: routing header totals, Job View, and reports.

When to change. Turn it on if you use dependent-parallel routings and want job totals to reflect the primary path. See EDGEBIC parallel work centers explained for what dependent-parallel means.

7. Sub-Assemblies

Leave this on unless you deliberately plan sub-assemblies as separate jobs. Turning it off for a multi-level product changes what gets planned, not just what gets displayed.

What Happens When You Save

The line worth repeating from that table: completed operations never move. A reschedule replans what has not happened yet, whatever the policy says.

A Worked Example: A Just-in-Time Cell

A plant runs a just-in-time cell and wants three things: new orders scheduled backward, a mandatory review when a date cannot be met, and honest job totals despite three synchronized drill heads on one weld station.

1. Open Settings, then Schedule.
2. Under Default Scheduling Direction, select Backward.
3. Under When a Backward Job Doesn't Fit, select Show a popup so I can review it.
4. Under Job-Level Hours, tick Primary hours only (exclude parallel).
5. Click Save.

A new job for 300 units, due on the 24th, is created the next day and inherits Backward. Run the scheduler and the job right-aligns to the 24th. A week later a rush order eats the free capacity; on re-run the backward plan no longer fits, so the review dialog appears with the earliest-possible forward plan attached. The planner accepts it knowingly, instead of discovering the slip on a report. Meanwhile in Job View, the job's total now reads the primary path's hours: the mirrored drill-head hours no longer inflate it.

How to Test a Policy Change Before You Live With It

Policy affects everyone's next run, which makes "try it and see" a group experiment unless you contain it. Two ways to contain it:

Run and read before the floor does. Change the setting at a quiet moment, run one schedule yourself, and read the jobs you know best. A direction change or a partial-confirm change shows up immediately on jobs that have short confirms or tight due dates. If it looks wrong, change the setting back and run again: nothing is committed to the floor until people work from it.

Use a scenario for the bigger questions. What-if scenarios and quote simulation exist to answer "what would happen if" without touching the live plan, which is the right tool when the question is about a whole product family rather than one setting. See the EDGEBIC quoting guide for how a simulation is run and read.

What you should not do is change two policy groups at once and then try to attribute the result. Direction and partial-confirm behavior both move downstream work, and changed together they are indistinguishable.

Three Habits That Keep Policy Trustworthy

Change policy at a quiet moment and tell the team. Direction and partial-confirm behavior alter what the next run produces, and surprises there erode trust in the plan faster than any bug.

Run the scheduler after saving. Policy is read at the start of a run. Saving alone changes nothing visible, which is the number one reason a change looks like it "did nothing".

Write down what you changed and why. Six months later, the question "why does this shop schedule backward?" should have an answer that is not a shrug.

Where to Go Next

Read the settings that change how your schedule looks for the display side and why the boundary matters, and configuration mistakes in EDGEBIC for the symptoms that follow a policy change nobody announced. The wider map is in EDGEBIC configuration options explained, and the whole product in the EDGEBIC complete guide.

Tell us how your shop treats a short confirm today, and we will show you the matching policy on a demo of EDGEBIC.