With more and more customers opting for cloud based solutions like SuccessFactors, customization skills on Time Evaluation engine (RPTIME00) in SAP on-premise solution is unfortunately becoming a dying art. But still there are few, who are not yet ready to move out of the on-premise solution. It could be because of number of factors due to which these organizations feel its in their best interest to continue with the on-premise solution rather than spending on migrating to a new HCM solution. I personally believe that the time evaluation driver built by SAP for its on-premise solution is still one of the most robust and configurable time management solution in the ERP domain. But, due to the latest shift in technology and customer focus towards cloud based solutions, it has brought us to a situation, where the consultants supporting customers still continuing with on-premise solution, may come across new or something out of the ordinary requirement, where they may not get enough support from the SCN discussions or other SAP content repositories or forums.

In my small career of working extensively with SAP on-premise time management solution for more than 4 years now, I have come across situations such as above and thought of documenting the solutions I implemented, so it can help another fellow consultant in getting the solution but only much faster than me.

I am going to start with something, which recently had me scampering through SAP forums. I wanted to see if any standard solution was available but ultimately had to resort to building a custom time function to solve this.

Target audiences

This blog can be helpful for SAP HCM and time management functional consultants, who are facing the same error which is described below in details. Also this blog has been written based on assumption that 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 setup 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.

High level Solution details

I am going to write a separate blog on how this requirement was configured as I found the SAP help documentation on service hours based progression is not detailed enough for me to be able to adopt it into a configuration solution. The grouping configuration (ESG for CAP) for my customer did not differentiate based on employee being Full Time, Part Time or Casual.

The solution implemented on a high level is as follows:

Update the variable ITIG in table VS with hours worked in payscale (from the date employee first moved to this payscale classification, because that is how the standard payscale reclassification works) for Part time and Casual employees, once they had completed 12 months on payscale. For Full time employees once they complete 12 months on payscale update ITIG as YYYY each day till reclassification happens.

Technical Issue

It was key for above solution that each day VS table is updated with hours worked in payscale (or hard coded hours for Full time) after employee completed 12 months on payscale. In cases, where reclassification is not done for a significant period of time after employee is eligible, the VS variable ITIG keeps on cumulating each day into CVS and would extrapolate into a large value ultimately leading to system dump ‘COLLECT_OVERFLOW_TYPE_P’ when running time evaluation.

CVS Overflow System Dump

We needed the service hour progression in VS table and not in CVS table, but CUMBT being a standard function always cumulates VS variable into CVS.

Reset CVS using custom function

I could not find any standard delivered function or operation to reset CVS. ADDVS with a negative offset is not an option, as we needed to retain the service hours in payscale day-wise value in VS. So, I created a custom function with code below to reset CVS-ITIG once it crosses YYYY hrs. Since our reclassification configuration would trigger for anything equal to or above YYYY hours, resetting CVS-ITIG to YYYY did not impact our solution and stopped the overflow system dump.

Custom Function Z_ABC

Create Function Z_ABC like time management function (eligible for all country assignment), with no input / output parameters, from transaction PE04.

Modify RPTMOZ00 include to insert subroutine FUZ_ABC (mapped to custom function) from transaction SE38.

Insert newly created custom function in time management schema, just after function CUMBT is called.

You may encapsulate the custom function call inside a condition based PCR to check for applicable employee attributes. In my case, it has been created with a check on eligible Payscale types.

This function will reset the value of ITIG to YYYY hours in CVS table every time it crosses YYYY hours hence resolving the issue of CVS overflow.

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

Regards,

Jeet Bhattacharjee

P.S. I will add here a reference link to my other article, describing the solution details for service hours based payscale reclassification, once both the articles are published.