HRM-System/docs/PLAN-payslip-data-patch.md

PLAN: Payslip Data Mapping Correction

Context

The payslip simulation engine output 18,360 for Ana instead of 13,000, and labeled her as EMP-00002 instead of SEB2018-2008T.

Root Cause Analysis

1. The Salary Defect: During the SimulatePayslips command, we tried to patch Ana's legacy gross salary to 26000 by targeting user_id = 2. However, Ana is EMP-00002 in the new system, meaning her user_id is actually 3 (since User 1 is the Admin). By targeting ID 2, we patched the wrong employee entirely! Because of this, the engine fell back to Ana's actual legacy gross_salary sitting in the database... which was exactly 18,360!
2. The ID Defect: The data migration script (ImportLegacyRamesebData.php) generated brand new sequentially assigned Employee IDs (e.g. EMP-00002) instead of importing the exact legacy IDs from Rame_Seb.

Task Breakdown

Phase 1: Dynamic Data Selection

• Update the SimulatePayslips.php patcher. Instead of blindly targeting user_id = 2, we will strictly target Ana's email or employee profile linkage, ensuring the 26000 gross salary injection successfully hits her record.
• We will do the same for Paul Rei Paas (Target B) to ensure his values don't break either.

Phase 2: Employee ID Override

• Update the ImportLegacyRamesebData.php script to map the physical legacy employee ID (legacyUser->employee_id or similar legacy string) onto the new employee_id column, forcing Ana to natively become SEB2018-2008T.
• Instead of wiping and perfectly re-importing the whole DB right now, I will explicitly run an update query in SimulatePayslips.php to patch Ana's active employee_id to SEB2018-2008T so the PDF reads it perfectly.

Phase 3: Scrub Exemption Fixes

• Now that Ana's true ID is known, we will fix the attendance absentee scrubber (1.5 Scrub dirty legacy data) so it scrubs employee_id 3 instead of 2.