| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Attendances (hr_attendance)
• Discuss (mail) • Employees (hr) |
| Community Apps Dependencies | Show |
| Lines of code | 2638 |
| 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
Roster shifts from weekly templates, then let those shifts drive lateness and overtime, no Enterprise Planning license.
Why this module
Attendance Roster
Templates become real shifts
A shift template carries one row per active day of the week with start, end, and break. Set it as an employee's default and a daily cron materialises concrete shifts up to a configurable horizon, four weeks ahead out of the box. Re-running never duplicates.
The roster actually drives detection
A generated shift is not a dead calendar entry. Its planned start sharpens lateness detection, and its window drives attendance overtime: hours past the shift are daily overtime, and ordinary hours over the weekly or fortnightly cap become period overtime.
Yours to keep
LGPL-3 source on disk. No activation key, no phone-home, no recurring licence. Read it, extend it, fork a model if you need to. Free today, free at renewal, because there is no renewal.
Day in the life
A shift supervisor plans the week and the roster does the rest.
The supervisor builds one weekly template, nine to five Monday through Friday with a thirty minute break, and sets it as the default for the floor team. Overnight the generation cron writes concrete shifts for each rostered employee up to the four week horizon, skipping anyone whose shift already exists. One Saturday shift goes out as an open shift with no employee, and a staff member claims it from the form, blocked only if they already have a shift starting at that moment. When Alice asks to hand her Tuesday shift to Bob, she raises a swap; the manager approves it and the shift reassigns, unless Bob already has a shift at that start, in which case approval is refused rather than crashing. The next morning, lateness is judged against each person's planned shift start plus the company grace, not a blunt company-wide time, and anyone who worked past their rostered window picks up roster overtime, with the week's excess over thirty-eight hours landing on the later shift.
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.
The generation cron is idempotent on (employee, shift start). A database UNIQUE constraint plus a pre-create existence check mean a second run, or an overlapping horizon, never creates a duplicate shift for the same employee and start moment.
Approving a shift swap re-checks that the target employee has no other shift starting at the same moment before reassigning. If they do, approval raises a clear error instead of letting the roster's UNIQUE constraint throw a cryptic database fault.
When this module is installed it owns the whole late-detection pass and deliberately does not call super(). That avoids double-processing shift-covered employees against the company default and double-flagging someone who arrived early for their shift but late against the company-wide time.
Weekly or fortnightly overtime is summed across sibling attendances in the period and lands on the later shift. Adding or editing one attendance recomputes its period siblings, so a shift added later in the week correctly tips earlier ordinary hours into overtime.
The averaging window is anchored on Monday, and a fortnight is pinned to an even ISO week's Monday, so the same attendance always falls in the same period regardless of when the compute runs.
Claiming an open shift is blocked if the shift is already assigned, the user has no linked employee record, or the user already has a shift starting at that moment, so a self-service claim cannot create a clash.
Shift templates and shifts carry a company and are filtered by per-company record rules. A shift's company follows its employee, and an open shift with no employee falls back to the active company.
Generation reads the company timezone, builds local shift times from the template, and stores them in UTC. A template end at midnight rolls the stored end onto the next day so the shift window is correct across the date boundary.
What is inside
Built to do the job, end to end.
- Shift templates with weekly patterns. Each template holds one line per active day of week with a start hour, end hour, and optional break in minutes. Validation enforces hours inside the day, an end after the start, and at least one day per template, checked on both create and write.
- Per-employee default template and generation cron. Assign a default shift template to an employee and the daily cron, running as system, materialises their shifts up to the company horizon (default twenty-eight days), in batches, skipping inactive employees and inactive templates.
- Calendar, list, and form scheduling. Scheduled shifts appear in a weekly calendar coloured by employee, plus a list and form with planned, completed, missed, and cancelled status badges, search filters for today and the next seven days, and group-by employee, status, or day.
- Open shifts and self-service claim. A shift with no employee is flagged as open and can be claimed from the form by the current user's employee record, with guards against double assignment and clashing start times.
- Manager-approved shift swaps. An employee raises a swap to hand a shift to a colleague; a manager approves or rejects it. Approval reassigns the shift, blocked if the target already has a shift at that start, and refuses a swap to the same employee.
- Roster-driven lateness and overtime. A planned shift sharpens the reports module's lateness cutoff to the shift start plus grace, and the shift window drives attendance overtime with daily excess plus weekly or fortnightly period averaging against a configurable cap.
- Four-tier access and per-company isolation. User, manager, admin, and auditor roles map to read and write access across templates, shifts, and swaps, with auditor kept read-only, and per-company record rules scope every roster record to its company.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a rostering and exception layer, not a full Enterprise Planning replacement. It generates shifts from weekly templates and drives detection; it does not do drag-and-drop gantt planning, skill or role matching, demand forecasting, or auto-assignment of open shifts.
- Generation works from each employee's single default shift template on a weekly cycle. There is no rotating multi-week pattern, no per-day per-employee override at generation time, and no public holiday or leave awareness in the cron.
- Shift swaps use a plain status field (draft, requested, approved, rejected) with a manager approval action. There is no multi-step escalation ladder, no delegation, and no separate countersignature beyond the single approve step.
- Idempotent generation and swap approval are protected by a database UNIQUE constraint plus existence checks, not by explicit advisory locks. This is robust for the daily cron and normal use, not engineered for high-frequency concurrent writers against the same shift.
- Roster overtime is computed against the rostered window with weekly or fortnightly averaging and a configurable cap defaulting to the Australian 38 hour standard. It is a roster-driven calculation, not a certified payroll award engine, and does not itself post pay.
- Requires the ERP Heritage attendance base and reports modules and standard hr_attendance. It is designed for this suite, not as a standalone planning app.
Odoo 18 roster, shift planning Odoo Community, hr attendance roster, shift templates, work schedule Odoo, open shifts, shift swap, roster overtime, weekly schedule, planned versus actual attendance, Community Edition planning, self-hosted rostering, employee shift scheduling
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