When to Schedule in Pieces Instead of Hours

EDGEBIC by User Solutions offers three capacity modes on every work center: hours, pieces, and both, and only the third one changes the answer the scheduler gives you. Hours and pieces are two ways of asking the same question. Both is a genuine constraint check, and it exists because some equipment cannot go as fast as a routing claims.

The definitional material is in work centers explained and how EDGEBIC calculates work center capacity. This post is about choosing between the modes and what each one does when it meets the rest of the configuration.

Two Separate Questions

Every scheduled operation needs two numbers answered, and it helps enormously to keep them apart:

1. How long does this operation need? This is what the capacity type controls.
2. How much time can this machine offer on this day? This is the shift capacity formula, and it is the same regardless of capacity type.

The second is always available shift hours, minus downtime and partial holidays, multiplied by the instance count, multiplied by the utilization percentage. Work centers run at their full clock in current versions, so an eight-hour shift on a three-instance machine offers 24 hours. That does not change because you switched to pieces. How to configure instances and utilization covers that half.

What changes is the first number.

The Three Modes

Hours. The duration comes from the routing: hours per unit multiplied by order quantity, plus the resolved setup. This is the default and it suits any machine whose cycle time is a property of the part. A mill takes longer on a complicated housing than on a simple bracket, and the routing is where that difference lives.

Pieces. The duration is derived from the machine's own output rate rather than the routing. Effective output is the rated pieces per hour multiplied by an efficiency factor, and the operation needs the order quantity divided by that effective rate. This suits equipment whose throughput is a property of the line and barely varies by part: a bottling line, a packaging machine, a conveyorized wash.

Both. Both durations are computed and the longer one wins. This is the mode that actually stops a plan being optimistic.

Where Both Earns Its Place

Take a bottling line rated at 120 pieces per hour with an efficiency factor of 0.9, so an effective 108 per hour. The routing carries 0.005 hours per unit, which is three minutes per bottle. The order is 500 bottles.

The routing says two and a half hours. The line physically cannot do it. Under the hours mode, the plan promises the shorter figure and the floor misses it every single run, which is exactly the pattern that erodes trust in a schedule. Under both, the plan says 4.63 hours and is honest.

The general rule: use both when a routing time exists but a physical output rate is the real ceiling. Use hours when the routing time genuinely governs. Use pieces alone when the routing time is a rough placeholder that nobody maintains and the rate is the number the shop actually believes.

The Zero-Rate Trap

A machine set to pieces with a pieces-per-hour rate of zero produces durations that are meaningless, because there is nothing to divide the quantity by.

This is by some distance the most common configuration error on this feature, and it is at least a loud one: the resulting durations are absurd rather than subtly wrong, so it is spotted on the first run rather than a month later. The rule is unconditional. If the capacity type includes pieces, the rate on the routing step is not optional.

The rate and the efficiency factor are deliberately separate fields. Put the equipment's nominal rating in the rate, and express the real-world derate as the factor, which is bounded between 0.1 and 2.0. That way a rebuild that recovers speed is a change to one number, and the machine's nameplate capability is not lost.

Batch Limits

Pieces-capable machines also carry minimum and maximum batch sizes. They are validation bounds on a proposed allocation quantity rather than a scheduling objective: the engine checks that what it is about to allocate falls inside the range.

They are useful where the physics has real limits, such as an oven that cannot be loaded below a certain fill or a line that cannot run above a certain queue depth. They default to permissive values, so leaving them alone is fine on equipment where there is no genuine limit. Inventing bounds you do not actually have will only produce rejections you then have to explain.

Three Fields Named Something Like Efficiency

This is the naming collision most likely to waste an afternoon.

Two of those are load-bearing on a pieces-based machine, one is inert, and the fourth belongs to a different feature entirely. The utilization percentage is the one people reach for and cannot turn: it is genuinely in the formula, but current versions run work centers at 100% and expose no editor for it. To make a machine offer less than a full shift, shape the calendar with honest shift hours, record recurring maintenance as downtime, or use a per-day capacity override on the days that genuinely differ. All three carry a reason and are read identically by the scheduler and the dashboards. Changing the plain efficiency field, meanwhile, will look like it should do something and will not.

Instance and utilization mistakes covers the wider set of traps on the capacity side, and capacity shows zero for a work center is the diagnosis path when a machine offers nothing at all.

Unit of Measure Is a Hint, Not a Control

Every unit of measure carries a scheduling behavior with the same three values: hours, pieces, or both. It reads as though it should drive the work center's behavior. It does not.

