Rehire an existing employee
Reuse the existing employee master and Party. Add a new non-overlapping employment period for the return. A second master for the same Party is refused.
Procedure
- Find the existing employee number and verify the returning person through Party identity.
- Review prior employment closure and the current master/login state.
- Add a new employment with the approved start, employer unit and contract facts.
- Add new assignment, compensation and benefit periods linked to that new Employment ID.
- Once a current employment covers server today, explicitly change the master to ACTIVE when approved.
- Review the existing optional User link and separately arrange approved login reactivation/access.
- Reload history and both employment periods; confirm original hire date stayed unchanged.
Examples
Employment 1 ends 30 November; rehire starts 1 December or later. Starting on 30 November overlaps because both endpoints count. A gap is allowed when it reflects the actual service history.
A future rehire starting next month does not satisfy ACTIVE eligibility today. Add the approved future period, retain the appropriate current status and arrange an explicit status action when permitted. There is no scheduled reactivation.
Rehire Eligible is an administrative recorded decision. The current service does not implement an automatic policy engine that refuses all rehires when that flag is No. The responsible team must review prior decisions and approvals before creating a new period.
What stays and what needs review
Party identity and original hire date remain fixed. Employee number remains the master identifier unless separately approved for editing. Prior status events and service periods remain available under access rules. Old compensation and benefits do not automatically extend into the new employment; create approved new periods.
Some personal/supporting records remain employee-linked across employments. Review current contacts, references, qualifications and authorisation evidence; do not assume their earlier verification is still sufficient or that the application refreshed it.
If the historical master is outside your scope, use authorised support rather than creating a spelling-variant Party or duplicate employee. If the new period overlaps, inspect and correct the actual dates, not the immutable original-hire anchor.