Org Assignment Stuck After Employee Transfer

HR reports it as 'the transfer went through but the org chart still shows him under the old manager' or 'payroll charged the cost center from before the move'. Sometimes it surfaces as an approver getting a workflow task routed to the wrong manager weeks after the transfer was processed. Time and attendance teams notice it when an employee's absence request still routes for approval to a manager who is no longer responsible for them. Occasionally the complaint comes from a downstream system - SAP HCM or Employee Central Payroll - where the infotype 0001 record on the backend still carries the old organisational unit, cost center, or position, even though the Employee Central Job Info portlet looks correct when opened directly.

Pull the Job Info history for the employee showing all effective-dated records with their sequence numbers, and lay it next to the Position's own history for the same date range. Separately, pull the integration or replication log filtered on the employee's ID and a date range spanning the transfer's effective date, looking for the last successful transmission timestamp. If the backend is reachable, compare the PA20 infotype 0001 record's effective date and organisational fields directly against the Employee Central source record for the same date.

If the cause is date sequencing, correct the record dates in Job Info directly - this is a data fix, no transport required, but it must be done as an insert or correction on the correct record, not as an overwrite of the wrong one. If Position and Job Info are decoupled, update whichever side was missed; if the underlying issue is that the business rule does not derive from Position when it should, that is a configuration change to the rule and needs to move through transport. If the transfer is stuck in workflow, either complete the approval through the normal route or have an administrator force-complete it, which is a data action but should be logged since it bypasses the intended approval control. If replication is stale, rerun the integration job for the affected employee once the upstream record is confirmed correct; if the job is failing systemically due to a mapping or filter defect, that is a configuration fix for the integration team and needs transport and testing before it is trusted for other employees. If the record came in through an import, the cleanest fix is to reverse it and re-enter the transfer through the standard action so the correct rules and workflow apply.

The reflex is to open Job Info and manually overwrite the current record with the correct department, cost center, and manager. This makes the screen look right for the one employee someone complained about, but it does nothing about the underlying cause. If the real problem was replication, the correction never reaches payroll or the backend system because the manual edit was made on a record the integration job already considered processed. If the real problem was a business rule not firing, the same defect will hit the next transfer and the next employee, and each one gets patched by hand instead of fixed once.

Data sequencing and workflow completion issues sit with the HR administrator or HRIS support who processed the transfer. Business rule and foundation object configuration defects belong to the Employee Central functional consultant. Replication failures belong to the integration or middleware team running the point-to-point or Integration Center job. The handover note should state the employee ID, transfer effective date, the record or job where the break was found, and whether payroll for an already-run period needs retroactive correction as a result.