How a Shutdown Week Stops Breaking Your Promise Dates

Nearly every shop has promised a delivery that ran straight through its own shutdown week, because the closure lived in everyone's memory rather than in the capacity calendar. EDGEBIC by User Solutions removes the days instead of warning about them: a whole-day plant holiday blocks that date for every work center and every shift, so no schedule and no quote can place hours there. A date that was never possible stops being offerable, which is a better control than reminding people.

This post covers the promise-date outcome. It sits under the EDGEBIC results guide. For the procedure itself, see how to schedule around a planned shutdown week.

The Promise Nobody Meant to Make

It happens in June. A customer asks for a delivery in the second week of July. The salesperson checks the backlog, sees room, and confirms. Everyone in the room knows the plant closes the first full week of July, and nobody thinks of it, because the closure is not part of the arithmetic being done. It is a fact about the year rather than a fact about capacity.

Two weeks of production disappear from the plan on the day the plant locks the doors, and every promise built on those days breaks at once. That is the part that hurts: it is not one late job, it is a cohort of jobs that were all quoted against the same phantom capacity.

The fix is not discipline. Salespeople and planners already know about the shutdown. The fix is making those days absent from the number they read.

Removing the Days, Not Warning About Them

A whole-day plant holiday takes a date out of capacity for every work center and every shift. The engine then has nothing to place there, so the closure propagates automatically into every date the system produces: schedule dates, quote simulation dates, and the completion dates on any what-if you run.

The model has four levels, and knowing which to use is most of the skill:

A holiday record covers one date, so a five-day shutdown is five records. Weekends the plant already does not work need no record, because they are already outside the shift calendar. If the closure repeats on the same month and day every year, mark it recurring and it applies each year without re-entry. See EDGEBIC shifts and calendars explained for how the layers resolve together.

Saving Is Not Rescheduling

Saving holidays changes the calendar and moves nothing. You then pick the jobs whose work overlaps or runs near the closure and run a reschedule, and the engine flows their work before and after the closed days.

That separation is intentional and worth defending. Master data changes and replanning are two decisions. If every calendar edit silently rearranged the floor, nobody could safely correct a typo in a holiday name. Here you edit, review, then choose which jobs to replan.

Completed work is not affected either way. Operations that carry an actual start and an actual end are preserved exactly as logged and excluded from replanning, so a shutdown entered mid-year does not disturb the record of what already happened. See why a mid-job reschedule keeps your finished work.

The Arithmetic of a Missed Week

A shutdown is not a delay, it is a capacity subtraction, and the two behave differently.

Take a plant with 12 work centers on one shift, 8 hours a day:

Four hundred and eighty hours does not push out by a week. It pushes out until the surrounding weeks can absorb it, and the surrounding weeks were already loaded. That is why a shutdown that is planned for looks like a quiet fortnight and a shutdown that is not planned for looks like a bad August.

Loading the calendar in April costs nothing. Loading it in late June means every promise made in between was computed against hours that do not exist, and the correction lands as a batch of date-change calls you have to make.

The Quoting Side

The larger benefit is upstream of the schedule. A quote simulation runs the job against the same finite capacity and the same calendars, so the estimated dates it returns already contain the closure. The salesperson does not have to remember the shutdown, subtract a week, and hope.

This is the same reason quote scenarios respect maintenance downtime rather than ignoring it. A promise date is only as honest as the calendar behind it, and a calendar that is missing a fortnight makes every date in that period optimistic by exactly that fortnight. See EDGEBIC quote simulation explained and how credible promise dates win bigger orders.

What This Does Not Solve

It does not create the capacity you lost. Removing the days makes the plan honest, not larger. If the backlog does not fit around the shutdown, you still have a decision to make: overtime before the closure, a capacity override to run part of a weekend, or moving dates while it is still a conversation.

It only knows the closures you enter. A supplier's shutdown, a customer's receiving dock closing for inventory, and a carrier's holiday are all real constraints and none of them are in your calendar unless you model them, usually as transit time rather than as capacity.

Recurring means month and day. It is right for a fixed national holiday and wrong for a shutdown week that moves with the calendar. For a moving shutdown, enter the dates each year; it is five records and about five minutes.

Entering it late still leaves the promises you already made. The calendar corrects the future. Quotes already sent and orders already confirmed have to be reviewed by hand, which is the argument for loading the year's closures during annual planning rather than when someone notices.

A partial closure needs care. A half-day holiday scales capacity rather than removing the day, and getting the scope wrong is the most common way a holiday reduces too much or too little. See how a schedule accounts for holidays and downtime and the generic seasonal capacity planning view.

Want to see your own year loaded before quoting season? Bring your closure dates and a backlog to a demo and we will show what the promise dates look like with the shutdown in place.