How to Tell Which Order Edits Need a Reschedule in EDGEBIC

In EDGEBIC, an order edit that changes what to build, how many, when it may start, when it is due, or how urgent it is needs a reschedule before the plan reflects it; commercial fields like unit price, markup, owner, and customer do not. Saving an order in EDGEBIC by User Solutions never schedules anything, and that is a design choice rather than an omission.

This post is the decision rule. For a specific field, changing a job's due date and changing a job quantity after scheduling go deeper; the full task library is at the EDGEBIC how-to hub.

Before You Start

• You have at least one scheduled job, so there is an existing plan an edit could be expected to move.
• You know where the two edit routes live: the row's edit button opens the full Edit Manufacturing Order dialog, and Priority, Due Date, and Direction can be changed inline in the grid.
• You accept that the plan on screen is the output of the last run, not a live calculation.
• If the job has recorded work, note that the Direction field is locked once Actuals Logged? reads Y. Started work always continues forward.

The Steps

1. Make the edit. Either open the order with the row's edit button and press Save Order, or change Priority, Due Date, or Direction straight in the grid cell.
2. Commit inline edits. While any inline edit is unsaved, a Save Changes button appears on the filter bar. Click it. This writes the values and schedules nothing.
3. Classify the change against the table below. Ask a single question: would the engine have read this field when it placed the operations?
4. If the answer is no, stop here. The edit is already live and the plan is correct as it stands.
5. If the answer is yes, tick the affected rows with the Select checkbox. Ticking is how you keep the run narrow so untouched jobs hold their plans and their reserved capacity.
6. Press Schedule + Re-Schedule and read the Confirm Scheduling dialog, which reports how many jobs are new and how many are being re-planned.
7. Verify against the columns that moved. After the run, Item Start, Job End, and Days Late should reflect your new values.

The Field-by-Field Rule

One extension worth internalizing: the same rule applies beyond the order grid. Adding a plant holiday, changing a shift, editing a routing, or altering a work center's capacity does not ripple into an existing plan by itself either. The plan stays as the last run left it until you re-run for the affected jobs.

How to Check It Worked

For a no-run field, the check is that nothing moved. Open the job and confirm Item Start and Job End are unchanged while the edited value shows its new content. If bars did shift, someone ran the scheduler in between.

For a run-needed field, compare the same two columns before and after. A priority increase should show the job claiming capacity earlier where it competes for the same machine, and a quantity increase should lengthen the operations that scale with pieces. If the run finished but nothing moved, the likeliest cause is that the job was never ticked, so the run scheduled a different set. How to check what a scheduling run changed is the thirty-second confirmation.

Common Mistakes

Reading the Gantt as a live calculation. It is a picture of the last run. Until you re-run, a corrected due date is a correct promise sitting beside an out-of-date plan.

Editing inline and never pressing Save Changes. The button only appears while edits are pending, which makes it easy to walk away mid-edit. Nothing is written and nothing warns you later.

Changing priority and expecting movement. Priority decides who claims contested capacity first, and that decision is made during a run. It has no effect between runs, as covered in how to set a job priority.

Double-clicking the Start Date cell and treating it as a move. It stores the job's earliest allowed start, nothing more. See how to set the planning start date.

Trying to switch direction on a started job. The field locks once actuals exist, on purpose. Remaining work always continues forward from where the floor is, which is why backward scheduling only decides where a job is born.

Running the whole plant to apply one edit. Ticking the changed rows keeps the run narrow. How to reschedule only the jobs that changed is the polite option on a busy board.

Next Steps

Turn the rule into a rhythm: collect edits, save them, tick the affected rows, run once, and glance at the dates. That habit is the whole of good order maintenance. If your edit was a routing change on a job already on the floor, the job carries its own frozen routing and adopting a master change is a deliberate act, described in how to work with frozen routings. If you are creating rather than correcting, how to create a manufacturing order walks the dialog field by field, and how to run the production scheduler covers the run that makes any of it real.

The takeaway

The rule fits in one line: if the change describes the work, re-run; if it describes the paperwork, do not. Everything frustrating about order editing dissolves once you stop expecting a save to be a plan, because the gap between the two is the space where you get to batch corrections and review them as a set before the shop floor ever sees a new date. See where order management sits in the platform on the EDGEBIC product page, and if you are stepping up from the earlier User Solutions planning tools, the move from RMDB to EDGEBIC explains what carries across. Next, read how to reschedule only the jobs that changed and how to check what a scheduling run changed.