| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1357 |
| Technical Name |
eh_hr_insurance |
| License | LGPL-3 |
| Website | https://erpheritage.com.au |
| Versions | 16.0 17.0 18.0 19.0 |
EH HR Insurance
Employee insurance policies, named beneficiaries, and an expiry watch, on the shared HR workflow engine.
Why this module
EH HR Insurance
A thin record on a hardened engine
The module ships policy and beneficiary models, views, and a workflow definition. It writes no workflow, audit, or company-scope code of its own. Those guarantees are inherited from the platform mixins, so the same engine that governs the rest of the HR suite governs insurance too.
States and gates from data, not code
The draft, active, expired, cancelled progression and its allowed transitions live in workflow definition records, not hardcoded selections. The statusbar and transition buttons are driven from that definition, and each transition is gated to the HR Officer group.
LGPL-3 source on disk
No activation key, no subscription, no phone-home. Read the models, extend the policy types, fork it if you need to. Free today and free at renewal, because there is no renewal.
Day in the life
An HR officer logs a new health plan and checks what is lapsing.
A new starter is enrolled in the company health plan. The officer creates a policy: the reference number is generated automatically as INS/2026/00001, the company defaults to their own and cannot be silently pointed at another, and the record opens in Draft. They record the provider, coverage amount, monthly premium, and a cover end date, then name two beneficiaries, a spouse at 60 percent and a child at 40 percent, and the beneficiary share rolls up to 100. Activating the policy is a single gated transition, captured as a tracked state change and an append-only audit row. Later, the officer scans the policy list: any cover ending within the next 30 days shows its expiring-soon flag and its exact days to expiry, so renewals get chased before they lapse. Every field change along the way is snapshotted before and after into 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.
Every create, write, and unlink on a policy emits a row into a hash-chained audit log. Each row stores the sha256 of the previous row plus its own fields, so any later edit that does not recompute the entire downstream chain is caught by verify_chain. Appends are serialised by a transaction-scoped Postgres advisory lock so concurrent writers cannot fork the chain.
company_id is required and defaults to the active company. A write that tries to move a policy into a company the user is not a member of is rejected, even under sudo, unless an explicit audited override context is set. The cross-company elevation is itself written to the audit trail with every affected record id.
Expired and cancelled are marked final. Once a policy reaches either, any further transition is refused, even one a misconfigured definition might declare from it. The is_final marker is authoritative, so a closed policy cannot be quietly reopened.
Activate, expire, and cancel each carry the HR Officer group. A user outside the transition's allowed groups is refused with a clear error rather than silently advancing the record. The current state is checked against the from-state, so a transition not defined from where the record sits is rejected.
Each beneficiary share is constrained at the database level to between 0 and 100 percent by a CHECK constraint, enforced even on direct SQL paths. The policy exposes a computed total of all shares so a split that does not add up to 100 is visible at a glance.
Where a transition is configured to require approval, the engine captures the real submitter before it elevates to sudo, so the user 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.
- Policy record. eh.hr.insurance carries provider, policy number, policy type (health, life, dental, disability, other), coverage amount, premium with monthly, quarterly, or annual frequency, and cover start and end dates. The reference number is generated from a yearly sequence (INS/YYYY/00001) on save.
- Named beneficiaries. eh.hr.insurance.beneficiary lists each payee with their relationship (spouse, child, parent, sibling, other), an ordered handle, a contact field, and a payout share. Shares are bounded 0 to 100 by a CHECK constraint and rolled up into a total on the policy.
- Expiry watch. days_to_expiry and an is_expiring_soon flag are computed from the end date, with the flag true when cover ends within the next 30 days. The list view surfaces the flag so lapsing policies are visible without a report.
- Workflow and audit. A draft, active, expired, cancelled workflow with HR Officer-gated transitions, a status bar driven from the workflow definition, mail-thread tracking on key fields, and an inherited append-only hash-chained audit trail capturing state, employee, provider, policy number, type, coverage, premium, and dates.
Honest about the edges
What this does not do, so nothing surprises you.
- This module records premiums and frequency as data. It does not post premiums to payroll or accounting, accrue them, or generate any journal entries.
- The expiring-soon flag and days-to-expiry are computed on read. There is no scheduled job and no email or activity reminder shipped with this module, so expiry is surfaced in the views, not pushed out as an alert.
- Beneficiary shares are bounded 0 to 100 each and totalled for visibility, but the module does not force the total to equal exactly 100 percent. An under or over split is shown, not blocked.
- The workflow engine, hash-chained audit log, and multi-company scoping are provided by the dependencies (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow). This module installs them as requirements and adds no engine logic of its own.
- Approval gating exists in the underlying engine but the shipped insurance transitions are group-gated, not configured to require a separate approval chain out of the box.
- Cover documents and certificates are not managed here beyond the standard chatter on the record; there is no structured attachment or document-expiry workflow.
employee insurance odoo, hr insurance management, group health insurance tracking, employee benefits odoo 19, insurance policy expiry tracking, beneficiary management hr, life insurance employee records, odoo community human resources, multi-company hr insurance, hash-chained audit trail hr, configurable hr workflow, premium tracking odoo
Please log in to comment on this module