Shifts, Holidays, and Calendars in EDGEBIC: The Plant Clock

A production shift calendar is the set of rules that tells a finite scheduler when work is possible, and in EDGEBIC it resolves into a single number: available hours for one work center, one shift, one date. Everything visible downstream (Gantt bars, utilization percentages, promised delivery dates) is that number, computed thousands of times. Get the calendar wrong and every promise inherits the error.

EDGEBIC by User Solutions builds the calendar from four layers that stack in a fixed order: shifts, holidays, downtime, and planner overrides. This article explains what each layer is for, how they combine, and which of them you can actually configure on a screen today. The click-by-click setup is in the calendar setup guide, and the exact arithmetic is in how EDGEBIC resolves capacity day by day.

Layer 1: The Shift

A shift is a named weekly pattern. Day Shift, Night Shift, Weekend Shift. Each weekday carries its own working-day checkbox and its own start and end time, which means one shift can run ten hours Monday through Thursday, eight on Friday, and nothing at the weekend.

Two properties make shifts the right unit of plant time:

They are shared. One shift record serves many work centers. Extend Day Shift by two hours and every work center that inherits it gains two hours a day, in one edit.

They are literal. The scheduler believes the times exactly as entered. A shift that says 08:00 to 16:00 offers eight hours, not "about a day".

Shifts are plant-wide master data, and most work centers should simply inherit them. A work center that genuinely runs a different pattern (the one mill staffed on nights, the cell that works Monday to Thursday) can carry its own calendar instead, which is covered in work centers explained.

Breaks are not a separate field on the shift. Model a plant-wide lunch either by defining the shift hours net of the break, or as a recurring partial holiday for the break window. If no job may span the break, define two shifts instead of one.

Layer 2: Plant Holidays

A plant holiday is a closure that affects every work center and every shift. Two dimensions matter.

Recurring or one-off. A recurring holiday matches the same month and day every year, so Christmas is entered once and expands into every year the scheduler plans across. Only the month and day of the date matter for a recurring record; the year is ignored.

Whole day or partial. A whole-day holiday removes the date entirely: every work center returns zero capacity and the scheduler skips it. A partial holiday blocks only a window, and the subtraction is computed per shift.

The partial version is the more useful of the two, because most real interruptions are not full days:

blocked hours = max(0, min(shift end, holiday end) − max(shift start, holiday start))

A quarterly all-hands from 10:00 to 10:45 against a 08:00 to 16:00 day shift blocks 0.75 hours. Against a 16:00 to 00:00 night shift it blocks nothing, because the two windows do not overlap. One record, entered once, charged correctly to each shift.

That overlap is subtracted before the instance and utilization multipliers, so it scales with the size of the work center. On a two-machine work center, a 45-minute meeting costs 1.5 hours of schedulable capacity, exactly as it does in the building.

Closures Come at Three Scopes

A closure is not always plant-wide, and the scheduler recognizes three levels that coexist without double-counting:

The hierarchy resolves in the obvious direction. A whole-day plant holiday wins outright: no work center gets an allocation that day regardless of what the other two levels say. Below that, a shift-scoped closure blocks one shift while the others keep working, and a machine-specific closure takes one work center out while its neighbors continue.

Only the plant level has a screen. That table describes what the engine understands, not what you can create. Shift-scoped and machine-specific closure records are honored if they exist, but the current release gives you no way to enter them, so treat the plant holiday page as the one closure surface you have. Anything narrower than the whole plant is a per-day capacity override: set the affected machine, shift, and date to reduced hours or to zero, with a reason. For a single machine's teardown day that is the whole procedure, and it leaves a better audit trail than a closure record would, because the override shows in the grid with the reason attached.

Layer 3: Downtime

Downtime is unavailability inside a shift rather than instead of it: a lubrication window, a PM slot, a one-off bearing replacement. It subtracts hours from the shift without eliminating the shift, and the engine treats it exactly that way: the hours come off the per-machine shift duration before the multipliers, which is why an hour of PM on a three-instance work center removes three hours of capacity, not one. Maintenance on multi-machine resources is always more expensive than the clock suggests.

That is the concept, and the capacity effect is real. What does not exist in the current release is a downtime record you configure on its own screen. Standalone downtime events and shift-scoped closures are honored by the scheduling engine, but there is no UI for creating them, so the practical way to put maintenance into the calendar today is one of three:

• Net it into the shift. If the loss is genuinely every week, define the shift hours net of it. Simple, permanent, and it never drifts.
• A partial plant holiday for a dated, plant-wide interruption. Note that the recurring flag matches the same month and day each year, so it fits an annual event rather than a weekly one.
• A per-day capacity override for anything specific to one machine on one date: type the reduced hours, or zero, and add the reason.

