What Is a Routing Header in Manufacturing? EDGEBIC Definition

A routing header is the container that groups every step belonging to one product's routing. In EDGEBIC by User Solutions, the bill of routing is built from individual steps, each naming a work center, the hours it takes, and how it connects to the next step. The header is the record all of those steps hang from, and it is the thing you name and select when you say a product has a routing.

If one step is a single recipe card, the header is the folder holding the complete set of cards for that dish. You cook from the cards. You file, name, and hand over the folder.

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

How a Routing Header Works

Everyday shop language uses the word routing for two different things, and that is the source of most of the confusion around this term.

The first meaning is one operation: mill at station 3 for two hours per unit, then move to deburr. That is a routing step. It carries the work center assignment, the hours per unit, the setup time, any queue or transit time, and the link that says which step comes next.

The second meaning is the whole set of those operations for a product. That is the routing header. It has an identity of its own, it belongs to a product, and it owns the steps beneath it.

The engine schedules against the steps, because the steps are where the work lives. But several important things are stated at the level of the header. A product either has a routing or it does not. A job that gets scheduled takes a snapshot of the routing it was planned against, so the plan does not silently change underneath it when someone edits the live routing later. That protection is expressed about the routing as a whole.

The practical rule is simple. When you ask "can this product be scheduled at all", you are asking about the header. When you ask "how long does the mill take", you are asking about a step.

A Concrete Example

A new part number arrives and you need to make it schedulable.

You start by creating its routing. At that moment the routing exists but contains nothing, the way a fresh recipe folder exists before you write any cards. Nothing can be scheduled yet, because there are no operations to place.

Then you add steps into it. Step 10, saw, at the saw work center. Step 20, mill, two hours per unit, one hour setup. Step 30, deburr. Step 40, inspection. Each of those is a step record, and each sits inside the routing you created.

Now the product has a routing with four operations, and the engine has something to work with. When a job for this part gets scheduled, the engine reads those four steps, orders them by their dependency links, and places each one on a work center with real capacity. The job also keeps a frozen copy of that routing, so if someone adds a fifth step next month the running job still reflects what it was actually planned against.

Delete the header and every card in the folder goes with it. That is why the routing state of a product is worth watching: an item with no routing is an item nothing can be planned for.

How EDGEBIC Uses It

The routing header shows up in three places you will notice:

• On the product. A product owns its routing, and the Products dashboard reports which items have one, which have none, and which carry more than one from older data. Items with none cannot be scheduled.
• In the routing editors. Whether you build the routing as a grid of steps or as a flow chart on the design canvas, you are adding steps into a header that already exists.
• In the snapshot taken at scheduling time. The plan freezes the routing it used, so later edits to the live routing do not retroactively change a job that is already on the board.

For the individual operations inside the container, see what is a bill of routing. For the frozen copy a job keeps, see what is a routing snapshot. To build one from scratch, follow how to build a routing step by step.