Employee Department Transfers
Move an employee between departments through a reviewed, approved, audited workflow that updates the record on completion.
Why this module
Employee Department Transfers
Nothing moves until it is approved
The target department is written onto the employee only on the final apply step, after submit and approve. Submit and cancel are gated to HR managers, approve and apply to HR officers, so a draft request cannot quietly change someone's department.
Every change leaves a trail
State, employee, both departments, and the effective date are captured to the platform's append-only, hash-chained audit log on create and on every change, and the key fields are tracked in the chatter. Who moved whom, from where to where, and when, is reconstructable after the fact.
Built on the platform, not beside it
Workflow, audit, sequencing, and multi-company scoping come from the shared EH HR Platform engine rather than being re-implemented here. The transfer record behaves like every other request in the suite and inherits the same guards.
Day in the life
A move that holds up to a question three months later
An officer opens a transfer, picks the employee, and the from-department fills in from their current posting. They set the target department, an effective date, and a one-line reason, and save: the record takes a TRF/year/number reference. The HR manager submits it, an HR officer approves it, and on Apply the employee's department updates in one step. If anyone later asks why this person sits in a different team, the chatter and the audit log answer it, including the dates and the people involved.
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.
The from-department is set from the employee's current department both on the form (onchange) and at create time, so a request created over the API or in a batch still records where the person actually came from rather than leaving it blank.
Once a transfer reaches done or cancelled, the engine refuses any further transition, even one a misconfigured definition might declare. A completed transfer cannot be re-applied or quietly reopened.
Each transition checks the user's HR groups before it fires. A user outside the allowed group is refused the step with a clear error, so submit, approve, and apply rights stay separated.
The company-aware mixin defaults the owning company, makes it required, and rejects cross-company writes unless an explicit, audited override is set. Null-company records cannot leak a transfer across companies.
Audit rows are append-only and hash-chained, with appends serialized by a Postgres advisory lock so concurrent writes cannot fork the chain. verify_chain walks the tail and flags the first row that does not match.
The reference number is assigned once on create from a year-prefixed sequence and never changes on copy or re-save, so a transfer keeps a stable identifier through its whole lifecycle.
What is inside
Built to do the job, end to end.
- The transfer record. eh.hr.transfer holds the employee, from-department, to-department, effective date, and reason. The target department is required; the from-department is informational and auto-filled. Records are ordered by effective date, most recent first.
- The workflow. A five-state definition (draft, submitted, approved, done, cancelled) with submit, approve, apply, and cancel transitions. Apply runs the post-action that writes the new department onto the employee. Done and cancelled are terminal.
- Platform engine, inherited. Workflow mixin, audited mixin, and company-aware mixin from the EH HR Platform supply the status bar, transition guards, hash-chained audit, and multi-company safety. This module adds the transfer fields and the apply step, nothing more.
- Access and placement. Read for self-service employees, create and edit for HR managers, full control for HR admins. The Transfers menu sits under HR requests, visible to HR officers. Standard list and form views with a status bar and chatter.
- Tested behaviour. Shipped tests confirm a new transfer gets a reference and a draft state with the from-department resolved, and that running submit, approve, apply moves the employee into the target department and lands the record in done.
Honest about the edges
What this does not do, so nothing surprises you.
- This module transfers an employee between departments only. It does not change job position, manager, contract, salary, work location, or company; the apply step updates the department field and nothing else.
- Despite some older wording, there is no job-transfer field or job-change logic in this release. It is a department transfer.
- It does not pro-rate, schedule, or defer the change to the effective date. Apply writes the new department immediately when the officer runs it; the effective date is recorded as data, not enforced as a future-dated action.
- The transfer workflow ships without a separate approval-chain or escalation ladder configured. Routing is by transition group rights, so the self-approval guard and multi-step approval engine only engage if you wire a chain onto a transition.
- It depends on the EH HR Platform (eh_hr_core, eh_hr_compat, eh_hr_engine_workflow) and on Odoo's hr module. It is not a standalone add-on and is not designed for Enterprise-only HR features.
- Reporting is the standard list, form, and chatter. There is no dedicated transfer dashboard, analytics view, or bulk-transfer wizard in this module.
Odoo 19 employee transfer, HR department transfer, employee department change, internal mobility Odoo, HR transfer workflow, staff reassignment, hr.employee department update, HR approval workflow, employee movement tracking, multi-company HR Odoo, HR audit trail, Odoo Community human resources, transfer request management, ERP Heritage HR Platform, workflow-gated HR request
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