A Shift That Crosses Midnight Logged Hours on the Wrong Day

When an overnight shift logs all of its hours on the day it started, that is shift-start-date anchoring working as designed: a shift that crosses midnight is treated as one shift belonging to its start date, so even the hours worked after midnight roll up to the day the shift began. EDGEBIC by User Solutions keeps an overnight run whole rather than splitting it into two partial days, which is what makes the totals look surprising until you know the rule.

This post covers the wrong-day symptom in the EDGEBIC troubleshooting guide. It is close to but distinct from a booking falls outside its shift hours, which is about a time window rather than a calendar date. For how logged hours reach the plan in the first place, see how kiosk actuals close the planning loop, and for the shift definition itself, what a work center shift is.

What You Are Seeing

A night shift runs from late evening into the next morning, and every hour it produces, including the ones worked after midnight, appears on the calendar day the shift started. The daily total for that first day looks too high, and the next day looks empty, even though the crew clearly worked into it.

Why It Happens

Cause 1: Shift-Start-Date Anchoring (the Usual Answer)

A shift that crosses midnight is one working period, and the engine credits it to the calendar day it starts. A shift beginning at 22:00 and ending at 06:00 attributes all eight hours to the start day. This keeps the overnight run as a single block for capacity, resource load, and daily rollups rather than fracturing it into two partial days.

How to tell: the hours land on the correct shift, just all on the start date, and the split matches the overnight span exactly.

Cause 2: The Shift Is Defined to Start on the Wrong Day

If the hours truly belong to a different calendar day, the shift definition is the lever. A shift whose start day is set one day off from your intent credits its whole run to that off-by-one day, and the anchoring then carries that offset forward.

How to tell: the shift's defined start day does not match the day you expect the run to belong to.

Cause 3: A Kiosk Punch on the Wrong Calendar Date

Anchoring only explains why a run credits to its start day. It does not move hours to an unrelated date. If a job's hours landed on a day the shift did not run, or a day off by more than the overnight span, the punch itself was recorded against the wrong calendar day.

How to tell: the hours sit on a day the shift is closed, or far from the overnight window, not merely on the start day. Hours sitting on a date the operation's own bar does not cover are a separate case, covered in hours landed on a date outside the operation window.

How to Fix It

• For anchoring: nothing to fix. The overnight run correctly belongs to its start date, and capacity totals treat it as one block. Adjust your reporting convention if you need hours attributed to the day physically worked.
• For a mis-defined shift: set the shift to start on the day you want its hours credited, then re-run scheduling.
• For a wrong-date punch: correct the actuals entry to the real date in the Job View or at the kiosk, then reschedule so the plan re-anchors to the corrected reality.

How to Diagnose It, in Order

1. Compare the split to the overnight span. If all the hours sit on the start day and the shift runs into the next morning, that is anchoring, not an error.
2. Confirm the hours are on the right shift, just the start date. Anchoring keeps the shift correct.
3. Check the shift's defined start day if you expected a different calendar date entirely.
4. Look for a punch on a closed day or one far from the shift window, which points at a wrong-date entry rather than anchoring.
5. Correct the punch date, then reschedule, if the entry was genuinely mis-logged.

How to Prevent It

• Teach the crew the anchoring rule. An overnight shift belongs to its start date, so the "missing" next-day hours are expected, not lost.
• Define overnight shifts to start on the day you want the hours credited, so anchoring carries your intent, not an off-by-one.
• Verify the punch date at the kiosk when logging near midnight, since a date entered a day off is the one case anchoring cannot explain.
• Log actuals first, then reschedule, so any date correction is in place before the plan re-anchors to it. For tracing which source wrote a suspect value, actual dates look wrong walks each origin.