What Is Re-Shopping in Work Center Group Scheduling?

Re-shopping is the behavior in machine-pool scheduling where a routing step that has not started yet chooses its machine again on every reschedule, picking the best member of the pool against the current capacity picture, while any step that has started or finished keeps the machine it was already resolved to. It is the reason a pooled part planned on Mill-1 on Monday can legitimately move to Mill-2 by Wednesday: the still-unstarted step re-shopped the pool, and Mill-1 was jammed.

This entry is part of the EDGEBIC by User Solutions glossary; the broader dictionary lives in the manufacturing glossary.

Why Pools Re-Shop

The entire value of a work center group is that the scheduler picks the best available machine at planning time rather than pinning the routing to one machine forever. But "best available" is not a one-time answer. A machine that was free on Monday can be buried under higher-priority work by Wednesday, and a machine that was jammed can open up.

If the pool's choice were frozen after the first run, the group would degrade into a fixed pin the moment anything changed, and the flexibility you bought it for would evaporate on the first reschedule. Re-shopping keeps the choice alive: each reschedule re-asks the question against the freshest load.

How It Works

For a step to re-shop, two conditions hold. First, the step has not started: no actual start has been recorded. Second, the step is still bound to the group, which it always is, because the group binding is designed to survive saving, snapshots, and every reschedule.

When those hold, the reschedule re-expands the group into its members and lets the selection strategy pick again against current capacity. If a different member now finishes soonest, or the primary is now free, the step moves to it, and the change is shown as a replacement indicator so it is never a mystery.

The counterpart rule is just as important: a step that has started, or is complete, keeps its resolved machine. Actuals are immutable, and started work never migrates. So re-shopping only ever reshuffles future work, exactly as a real shop would.

A Concrete Example

Group MILLING has three members. On Monday's run, a routing step's earliest-completion projection favors Mill-1, so the part is planned there. On Tuesday, a rush order lands and consumes most of Mill-1's week.

Wednesday's reschedule fires. The milling step has not started, so it re-shops. Mill-1 now projects a late finish because it is buried, while Mill-2 can start and finish the step sooner. The pool re-chooses Mill-2, and the Gantt shows "Replaced: Mill-1 to Mill-2." The work found the open machine instead of waiting behind the rush order.

Now suppose the operator had already started the step on Mill-1 Tuesday afternoon. Wednesday's reschedule would leave it on Mill-1, because started work keeps its machine. Only genuinely unstarted steps re-shop.

How EDGEBIC Uses It

In EDGEBIC, re-shopping is why a group binding is preserved through every converter, snapshot, and reschedule instead of being overwritten with the resolved machine. On each run, a not-yet-started group step is re-exploded via group explosion and the resolver picks a member again against live capacity. Started or completed operations are held by the locked-machine guard.

Any resulting move is surfaced through the standard replacement indicator ("Replaced: from to"), so a planner never has to hunt for why an assignment changed. If you prefer routing that changes only when it truly must, the group's primary-first selection strategy keeps a step on the designated primary whenever it has capacity and re-shops only on genuine overflow. For the wider picture, see the work center groups overview and, for how reschedules preserve started work, actuals preservation on reschedule.