A Mid-Month Transfer, a Double Workflow, and a Second Employment Question
Priya, a 1,200-employee population, monthly payroll, moves from Legal Entity A to Legal Entity B effective the 16th of a 30-day month. Her salary is 4,800 per month, FTE drops from 1.0 to 0.8, pay grade changes, and her manager changes. The transfer was entered through the Job Information change transaction by the HR admin on the 18th, and the import that loads pay components ran on the 19th. Payroll for the month shows her full 4,800 charged entirely to Legal Entity A, and FTE appears as 1.0 for the whole period. Additionally, two approval requests sit in the manager's inbox for the same transfer, both approved, and the second one re-saved her record. HR now asks whether she should instead have been created as a 'new employment' in Legal Entity B.
1. Explain why payroll charged the full month to Legal Entity A at FTE 1.0, and describe the sequence that would have produced correct proration.
Read the worked answer
Proration in Employee Central is a consequence of how many dated records exist at the moment payroll replicates, not of a setting alone.
Two separate failures compound here:
- No split existed at replication time. The change was effective the 16th but was saved on the 18th, and the pay-component import followed on the 19th. If replication ran between the save and the import, or if the new dated Job Information record carried no recurring pay component of its own, payroll sees one continuous record: 4,800 and FTE 1.0 against Entity A.
- Pay-component attributes were not re-derived. Even with a split, the amount only prorates if the pay component is proration-eligible and the FTE-driven amount is recalculated on the new record.
Correct sequence:
- Enter the change effective on the 16th producing a closed old record (through the 15th) and a new open record (from the 16th) with Legal Entity B, FTE 0.8, new grade, new manager.
- Ensure both records carry their own recurring pay component values (old at 1.0; new at 0.8).
- Only then let the pay-component load or replication run, and verify replication status before the payroll period is pulled.
- Review the resulting split in the payroll input, not just in Job Information - a correct-looking UI record with no pay component on the new segment still pays wrong.
2. Two identical approval requests appeared and the second re-saved the record. Diagnose the most probable causes and state the controls that prevent recurrence.
Read the worked answer
Two approved requests for one business change, with a re-save, points to more than one save event on the same effective-dated record. Ranked causes:
- The transaction was submitted, the approver approved, and a business rule that fires on save changed another field, generating a second pending request.
- The HR admin re-saved or re-imported the record after the first approval, and the workflow was configured to trigger on any modification rather than on the specific change.
- An integration/technical user, excluded from workflow in the UI but not in RBP, performed the second save and triggered the scenario again.
Controls:
- Scope the workflow trigger tightly (trigger on the field set that genuinely needs approval, e.g. legal entity or pay grade, not on any edit).
- Prevent rule-driven secondary saves from re-triggering approval by ordering rules so the full change lands in one save.
- Give technical/integration users a RBP role that does not initiate that workflow scenario, and confirm it at the role level, not only at the UI.
- Operationally, ensure the duplicate is withdrawn, not left approved, and correct the record once with a single dated save - the second approval has already created an extra dated record that payroll may now read.
3. Should Priya have been modelled as a new employment in Legal Entity B? Advise, including the downstream consequences of each choice.
Read the worked answer
The deciding question is whether this is one continuous relationship with the employer group or genuinely two. Not whether two legal entities are involved.
Choose a transfer within a single employment (old record closed, new record opened) when: service is continuous, there is one contract at a time, one payroll relationship, one benefits enrolment, and Time Off balances should follow the employee across entities. Consequence: proration is handled by the dated split; the employee keeps one time account history; seniority and service date follow.
Choose multiple employment (overlapping Job Information records against different legal entities) only when the employee genuinely holds two concurrent relationships - separate contracts, separate payrolls, potentially separate work schedules, time accounts per employment, and benefits eligibility that differs. Consequences to accept: two payroll results, duplicated time-off accounts, benefits double-counting risk, and reporting that must aggregate across employments.
In this scenario the described facts (one salary, one manager, FTE change, no concurrency) fit a transfer, not multiple employment. Converting retroactively is not a cosmetic change: it would require terminating the existing record and creating an overlapping one, re-pointing time accounts, and re-running the affected payroll period. Verify contract and benefits position with the local HR team before any conversion, and treat the current payroll error as a replication and record-split defect to fix in-period.