The unit's behavior acts as a hint and a sensible default when you are building work centers that handle that unit. The work center carries its own capacity type independently, and that is the field the engine reads. If a unit says pieces and the machine says hours, the machine wins.

Both the capacity type and the unit of measure appear as read-only columns on the work centers grid, so the practical instruction is simply to read them there rather than assuming the machine inherited from the unit. Two minutes of checking on setup saves the class of confusion where a planner changes a unit's behavior and nothing happens.

What the Operators Log Is a Separate Decision

What the floor records is independent of how the engine plans, and keeping the two apart is useful. A shop whose routings are trustworthy in hours may still count output in pieces on the floor, because pieces are what the operator can see.

There is nothing to configure for that. The terminal captures both measures at every machine: during a run the elapsed clock advances on its own, and the good and scrap counters are there to tap. Which measure becomes the recorded truth is decided when the day is logged, through the Auto Calc Hours control in the daily actuals grid. Ticked, typing one side derives the other from the operation's rate; unticked, both are recorded independently. See what is an actual entry mode for the convention and how to capture hours or pieces for a work center for the walkthrough. A machine planned by hours whose floor counts pieces is not a contradiction to resolve; both halves already reflect reality.

There is a second reason to capture pieces even on an hours-based machine. Logged piece counts feed the overlap calculation on a reschedule: when an upstream operation is in progress and the transfer batch threshold has already been crossed in real counted pieces, the downstream start is set from the crossing rather than from a projection. That is only available if somebody logged pieces. How to log actual hours and pieces covers the kiosk side, and lot streaming explained covers the overlap it feeds.

Choosing a Mode by Equipment Type

The oven and booth rows point at two other settings that pair with capacity type. A machine where a job occupies the whole unit for the day wants the one-job-per-instance-per-day flag rather than a rate. How EDGEBIC picks an instance covers that choice. A machine producing a continuous stream wants the continuous-process flag, which changes which overlap model applies; scheduling ovens, baths and other continuous-process equipment covers it.

Migrating an Existing Machine

Switching an already-configured machine from hours to both is a low-risk change, but it is not a no-op, and it is a setup-level change rather than a toggle a planner flips between runs. Capacity type belongs to the work center record and appears as a read-only column on the grid.

The duration of every future operation on that machine can only stay the same or get longer, because both takes the maximum. Existing scheduled jobs keep their planned durations until they are rescheduled. So the sequence that produces the least surprise is:

1. Get the rate right on the routing step first, while the machine is still planned by hours. Nothing changes yet.
2. Compare the derived piece duration against the routing duration on a few representative orders. If they are close, the routing is already honest and the change buys you little. If the piece duration is consistently longer, you have found real optimism in the plan.
3. Have the capacity type changed to both on the work center record.
4. Run a full reschedule so existing jobs pick up the longer durations, and expect the finish dates on that machine's work to move out.

Step four is the one worth warning people about. A machine that has been quietly under-planning will produce a visible jump in completion dates the first time both is enabled. That jump is the truth arriving, not a regression, but it goes down better when the plant has been told to expect it.

What Pieces Capacity Does Not Do

Two limits are worth stating so the mode is not asked to carry more than it does.

It does not sequence by rate. A pieces-based machine still takes work in the order jobs are dispatched, and slot selection still follows the run's strategy. Nothing groups high-rate products together to protect throughput. If that grouping matters, it is a sequencing decision made through priority, the slot strategy, or the optimizer, as covered in deciding what runs first.

It does not replace overlap. The rate decides how long an operation needs; it says nothing about when the next operation may start. A pieces-based line that feeds a downstream operation still needs a transfer batch or an hour lag if you want them to overlap. The two features happen to both involve piece counts and are otherwise unrelated.

The batch bounds sit in a similar place. They validate an allocation quantity rather than steering one, so a minimum batch is a rejection rule rather than an instruction to accumulate work until the minimum is reached.

Verifying After the Change

Three checks confirm the configuration is doing what you intended.

Compare a scheduled operation's planned hours against the arithmetic by hand on one order. Under both, they should match the longer of the two models. Check that the machine's daily capacity in the capacity view still reflects instances and utilization as before, because the capacity type does not change that half. And confirm the daily actuals grid is carrying the side your floor genuinely counts, since a gap there produces missing actuals rather than wrong plans.

For the full picture of how a machine's day is computed, how EDGEBIC resolves capacity day by day is the deeper reference. For the whole feature map, see the complete guide.