How a Scheduler Absorbs a Rush Order Without Wrecking the Plan

A finite capacity scheduler absorbs a rush order by slotting it in on priority and rescheduling only what it must: completed and in-progress work is preserved, the rush job takes its place among the unstarted work, and only the jobs it displaces move. In EDGEBIC by User Solutions, inserting a hot order is a contained change, not a full reshuffle, because the engine never moves work the floor has already started or finished and it sequences deterministically, so you can see exactly which few jobs slipped. The whole point is that a rush order tests the plan without wrecking it. You find out what the rush costs, in specific jobs and dates, and then you decide.

The rush order competes only for the future

The reason a rush order does not blow up the plan is that most of the plan is off-limits to it. Completed steps, those with an actual start and end, are written back verbatim and never touched by a reschedule. In-progress steps, started but not finished, are preserved too. So the work the floor is actually doing right now, and everything already done, is fixed.

That leaves only the unstarted future as contestable capacity. The rush order competes there, and nowhere else. It cannot bump a job off a machine it is already running, and it cannot rewrite this morning's completed setups. The blast radius of a rush insertion is bounded by construction: it can only rearrange work that has not begun. See why completed work is never moved on reschedule.

Priority is how you insert it

You tell the plan the order is urgent by giving it a high priority, a lower priority number, or a tight due date. The engine sorts every order by priority, then start date, then due date, and processes them in that order, each job claiming capacity ahead of those below it. Raising the rush order's priority lifts it up that sort, so it takes the contested slots before the jobs it now outranks. The full sequencing rule is in how a scheduler decides which job runs first.

Because the sort is deterministic, with no randomness anywhere, the insertion is predictable. The rush job lands where its priority entitles it, and the jobs it displaces are exactly the lower-priority unstarted jobs that were holding the capacity it needs. Nothing moves by chance.

You see precisely what slipped

Determinism is what turns a rush insertion from a scary event into a readable one. Run the schedule with the rush order in place and compare it to before. Every job whose dates changed did so for one reason: the rush order displaced it. There is no noise to filter out.

So you get a precise list. These three jobs moved, this one now finishes two days later, that one still makes its date. You know the cost of saying yes to the rush order before you commit to it. That is a very different situation from a system that reshuffles the whole board and leaves you unsure what actually changed or why. A contained, readable change is the foundation of why a good schedule is boring, and it is what keeps the floor's trust when you do have to insert something.

A worked example

A shop has 30 jobs planned for the week. Monday morning, crews are set up and the board is quiet. At 10 AM a hot order arrives that must ship Wednesday.

Everything running or finished by 10 AM is preserved, so no crew loses the job it is on. You set the rush order to a high priority and reschedule. The engine sorts it near the top and gives it the earliest unstarted capacity it can reach on its work centers. Two lower-priority unstarted jobs that were holding Tuesday slots on the shared machine give up that time and shift to later in the week.

The comparison is clean: 28 of the 30 jobs did not move at all, two shifted, and one of those two now finishes a day past its due date. That is the whole cost of the rush order, laid out in specifics. You decide: accept the one slip, expedite that job, or add a few hours of capacity to save both. The rush order got absorbed, the running floor never flinched, and you made an informed call instead of reacting to a board that scrambled itself.

When a rush order cannot get what it wants

Sometimes the honest answer is that the rush order cannot hit its date without breaking a rule the plan protects. It cannot jump ahead of a job already started, because started work is preserved. If the earliest unstarted capacity its priority can reach is still too late, the plan says so.

That is not the scheduler failing; it is the scheduler telling the truth, the same honesty covered in the cost of an unrealistic due date. Your levers then are real capacity: add a shift, route an operation to an alternate work center with room, or accept the feasible finish. And if you want to reduce the disruption of the insertion further, the optimizer can propose a resequenced plan, but it only proposes and its proposal is clamped never worse than your current plan, so you stay in control of whether to take it. What the never-worse guarantee means for planners covers that safety net.

The pattern throughout is the same. A rush order is a request for future capacity, weighed by priority, that never disturbs the committed present. You see its exact cost and decide with your eyes open. That is how a plan absorbs the urgent without becoming a mess. See how a rush insertion lands on your own board in EDGEBIC, and for the step-by-step on the screen, see how to schedule a rush order.