| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 2642 |
| Technical Name |
eh_hr_attendance_roster |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Attendance Roster
Template-driven shift planning that generates real shifts, drives roster overtime, and sharpens late detection, no Enterprise license.
Why this module
Attendance Roster
Templates become real shifts
Build a shift template once with a row per active weekday (start, end, break). Set it as an employee's default and the daily cron materialises concrete shifts up to your horizon, default 28 days ahead. Re-running never duplicates: generation is idempotent on employee and start time.
Rosters that actually drive hours
Generated shifts are not decoration. Each attendance resolves to its covering rostered shift, so hours beyond the rostered window count as daily overtime and ordinary hours over the weekly or fortnightly cap land as period overtime on the later shift. Late detection also tightens to the planned shift start plus grace.
Open shifts, claims, and swaps
Leave a shift unassigned and it is flagged as open for staff to claim, with guards against double-booking. Swap requests move a shift to a colleague on manager approval, and the approval blocks when the target already has a shift at that moment so you never hit a raw database error.
Day in the life
From weekly pattern to a checked roster
A planner builds a Mon to Fri 9 to 5 template, assigns it as the default for the floor team, and the overnight cron fills four weeks of shifts for every employee who has a default template, in their company timezone. One shift is left open for cover; a casual claims it the next morning. Someone requests a swap and the manager approves it, with the system refusing if the colleague is already rostered then. As the week's attendances land, hours past each rostered window and over the 38 hour weekly cap surface as roster overtime, and a late arrival is judged against the planned shift start plus grace rather than a blanket company time.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Re-running the cron, or running it for an overlapping horizon, never creates a second shift for the same employee and start. A database UNIQUE(employee_id, date_start) plus a pre-create existence check guarantee it.
Generation is batch-capped at 2000 shifts per run and reports progress through the scheduler's commit-progress hook when invoked as a cron, so a large roster does not run away in a single transaction.
Shift start and end are computed in the company partner's timezone then stored in UTC, and an end hour of 24:00 rolls correctly into the next calendar day. An unknown timezone falls back to UTC rather than failing.
Claiming an open shift is blocked if the shift is already assigned, the user has no linked employee, or the user already has a shift starting at that moment. Swap approval applies the same clash check on the target employee.
A swap request cannot target the employee already assigned to the shift; the constraint rejects it before it reaches approval.
The late pass owns the whole comparison when this module is installed instead of delegating to the base pass, so an employee early for their shift but late against the company default is not wrongly flagged, and already-tagged attendances are skipped on re-run.
Adding or editing an attendance recomputes the other shifts in the same week or fortnight, so when a later shift tips the period over the cap the overtime lands on the later shift, not an earlier one.
Global record rules scope shift templates and scheduled shifts to the user's allowed companies, and generation runs company by company using each company's own horizon and timezone.
A template must carry at least one day line, enforced both by a constraint and on create where the constraint would not fire, and each line must have an end hour strictly after its start hour within 0 to 24.
What is inside
Built to do the job, end to end.
- Models. eh.hr.shift.template and its day-pattern lines, eh.hr.roster.shift (the scheduled shift, with open-shift, status, and company computes), and eh.hr.roster.swap. Inherits extend hr.employee, hr.attendance, res.company, and res.config.settings.
- Generation engine. A code-based daily ir.cron runs as the root user and calls the generator, which walks each company's active employees with a default template, builds shifts across the horizon per the template's weekday lines, and creates only the missing ones.
- Overtime engine. Stored computes on hr.attendance resolve the covering rostered shift, subtract the break for net rostered minutes, take daily overtime beyond it, and add the share of ordinary hours over the weekly or fortnightly cap, anchored on Monday with a deterministic fortnight.
- Late detection override. An inherit of eh.hr.attendance.exception replaces the late-check pass so the cutoff follows the planned shift start plus company grace when a shift exists, and the company default time plus grace otherwise.
- Security and views. Four access tiers (user, manager, admin, auditor) over templates, shifts, and swaps, two global per-company record rules, a Roster menu, and calendar plus list plus form views for shifts with tree and form for swaps.
- Tests. Six test modules cover shift generation and idempotency, template validation, open-shift claiming, swaps, roster-driven daily and weekly overtime, and shift-aware late detection.
Honest about the edges
What this does not do, so nothing surprises you.
- Depends on eh_hr_attendance_base and eh_hr_attendance_reports plus core hr_attendance; it extends that suite rather than standing alone.
- Generation works from a single default shift template per employee. There is no multi-template rotation, no per-day exception calendar, and no public holiday awareness.
- There is no skills, role, or coverage-requirement matching and no auto-fill of open shifts; open shifts are claimed manually.
- The swap workflow is a single manager-approval step on a plain state field, with no multi-level escalation ladder and no employee-to-employee consent step.
- Roster overtime is a planning and reporting figure on attendance records; it does not post to payroll, and weekly or fortnightly caps are a flat hours number, not award-rule interpretation.
- Late detection is the only attendance exception this module reshapes; early-leave, absence, and missing-checkout logic stay in the reports module.
odoo 17 roster, odoo attendance roster, shift planning odoo community, hr_attendance roster module, weekly shift template odoo, shift generation cron, open shift claim odoo, shift swap approval, roster overtime odoo, weekly fortnightly overtime cap, shift aware late detection, community edition planning, work schedule odoo 17, planned versus actual attendance, multi company roster
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Please log in to comment on this module