Salary Advance with Recovery Schedule
Request, approve, pay and recover employee salary advances on a governed workflow with a tamper-evident audit trail.
Why this module
Salary Advance with Recovery Schedule
Approvals that hold
Submit, approve, pay, recover and reject are real workflow transitions, each gated by HR role. Final states block any further move, so a recovered or rejected advance cannot be reopened by accident.
An audit trail you can verify
Every create, write and state change lands in an append-only, SHA-256 hash-chained log serialized by a Postgres advisory lock. A built-in chain check pinpoints the first row that was tampered with.
Schedules that always reconcile
Generate equal monthly installments from the recovery month; the final row absorbs any rounding remainder so the lines sum back to the exact advance amount, and the balance derives only from rows actually marked paid.
Day in the life
From request to recovered
An employee files a 1,500 advance with reason and a recovery start month, then submits it. Their manager approves; an HR officer marks it paid. The officer generates a three-month schedule, and the module splits it into installments that sum exactly back to 1,500. Each month an installment is marked paid; the outstanding balance drops automatically. When the last installment is settled the advance flips to recovered on its own, and every one of those steps is sitting in the hash-chained audit log, attributed to the user who made it.
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.
A 500 advance over 3 months splits to 166.67, 166.67, 166.66; the final installment absorbs the remainder so the schedule reconciles to the cent.
Marking the last installment paid while the advance is in the paid state flips it to recovered automatically, with the balance landing at zero.
Audit appends take a transaction-scoped Postgres advisory lock, so two concurrent saves cannot fork the hash chain; the lock releases on commit or rollback.
Recovered and rejected are terminal; the engine refuses any further transition from them even if a misconfigured definition declares one.
Company is required and defaults to the active company; a cross-company write is refused even under sudo unless an explicit audited override context is set.
Employees can create and submit their own request but cannot approve it; approval is reserved to the HR manager group and the pay and recover steps to HR officers.
A database CHECK constraint rejects negative advance and installment amounts at the storage layer, not just in the form.
What is inside
Built to do the job, end to end.
- Two models. eh.hr.salary.advance for the request and eh.hr.salary.advance.line for each installment, with due date, amount, paid flag and paid date per row.
- Computed balance. amount_recovered and balance are stored computes that depend on installment amounts and paid flags, so the outstanding figure is always derived, never hand-keyed.
- Workflow definition. A six-state ladder (draft, submitted, approved, paid, recovered, rejected) with five group-gated transitions, loaded as data so the steps are configurable without code.
- Audit and platform mixins. Inherits the workflow, audited and strict company-aware mixins plus mail.thread chatter; state, employee, amount, recovery month and installment count are captured on every change.
- Auto sequence. References are generated as ADV/<year>/ with five-digit padding from a company-independent sequence on first save.
- Test suite. Eight post-install tests cover defaults, the full workflow path, rejection, the non-negative constraint, even splitting, balance tracking and auto-recovery.
Honest about the edges
What this does not do, so nothing surprises you.
- Recovery is tracked by a manual paid flag per installment; there is no automatic deduction from a payroll run or accounting journal. Posting to journals is a deliberate future seam, not a shipped feature.
- No interest, fees or eligibility limits are calculated; this is a plain advance recovered at face value, simpler than a loan product.
- The schedule generator splits into equal monthly installments from the recovery month; arbitrary custom dates or uneven amounts are edited by hand on the lines after generation.
- Depends on the EH HR Platform modules (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow) and the standard hr app; it is not a standalone install.
- Targets Odoo 18 Community. No portal or self-service website view ships; requests are raised from the backend HR interface.
odoo 18 salary advance, employee salary advance odoo, payroll advance recovery, salary advance installments, hr advance request workflow, salary advance repayment schedule, odoo payroll advance module, employee cash advance hr, advance approval workflow odoo, salary advance audit trail, multi company hr odoo, staff advance 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