How Queue, Flow, and Transit Stack After an Operation

After an operation ends, EDGEBIC by User Solutions composes up to three timing layers before the next operation may start, and it applies them in a fixed order: queue time first, then lot-streaming flow, then transit days. Each layer is optional, each answers a different question, and the order they stack in determines the successor's earliest start. Understanding the stack explains why a gap between two operations is sometimes longer than any single field suggests, and why turning on lot streaming can make a queue time appear to vanish.

The time an operation occupies a machine is only part of a step's footprint. Just as important is what happens in the gap before the next operation begins. That gap is not one thing. It is a small stack of distinct mechanisms, and they interact in ways worth knowing.

Three layers, three jobs

Each layer models a different real-world delay.

• Queue time is a buffer the successor waits before it may start, a deliberate cushion that absorbs variability so the downstream operation is not starved the instant the upstream one finishes. It is shift-aware, meaning it is measured against the calendar of working hours rather than raw clock time. The case for keeping it is covered in why queue time is not wasted time.
• Flow time, or lot streaming, is the opposite instinct. Instead of making the successor wait, it lets the successor begin before the upstream operation fully completes, because the first transfer batch of parts is already available. This is what overlaps two operations and shrinks total lead time.
• Transit days model the physical movement of material after it is ready, such as shipping a batch to another building or plant. This is a whole-day delay layered on after the work is done.

Queue and flow are competing answers to the same question, when can the next step begin. Transit is a separate concern, when does the material arrive, so it composes after whichever gate applies. A parallel group adds a fourth kind of padding that is easy to confuse with the first layer, and how a synchronized group buffer differs from queue time sets the two apart.

The order the engine applies them

EDGEBIC composes these in a fixed sequence at the point it finishes an operation:

operation end
  -> apply queue time (shift-aware)
  -> apply flow / lot streaming (if active, this becomes the gate)
  -> apply transit days (calendar or working-day)
  = successor earliest start

The order matters because of one interaction. When a lot-streaming flow is active on a step, the flow result replaces the queue-adjusted end rather than adding to it. The streaming time is itself the successor's start gate, so it overrides the queue rather than stacking behind it. If you genuinely need a fixed handling lag on top of streaming, that is a separate transfer-delay value, which does add. EDGEBIC surfaces the queue-plus-flow case as an anomaly so a planner can confirm which behavior they intended rather than being surprised by it.

Transit days sit at the bottom of the stack. Whatever gate came out of the queue-or-flow step, transit adds its whole-day delay after it. So a job with a flow overlap and a transit still gets the transit, because material still has to move once the streamed parts are ready.

Calendar days versus working days

Transit has one more choice: how to count its days. In calendar mode, the days run straight through, so a four-day transit that departs Thursday lands the following Monday, weekend included. In working-day mode, only shop-open days count, so the same four-day transit skips Saturday and Sunday and arrives later in the following week. You choose the mode per step, which lets an over-the-road shipment (which does not care about your shop calendar) use calendar days while an internal move that depends on a receiving dock being staffed uses working days. The plant-to-plant version of this is explored in how transit time between plants affects a schedule.

A worked example: the same gap, three ways

Take two operations. Op 10 finishes Thursday at 14:00 on a Monday-to-Friday day-shift calendar, 08:00 to 16:00. Op 20 depends on it. The step carries a 4-hour queue time, and we will vary the flow and transit.

Queue only. The 4-hour shift-aware queue runs from Thursday 14:00 to Friday 10:00 (2 hours Thursday afternoon, 2 hours Friday morning, jumping the overnight). Op 20's earliest start is Friday 10:00.

Queue plus a 2-day calendar transit. The queue lands Friday 10:00, then transit adds 2 calendar days: Saturday and Sunday. Op 20's earliest start is Sunday 10:00, which the calendar then rounds forward to the next open shift, Monday 08:00, because Sunday is not a working day.

Queue plus a 2-day working-day transit. The queue lands Friday 10:00, then transit counts only shop-open days: Monday and Tuesday. Op 20's earliest start is Tuesday 10:00. The weekend was skipped by the counting itself, not just rounded away afterward.

Flow instead of queue. Now suppose Op 10 has a lot-streaming flow that makes the first transfer batch ready 1 hour into its run. The flow becomes the gate and replaces the queue-adjusted end, so Op 20 can begin as soon as that batch exists rather than waiting the 4-hour queue. If the step also carries transit, the transit still applies after the streamed batch is ready.

Same two operations, same 4-hour queue field, and four different successor starts depending on which layers are active and how transit counts. None of it is arbitrary. Each result is the fixed stack applied to the data on the step.

When to use which layer

Reach for queue time when you want a protective buffer between operations, a cushion against upstream variability. Reach for flow, or a transfer batch, when the operations can overlap and you want to compress lead time by starting the successor early. Reach for transit when material physically moves and that movement takes real days, and pick working-day mode when the arrival depends on the shop being open. The one combination to be deliberate about is queue plus flow on the same step, because flow wins and the queue you entered will not add. When both are set, decide whether you meant streaming with a handling lag (use transfer delay) or a plain buffer (drop the flow).

This stack is one slice of the larger pipeline. The complete scheduling engine guide places it alongside dependency ordering and capacity, and how one late operation ripples through a job shows how a delay in any layer cascades to the finish. The reason these gaps are honored at all rather than assumed away is the same one behind finite versus infinite capacity scheduling: a plan is only trustworthy when every real delay is on it. To see how your own routings compose these delays, explore the EDGEBIC engine or bring your data to a demo.