Routings

A part's sequence of operations, defined once and instantiated per work order with setup time plus run time × quantity.

Settings → Routings — “The sequence of operations a part goes through.” The page says what a work order gets: “one request per step, chained in order, with setup time plus run time × quantity.” Without this, a shop that runs the same bracket forty times a year draws the same chain forty times by hand. A routing is that chain as data.

What a routing is

A routing is an ordered list of steps. Each step names an operation and how long this part takes on it:

  • The operation is a request template. The template carries what the operation needs: the resource type under Needs, and the criteria. One Mill template serves every part that is milled.
  • The times are the part’s. Setup is paid once per work order. Run per unit is paid once per unit. Lag after is the minimum gap before the next step can start.

Quantity is not part of the routing. The work order sets it.

Creating a routing

Add Routing opens Create Routing:

  • Name — for example Bracket BR-100.
  • Description — optional context.
  • Steps — one row per operation, in order. Each row has Operation (a request template), Setup (min), Run per unit (min) and Lag after (min). Add step appends a row. The arrows move a row up or down, and the bin removes it.

Orkyo refuses a routing with no steps, a step with no operation, and a step with zero setup and zero run time. The operation must be a request template. A template with no resource type is accepted here. Because a step scheduled onto nothing is not an operation, a work order from that template is refused.

Managing routings

The list shows Name, the number of Steps with their operations in order, and Description. Sort and filter from the column headers, like every list in Orkyo. Edit freely. A change affects future work orders only. Deleting asks for confirmation. “Work orders already created from it are kept.”

Creating a work order

On the Requests page, New from routing opens the work-order form:

  • Routing — which routing to instantiate. When the name is empty, choosing a routing fills it.
  • Name — the work order, for example WO-2026-0142.
  • Quantity — “Each step takes setup time plus run time per unit × quantity.”
  • Site — when the workspace has more than one site, the form shows this field.
  • Earliest start and Latest end — optional. “Every step inherits this window.”
  • Parent — when the workspace has a group, the work order can go under it.

Create work order writes everything in one step, or nothing:

  • A container request with the name you entered. Its description names the routing.
  • One request per step, named 1. Saw, 2. Mill and so on, under the container. Each lasts setup + run × quantity minutes, needs the operation’s resource type, and carries the operation’s requirement values.
  • A finish-to-start dependency from each step to the next, with the step’s lag.

A step whose operation names no resource type stops the whole work order. The message names the step: “Step 2 (‘Mill’) targets no resource type, so it cannot be scheduled.”

Scheduling a work order

The result is ordinary requests. One auto-schedule run places every step across every resource type it needs, in order, in working minutes. A saw operation of 20 minutes, a mill operation of three hours and a deburr of 45 minutes finish on the same day. The critical path reports the chain to the minute.