How a Multi-Day Operation Spreads Hours Across Days

When an operation in EDGEBIC by User Solutions spans several shifts, the engine does not store it as one undifferentiated block of hours. It records a per-day breakdown, attributing to each calendar date exactly the hours the operation consumes on that date. A 28-hour operation that runs a partial Monday, two full middle days, and a partial Thursday is kept as those four daily figures, and their sum equals the operation's hours. That daily attribution is quietly load-bearing: it is what daily load reports read, what capacity checks measure against, and what actuals compare to day by day.

An operation's total hours tell you how much work it is. They do not tell you where that work lands on the calendar, and for a job that runs several days, where it lands is what a planner actually needs to see.

Capacity is a daily quantity

The reason the breakdown exists is that capacity is measured per day. A work center offers some number of hours on a given date, from its shift hours, its instances, and its utilization, as described in how capacity is computed for a work center, shift, and day. To decide whether a particular day is full, the engine has to know how many hours every operation places on that specific day.

A single-day operation is easy: all its hours land on one date. A multi-day operation is not. Its 28 hours are spread across four dates, and the only way to know that Tuesday is at ninety percent is to know that this operation put 8 hours on Tuesday specifically. So the engine records the split as the operation is placed, one figure per day, so that every day's total load is a real sum of real per-day contributions.

The breakdown follows the shifts

The per-day figures are not an even division of the total. They follow the shifts the operation actually fills, which are usually uneven. This is a direct consequence of how the multi-shift allocator fills capacity: it walks the calendar and consumes real hours shift by shift.

An operation that starts at noon only uses that first day's afternoon, so the first day's figure is partial. The full middle days each carry a full shift's worth. The last day carries whatever is left when the work runs out, which is usually partial again. The setup at the front of the operation sits inside that first partial day and is not repeated on the mornings that follow, which is why a multi-day run sets up once rather than each day. The result is a daily profile that ramps in, holds, and ramps out, rather than a flat line. That shape is the truth of where the hours land, and a load report that reads the breakdown shows exactly that.

Weekends, holidays, and downtime punch gaps in the profile. A day the work center is closed carries zero, and the operation resumes on the next open day, so a multi-day operation over a weekend simply has no figure for Saturday and Sunday and picks up Monday. The breakdown records only the days work actually happened.

What the breakdown feeds

Three things read the daily figures, and each needs them.

• Load reports. To show a work center's utilization by day, a report sums every operation's contribution to each date. A multi-day operation contributes to several dates, and its uneven profile is part of the picture. This is the raw material for load leveling across a planning week.
• Capacity checks. When the engine places the next job, it checks how much of each day is already consumed. The daily breakdowns of everything placed so far are what tell it a day is nearly full and the search should move on.
• Actuals comparison. When operators log time, the hours land against specific dates. Comparing planned against actual is only meaningful per day, so a day that ran long shows an overrun on that date, next to the planned figure for the same date, rather than a single blended number for the whole operation.

A worked example: 28 hours across four days

Take an operation needing 28 hours on a single-instance work center with a Monday-to-Friday day shift, 08:00 to 16:00, 8 hours a day. It becomes ready at noon on Monday.

The allocator fills forward:

Monday    12:00-16:00   4 h   (partial first shift)
Tuesday   08:00-16:00   8 h
Wednesday 08:00-16:00   8 h
Thursday  08:00-16:00   8 h
Friday    08:00-08:00... remainder = 0

That is 4 + 8 + 8 + 8 = 28. The operation finishes Thursday at 16:00, and the breakdown is stored as four daily figures: Monday 4, Tuesday 8, Wednesday 8, Thursday 8. A load report for that work center shows Monday only half-loaded by this job and the three following days full.

Now suppose Wednesday actually ran 10 hours because of a problem. The recorded actual for Wednesday is 10, sitting next to the planned 8, so the overrun is visible on Wednesday specifically. On the next reschedule, because the job's remaining work is re-timed from where it actually stands, that overrun pushes the operation's finish and the downstream steps, exactly as resuming from actuals describes. Without the daily breakdown, the overrun would be invisible, buried inside a single operation total that only says "28 planned, 30 actual" with no idea which day went wrong.

Why not just store one number

A single total is simpler to store, but it answers none of the questions a planner asks of a running plan. It cannot say whether Tuesday is full. It cannot show which day of a long job ran over. It cannot feed a daily load chart. The per-day breakdown is a little more data for a lot more visibility, and it is the difference between a schedule that is a black box of totals and one whose footprint on every single day can be read directly.

The daily breakdown is one of the quiet mechanisms that make finite scheduling legible, and it plugs into the wider pipeline in the scheduling engine guide. It exists for the same reason the whole engine does, captured in finite versus infinite capacity scheduling: a plan is only useful when you can see where the work really lands. To watch your own multi-day operations spread across your real shifts, explore the EDGEBIC engine or bring your data to a demo.