HR Payroll Links
Loans, advances, overtime and gratuity reach the payslip automatically, once and only once.
Why this module
HR Payroll Links
Requests that never reach pay
Approving a loan, advance, overtime or gratuity request does not move money on its own. Someone still has to read each one and key the amount onto the payslip by hand every period, which is slow and easy to get wrong.
Feeders that wire into compute
This module overrides the payslip's auto input collection so an instalment due this period, a recovery month that lands in the period, paid and completed overtime, and an approved gratuity each become a coded input line the moment you compute.
Paid once, marked processed
Inputs are rebuilt fresh on every compute and the source records are flagged processed only when the slip is actually paid, so a recompute never duplicates and a later payslip for the same employee feeds nothing already settled.
Day in the life
Run a monthly cycle without keying a single deduction
Open the payslip and hit compute. The instalment due this month lands as a LOAN deduction, a salary advance whose recovery month falls in the period lands as ADVANCE, the employee's paid and completed overtime hours land as OT_HOURS for a rule to rate, and an approved gratuity lands as GRATUITY. Any manual line you added stays put. You confirm and pay; behind the button the loan instalment is marked paid, the advance recovered, the overtime and gratuity processed. Next month the same compute feeds only what is genuinely outstanding.
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.
Every compute unlinks the existing automatic inputs and recreates them from the live sources, so recomputing a slip never stacks a second LOAN or ADVANCE line. A test asserts the count is unchanged after a second compute.
Source records carry processed markers (overtime and gratuity flagged processed, advance flagged recovered, loan instalment flagged paid) set only on pay, so a fresh payslip for the same period afterwards feeds nothing. A test confirms the second slip has no automatic inputs.
Only lines marked automatic are rebuilt. A manual input you typed onto the slip survives compute unchanged and is never treated as a feeder line.
Feeders are selective by state: advances must be paid and not yet recovered, overtime must be paid compensation in done state, gratuity must be approved, and loan instalments must be unpaid, so draft or rejected requests are ignored.
Each feeder filters source records to the payslip's own date_from and date_to window for that employee, so amounts land in the correct period and not a neighbouring one.
Overtime is fed as a quantity of compensated hours rather than a fixed amount, so your salary rule applies the employee's own rate instead of a frozen figure.
What is inside
Built to do the job, end to end.
- Four feeders, one hook. A single override of the payslip's automatic input collection appends loan, advance, overtime and gratuity input dictionaries with stable codes LOAN, ADVANCE, OT_HOURS and GRATUITY plus a source tag identifying which feeder produced each line.
- Processed markers. Adds eh_payslip_processed to overtime and gratuity and eh_payslip_recovered to salary advance, each read-only and not copied, set on pay so the record cannot be fed into a future payslip again.
- Pay-time settlement. On the paid hook the module reads which sources the slip carried, then marks just those record types processed for the employee and period: loan instalments paid, advance recovered, overtime and gratuity processed.
- Rule-driven treatment. The module only delivers coded inputs. Your salary structure decides the accounting by referencing inputs.LOAN, inputs.ADVANCE, inputs.OT_HOURS or inputs.GRATUITY in a rule, so a deduction or an allowance is your structure's choice.
- Pure server wiring. No views, wizards, cron or seed data ship with this bridge. It depends on the payroll engine and the four request modules and adds only the Python that connects them.
Honest about the edges
What this does not do, so nothing surprises you.
- Targets Odoo 16 Community and depends on eh_hr_payroll plus the eh_hr_loan, eh_hr_overtime, eh_hr_gratuity and eh_hr_salary_advance request modules; it is a bridge, not a standalone payroll.
- It delivers coded input lines only. You must add rules to your salary structure that reference inputs.LOAN, inputs.ADVANCE, inputs.OT_HOURS and inputs.GRATUITY, otherwise the amounts arrive but are not applied.
- Overtime is fed as compensated hours; the per-hour rate lives in your salary rule, not in this module.
- Settlement happens at pay time. Cancelling or reversing a paid slip does not automatically unmark the source records as outstanding.
- Scoping is by employee and payslip period only. There is no separate multi-company filter, advisory locking, or batch cron layer in this module beyond what the payroll engine itself provides.
Odoo 16 payroll integration, loan deduction payslip, salary advance recovery payroll, overtime pay input, end of service gratuity payroll, payroll input lines, automatic payslip feeders, HR payroll bridge, loan instalment deduction, payslip compute inputs, Odoo HR payroll Community, no double deduction payroll
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