| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1323 |
| Technical Name |
eh_hr_reward |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
EH HR Reward
Rewards and recognition, on the record.
Why this module
EH HR Reward
A real approval path, not a status field
Every reward moves draft to nominated to approved to granted on a workflow defined as data. HR Officers nominate and grant, HR Managers approve or reject, and the engine refuses any transition the current user's groups do not allow. Granted and rejected are final states that block further changes.
An audit trail you can verify
Each create, edit and state change is written to an append-only, hash-chained log. The reward captures its state, employee, type, amount, points and reason on every change, so you can show who changed what and prove nothing was edited after the fact.
Owns no engine code of its own
The workflow, audit chain and multi-company scoping all come from the shared EH HR Platform engines. The module adds one clean model and stands on the same audited foundation as the rest of your HR, so it behaves like the modules beside it from day one.
Day in the life
From nomination to a granted reward
A manager opens a new reward, picks the employee, chooses a type such as bonus or recognition, and writes the reason. It is auto-numbered RWD/2026/00001 and starts in draft. An HR Officer nominates it; an HR Manager approves or rejects it; an HR Officer grants it. On grant the date is stamped once and any recognition points roll up onto the employee's running tally and reward count. Every step is tracked in the chatter and written to the hash-chained audit log.
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.
Granted and rejected are marked final. The workflow engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so a granted reward cannot be quietly re-opened or re-rejected.
Granting stamps granted_date with the local-context date only when it is not already set, so re-running the grant action never silently moves the recorded grant date.
The employee point and count tallies filter to rewards in the granted state, so a nominated or rejected reward never inflates the leaderboard. Points from multiple granted rewards accumulate correctly.
Nominate and grant require the HR Officer group, approve and reject require the HR Manager group. A user outside the transition's allowed groups is refused with a clear error, with administrators exempt by design.
Audit rows are serialized by a transaction-scoped Postgres advisory lock so concurrent changes cannot fork the chain, and each row's sha256 binds to the previous one. verify_chain walks the chain and flags the first tampered row.
Rewards default to the active company and are required to carry one. Attempts to move a reward to a company outside the user's allowed set are refused, and any permitted cross-company write is itself audited.
What is inside
Built to do the job, end to end.
- Models this module adds. One model, eh.hr.reward, carrying the reference, employee, reward type, amount, recognition points, reason, nominated-by and granted date. It inherits the workflow, audited and company-aware platform mixins plus mail.thread.
- Standard Odoo models it extends. hr.employee gains a rewards list, a granted recognition-points total and a granted-reward count, computed live from the employee's rewards for a simple in-product leaderboard.
- Workflow and numbering. A Reward workflow definition with states draft, nominated, approved, granted and rejected, and transitions nominate, approve, grant and reject, all shipped as data. A year-prefixed sequence (RWD/YYYY/) auto-numbers each reward.
- Views and access. List and form views with a status bar and stage buttons, a Rewards menu action, and four access rules spanning HR Admin, Manager, Officer and read-only employee self. Six automated tests cover defaults, both workflow paths, the grant date stamp and point accumulation.
Honest about the edges
What this does not do, so nothing surprises you.
- The reward amount is recorded for reference only. This module does not post bonuses to payroll or accounting and does not create payslip lines.
- Approval is enforced by role-gated workflow transitions, not by the multi-step approval engine. There is no N-step escalation ladder or delegation inside this module.
- Recognition points accumulate into a per-employee tally and count. There is no points budget, redemption, spending or catalogue.
- The module ships no scheduled action and no email or notification templates of its own. State changes are tracked in the chatter and the audit log.
- Workflow stages and the numbering sequence are seeded as data and are intended to be configured by an administrator, not redefined per record at runtime.
odoo employee rewards, odoo recognition module, employee recognition odoo 18, staff bonus management odoo, recognition points odoo, hr reward workflow, employee reward and recognition, odoo hr platform, audited hr odoo, odoo 18 community hr, bonus approval workflow, employee leaderboard odoo
Please log in to comment on this module