What Is a Work Center Occurrence Suffix in a Routing?

A work center occurrence suffix is a small marker added to a routing step's display identity when the same work center appears more than once in that routing, so each visit stays distinguishable from the others. A part that is rough-milled, sent for heat treatment, then finish-milled passes through the same machine twice, and those two passes are different operations at different points in the sequence even though the machine's name is identical. The suffix is what keeps them apart when something needs to refer to one of them by name. EDGEBIC by User Solutions carries it on the step's display name only, leaving the underlying work center reference untouched.

How it works

A routing is a sequence of steps, and steps refer to each other so the scheduler knows what must finish before what. Those references can be resolved in two ways, and the difference matters entirely when a machine repeats.

By identifier, which is always unambiguous. Each step has its own identity independent of which machine it uses, so a successor link that names a step identifier points at exactly one step no matter how many times the machine appears. This is the preferred route and the one the editor populates.

By name, which is a fallback. Older or imported routings sometimes express links by naming the successor rather than identifying it. This works perfectly while every machine appears once, and stops working the moment one appears twice, because the name no longer identifies a single step.

The occurrence suffix exists to rescue the second case. Giving the two milling visits distinct display identities means the name-based lookup has something to distinguish them by, and the correct visit is found. It is a naming device, not a structural one.

Two properties of the suffix are worth being precise about.

It lives on the display identity, not on the work center reference. The step still points at the same real machine, and the machine's own name is unchanged. Nothing about capacity, calendars or setup is affected by whether a step carries a suffix, because none of those read the display identity.

It survives into schedule rows, and reporting handles that. Because the marker is part of how the step identifies itself, it can appear on the scheduled operation too. Summary views that report load per machine deliberately strip it back to the base name so both visits group under one heading, which is correct: the machine is one machine and its hours are its hours. Operation-level views keep the visits separate, which is also correct, because they are separate operations.

A concrete example

A shaft routing runs: turn, mill, heat treat at an outside vendor, mill again to finish, then inspect. The two milling steps use the same machine, because the shop has one mill and the part needs it twice.

Without any distinguishing marker, the routing contains two steps both identifying themselves as milling. When the finish operation after heat treatment declares that it follows milling, a name-based lookup finds the first match, which is the rough milling step. The scheduler concludes the finish milling can begin as soon as rough milling ends, and places it before the heat treatment has even started. The plan looks plausible on the board and is physically impossible.

With occurrence suffixes, the rough pass and the finish pass identify themselves distinctly. The finish operation's link resolves to the second visit. The scheduler waits for heat treatment plus its transit days, and the finish pass lands where it belongs.

The better fix, applied in the same sitting, is to make the links identifier-based so the naming stops mattering at all. The two approaches are complementary rather than alternative: distinct display identities make the routing readable to a human scanning it, and identifier links make it unambiguous to the engine regardless of what anything is called.

Once scheduled, the mill's own load report shows both passes under one machine heading, totaling their hours together, which is what a capacity conversation needs. The job's own view shows two separate operations at two separate points in the week, which is what a shop floor conversation needs.

How EDGEBIC uses it

The suffix is a naming convention rather than a feature to switch on, and it matters most on routings that were imported or hand-built rather than assembled in the editor, since the editor populates identifier links as a matter of course. Where a routing genuinely revisits a machine, the recommended practice is both: identifier links for correctness and distinct display identities for legibility.

How the engine builds the sequence from those links is covered in how EDGEBIC orders operations dependency graphs, and the link field itself is described in what is a next in sequence link in a routing. The ordering that results is described in what is a topological sort in job scheduling.

The failure mode a missing suffix produces is a dependency resolving to the wrong step, which surfaces the same way other sequencing faults do: see what is a dependency violation in scheduling and dependency and sequencing mistakes in EDGEBIC. The gap between the two milling visits in the example is created by the routing's own waiting rules, described in what is transit time in production scheduling.

The takeaway

A work center occurrence suffix solves a naming problem, not a scheduling one. The scheduling problem underneath it is that a routing which revisits a machine has two steps that look identical to anything reading names, and the durable fix is to stop reading names by linking steps through their identifiers. Where you inherit a routing you did not build, a machine appearing twice is the specific thing worth checking, because the symptom it produces is a plausible-looking plan in which a later pass runs before the process in the middle of it. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.