I Set Two Lot-Streaming Methods on One Step: Which Wins?

When a step carries both a transfer batch and a flow-step lag, the engine sizes the overlap from the piece-count transfer batch and ignores the flow step, because the two are competing ways to express the same overlap and only one can drive the step. EDGEBIC by User Solutions resolves the ambiguity by preferring the transfer batch on a discrete work center, and the anomaly report flags the pair so you can confirm which method you actually meant.

This post covers the two-methods symptom in the EDGEBIC troubleshooting guide. It sits alongside my transfer batch size was ignored and queue time and flow time are fighting each other, which cover related overlap and buffer interactions. For the payoff of overlap done cleanly, see how overlapping operations shorten delivery.

What You Are Seeing

You set a flow step on an operation expecting the downstream step to start after a certain elapsed time, but the downstream step instead started when a batch of pieces was ready. Both a transfer batch and a flow step are set on the same step, and the overlap follows the batch, not the lag you configured.

Why It Happens

Cause 1: The Transfer Batch Wins by Default (the Rule)

When both methods are set, the engine uses the piece-count transfer batch to size the overlap and ignores the flow step, as long as the work center is a discrete, non-continuous process. The two express the same overlap differently, so the engine chooses one, and the transfer batch is the one it prefers.

How to tell: the downstream step starts at a piece-count point, and the step has both a transfer batch and a flow step configured.

Cause 2: The Flow Step Is Now Dead Weight

The flow step you set is not combined with the batch; it is simply unused. It carries no effect while the transfer batch is present, so it neither adds to nor subtracts from the overlap, but it does obscure your intent for anyone reading the step later.

How to tell: clearing the flow step changes nothing, because it was already inactive.

Cause 3: The Ambiguity Was Never Resolved on Purpose

The engine's preference is a default, not a reading of what you wanted. If you meant the flow step to drive the overlap, the default silently chose against you, which is exactly why the anomaly report flags the pair.

How to tell: the anomaly report lists the step for having both methods set.

How to Fix It

• Decide which method you meant. Piece counts point to the transfer batch; elapsed time from the upstream start points to the flow step.
• Clear the method you did not intend. Leaving only one makes the step unambiguous for the engine and for the next reader.
• If you meant the flow step, set the transfer batch to zero so the flow step becomes the only method in play.
• Re-run scheduling and confirm the overlap follows the method you kept.

How to Diagnose It, in Order

1. Check whether the step has both a transfer batch and a flow step set. Both present is the whole cause.
2. Confirm the overlap follows piece counts, which is the transfer batch driving it.
3. Decide your intended method and clear the other.
4. Re-run and read the Gantt to confirm the overlap matches your intent.
5. Clear the anomaly flag by leaving a single method on the step.

How to Prevent It

• Set one overlap method per step, never both, so there is no ambiguity to resolve.
• Match the method to the operation: transfer batch for piece-count overlap, flow step for elapsed-time overlap.
• Treat the anomaly flag as a prompt to confirm intent, not a warning to ignore, since the step works but reads ambiguously.
• Leave the unused method at zero, so a future editor sees exactly which model the step uses. For the piece-count method on its own, see my transfer batch size was ignored.