EH HR Reward
Nominate, approve and grant employee rewards on a governed workflow with a hash-chained audit trail.
Why this module
EH HR Reward
Approval steps, not free edits
A reward cannot be granted by editing a field. It advances draft to nominated to approved to granted through named transitions, each one restricted to a specific HR group, so officers nominate and grant while managers approve or reject.
An audit trail you can verify
Create, write and unlink on a reward emit rows into an append-only audit log. Each row carries a sha256 hash of the previous row, so a single edited entry breaks the chain and verify_chain reports the first broken row.
No bespoke engine to trust
The module owns no workflow or audit code of its own. It reuses the shared platform engines, so the same governance, group gating and audit behaviour apply here exactly as they do across the rest of the EH HR suite.
Day in the life
From shout-out to granted, on the record
An HR officer opens a reward, picks the employee, sets the type to bonus or recognition, fills the amount or points and the reason, then nominates. A manager reviews the nominated record and either approves or rejects it. The officer grants the approved reward; the grant date is stamped and, for recognition rewards, the points are added to the employee's running total and reward count. Every step from creation to grant lands in the hash-chained audit log with who did it and the before and after values, so when someone asks how a bonus was approved months later the answer is already written down and tamper-evident.
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 declares, so a granted reward cannot be quietly walked backwards.
Each transition lists the groups allowed to run it. A user outside those groups, and not an admin, gets a UserError instead of silently advancing the record. Officers nominate and grant; managers approve and reject.
The employee total sums points only from rewards in the granted state. A nominated or rejected reward contributes nothing, so the leaderboard cannot be inflated by drafts.
Audit rows are serialized by a transaction-scoped Postgres advisory lock, so two concurrent writes cannot fork the chain. Each row hashes the previous tail; verify_chain walks forward in bounded batches and returns the first broken row id.
company_id is required and defaults to the active company. A write that moves a reward into a company the user does not belong to is refused, and any permitted cross-company elevation is itself written to the audit log.
Where a transition is configured to require an approval chain, the engine captures the real submitter before elevating to sudo, so the person who fired a gated transition cannot later approve their own request even if they hold an approver group.
What is inside
Built to do the job, end to end.
- Reward model and lifecycle. eh.hr.reward with reference, employee, reward type (bonus, recognition, gift, promotion), amount, points, reason, nominated-by and granted date. References auto-generate as RWD/year/00001 from a company-independent sequence. State buttons drive nominate, approve, grant and reject.
- Recognition points on the employee. hr.employee gains a one2many of its rewards plus computed eh_reward_points and eh_reward_count, summed from granted rewards only, giving a simple recognition leaderboard without a separate scoring module.
- Platform mixins it builds on. The model inherits the workflow mixin, the audited mixin and the strict company-aware mixin, plus mail.thread for chatter. Audited fields captured are state, employee, type, amount, points and reason.
- Security and menus. Access rights for HR admin, manager, officer and self-service employee, with unlink limited to admin. A Rewards menu under the HR records section, visible to the HR officer group.
- Tests. Shipped tests cover default reference and type, the grant and reject paths, grant stamping the date, points tallying on grant and points accumulating across multiple granted rewards.
Honest about the edges
What this does not do, so nothing surprises you.
- Targets Odoo 17 Community. It is part of the EH HR Platform and requires eh_hr_core, eh_hr_compat and eh_hr_engine_workflow plus the standard hr app; it is not a standalone module.
- The workflow, audit log and multi-company behaviour live in the platform engines, not in this module. This module wires rewards onto them and adds no engine code of its own.
- The shipped reward workflow advances states directly with group gating. It does not by default route grants through a multi-step approval chain; the approval-chain path exists in the engine and would need a transition configured to require it.
- Recognition points are a simple sum on the employee for a basic leaderboard. There is no points budget, redemption, expiry or catalogue.
- There is no payroll posting or accounting entry. The amount field records the monetary value of a reward but does not create a payslip line or journal entry.
- There is no employee self-nomination portal flow; rewards are created and progressed from the backend by HR users with the appropriate groups.
Odoo 17 employee rewards, employee recognition Odoo, HR rewards module, bonus approval workflow, recognition points Odoo, staff recognition software, promotion approval Odoo, gift and bonus tracking, employee reward management, multi-company HR Odoo, HR audit trail, reward nomination approval, EH HR Platform, hr.employee rewards, recognition leaderboard Odoo
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.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
The New Zealand country pack for the ERP Heritage Employment Hero integration
A reusable two way synchronisation engine that keeps Odoo in step with the people and payroll platform, idempoten...
The Australia country pack for the ERP Heritage Employment Hero integration
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1373 |
| Technical Name |
eh_hr_reward |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
Please log in to comment on this module