What Is an Off-Calendar Booking Check in Scheduling?

An off-calendar booking check is a scheduling anomaly test that flags any hours a plan has booked onto a date or window where the resource was supposed to be closed. It compares every allocation against four separate sources of non-working time: a plant-wide holiday, a holiday that belongs to one work center, a holiday that belongs to one shift, and a downtime window such as planned maintenance. Each firing is a warning scoped to a single job, so it names the job that assumes people and machines who will not be there.

Think of it as reading the plan against the wall calendar. The arithmetic in the plan may be perfect, but if it schedules eight hours of milling on a day the doors are locked, those eight hours will not happen, and everything queued behind them slides.

This entry belongs to the EDGEBIC by User Solutions glossary. For the wider vocabulary, see the manufacturing glossary, and for the parent concept, the definition of a scheduling anomaly.

How the Off-Calendar Booking Check Works

Non-working time in a production schedule does not come from one place. It comes from a small hierarchy, and each level closes a different slice of the plant. The check runs one test per level.

The first test looks at plant-wide holidays: dates entered as a global closure that applies to the whole working day. If a booking lands on one of those dates, the whole site was closed and the hours cannot be real.

The second test looks at work-center holidays: closures entered against one specific machine or cell. Here the check must match the work center as well as the date, because a shutdown of the heat-treat oven says nothing about the mills.

The third test looks at shift holidays: closures entered against one shift over a date range, again for the whole working day. This test matches on the shift the booking was assigned to, so a night-shift closure does not flag day-shift work on the same date.

The fourth test looks at downtime windows: blocks such as preventive maintenance. Unlike the holiday tests, these are time windows rather than whole days, and they can either be a one-off block or a block that recurs on a given day of the week. The check evaluates both forms.

Every one of the four reports at warning severity and at job scope. That combination matters: a warning will not stop you publishing, and job scope means the report hands you a job number to open rather than a vague plant-level complaint.

One practical caveat before you go looking for records. The check tests four sources, but the current release lets you create only the first: the plant holiday. There is no editor for work center holidays, shift holidays, or downtime events, so the way you actually close a single machine or a single date is a per-day capacity override on that work center, shift, and date. Reading the check is still worth doing, because it tells you what kind of closure the plan crossed; just do not go hunting for a downtime screen that is not there.

Why Bookings End Up Off-Calendar

The plan does not drift onto closed days by itself. The engine reads the calendar when it schedules and honors it. So a firing tells you one of two stories.

The common story is sequence. The plan was built while the day was still open, and the closure was entered afterward. Adding a holiday record does not reach back and move bookings that already exist, so the plan and the calendar quietly disagree until something compares them. That something is this check.

The second story is scope. Non-working time entered at the wrong level closes far less than intended. A per-day capacity override entered against the wrong shift leaves the shift that actually runs wide open, because an override is keyed to work center, shift, and date together. The check catches the mismatch because it tests where the closure actually landed, not where you meant it to land.

There is a third story that is really a variant of the second: the closure was never entered at all. Of the four sources the check tests, only the plant-wide holiday has a screen in the current release. Someone who goes looking for a per-machine holiday or a recurring downtime editor will not find one, and if they stop there the maintenance day never reaches the system. Nothing fires, nothing moves, and the machine keeps taking bookings, because as far as the engine knows it was open.

A Concrete Example

A fabrication shop closes on the Monday of a public holiday weekend. The planner enters the closure on the Thursday before, then runs the anomaly report before publishing the week.

Two jobs come back flagged. Both were scheduled on the Tuesday of the prior week, when that Monday was still an ordinary working day, so their hours sit squarely on the closed date. The plan is not corrupt: the arithmetic is fine, the machines exist, the hours add up. It simply assumes a Monday that will not happen.

The planner re-runs the schedule for those two jobs. The engine now sees the closure, skips Monday, and places the hours on Tuesday and Wednesday instead. Downstream steps queue behind the new end dates, the report comes back clean, and the week is publishable.

Had the planner instead taken a single machine out with a per-day capacity override, only that machine's bookings would have moved, and the check would have kept flagging every other cell that still had Monday work. The severity would still be a warning, but the story would be a scope error rather than a timing one.

How EDGEBIC Reports Off-Calendar Bookings

In EDGEBIC, the off-calendar tests run inside the Scheduler Anomalies report under the Reports menu. Run it for a single job while you are debugging, or plant-wide to sweep everything before you publish. Each firing names the job, the work center, and the date, so the trail from the report row to the offending allocation is one click.

The four calendar sources it tests are plant holidays, work center holidays, shift-level closures on a work center shift, and downtime events. Only the first of those is a record you create on a screen in the current release; the other three are concepts the engine honors but gives you no editor for. In practice that means a firing points you at one of two things: a plant holiday whose date or active flag is wrong, or a machine-level block that should have been a per-day capacity override and either landed on the wrong work center, shift, or date, or was never entered at all.

For the practical walkthrough of running the report and acting on what it returns, see how to run and read the anomaly report, and for the symptom-first version of this exact problem, a job was booked on a holiday. The habit worth building is simple: enter calendar changes first, re-run the affected jobs second, and treat a clean off-calendar strip as part of what publishing a week means.