Service Hours based Payscale reclassification or Auto progression in SAP

Service Hours based Payscale reclassification or Auto progression in SAP Time and Payroll

Introduction

I had started a series of blogs with a mission to share and revive the knowledge of SAP on-premise time management configuration on some typically offbeat business scenarios. Staying true to it, this blog is about another solution which I had developed some time back as a mix of customization and custom ABAP solution.

If you have not read my previous blog, I would urge you to do so as that will give you a bit more context into the business requirement I am going to talk about in this blog. It’s a quick 3-5 minute read and here is the link for your quick reference.

Reset a variable in CVS in B2 cluster using a custom function to stop CVS overflow dump

Target audiences

This blog can be helpful to consultants supporting SAP on-premise time management solutions and has a similar requirement on payscale reclassification. Also, this blog has been written based on the assumption that the reader is versed with writing custom functions in SAP HCM and this should not be treated as a tutorial for the same.

Business Requirement

To set up auto progression (payscale reclassification) based upon duration (time worked in payscale) and service hours (hours worked in payscale). For employees in an award/agreement (identified by Payscale type and Payscale Area by my customer) Full time employees are eligible to get auto progression once they complete 12 months on a payscale, whereas Part time and casual employees need to complete YYYY hours worked along with completing 12 months on payscale to be eligible.

Challenges

As I have mentioned in my previous blog, I found the SAP help documentation on service hours based progression not detailed enough for me to be able to adopt it into a configuration solution. PFB the snapshot of SAP help doc attached to payscale reclassification program RPIPSR00.

The highlighted section briefly talks about the solution that needs to be implemented for hours-based auto progression. We have leveraged this information and tweaked it as per our requirement to implement our solution.

Also, as often happens, when you are trying to design a new solution which is an extension to existing SAP implementation, the employee grouping configuration (ESG for CAP) for my customer did not differentiate based on employee being Full Time, Part Time or Casual. This made it difficult to set up different auto progression (payscale reclassification) rules for different groups of employees.

Solution Details

Payscale reclassification table V_T510_PSRCL

Update Payscale reclassification table V_T510_PSRCL, for Payscale type/Payscale area with hours required at level (YYYY hrs) for progression.

Time evaluation Custom PCRs

Create custom PCRs in time evaluation to capture the day on which employee completes required tenure (12 months) AND hours at level (YYYY hrs) for progression and set hours worked in variable ITIG of VS table in time evaluation.

For the sake of solution explanation, providing some hypothetical names to custom PCRs and time balances I have used as part of my solution.

Custom day balances created:

1. 9MCL - months in current PS type.
2. 9WCL - hrs worked in current PS type (Ordinary hours - paid absence hours, tracked in custom day balances).
3. 9TIG - set to YYYY in qualifying scenarios.
4. 9PAV - Payscale anniversary check.
5. 9RCL - PS reclassification indicator.
6. 9CMP - YYYY hrs worked in Payscale classification.

Custom operation created:

1. Z_RCL – Update Day balance 9MCL, 9PAV and 9WCL.

NOTE: The source code of this operation is not provided under the assumption that reader is conversant enough to write code to set required day balances based upon service hours accrued and duration spent in payscale. This blog is to focus mainly on the configuration part of the solution.

Custom PCRs created:

1. ZYIG - For eligible PS type and Full-time employees, after 12 months completed in Payscale, 9TIG set as YYYY. For Part-time/Casual employees, check if more than 12 months in Payscale (9MCL day balance), if yes then check if more than YYYY hours worked in payscale (9WCL), if yes, then 9TIG set as YYYY.

For full time employees

For part-time and casuals

1. ZZIG (copy of standard PCR TTIG) - to cumulate hours worked (9TIG) in VS table in ITIG variable in B2 cluster.

1. ZCHE - check condition before resetting CVS for HE PS type to avoid overflow dump.

While implementing above steps, we observed that we were cumulating the hours worked in ITIG variable, so in cases where the hours worked condition is fulfilled while it takes time to fulfill the 12 months criteria, it may cause overflow on ITIG variable causing a system dump error in time evaluation. I have explained the cause and solution to this problem by resetting the CVS variables in detail by using a custom function Z_RVS in my previous blog (link provided at start of this blog).

NOTE: Replace YYYY with whatever qualifying service hours is the minimum criteria for eligibility for progression.

Modify time evaluation schema to call above PCRs

Call above PCRs using ACTIO function just before call to standard CUMBT (cumulate day balances) or customer copy of it is called in time evaluation schema.

Set up payscale reclassification job

Set up a batch job for daily run with below steps:

Step 1 RPTIME00 – Time evaluation. Since time evaluation is critical to functioning of Payscale reclassification rules (reading time evaluation result cluster table VS), it must be run as a first step of this job, so the balances and VS table are up to date before reclassification.

Step 2 RPIPSR00 – Payscale reclassification. Use below parameter selection on payscale reclassification program to do hours based payscale reclassification type.

Data period selection to be provided as per organization auto progression policy.

Payscale Type = Eligible pay scale type.

PS reclassification type = 5 – Hours worked based payscale reclassification.

I have used batch input session method because it gives good logging and reprocessing feature leading to better administration and governance on this process.

Step 3 RSBDCSUB – process the batch input session created in Step 2.

Considerations for the solution:

This solution relies on the below key data being correct at the time the Reclassification program is run

• Employee’s Pay Scale Structure held in Basic Pay (Infotype 0008). This data should therefore be reviewed and updated prior to these configuration changes being implemented.
• Also, this solution heavily relies on time evaluation process, so this job should be run after time evaluation has run for all the employees till the run date. If any of the employees have failed in time evaluation, it should be re-run and PS reclassification program should be run again.

With this I come to the end of this knowledge artifact. I hope this helps fellow consultants, coming across this requirement. Thank you for patiently reading through the document.

Regards,

Jeet Bhattacharjee

References:

SAP Help documentation on Payscale reclassification program RPIPSR00.