What Is a BOR Source Mode in Scheduling? EDGEBIC Definition

A BOR source mode decides which version of a product's routing a scheduling run reads: the current live routing, the frozen snapshot taken when the job was first planned, or a blend of the two. In EDGEBIC by User Solutions, the bill of routing on a product can be edited at any time, while a job that has already been scheduled keeps a copy of the routing it was actually planned against. The source mode resolves which one wins on the next run.

Cooking analogy: the recipe on the shelf can be revised by whoever owns it. The photocopy taped inside the kitchen door is the version this batch was started from. Deciding which one the cook follows for the rest of the batch is exactly this setting.

For the broader vocabulary of planning, see the manufacturing glossary.

How a BOR Source Mode Works

When a job is scheduled for the first time, the engine reads the product's routing and produces a plan. It also stores a frozen copy of the routing it used, attached to that plan. From that moment there are two versions in play: the master routing on the product, which anyone can edit, and the snapshot belonging to that job, which nobody edits.

Every later run has to choose between them.

Using the live routing means the run reads whatever the master routing says right now. New engineering, corrected times, an added step: all of it applies immediately, to every job that gets replanned.

Using the preserved snapshot means the run reads the frozen copy. The job continues to be planned against the operations it was originally planned against, no matter what happened to the master routing since.

The blended option exists between them, for the cases where you want the original basis to hold for work already underway while still picking up the current routing where doing so is safe.

Separately, the engine also records where a routing came from in the first place: loaded from a file during setup, read from the live database in normal operation, or constructed directly. That is provenance, not the same decision as which version to use, but the two are easy to conflate because both get described as a routing source.

One rule holds across all of them. Completed operations are never recomputed. An operation with a recorded actual end date is historical fact, and no source mode changes its dates, its hours, or the setup it consumed.

A Concrete Example

Job 42 is scheduled on the first of the month against Widget A's routing: saw, mill, deburr, inspect. Twenty hours on the mill. The plan goes to the floor and the saw step completes.

On the eighth, engineering revises Widget A's master routing. The mill step is now twenty-eight hours because a new feature was added, and a grinding step is inserted after it. This is correct for parts made from now on.

On the tenth, you reschedule because a machine went down.

If the run reads the live routing, Job 42 suddenly needs twenty-eight hours of milling and a grinding step nobody quoted, on a part whose drawings the floor already has in the old revision. The job's basis changes underneath it.

If the run reads the preserved snapshot, Job 42 continues as twenty hours of milling and no grinding, which is what it was planned, quoted, and started against. The completed saw step stays exactly as recorded. The revision governs the next job for Widget A, which is what everyone expected it to do.

The second behavior is the default for a reason: it is the one that keeps a running job honest.

How EDGEBIC Uses It

The source mode governs the routing basis of a scheduling run:

• On reschedule. Jobs already on the board are replanned from their preserved snapshot by default, so a mid-flight routing revision does not silently redefine work already released.
• On the live routing option. When a revision genuinely should reach jobs already planned, scheduling against the current routing is the deliberate way to do it.
• Never over completed work. Recorded actuals are immutable under every mode; only the remaining work is replanned.

For the frozen copy itself, see what is a routing snapshot. For the guarantee around recorded work, see what is actuals preservation on reschedule. For how the snapshot protects a job in flight, read how a frozen routing snapshot protects a running job.