EH HR Transfer
Employee department transfers that approve, then update the record.
Why this module
EH HR Transfer
Writes back to the native employee
On completion the transfer writes the new department straight onto the standard hr.employee record. There is no parallel posting table to reconcile; your org chart, reports and payroll keep reading the native data.
The workflow is data, not Python
The states and transitions, draft to submitted to approved to done plus cancel, live as workflow records on the shared engine. An administrator can adjust the steps and the groups that gate each one without a developer.
Every step on a verifiable chain
State changes and the department move are written to an append-only, hash-chained audit log with a verify-on-demand check. You can show who submitted, approved and applied each transfer, and prove the record was not edited after the fact.
Day in the life
A move from one department to the next, on the record
An HR manager opens a transfer, picks the employee, and the from-department fills in from their current department automatically; they set the target department, the effective date and a reason. Saving stamps an auto-numbered reference. The manager submits, an HR officer approves, and an officer applies the transfer. On that final step the employee's department is updated for real, and every transition is captured in the audit log. A move that would otherwise live in an email thread or a spreadsheet now runs inside Odoo with a complete, ordered trail.
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.
Once a transfer reaches done or cancelled, the workflow engine refuses any further transition, even one a misconfigured definition might declare from that state, because is_final is the authoritative terminal marker.
Submit and cancel require the HR Manager group; approve and apply require the HR Officer group. A user without the right group is blocked from advancing the transfer, with admin exempt.
Audit rows are serialized with a transaction-scoped Postgres advisory lock so two concurrent transactions cannot fork the chain. Each row carries the sha256 of the prior row, and verify_chain walks the log to find the first tampered entry.
company_id is required and defaults to the current company. A write that moves a transfer into a company the user is not a member of is refused, and any audited cross-company override is itself logged with every affected record id.
The transfer reference is generated only when still 'New', from a year-prefixed sequence, so re-saving or copying never silently mints a duplicate number, and copy is blocked from carrying the reference forward.
Applying the transfer writes the target department through sudo so the department move succeeds regardless of the approver's record-level rights, while the change is still attributed to the real actor in the audit log.
What is inside
Built to do the job, end to end.
- Models this module adds. One model, eh.hr.transfer, carrying the employee, the from and to department, the effective date, the reason and the workflow state, ordered by effective date.
- Workflow shipped as data. A transfer workflow definition with states draft, submitted, approved, done and cancelled, four transitions gated by HR groups, and an apply-transfer post-action bound to the completion step.
- Built on the platform engines. It owns no workflow or audit code of its own. It stands on eh_hr_core, eh_hr_compat and eh_hr_engine_workflow, and depends on the standard hr module.
- Security and access. HR Admin has full rights, HR Manager can create and edit, and employee self-service is read-only, all keyed to the platform's HR groups.
Honest about the edges
What this does not do, so nothing surprises you.
- Transfers change the employee's department only. There is no job position, manager or work location change in this module.
- No proration, payroll adjustment or accounting posting is performed; the transfer updates the department field and nothing financial.
- The shipped workflow is a fixed manager-then-officer ladder. It does not include the optional approval-chain engine, escalation or reminder steps out of the box.
- There is no scheduled job. A future-dated effective date is stored as information; the department is written when an officer applies the transfer, not automatically on that date.
- Multi-step or bulk transfers are handled one record at a time; there is no mass-transfer wizard.
odoo 16 employee transfer, hr department transfer odoo, employee transfer workflow, internal transfer request odoo, department change request hr, odoo community hr add-on, audited hr workflow, multi-company hr odoo, employee mobility odoo, self-hosted odoo 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