We’re experiencing issues with our labor management workflow in GPSF 2023.1 where overtime calculations are completely wrong for employees working split shifts. The problem becomes even worse when shifts cross midnight.
Our manufacturing facility runs 24/7 with rotating shifts. Some employees work split shifts (4 hours morning, 4 hours evening) and the overtime calculation logic isn’t handling these scenarios properly. For example, an employee worked 6am-10am and then 6pm-11pm (9 total hours), but the system only logged 8 hours with no overtime.
The cross-day workflow support seems problematic too - when a shift starts at 11pm and ends at 7am the next day, the overtime calculation treats it as two separate days instead of one continuous shift. This is causing major payroll errors and employee complaints.
Has anyone dealt with similar split shift handling issues in the labor-mgmt workflow? We need the workflow to properly recognize continuous work periods even when interrupted or crossing day boundaries.
Be careful with the consolidation window approach - if you set it too high (12 hours), you might accidentally merge shifts from consecutive days for employees working back-to-back doubles. A better approach is using shift codes or work order associations to explicitly group related time entries. In our facility, we assign the same shift code to both parts of a split shift, and the workflow uses that as the grouping key rather than time gaps.
Let me provide a comprehensive solution that addresses all three issues you’re facing: overtime calculation logic, split shift handling, and cross-day workflow support.
Overtime Calculation Logic Fix:
The core problem is that GPSF’s default labor workflow calculates overtime per clock-in/clock-out event rather than per work period. You need to modify the workflow to use a two-phase calculation approach:
- First phase: Aggregate all time entries that belong to the same logical shift
- Second phase: Calculate overtime against the aggregated total
In the workflow editor, add a ‘Shift Aggregation’ node before your overtime calculation node. Configure it with these key settings:
- Grouping Key: Employee ID + Shift Date + Shift Code
- Time Window: Set based on your facility’s needs (I recommend 16 hours to handle split shifts but prevent day-crossing issues)
- Aggregation Method: Sum all clock hours within the grouping window
Split Shift Handling:
For proper split shift support, implement a shift association strategy. There are two approaches:
Approach A (Recommended): Use shift codes that employees select at clock-in. When an employee clocks in for the second part of their split shift, they use the same shift code. Your workflow groups all entries with matching Employee ID + Shift Code + Date.
Approach B: Configure intelligent time gap handling. In the labor-mgmt workflow, set:
- Maximum gap between shift segments: 10-12 hours
- Minimum gap to treat as new shift: 14 hours
- This prevents merging consecutive days while allowing reasonable breaks
Cross-Day Workflow Support:
This is the trickiest part. You need to redefine what constitutes a ‘work day’ in your facility:
- Define your facility’s ‘day boundary’ (e.g., 6:00 AM rather than midnight)
- Create a custom workflow function that normalizes all timestamps to this boundary
- Modify the date grouping logic in your overtime calculation nodes
Here’s the workflow modification approach:
- Add a ‘Timestamp Normalization’ step at the beginning of your labor workflow
- This step adjusts the ‘shift date’ field: any clock-in between midnight and 6am gets assigned to the previous calendar day
- Example: Clock-in at 2:00 AM on March 16 → Shift Date = March 15
- All downstream calculations (including overtime) now use ‘shift date’ instead of ‘calendar date’
Implementation Steps:
- Open your labor management workflow in the GPSF workflow editor
- Before the existing overtime calculation node, insert the Shift Aggregation node
- Configure the aggregation node with the grouping rules I described
- Modify your overtime threshold check to operate on aggregated hours rather than individual entries
- Add the timestamp normalization step if you need cross-midnight support
- Test with sample data covering: normal shifts, split shifts, cross-midnight shifts, and back-to-back shifts
Additional Configuration:
In the labor-mgmt module settings, verify:
- OT Calculation Scope = ‘Consolidated Shift’
- Shift Consolidation Window = 12 hours (or your chosen value)
- Day Boundary Offset = 6 hours (if using 6am boundary)
Validation:
After implementing these changes, test these scenarios:
- Employee works 6am-10am, then 6pm-11pm (should show 9 hours, 1 hour OT)
- Employee works 11pm-7am (should count as single 8-hour shift on starting day)
- Employee works two separate 8-hour shifts on consecutive days (should NOT merge)
This solution comprehensively addresses your overtime calculation accuracy, split shift recognition, and cross-day boundary issues. The key is moving from event-based to shift-based calculations and redefining your facility’s concept of a work day to match operational reality rather than calendar boundaries.
The cross-midnight issue is a known limitation in older GPSF versions. Your workflow needs a custom time boundary definition. Instead of using calendar days (12am-12am), define a ‘work day’ that aligns with your shift patterns - maybe 6am-6am. This way a shift starting at 11pm is still within the same work day until 6am the next morning. You’ll need to modify the workflow’s date/time calculation logic in the labor tracking nodes.
Another thing to watch - make sure your overtime threshold is being calculated against the consolidated shift total, not individual segments. We found our workflow was checking each 4-hour segment against the 8-hour threshold independently (both under, no OT triggered) instead of checking the combined 9-hour total. There’s a setting in the labor-mgmt workflow editor under ‘OT Calculation Scope’ that needs to be set to ‘Consolidated Shift’ rather than ‘Individual Entry’.
Thanks for the suggestions. I found the shift consolidation window setting - it was set to 30 minutes which explains why our 8-hour gap between split shifts wasn’t being recognized. I’ve increased it to 12 hours for testing. However, I’m still not clear on how to implement the custom work day boundary. Is this a workflow configuration change or does it require modifying the labor-mgmt module’s core logic?
I’ve seen this before. The default labor management workflow in GPSF treats each clock-in/clock-out pair as independent events. For split shifts, you need to configure shift grouping rules that associate multiple time segments within the same workday. Check your workflow’s time calculation node settings - there should be a parameter for ‘shift consolidation window’ that defines how long gaps between shifts can be while still counting as the same work period.