| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1303 |
| Technical Name |
eh_hr_gratuity |
| License | LGPL-3 |
| Website | https://erpheritage.com.au |
| Versions | 16.0 17.0 18.0 19.0 |
EH HR Gratuity
End-of-service gratuity computed, routed through a group-gated workflow, and written to a tamper-evident audit chain.
Why this module
EH HR Gratuity
One formula, stored and tracked
Gratuity is (basic salary / 30) times days per year times years of service, computed and stored on the record. The days-per-year basis is a data value per record, so you set the accrual rate without touching code.
Officer computes, admin approves and pays
The workflow advances draft to computed to approved to paid, with cancel available from draft. Each transition is restricted to an HR group, so computation and final payment sit with different roles by default.
Every change on a hash chain
Create, write, and unlink events land in an append-only audit log. Each row carries the sha256 of the previous row, so any silent edit is caught by the chain verifier. Field snapshots cover state, employee, salary, service, and amount.
Day in the life
Settling a leaver
An HR officer opens a new gratuity record for the departing employee, fills in basic salary, years of service, and the days-per-year basis, and the payout amount computes immediately. They press Compute and the record moves to computed. An HR admin reviews the figure and presses Approve, then Mark paid once the settlement is disbursed, landing the record in its final paid state. Behind the scenes, every step writes a before-and-after snapshot to the audit chain, so the full history of who changed what and when is reconstructable later. A record entered against the wrong leaver can be cancelled from draft, but once paid the workflow refuses any further transition.
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.
Paid and cancelled are terminal. The engine refuses any transition out of a final state, even one a misconfigured definition might declare, so a settled record cannot be silently reopened.
When a transition is gated through the platform approval engine, the original submitter is captured before the engine elevates to sudo, so the user who fired a gated transition cannot later approve their own request even if they hold an approver group.
Audit appends take a transaction-scoped Postgres advisory lock, so two concurrent writes cannot read the same chain tail and fork it. The lock releases automatically on commit or rollback.
A write whose before and after snapshots are identical for the captured fields emits no audit row, so no-op saves do not pad the trail with empty events.
Company is required and defaults to the active company. Moving a gratuity record into a company the user is not a member of is refused, and any audited cross-company override is recorded with every affected record id.
A database CHECK constraint rejects negative years of service or negative basic salary, so a bad keystroke cannot produce a nonsensical payout.
Each transition checks the user against its allowed HR groups before advancing, so an officer cannot approve or mark paid a record reserved for an admin.
What is inside
Built to do the job, end to end.
- The gratuity record. A single eh.hr.gratuity model holds the employee, computation date, years of service, basic salary, days-per-year basis, and the stored gratuity amount. References are auto-numbered with a yearly GRAT sequence on save.
- The workflow engine. States and transitions are defined as data on the shared EH HR Platform workflow engine, not hard-coded. The statusbar and transition buttons are driven from that definition, and the module declares only its own state graph.
- The audit mixin. An audited mixin emits create, write, and unlink events into the platform hash-chained log, capturing before-and-after snapshots of state, employee, years of service, basic salary, days per year, and amount.
- Roles and access. Access rights map to HR admin, officer, and manager groups. Admin has full control, officer can create and edit but not delete, manager has read-only visibility.
Honest about the edges
What this does not do, so nothing surprises you.
- This module does not own workflow or audit code. It depends on the EH HR Platform engine modules (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow), which must be installed.
- The gratuity formula is fixed as (basic salary / 30) times days per year times years of service. Only the days-per-year basis is data-driven per record; the divisor and structure are not configurable in this module.
- The shipped workflow is a linear officer-computes, admin-approves-and-pays segregation. It does not configure a multi-step approval chain or escalation ladder out of the box, although the underlying engine supports gated approvals.
- Years of service and basic salary are entered manually on the record. The module does not auto-derive tenure from contract or attendance history, nor read salary from a payroll structure.
- There is no posting to accounting or payroll. Mark paid records the settlement state for audit and reporting; it does not create a journal entry or payslip.
- There is no built-in country-specific labour-law variation or end-of-service ceiling. Local rules must be reflected by setting the days-per-year basis and amounts yourself.
odoo end of service gratuity, odoo 16 gratuity module, end of service settlement odoo, gratuity calculation odoo, EOS gratuity HR, final pay settlement odoo, severance odoo HR, leaving entitlement odoo, days per year gratuity accrual, hash chained audit trail odoo, multi company HR odoo, odoo HR workflow approval, employee end of service payout, odoo community payroll gratuity
Please log in to comment on this module