| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 1374 |
| Technical Name |
eh_hr_loan |
| License | LGPL-3 |
| Website | https://erpheritage.com.au |
| Versions | 16.0 17.0 18.0 19.0 |
Employee Loans and Advances
Request, approve, disburse, and repay employee loans on a configurable workflow with a tamper-evident audit trail.
Why this module
Employee Loans and Advances
Six steps, role-gated
Draft, submitted, approved, disbursed, closed, or refused. Each transition is restricted to the matching HR group (self-service submit, manager approve, officer disburse and close) by the shared workflow engine, so no record skips a step or moves outside its allowed path.
Schedule on disbursement
Disbursing a loan auto-generates an equal-instalment monthly repayment schedule from principal plus flat interest, dated forward from the start date. Mark instalments paid and the total paid and outstanding balance recompute in place.
Tamper-evident trail
Create, write, and unlink on every loan land in an append-only, sha256 hash-chained audit log, serialized by a Postgres advisory lock and checkable with verify_chain. State, amount, interest, and employee changes are captured before and after.
Day in the life
From request to last instalment
An employee files a loan request with an amount, instalment count, and reason, then submits it. A manager reviews and approves or refuses. An HR officer disburses, which generates the monthly repayment schedule automatically. As payroll or finance settles each instalment, the officer marks the line paid and the outstanding balance falls, until the officer closes the loan at zero. Every one of those moves is signed into the audit chain, so a later reviewer can reconstruct exactly who changed what and when.
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.
Closed and refused are terminal. The engine refuses any further transition out of a final state, even one a misconfigured definition might declare, so a closed or refused loan cannot be silently reopened.
Each transition checks the user against the transition's allowed groups before the state advances. A user outside the group gets a clear refusal, not a partial state change.
Loans are strictly company-scoped. Writing a loan into a company the user does not belong to is rejected, and any audited cross-company override is itself logged with every affected record id.
Audit appends serialize on a transaction-scoped Postgres advisory lock, so two concurrent transitions cannot fork the hash chain. The lock releases automatically on commit or rollback.
Generating the schedule clears any existing repayment lines first, so re-running it on disbursement never leaves stale or duplicated instalments behind.
A database check rejects negative loan amounts and non-positive instalment counts at write time, before any schedule math runs.
What is inside
Built to do the job, end to end.
- Loan and instalment models. eh.hr.loan holds the request, amounts, interest rate, instalment count, and computed total repayable, total paid, and outstanding balance. eh.hr.loan.line holds each repayment instalment with sequence, due date, amount, and a paid flag, ordered by sequence and due date.
- Workflow definition. A data-defined workflow (states and transitions, group-gated) drives the status bar. Disbursement binds a post-action that builds the repayment schedule. States and ordering live in configurable records, not hard-coded enums.
- Audited and company-aware mixins. Shared platform mixins add the hash-chained audit emission, the strict multi-company company_id with cross-company refusal, mail.thread tracking on key fields, and auto-sequence naming on create.
- Access and security. Model access is split across HR admin, officer, and self-service employee groups, with employees able to read their own loan lines but not edit them, matching the workflow's group-gated transitions.
Honest about the edges
What this does not do, so nothing surprises you.
- No accounting integration. The module does not post journal entries or move money; disbursement and repayment are workflow and schedule state only. Posting to journals is a future seam, as the manifest states.
- No payroll deduction. Marking an instalment paid is a manual action; instalments are not auto-deducted from payslips or matched to bank statements.
- Interest is flat only. Total repayable is principal times (1 plus rate percent); there is no reducing-balance or amortized-interest method.
- The repayment schedule is equal monthly instalments dated forward from the start date. Custom cadences (weekly, fortnightly, irregular) and bespoke instalment amounts are not generated automatically.
- Loan transitions are gated by HR group membership. This module's workflow does not route loans through the separate multi-step approval-engine chain, so escalation ladders and the engine's self-approval guard are not wired into the loan flow as shipped.
- Requires the EH HR Platform base (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow) and the standard hr module.
employee loan management odoo, salary advance odoo 19, hr loan repayment schedule, staff loan instalment tracking, loan approval workflow, employee advance request, outstanding loan balance, multi-company hr odoo, hr audit trail, odoo 19 community hr loan, flat interest loan, payroll loan module
Please log in to comment on this module