Why EDGEBIC Refuses a Drop on the Planner Board

When EDGEBIC by User Solutions refuses a drop on the Planner board, it is never silent and never destructive. The operation stays on the machine it was already on, whatever time shift you made is kept, and the specific reason appears on the status line under the toolbar. Nothing is lost and nothing has to be redone from scratch.

That contract is worth internalizing before you learn the individual refusals, because it changes how a refused drop feels. You are not being told to start over. You are being told which half of your drag could not be honored.

The Shape of Every Refusal

Three things are always true.

The machine is unchanged. The operation is still assigned where it was. It does not land somewhere partial, and it does not end up in an ambiguous state.

The time shift is kept. If you dragged the bar two hours later on the way to a machine that turned out to be off limits, those two hours are staged as an ordinary re-time. That is usually the useful half of what you were doing anyway.

The reason is named. Not a generic rejection, the actual cause. Glance under the toolbar after any drag that did not do what you expected.

The board is otherwise built on an override-and-warn contract, described in drag-and-drop rescheduling: EDGEBIC warns about questionable moves rather than blocking them, because the planner knows things the model does not. The refusals below are the small set of moves that are not questionable but genuinely impossible, and each one is refused for a concrete reason rather than out of caution.

The Refusals

Another job's lane

You dragged an operation onto a different job's lane in the upper block. The machine is unchanged, the time shift is kept, and the status line tells you operations cannot move between jobs and the lane change was ignored.

An operation belongs to its job's routing. It is a step of that job, not a free-floating unit of work that can be handed to another order. If the work genuinely belongs somewhere else, that is a routing change made in the job's routing, not a drag on a schedule board.

A job lane, having dragged the machine-lane bar

You picked up the bar in the machine block and dropped it in the job block. Again the machine is unchanged and the time shift is kept, and the status line explains that you assign an operation by dropping it on a workcenter lane, because the job block is a read-across.

This one is a reminder rather than a restriction. The job block exists so you can read a routing and grab an operation from a job-shaped position. Assignment happens in the machine block, because that is where machines are.

A machine that is not a member of the operation's group

The operation is bound to a work center group, and you aimed it at a machine that is not an active member of that group. The status line says the selected workcenter is not an active member of this group.

This is the refusal most worth understanding, because the machine you aimed at may be perfectly capable of the work. The reason is not capability, it is durability.

EDGEBIC records a group step's machine choice as a pin against the group, and the engine discards a pin that names a non-member. So if the assignment were accepted it would look fine on your screen, save without complaint, and then quietly fail to stick on the next reschedule, with the operation back on its original machine and no explanation anywhere. Refusing at the drop is the honest version of the same outcome, delivered at the moment you can still do something about it.

If the machine genuinely belongs in the mix, put it in the group. See how to add a machine to a pool.

The operation already has actuals

Somebody has logged a start or a completion against this operation. The status line says the operation has actuals logged and that started or completed work keeps its machine.

Recorded work is a statement about what physically happened. A drag cannot move it, and neither can a reschedule. If the machine on the record really is wrong, clear the actuals on that operation first and then reassign it. The two-step is deliberate: rewriting history should take a decision, not a slip of the mouse.

The group has only one active member

The operation is group-bound and its group currently has no other active member to move to. The status line names the group and says it has no other active members.

This is almost always a master data signal rather than a scheduling one. A membership was deactivated for a retrofit and never reactivated, or the group was created with one machine as a placeholder. Open the group in the Work Center Groups manager and check which memberships are active. Background in EDGEBIC work center groups explained.

Replacement is switched off for capacity request jobs

You are on a capacity request job and work center replacement has been disabled for that class of job. The status line says workcenter replacement is disabled for capacity request jobs.

This is a configuration decision somebody made on purpose. If a bar shifts in time but keeps its lane on those jobs, that is the setting doing its work rather than a fault.

Quick Reference

Refusal Is Not the Only Reason Nothing Happened

Two other outcomes look similar at a glance and are not refusals at all.

Drop an operation back on the machine it is already scheduled on and EDGEBIC reads it as a re-time, not as a second assignment. Drop it back at exactly the same time and nothing is staged, on purpose. Both are covered in dropping an operation back on its own machine.

If your drag genuinely produced no visible result and no message, work through a Planner drag that did nothing.

The Principle

A scheduling board that blocks the planner becomes a board the planner abandons, which is why EDGEBIC warns far more often than it refuses. But there is a category of move that cannot be honored no matter how confident the human is: an operation cannot join a different order, and work that has already happened cannot be moved to a machine it did not happen on.

For those, the right behavior is to refuse immediately, preserve everything salvageable about the gesture, and say precisely why. A refusal that arrives at the drop is a small annoyance. The same refusal arriving silently at the next reschedule, three days later, with a bar mysteriously back where it started, is the kind of thing that ends trust in a schedule.

User Solutions has been building scheduling tools on that trade-off since 1991, for shops from ten people to the US Navy, GE, BAE Systems, and Cummins.

See the full EDGEBIC platform, read the Planner view overview, or bring the move your current system will not let you make to a demo and let US tell you honestly whether it should.