A job booked on a holiday or downtime day almost always means the closed day was added after scheduling ran. The engine subtracts holidays and downtime before it allocates, so a booking on a closed day is a stale plan, not a live one. EDGEBIC by User Solutions separates off-calendar bookings into four checks by source, each naming the exact closed record, and the fix is nearly always to re-run scheduling.
This post is part of the EDGEBIC troubleshooting guide. It explains why calendar edits are not retroactive, how the four off-calendar checks pinpoint the source, and how to clear each one.
Calendar Edits Are Not Retroactive
The engine builds capacity by starting from a machine's shift hours and subtracting every closed day: plant holidays, machine holidays, shift holidays, and downtime windows. It does this at scheduling time. Once a schedule exists, editing a calendar does not reach back and move it.
That is deliberate. A committed plan should not silently rearrange itself the instant someone adds a holiday. So the moment you enter a closed day, existing schedules that already used it stay in place until you reschedule. A booking on a holiday is the visible result of that rule: the closed day was entered, but scheduling has not been re-run since. This is closely related to why a reschedule can move a job you did not touch, and it comes from the same principle of when the engine reads the calendar.
Four Checks, Four Sources
EDGEBIC's anomaly report splits off-calendar bookings by which calendar was violated. Reading which one fired tells you what kind of closure the plan crossed.
| Check | Fires when a booking falls on | What its detail names |
|---|---|---|
| Plant holiday | A plant-wide closed day | The holiday name and date |
| Work center holiday | A closed day on that specific machine | The machine and date |
| Shift holiday | A closed date range on a shift | The holiday and the shift |
| Downtime event | A one-off or recurring downtime window | The event name and whether it recurs |
One thing about that table matters more than the rest: only the first row has a screen you can enter records on. The engine understands all four kinds of closure and checks bookings against all four, but the current release gives you no way to create work center holidays, shift holidays, or downtime events. So in day-to-day use the plant-holiday check is the one that fires, and the way you close a single machine or a single date is a per-day capacity override rather than a closure record. The shifts and calendars overview covers how the layers stack and which of them you can reach; holiday scope covers the concept.
The Fix, Step by Step
- Run the anomaly report for the job. Read which of the off-calendar checks fired. The detail names the closed record and the date.
- Confirm the closure is where you think it is. For a plant shutdown, confirm the plant holiday covers the full range and is active. For a single machine's maintenance day, the closure is a per-day capacity override on that work center, shift, and date, set to zero or to reduced hours: check the overridden flag in the capacity grid rather than looking for a holiday record that does not exist.
- Re-run scheduling for the affected jobs. The engine now regenerates the plan around the closed day.
- Re-run the anomaly report. A clean off-calendar result confirms nothing is booked inside the closed window.
When a Booking Survives the Reschedule
If an off-calendar check keeps firing after a reschedule, the closed record and the booked record do not line up. Three mismatches cause this:
- The plant holiday does not cover the date it looks like it covers. A recurring holiday matches only the month and day, so a record saved with the wrong month or day fires on a date nobody expected. An inactive holiday is honored by nothing at all.
- The override is on the wrong target. A per-day capacity override is keyed to work center, shift, and date together. Get any one of the three wrong and you have reduced capacity somewhere else while the booked machine keeps its full hours. The overridden flag on the day is the fastest way to confirm.
- The closure was never entered anywhere. This is the quiet one. Someone went looking for a machine-holiday or recurring-downtime screen, did not find it, and the maintenance day never made it into the system. Nothing fires and nothing moves, because as far as the engine knows the machine was open.
Fix the mismatch, then reschedule again. For a booking that lands inside a maintenance window rather than a holiday, a job booked during a machine downtime window covers how the closure gets modeled in the current release. For the neighboring case where a job lands far in the future because closed days consumed its window, see a job was scheduled far in the future. The troubleshooting guide links the full calendar set.
Almost always because the holiday or downtime was added after the schedule was generated. The engine subtracts holidays and downtime before it allocates, so a booking on a closed day means the closed day was not in effect when scheduling ran. Adding a holiday, activating one, or entering a downtime window does not retroactively move existing schedules. Re-running scheduling regenerates the plan around the closed day.
The anomaly report separates off-calendar bookings by source: a plant-wide holiday, a work center holiday, a shift holiday covering a date range, and a downtime event that is either one-off or recurring on a day of week. Each check names the specific closed record and the date. Worth knowing, though, is that only the plant-wide holiday has a screen you can enter records on in the current release. The other three checks watch for closures the engine understands but gives you no way to create, so in practice a firing is nearly always the plant-holiday check, and the machine-level equivalent of a closure is a per-day capacity override.
No. Calendar changes take effect on the next scheduling run, not retroactively. If you add a plant holiday for next Friday, existing schedules that already booked Friday stay put until you re-run scheduling. This is deliberate: the system does not silently rewrite a committed plan the moment you edit a calendar. Add the closed day, then reschedule the affected jobs.
The closed record and the booked record do not line up. For the plant-holiday check, confirm the holiday is active and that its date genuinely covers the booking, remembering that a recurring holiday matches only the month and day. If the machine was meant to be out rather than the plant, check whether the block was ever entered somewhere that exists: a single machine is taken out with a per-day capacity override on that work center, shift, and date, and an override on the wrong shift reduces capacity somewhere you were not looking. The shift-holiday and downtime checks can also fire on records that arrived with imported data, and since neither has an editing screen in this release, those are worth raising with support rather than hunting for.
Expert Q&A: Deep Dive
Q: We added a plant shutdown for the week of July 4 but the schedule still shows jobs running that week. Did the shutdown not save?
A: The shutdown almost certainly saved; it just does not move existing schedules on its own. Calendar changes apply on the next scheduling run. Confirm the holiday record covers the whole week and is active, then re-run scheduling for the affected jobs. Afterward, run the anomaly report and check the plant-holiday finding: a clean result confirms nothing is booked inside the shutdown. If a booking survives, the anomaly detail names the job and date so you can see which one did not move.
Q: One machine has a maintenance day next Tuesday, but a job is still scheduled on it. The plant is open that day. Which calendar do I check?
A: None of the holiday screens, because the plant is open and there is no per-machine holiday screen in this release. A single machine taken out for a day is a per-day capacity override: open that work center's per-day capacity view, find next Tuesday, set the hours to zero, and add a reason. Then re-run scheduling. If the job still sits there, check that the override landed on the shift the job actually runs on, since an override is keyed to work center, shift, and date together. Because the plant is open, only that one machine's jobs should move; everything else stays put.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
An Operation Moved and the Machine Was Free: Finding the Hidden Cause
A job slid and every machine shows open hours. Tooling is the cause the Gantt cannot draw. How to rule it in or out in two minutes before you chase calendars.
An Operation Shows Running Forever Though All Hours Are Logged
A step stays in progress after every hour is logged because completion is an explicit stamp, not an hours threshold. How to close it and stop it recurring.
Another User Changed This Record: Causes and Fixes
EDGEBIC refuses a save when the record moved after you loaded it. The usual cause is a colleague, but the message also appears when you are alone. How to read it and what to do.