My Transfer Batch Is Larger Than the Order Quantity

When a transfer batch larger than the order quantity produces no overlap, the engine capped the batch at the order quantity, turning it into a single full-order batch, and one batch that equals the whole order has no partial to hand off before the operation finishes. EDGEBIC by User Solutions sizes the first hand-off from the smaller of the transfer batch and the order quantity, so a transfer batch bigger than the order behaves exactly like no lot streaming at all.

This post covers the oversized-batch symptom in the EDGEBIC troubleshooting guide. It is a close cousin of my transfer batch size was ignored and lot streaming did not overlap my operations. For why overlap matters at all, see how overlapping operations shorten delivery.

What You Are Seeing

You set a transfer batch to enable overlap between two operations, but the downstream step still waits for the upstream step to finish completely. The operations run back to back on the Gantt, with no overlap, and the transfer batch you entered is larger than the order quantity for the job.

Why It Happens

Cause 1: The Batch Was Capped to the Order Quantity (the Rule)

The engine uses the smaller of the transfer batch and the order quantity when it sizes the first hand-off. A transfer batch of one thousand on an order of five hundred becomes five hundred, which is the whole order. A single full-order batch cannot move downstream early, because there is no partial quantity to pass while the upstream step keeps working.

How to tell: the transfer batch you entered is greater than or equal to the order quantity.

Cause 2: The Order Is Small

Even a modest transfer batch can exceed a small order. A batch that overlaps a five-hundred-piece order fine offers nothing on a fifty-piece order if the batch is above fifty. The cap is relative to each order's quantity.

How to tell: the same batch overlaps larger orders but not this small one.

Cause 3: You Expected the Batch to Add Capacity

A transfer batch controls overlap, not throughput. Sizing it large does not push more work through; it just removes the overlap by collapsing to one batch. If the goal was speed, overlap comes from a smaller batch, not a larger one.

How to tell: the intent was to go faster by making the batch big.

How to Fix It

• Set the transfer batch below the order quantity. A partial batch must exist for the downstream step to start early.
• Size it to a handful of hand-offs. On a five-hundred-piece order, a batch of one hundred gives five hand-offs and real overlap.
• Account for small orders. A batch that overlaps large orders may exceed a small one, so review the batch against each order's quantity.
• Confirm the overlap on the Gantt after a run, rather than assuming the setting took effect.

How to Diagnose It, in Order

1. Compare the transfer batch to the order quantity. Batch greater than or equal to order means no overlap by rule.
2. Lower the batch below the order quantity and re-run.
3. Read the Gantt for overlap between the two operations.
4. Check whether the order is unusually small, which caps even a moderate batch.
5. Run the anomaly report, which flags a transfer batch larger than the order quantity so the intent is confirmed.

How to Prevent It

• Always size the transfer batch below the order quantity, since a full-order batch cannot overlap.
• Pick a batch that yields a practical number of hand-offs, not dozens, so downstream setup exposure stays reasonable.
• Review batch sizing when orders are small, where a standard batch can exceed the quantity.
• Verify overlap on the Gantt after any lot-streaming change, because the setting is accepted even when it produces no effect. For the difference between piece-count batches and a flow-time overlap, see lot streaming did not overlap my operations.