Trouble with anchor and reference attributes combined with a Correlation ID

Question

Greetings, I'm a little green on FIM and looking for some advice.
We have an HR system where we store the information on Contractors, Interns, and Employees.
The business process for converting Contractors and Interns to Employees is to terminate the Contractor and re-hire as an Employee. This gives us a different employee number for the "live" entry in the HR system.
Also, there is a "Supervisor No" attribute that is a Reference attribute for their manager. This is their employee number.
What do I do in FIM? If the Employee number is the anchor, won't the system consider the employee a new object? Is there a way to connect the new employee record to the metaverse object that was a contractor or intern, and update the anchor attribute (the
new employee number)?
I was thinking of using a different custom field in the HR system as the FIM_Sync. But just realized that if this became the anchor, then no managers would connect since the Supervisor No is an Employee number.
Thanks in advance for helping.
-Doug
*** Update ***
I read some of the articles on Correlation ID that are in the 2003 version of MIIS the TechNet library. So a follow up question would be what happens between the CS and MV when the HR object changes.. Assuming I have this FIM_Sync attribute to be my
Correlation ID.
Contractor is created. Employee ID is anchor and FIM_Sync field is populated.
New object in CS
Projected into MV
Provisioned out to AD and other systems, but they don't have the FIM_Sync attribute in their schema.
Business Event.. Contactor converted to Employee:
Contractor in HR system terminated (employment_state) and FIM_Sync entry removed.
Employee record created in HR system and FIM_Sync value populated with what it was in the contractor record
New Employee object in CS
Does Contractor get disconnected?
Does the Employee CS object get joined to existing MV object?

Answer 1

At one of my previous projects we solved the same scenario as following:
1. That was not a fully automatic process.
2. Once we receive event that Contractor is terminated in HR, we put that user in "Terminated Contractors" set, disabling his active accounts, where the object resides for 30 days (business policy) before his accounts are removed from target systems.
3. There's a custom workflow which triggers a notification to administrators if the following criteria are met:
Name/Surname of fresh Employee are equal to one of the members of "Terminated Contractors" set
Employee record from HR came within a week after Contractor's termination date (also, a business policy, agreed at customer's level. HRs are lazy and not necessarily process that transfer same day).
4. IAM Administrator contacts HR to ensure that persons in question are actually the same one. Upon confirmation, manual join is made. Once object is joined, Correlation ID is written back to HR (actually, a buffer database acting as HR source) to ensure
that the join can be made automatically.
We faced several problems, though, which are beyond the scope of FIM itself:
1. HRs were creating Employee record before terminating Contractor's one. A major pain, since new accounts are created, et cetera.
2. HRs were creating Employee records too late (that's why we set a "timeout" for a week, initially it was two days)
3. We had a case once when Contractor was terminated and new Employee came with the same name, but those were different people and HR application doesnt allow to differentiate "contractor fired" and "contractor moves to employee" events. That's why we had
to stick to a manual and documented procedure.