Organization

ONe-HR models the company's organizational structure with three tiers: Division ▸ Department ▸ Employee. On top of that, each employee has three independent approver chains — one each for Leave, Official Business, and Overtime — plus an Executive hierarchy (executive_id, avp_id, all_employee_manager_id).

Audience

HR Administrators, MSD administrators, executives setting up their subordinate chains.

Division ▸ Department

hr.division is a custom top-level grouping (e.g. "Commercial Operations", "Corporate Services"). A department belongs to a division; an employee belongs to a department, and the division is inherited as a related field.

Divisions

HR ▸ Maintenance ▸ Divisions

Fields:

• Name — the division label.
• Company — the BU this division belongs to (the ir.rule keeps divisions scoped per BU).
• Executive ID — the VP/SVP heading this division. Used as the default executive for all departments under it.

Departments

HR ▸ Maintenance ▸ Departments

Departments extend the standard hr.department with:

• Division — links to hr.division.
• Executive ID, AVP, All Employee Manager, Assistant Manager — the default management chain.

The department's executive/manager defaults flow onto any employee assigned to that department (see _onchange_department_id in models/hr_employee.py:220–227) — so the HR admin rarely sets these manually per employee.

The Executive flag

Every employee has an executive boolean. Execs appear in the Executives action window (restricted menu), get an extra Subordinates section on their form, and are eligible as pickers for executive_id / avp_id / all_employee_manager_id / assistant_manager_id on other employees (via the read-only hr.all.employee mirror, filtered to executive=True).

Toggling the flag

Header button Toggle Executive on the employee form flips the flag. The employee immediately moves between the Non-Executives and Executives action windows.

Approver hierarchies

An employee has three independent Many2many approver fields:

Field	Screen label	Used by
leave_approver_ids	Leave	Leave approval flow
ob_approver_ids	Official Business	OB approval flow
ot_approver_ids	Overtime	OT approval flow

These are three separate lists — an employee's leave approver is not necessarily their OT approver. This lets orgs split responsibilities (e.g. direct manager approves leave; department head approves OT because budget ownership is different). The approver pickers render on the employee form in a dedicated Approvers section.

The hr.approvers model

The picker options come from hr.approvers — a registry of named approver roles (e.g. "Department Manager", "AVP", "Division Head"). Each role points to a specific res.users or hr.all.employee. Edit under HR ▸ Maintenance ▸ Approvers.

Any-of approvals

All three flows use any-of semantics: if three people are in the approver list, any one of them can approve, and all receive notifications. No all-must-approve chain.

Subordinates view

On an executive's employee form, three computed Many2many fields surface subordinates:

• Leave Subordinates — employees who have this exec in their leave_approver_ids.
• Official Business Subordinates — employees who have this exec in their ob_approver_ids.
• Overtime Subordinates — employees who have this exec in their ot_approver_ids.

These compute methods use sudo() to search across all companies — so an exec with BU-spanning responsibility sees subordinates across every BU they approve for (models/hr_employee.py:259–305). This is one of the places the hr.all.employee read-only mirror is essential: the subordinate list bypasses the per-BU ir.rule by design.

Team Availability

When an employee has can_view_team_availability=True, they get access to a Team Availability view showing subordinates' current status (on leave, rendering OT, on official business). This is typically set on managers who need real-time visibility into who's available for work assignments.

Approver Subordinates table

The hr.approver.subordinates model is an audit table — every time a subordinate relationship is created or changed, a row is written here tracking which approval type (leave/OB/OT), which employee, which approver, and when. This is distinct from the computed subordinate fields (which show the current state) — hr.approver.subordinates shows the history.

Employee transfer

When an employee moves between BUs, don't rebuild their record — use the Transfer Employee wizard (header button on the employee form). It:

• Writes the new company_id.
• Carries over leave balances, OT approvers, and rates history.
• Maintains the res.users link so the employee keeps their login.

The wizard is at wizard/hr_employee_transfer.py.