What Is a BOR Change Type in Routing Comparison?

A BOR change type classifies the nature of a difference between the routing snapshot a job was scheduled against and the routing as it is defined today. It answers not just whether a routing moved but in what way, using six categories: work center, timing, requirements, sequence, structural, and other. EDGEBIC by User Solutions produces the comparison as a field-level report rather than a single yes-or-no signal.

How it works

When a job is first scheduled, the routing it was planned against is frozen and stored with that job. That frozen copy is what protects a running job from later engineering edits: change the master routing next week and the jobs already on the floor keep the version they were planned with.

The consequence is that over time a job's copy and the master routing diverge. A comparison walks the snapshot's steps against the live definition, step by step, and records what differs. Each difference is labeled with a change type.

Work center means the step is assigned to a different machine now than it was then. Timing covers the duration and buffer fields: setup time, cycle time, queue time, and the flow lag that governs overlap. Requirements covers the quantity side, the hours or pieces the step demands. Sequence covers ordering: the successor link or the position of the step in the routing. Structural is the largest category in practice, because it means a step exists in one version and not the other, whether added or removed. Other is the catch-all for anything the first five do not describe.

The distinctions are not cosmetic. A timing change to a step that has not started can usually be adopted without much thought. A structural change on a half-complete job is a different conversation, because the work already done was planned inside a different routing shape.

A concrete example

The book's analogy for a routing snapshot is a photograph of the recipe card taken at the moment the batch was made. Change the recipe afterwards and the photograph still shows what the kitchen actually cooked.

Now put the photograph next to today's card and read the differences out loud. "Step three moved from the small oven to the large oven" is a work center change. "Step three's bake went from forty-five minutes to fifty" is a timing change. "Step three now covers two hundred portions instead of a hundred and fifty" is a requirements change. "The glaze step moved before the bake instead of after" is a sequence change. "There is now a resting step that was not on the photograph at all" is a structural change.

A cook reading only "the recipe has changed" learns nothing useful. A cook reading those five specific statements knows immediately which ones affect the batch already in the oven and which can wait until the next one. That is exactly the difference a change type makes for a planner deciding what to do with a job that is already running.

How EDGEBIC uses it

The comparison runs against the frozen copy stored with each scheduled job, and the frozen copy itself has its own glossary entry in routing snapshot. Why the snapshot exists, and what it protects a running job from, is walked through in how a frozen routing snapshot protects a running job.

Whether a reschedule uses the frozen copy or today's master routing is itself a setting, covered in BOR source mode. Reading the comparison before switching a job between the two is the sensible order, because the change types tell you what adopting the current routing would actually do.

What the snapshot settles at the end of a job, and why it is the version worth reporting against, is explained in how a routing snapshot settles what you actually built. Completed operations are preserved in every case, per why actuals are immutable in EDGEBIC, so a comparison never puts recorded history at risk. For the wider vocabulary, see the manufacturing glossary, and to see routing snapshots inside a live plan, explore EDGEBIC.