EH HR Transfer
Employee department transfers that move through approval and update the record.
Why this module
EH HR Transfer
An approval path, not a free edit
A transfer cannot jump straight to applied. It moves draft to submitted to approved to done, each step restricted to the right HR group, so a manager raises it and an officer approves and applies it. The target department is written to the employee only on the final completing step.
Every step on a verifiable trail
State, employee, from and to department and effective date are written to an append-only, hash-chained audit log shared by the whole platform. The chain is serialized with a Postgres advisory lock and can be verified on demand to prove no row was edited after the fact.
No parallel system to reconcile
The module owns one model and leans on the platform engines for workflow and audit. It reads and writes the standard hr.employee and hr.department records, so your existing reports, org chart and payroll keep seeing the real data.
Day in the life
From request to applied, on the record
An HR manager opens Transfers and raises one for an employee. The reference auto-numbers as TRF/2026/00001 and the current department fills in by itself, so they only choose the destination, an effective date and a reason. They submit; an HR officer reviews and approves, then applies the transfer. On that final step the employee moves to the target department, the status bar reads Done, and the whole path, who raised it, who approved it and what changed, sits in the chatter and the platform audit log. A transfer in Done is final: the engine refuses any further transition on 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.
Once a transfer reaches Done or Cancelled the workflow engine refuses every further transition, even one a misconfigured definition might declare, so an applied or abandoned transfer can never be silently re-run.
References are drawn from a dedicated ir.sequence (TRF/year/00000) at create time, with a TRF/AUTO fallback if the sequence is missing, so two transfers created together never share a number.
Submit and cancel require the HR manager group; approve and apply require the HR officer group. A user outside the transition's allowed groups is refused with a clear error, and admin is the only bypass.
Every transfer is owned by a company and that is required. A write that tries to move a record into a company the user does not belong to is rejected, and any audited cross-company override is itself written to the log.
Audit rows are appended under a transaction-scoped Postgres advisory lock, so concurrent transfers cannot fork the hash chain. Each row links to the previous by sha256 and verify_chain walks the whole log in bounded batches.
The completing step writes the destination department through sudo only when a target is set, and re-reading a Done record changes nothing, so the employee lands in exactly the chosen department once.
What is inside
Built to do the job, end to end.
- One model, eh.hr.transfer. Holds the employee, from and to department, effective date, reason, auto-numbered reference and workflow state. From-department auto-fills from the employee both on the form and at create time as a backstop.
- A workflow defined as data. Draft, submitted, approved, done and cancelled states with submit, approve, apply and cancel transitions live in an XML workflow definition, not in Python. The apply transition is bound to the method that updates the employee.
- Platform audit and tracing, inherited. Through the platform mixins the model gains a correlation id, a structured platform event on every transition, and append-only hash-chained audit rows for create, write and the captured transfer fields.
- Views, menu and access rules. A list and a form with a status bar and stage buttons, a Transfers menu under HR requests for officers, and access rules giving admins full control, managers create and edit, and self-service employees read-only.
Honest about the edges
What this does not do, so nothing surprises you.
- Transfers move department only. The model has from and to department fields; it does not carry job position, manager, work location or salary change fields, so it does not reassign those.
- The effective date is recorded and audited but the apply step writes the new department immediately on completion. There is no scheduled job that defers or back-dates the move to the effective date.
- Approval here is the workflow's group-gated approve step, not a multi-step approval chain. This module's workflow does not enable the platform's N-step approval engine or escalation ladders, so there is one approve and one apply step.
- There is no transfer letter PDF, no bulk or mass-transfer wizard, and no import tool. Transfers are raised one record at a time through the form.
- Cancel is available only from Draft. A transfer already submitted or approved cannot be cancelled through the shipped workflow without an administrator adjusting the definition.
- It targets Odoo 17 Community and depends on eh_hr_core, eh_hr_compat, eh_hr_engine_workflow and the standard hr module; it is not a standalone app.
Odoo 17 employee transfer, department transfer module, HR transfer request Odoo, internal transfer approval workflow, employee movement tracking, Odoo HR workflow, audited HR transfer, multi-company HR Odoo, self hosted Odoo HR, transfer approval Odoo Community, employee department change, HR platform Odoo 17
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