This blog delves into the intricate process of loading Year-to-Date (YTD) values from a legacy system into the SAP/SuccessFactors Payroll (ECP/S/4 Hana) system. This operation becomes necessary during mid-year go-lives when YTD values are essential for the remaining payroll periods.
It's crucial to note that this process is specific to Canada Payroll. For Concurrent Employment, the recommended payroll schema is KLKC, while for regular payroll, it's either KLKL or KLK9. Furthermore, the focus here is on the KLKL option for loading YTD data and processing payroll.
Before embarking on preparing the YTD files T558B and T5K8C, certain considerations need attention.
For employees hired before the go-live date, it's advisable to hire them in a dummy payroll area (ZZ/99) using Action type=Hire, with the reason for action being Data migration. Subsequently, follow this with a data change action type effective from the go-live date. The mandatory infotypes for processing KLKL payroll include IT0000, 0001, 0002, 0006, 0007, 0008 (optional), 0461, 0462, 0463, and 0464.
Even if there are multiple payroll areas, hire all employees in a dummy payroll area and transfer them to the actual payroll area effective from the go-live payroll period start date. If the pay period frequency of actual payroll areas differs, the date strategy in table T558B needs planning, which will be discussed further in the T558B section.
It's recommended to process the KLKL payroll as soon as the data migration record is created, along with the other mandatory infotypes mentioned above. The rationale behind this recommendation is that the KLKL schema checks whether the employee is active during payroll processing. Processing active and terminated employees in one go proves efficient. After successfully completing YTD payroll activities, upload termination records and transfer the employee to the actual payroll area effective go-live date.
SAP recommends using WTs mapped to processing classes 06, 30, and 70:
My take is to consider WTs mapped to T4, REL1 & T4A, and any other YTD amounts required post go-live for payroll calculations.
Update this table for all employees for whom KLKL payroll has to be processed. Use the go-live minus 1 pay period. Key fields for running KLKL payroll are populated in the below screenshot.
If there are multiple payroll areas with different pay period dates, use the below strategy to determine the dates to be used in T558B table.
Update this table with YTD values for each employee. Utilize the same pay period end date (Column J) maintained in T558B. This date matching is crucial.
Cumulation type T&C: Indicator 'T' updates TCRT table, and indicator 'C' updates CRT table. I did not see the need for updating RT. If you update the values in RT, it will duplicate the amount in CRT.
Tax key: This is a vital field. If there are multiple business numbers for an employee before go-live, all amounts respecting that business number should be loaded in sequence. For instance, the current business number is 001, and the previous one was 002. Load the 002 entry first, and 001 follows that – sequence matters.
For each WT, both T&C indicators should be updated.
The business key is not required for indicator C, and hence, the cumulative value can be added together for all business numbers for indicator C.
Multiple business number scenario
It's crucial to note that this process is specific to Canada Payroll. For Concurrent Employment, the recommended payroll schema is KLKC, while for regular payroll, it's either KLKL or KLK9. Furthermore, the focus here is on the KLKL option for loading YTD data and processing payroll.
Before embarking on preparing the YTD files T558B and T5K8C, certain considerations need attention.
Employee Master Data:
For employees hired before the go-live date, it's advisable to hire them in a dummy payroll area (ZZ/99) using Action type=Hire, with the reason for action being Data migration. Subsequently, follow this with a data change action type effective from the go-live date. The mandatory infotypes for processing KLKL payroll include IT0000, 0001, 0002, 0006, 0007, 0008 (optional), 0461, 0462, 0463, and 0464.
Even if there are multiple payroll areas, hire all employees in a dummy payroll area and transfer them to the actual payroll area effective from the go-live payroll period start date. If the pay period frequency of actual payroll areas differs, the date strategy in table T558B needs planning, which will be discussed further in the T558B section.
It's recommended to process the KLKL payroll as soon as the data migration record is created, along with the other mandatory infotypes mentioned above. The rationale behind this recommendation is that the KLKL schema checks whether the employee is active during payroll processing. Processing active and terminated employees in one go proves efficient. After successfully completing YTD payroll activities, upload termination records and transfer the employee to the actual payroll area effective go-live date.
Ways to Upload Legacy Data to SAP Payroll
- Update RT: This updates CRT and TCRT(KLK9).
- Update CRT & TCRT (KLKL): This blog delves into option 2.
Choosing Wage Types (WTs) to Upload
SAP recommends using WTs mapped to processing classes 06, 30, and 70:
- Processing class 06: Transfer wage types from the previous payroll account.
- Processing class 30: Cumulation of wage types (CRT).
- Processing class 70: Cumulation of wage types (TCRT).
My take is to consider WTs mapped to T4, REL1 & T4A, and any other YTD amounts required post go-live for payroll calculations.
Tables to Upload: T558B & T5K8C
T558B:
Update this table for all employees for whom KLKL payroll has to be processed. Use the go-live minus 1 pay period. Key fields for running KLKL payroll are populated in the below screenshot.
- Dates here are linked with T5K8C. KLKL reads dates from T558B, not the period mentioned in the payroll drivers.
- For folks hired in the middle of a period, the hiring date becomes the start date of the pay period.
- Maintain sequence number as 0001 for all entries, as cumulative values are being uploaded.
- For multiple pay period values, sequence number changes; otherwise, it's not required. Four digits are important (0001).
If there are multiple payroll areas with different pay period dates, use the below strategy to determine the dates to be used in T558B table.
| Payroll Area | Pay Period | PP Start Dates | PP End Date |
| ZZ/99- Bi-weekly | PP12 | 01.07.2013 | 14.07.2013 |
| Go Live Date | |||
| KB_Biweekly | PP13 | 15.07 2013 | 30.07.2013 |
| KH_Weekly | PP25 | 08.07.2013 | 14.07.2013 |
| Dates to use in T558B | |||
| KB | PP12 | 01.07.2013 | 14.07.2013 |
| KH | PP12 | 07.07.2013 | 07.07.2013 |
T5K8C:
Update this table with YTD values for each employee. Utilize the same pay period end date (Column J) maintained in T558B. This date matching is crucial.
Cumulation type T&C: Indicator 'T' updates TCRT table, and indicator 'C' updates CRT table. I did not see the need for updating RT. If you update the values in RT, it will duplicate the amount in CRT.
Tax key: This is a vital field. If there are multiple business numbers for an employee before go-live, all amounts respecting that business number should be loaded in sequence. For instance, the current business number is 001, and the previous one was 002. Load the 002 entry first, and 001 follows that – sequence matters.
For each WT, both T&C indicators should be updated.
The business key is not required for indicator C, and hence, the cumulative value can be added together for all business numbers for indicator C.
Multiple business number scenario
Payroll Processing Tips
- Create the control record for ZZ/99 payroll area.
- Process payroll using KLKL schema.
- After processing payroll, ensure CRT and TCRT are populated correctly.
- Run an audit reconciliation report and check for errors.
- Execute PIER reports.
- Run PD7A reports.
- After uploading and processing KLKC payroll, clear IT0003 'earliest MD change' field to blank.
- SAP Managed Tags:
2 Comments
