HR Salary Advance
Request, approve, pay and recover staff salary advances on a configurable, audited workflow, in one cycle or several installments.
Why this module
HR Salary Advance
Approvals that follow the rules
Every advance moves through draft, submitted, approved, paid, recovered and rejected. Each step is gated to a real group, the employee submits, a manager approves or rejects, an officer pays and recovers, and the engine refuses any transition that is not declared from the current state.
One cycle or many installments
Generate an equal split repayment schedule from the chosen recovery month. The final row absorbs any rounding remainder so the installments always sum back to the advance, and the outstanding balance updates from the paid rows on its own.
A trail you can trust
State, employee, amount, recovery month and installment count are captured on an append only, hash chained audit log. Cross company writes are refused unless explicitly overridden and audited, so the record of who changed what stays intact.
Day in the life
From request to recovered
An employee raises a 500 advance for an emergency car repair and submits it. Their manager approves, an HR officer pays it out, then generates a three month recovery schedule starting next payroll month. As each installment is marked recovered the balance drops, and when the last one clears the advance flips to recovered on its own. Every step is stamped into the audit trail with the real submitter recorded, so the person who raised the request cannot quietly approve 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 schedule split across installments never drifts. Each row is rounded to two digits and the final row takes the remainder, so the lines always reconcile back to the exact advance amount.
Recovered and rejected are terminal. The engine checks the final marker before looking up any transition, so a closed advance cannot be nudged back into motion even by a misconfigured definition.
Transitions resolve strictly from the record's current state. Firing a step that is not declared from where the advance actually sits raises a clear error instead of silently writing an out of order state.
The real submitter is captured before the approval engine is called under sudo, so the user who raised a gated advance cannot later approve their own request even if they hold an approver group.
Advances default to the current company and are required to carry one. A write that moves a record into a company the user does not belong to is refused, and any permitted cross company elevation is written to the audit log with every affected id.
When the last installment on a paid advance is marked recovered, the advance promotes itself to recovered. The balance reaching zero and the state are kept consistent without a manual final click.
A database CHECK constraint on both the advance amount and each installment amount rejects negative values at the storage layer, not just in the form.
What is inside
Built to do the job, end to end.
- Two models, one schedule. eh.hr.salary.advance holds the request, amount, recovery month and computed balance. eh.hr.salary.advance.line holds each installment with its due date, amount, paid flag and paid date, ordered by due date.
- Engine driven states. The six states and five transitions are data, loaded from the workflow definition and editable without code. The status bar, the visible action buttons and the group gates all read from that definition.
- Audited and company aware. The model inherits the platform audit mixin and the strict company scope mixin, so it gains hash chained audit emission and cross company protection without bespoke code in the module.
- References and access. A per year sequence stamps each advance as ADV/YYYY/NNNNN. Access is split across HR admin, manager, officer and employee self groups, with employees able to raise their own request but not delete records.
- Chatter and tracking. The form carries a chatter and field level tracking on employee, amount, recovery month, installments and state, so the message history mirrors the audited changes.
- Covered by tests. The shipped suite exercises the full approval path, rejection, the non negative constraint, even schedule splitting, balance tracking from paid lines and the automatic flip to recovered.
Honest about the edges
What this does not do, so nothing surprises you.
- No journal entries or payroll posting. Marking an installment recovered updates the advance state and balance only; it does not post to accounting. The manifest names journal posting as a future seam.
- No interest, fees or amortization. Installments are an equal split of the principal with the remainder on the final row. This is simpler than an interest bearing loan by design.
- No payroll rule or salary structure integration. The advance does not automatically deduct from a payslip; recovery is recorded by marking installments paid.
- No automated recovery scheduler. There is no cron that marks installments recovered on the due date; an officer marks them.
- Requires the EH HR Platform base. It depends on eh_hr_core, eh_hr_compat and eh_hr_engine_workflow and is not a standalone add on to stock HR.
- Reporting is the list and form views. There is no dedicated dashboard, pivot or PDF statement in this module.
salary advance odoo, employee salary advance, odoo 17 salary advance, pay advance request, salary advance recovery, installment repayment hr, payroll advance, advance against salary, hr advance approval workflow, employee cash advance odoo, salary advance audit trail, multi company hr odoo, salary advance schedule, odoo hr platform
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