EH HR Payroll Links
Loans, advances, overtime and gratuity reach the payslip as input lines, rebuilt on every compute and marked processed once paid so nothing is deducted twice.
Why this module
EH HR Payroll Links
The request modules stop being islands
A loan, advance, overtime claim or gratuity raised in its own module is worthless until it hits a payslip. This module collects all four for the employee and period at compute time and turns each into an input line your salary structure can read by code.
Rebuilt every compute, never duplicated
Auto inputs are deleted and rebuilt on each compute, so re-running a payslip always reflects the current loan balance and approved overtime. Manual input lines you added by hand are left untouched. Recomputing twice yields the same set, not doubled deductions.
Source records marked processed on pay
When a payslip is paid the loan instalment is marked paid, the advance recovered, and the overtime and gratuity flagged processed. A later payslip for the same employee and period then feeds nothing, so the same amount is never deducted or paid twice.
Day in the life
A payroll officer runs the January slip for a fed employee.
The employee has a loan instalment due 15 January, a salary advance set to recover in January, ten hours of paid overtime done on the 10th, and an approved gratuity computed on the 5th. The officer opens the payslip, sets the structure and period, and clicks compute. Without touching the request modules again, four input lines appear: a LOAN deduction for the instalment, an ADVANCE deduction for the recovery, OT_HOURS carrying the compensated hours as a quantity so the overtime rule applies the rate, and a GRATUITY input the gratuity rule pays out. The structure rules turn these into pay and deduction lines, gross and net settle, and the officer confirms and pays. At that moment the instalment is marked paid, the advance recovered, and the overtime and gratuity flagged processed. If anyone computes a second January slip for the same employee, no auto inputs are produced, because every source has already been consumed.
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.
Auto inputs are unlinked and rebuilt on every compute, so a re-run reflects the current loan balance and approved records rather than stacking a second set of deductions on top of the first.
Once a payslip is paid the loan instalment is marked paid and the advance, overtime and gratuity are flagged on their own records. A fresh payslip for the same employee and period then collects nothing, so an amount cannot be deducted or paid in two periods.
Only lines flagged as auto are rebuilt. An input line you entered by hand survives every compute untouched, so fed-in amounts and manual adjustments coexist on the same slip without clobbering each other.
Overtime is fed as a quantity with a zero amount, carrying the compensated hours (hours times multiplier), so the salary structure rule decides the hourly rate rather than the bridge hard-coding a pay figure.
The processed and recovered flags on the source records are copy-false and read-only, so duplicating a record clears the flag for a genuinely new claim while a user cannot silently un-mark a consumed one in the form.
Each feeder is independent. A period with only a loan due produces just a LOAN input, and on pay only the loan source is searched and marked, leaving advance, overtime and gratuity records alone.
What is inside
Built to do the job, end to end.
- Auto-input collector. Overrides the payslip _collect_auto_inputs extension point to append loan, advance, overtime and gratuity input dicts for the slip's employee and period. Loans pull unpaid instalments due in the period, advances pull paid advances whose recovery month falls in the period and are not yet recovered, overtime pulls paid done records, gratuity pulls approved records computed in the period.
- Pay-time reconciler. Overrides _on_payslip_paid to mark each consumed source processed, but only for the feeders that actually appear as auto inputs on the slip. Loan instalments are set paid, advances recovered, overtime and gratuity flagged processed, all scoped to the same employee and period the slip covered.
- Processed-marker fields. Adds copy-false, read-only boolean markers to the overtime, gratuity and salary-advance models (eh_payslip_processed and eh_payslip_recovered) so a record consumed by one payslip is invisible to the next compute. The loan side reuses the existing paid flag on the instalment line.
- Structure-driven treatment. The bridge only supplies input lines keyed by code (LOAN, ADVANCE, OT_HOURS, GRATUITY). Whether each becomes a deduction, an allowance or a paid line is decided entirely by the rules in your salary structure that reference inputs.CODE, so behaviour stays under your control.
Honest about the edges
What this does not do, so nothing surprises you.
- Server-side bridge only. It adds no menus, views, wizards or scheduled jobs of its own; the manifest ships no data files. You drive it through the existing payslip compute and pay buttons.
- Requires its five dependencies installed: eh_hr_payroll, eh_hr_loan, eh_hr_overtime, eh_hr_gratuity and eh_hr_salary_advance. It bridges those specific modules and is not a generic payroll connector.
- It does not write the salary-structure rules for you. The codes it feeds (LOAN, ADVANCE, OT_HOURS, GRATUITY) only affect pay if your structure has rules that reference them; without those rules the inputs sit unused.
- Feeding is by employee and pay-period date match on each source. It does not prorate an instalment across split periods or apply approval, escalation or self-approval logic; those live in the source request modules, not in this bridge.
- Source records are consumed when the payslip is paid, not when it is confirmed or cancelled. The bridge does not reverse a marker if a paid slip is later undone, so cancelling after payment is an operational step you handle in the source modules.
Odoo 18 payroll integration, Odoo loan deduction payslip, salary advance recovery payroll, overtime to payslip Odoo, end of service gratuity payroll, payslip input lines, salary structure rule inputs, HR payroll bridge module, automatic payroll deductions Odoo, idempotent payslip recompute, double deduction protection payroll, ERP Heritage HR
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