EH HR Gratuity
End-of-service gratuity computed, approved, and settled on a configurable, audited HR workflow.
Why this module
EH HR Gratuity
A formula you can read
The payout is (basic salary / 30) times gratuity days per year times years of service, computed and stored on every change. Days per year is a per-record value (default 21), so you set the accrual basis instead of trusting a hidden constant.
Settlement that is approved, not just typed
Each record walks a draft, computed, approved, paid lifecycle. Compute and cancel sit with HR Officers, approve and mark-paid with HR Admins. The states and transitions are data records, so the ladder can be reshaped without touching Python.
Every change is on the record
State, employee, years of service, basic salary, days per year, and the computed amount are written to an append-only, SHA-256 hash-chained audit log. A built-in chain check flags any row that was altered after the fact, which is what a termination payout dispute needs.
Day in the life
Settling a leaver, start to finish
An HR Officer opens a gratuity, picks the employee, and enters years of service and basic salary. The amount computes live from the days-per-year basis. They press Compute and the record locks into the computed state. An HR Admin reviews and Approves, then marks it Paid once payroll has released the funds. Paid is final: no quiet edits, no re-opening, no transition out of it. Every step, and every figure behind it, is on the chatter and in the audit chain.
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.
Once a gratuity is Paid or Cancelled, the workflow engine refuses any further transition, even one a misconfigured definition might declare from it. The terminal marker is authoritative.
When a transition is approval-gated, the engine captures the real submitter before it elevates to sudo, so the user who fired the request cannot later approve their own request even if they hold an approver group.
company_id is required and defaults to the active company. Writing a gratuity into a company the user does not belong to is rejected, even under sudo, unless an explicit audited override context is set, and the elevation is logged with every affected record id.
Audit appends take a transaction-scoped Postgres advisory lock so concurrent writers cannot read the same chain tail and fork it. Hashes stay strictly ordered under load.
A transition is only allowed from its declared source state and only for users in its allowed groups. Approving a draft, or paying something not yet approved, raises a clear error instead of skipping steps.
A database CHECK constraint rejects negative years of service or negative basic salary, so a fat-fingered minus sign cannot produce a nonsense settlement.
What is inside
Built to do the job, end to end.
- The gratuity record. eh.hr.gratuity holds the employee, computation date, years of service, basic salary, days-per-year basis, and the stored computed amount. References auto-number as GRAT/<year>/00001 from a shared sequence. List and form views, a statusbar, and a chatter come ready to use under HR Records.
- Configurable workflow. States (draft, computed, approved, paid, cancelled) and the transitions between them are data records on the platform workflow engine, each carrying its own allowed groups. You can relabel steps or change who may act without editing code.
- Audit and company mixins. The record inherits the platform audited mixin and the strict company-aware mixin. Creates, writes, and deletes emit hash-chained audit rows; company scope is enforced on create and write. This module owns no audit or workflow code of its own, it consumes the shared engine.
Honest about the edges
What this does not do, so nothing surprises you.
- Computation uses a single days-per-year basis per record (default 21) and a flat years-of-service input. It does not ship country-specific statutory gratuity tables, banded accrual rates, or partial-year proration logic; enter the basis and service figure that your policy or jurisdiction requires.
- Mark paid records the settlement state in the workflow. It does not post a journal entry or payment into Odoo Accounting and does not generate a payslip or PDF certificate.
- There is no scheduled job or wizard in this module; gratuities are created and advanced manually by authorised HR users.
- Requires the EH HR Platform modules (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow) and Odoo HR. It is a settlement record on that platform, not a standalone payroll engine.
end of service gratuity odoo, EOSB odoo 19, gratuity calculation odoo, terminal benefits HR, final settlement payroll, employee offboarding odoo, severance pay module, odoo HR workflow approval, audited gratuity trail, multi company HR odoo, Odoo 19 Community HR, gratuity settlement workflow
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