The override version is arguably the better record anyway. It carries a reason and shows as overridden in the grid, so six months later the plan still explains why that Wednesday was short.

Layer 4: Capacity Overrides

The first three layers describe the rules. The fourth lets a planner state an answer directly.

A per-day capacity override sets the effective hours for one work center, one shift, one date. It carries a reason, it is flagged as overridden in the grid, and it replaces the formula entirely for that cell. Approved Saturday overtime, a half-day PM window, a temporarily de-rated machine, a single machine closed for its annual teardown: all of them are one typed number rather than a calendar edit. This is the workhorse of the fourth layer and the one you will actually use.

A date-range override, which spreads a total hours budget across a period, also exists in the engine, but it has no visible entry point in the current release. Per-day overrides cover the day-to-day cases, including a retooling week, which is five typed numbers rather than one budget.

Resolution runs in a strict order, and the more specific instruction wins:

1. per-day override for this work center, shift, and date
2. date-range override covering this date
3. the shift-hours formula

The one rule that catches people: an override is the total for the day across every machine in the work center. The engine uses it verbatim and never multiplies it by the instance count. On a three-instance work center where each machine will run four hours, the entry is 12.

How the Layers Become a Number

For every work center, shift, and date:

available hours = (shift hours for that weekday
                   − downtime
                   − partial-holiday overlap)
                  × number of instances
                  × utilization %

An example with real numbers. CNC-Mill-1 has one instance and works Day Shift, 08:00 to 16:00. Its Monday capacity is 8 hours. Add a second instance and it becomes 16. Put the quarterly all-hands on that Monday and it becomes 7.25 per machine, so 14.5 across two.

Before the formula runs at all, a date gate can zero the day outright: the work center is unavailable, its effective date has not arrived, a machine-specific closure covers the date, a whole-day plant holiday covers the date, or the date is a weekend with weekend production off. That gate is why a work center can show zero capacity with a perfectly valid shift attached.

What Changes When You Save, and What Does Not

This is the part that surprises new planners, and it is deliberate.

Saving a calendar change never reschedules anything. The plan on screen was computed against the old calendar and keeps its dates, including allocations that may now sit outside working hours. Run the schedule again to rebuild it, and note the guarantee that makes that safe: completed work is never moved by a reschedule.

The effect is large. Take a 20-hour milling job on a single-instance work center, day shift only, starting Monday morning. At 8 hours a day it finishes Wednesday at noon. Extend the shift to 10 hours and rerun, and it finishes Tuesday at 18:00. A full day earlier, with nothing changed but the calendar. The same lever works in reverse, which is why adding a holiday or unticking a weekday pushes end dates out at the next run.

The Calendar Is Also the Quote

Quote simulation runs through the same engine and the same calendar, so a quoted delivery date already accounts for holidays, downtime, and overrides. That is worth knowing for two reasons: quotes stay honest without a separate maintenance job, and a calendar left optimistic will make sales promise dates the plant cannot hit.

This is also why the calendar is where a new implementation starts. The greenfield walkthrough builds shifts first, then work centers, then routings, in that order, because a work center without working hours has no capacity to configure.

Keeping It Honest

Standard finite-capacity practice, and the reasoning behind buffer management in the Theory of Constraints and APS literature, is that a resource planned to 100% of the theoretical clock has no recovery room: the first breakdown propagates through every downstream date. Express the headroom in the calendar rather than in hope. Honest shift hours, partial plant holidays, and per-day overrides are all read identically by the scheduler and the dashboards.

A few standards that hold up in practice:

• Name shifts by when they run, not by who works them. The name appears on every capacity screen and every allocation.
• Prefer global shifts. Every custom work center calendar is one more place to update when the plant pattern changes.
• Enter recurring holidays once with the recurring flag rather than maintaining a row per year, which invites gaps.
• Model meetings and breaks as partial holidays, not by shrinking shifts. The record documents why the hours are missing.
• One-off exceptions belong in per-day overrides. Editing a shift for one approved Saturday changes every week and every work center on it.
• Rerun the schedule after any calendar change and review the result before communicating dates.

Next

Build the calendar with the step-by-step setup guide, which covers the shift and plant-holiday screens. Understand exactly how the layers resolve in how EDGEBIC resolves capacity day by day. Then read the shift and calendar mistakes that produce right-looking, wrong plans. If a job has landed somewhere it should not, a job scheduled on a holiday explains the usual cause.