EH HR Loan
Employee loans and salary advances with an auto-built repayment schedule, governed by a configurable approval lifecycle and a tamper-evident audit trail.
Why this module
EH HR Loan
Schedule builds itself
On disbursement the engine wipes any draft lines and lays out equal instalments, one per month from the start date, sized to principal plus flat interest. No manual row entry.
Every step is gated
Submit, approve, disburse, close and refuse are separate transitions, each restricted to its own HR group. Closed and refused are final states the engine refuses to move past.
Nothing edits silently
State, employee, amount, rate, instalment count and start date are written to an append-only, sha256 hash-chained audit log that verify_chain can re-check end to end.
Day in the life
From request to paid off
An employee raises a loan for a known principal, instalment count and start date, then submits it. A manager approves or refuses. An HR officer disburses, and at that moment the repayment schedule appears as equal monthly instalments covering principal plus any flat interest. As each instalment is settled the officer marks the line paid, and the total paid and outstanding balance recompute live. When the balance is cleared the officer closes the loan, and the record locks into its final state. Every transition and every change to the key figures lands in the hash-chained audit log, so months later you can prove who approved what, when, and for how much.
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 loan is closed or refused the workflow engine refuses any further transition, even one a misconfigured definition might allow, so settled loans cannot be quietly reopened.
Each transition checks the acting user against its allowed HR groups before advancing. A self-service employee can submit but not approve, disburse or refuse.
Audit rows are appended under a Postgres transaction-scoped advisory lock, so concurrent writes cannot fork the hash chain; verify_chain walks the chain and returns the first broken row if anyone tampers.
company_id is required and defaults to the active company. Writing a loan into a company the user does not belong to is rejected, even under sudo, unless an explicitly audited override context is set.
Regenerating the schedule unlinks the previous instalment lines first, so re-running disbursement logic never leaves stale or duplicated rows behind.
A database CHECK constraint forbids a negative principal and requires a positive instalment count, so a loan cannot be saved with values that would break the schedule maths.
What is inside
Built to do the job, end to end.
- Loan and instalment models. eh.hr.loan holds principal, flat interest rate, instalment count, start date and reason, with stored computes for total repayable, total paid and outstanding balance. eh.hr.loan.line holds each dated instalment with a paid flag and a Mark paid action.
- Workflow definition as data. States and transitions ship as eh.hr.workflow.definition records: draft, submitted, approved, disbursed, closed and refused, with submit, approve, disburse, close and refuse transitions. The status bar and buttons derive from this data, so the lifecycle is configurable without code.
- Audit and company mixins. The model inherits the platform audited and company-aware mixins, giving it the append-only hash-chained audit log, mail thread tracking on key fields, and strict multi-company scoping out of the box.
- Security, sequence and menu. Access rights for HR admin, officer and self-service groups, a per-year LOAN sequence, and a Loans menu under the HR requests section. Three automated tests cover defaults, interest and the disburse-to-schedule path.
Honest about the edges
What this does not do, so nothing surprises you.
- No accounting integration. The module posts nothing to journals or payroll; the manifest is explicit that journal posting is a future seam, and there is no dependency on the account module.
- Interest is flat only. Total repayable is principal times one plus the flat rate; there is no reducing-balance or amortized interest model.
- Instalments are equal. The schedule spreads the repayable amount evenly across the instalment count from the start date, one per month, with no custom or irregular instalment sizing.
- Repayment is marked manually. There is no automatic salary deduction or payslip link; an officer marks each instalment paid.
- The shipped loan workflow uses direct group-gated transitions, not multi-step approval chains. The platform approval engine exists but this module does not flag its transitions as requiring an approval chain.
- Amounts are tracked in the company currency. There is no per-loan multi-currency handling.
employee loan Odoo 16, HR loan management, salary advance Odoo, loan repayment schedule, instalment tracking, loan approval workflow, employee advance, flat interest loan, HR loan module, multi-company HR loan, loan audit trail, Odoo Community HR, ERP Heritage HR, staff loan management
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