I recently had a client come to me for help with an issue they were seeing when trying to activate Bonus Compensation records via the standard program PECM_CHANGE_STATUS – Change Compensation Process Status for certain employees (Only a small handful) within the Enterprise Compensation Management (ECM) module of SAP. The issue was that they were receiving an error saying that “No Infotype 0759 record with process status Approve selected” when running the program. They were running the program to move the records from “Approved” to “Activated”. You cannot change a record from Approved to Activated manually via PA30, because it involves the creation of corresponding records (IT8 for Merit & IT15 for Bonus) and needs to be done via the program provided by SAP so we did not have a manual workaround at this time.
This error obviously points us to the existing IT759 record and I did double check to make sure it was in Approved status and it was. I also made sure the Compensation Review entered on the selection screen of the program matched the IT759 record value (Which it did) and that there were no errors on the selection screen. My next step was to debug the program to see why it was giving us this message when clearly there should be an IT759 record that the program should pick up.
Before I get into my debugging steps, here is a little bit of background on my client
- SAP ERP 6.0 EHP 5
- MSS via Enterprise Portal (Use Standard ABAP WebDynpro Application for Compensation Planning)
- Do not have ESS
- Global Organization with 20+ countries using ECM to handle compensation planning
- Heavily customized ECM implementation with many BADIs and custom processes
- Use ECM for Merit & Bonus only
- Both done annually
- Payroll Processing outsourced
I have helped this client with many ECM issues, so when I first got the information on the issue I was thinking there is probably some customization causing the issue. I debugged a little and did see that the standard program that we were running does check for a BADI implementation HRECM00_ACTIVATION and of course knowing this client the BADI was implemented. From the standard program I found this logic within RHECM_CHANGE_PROC_STATUS_M01 –> FM HR_ECM_CHANGE_PROC_STATUS –> FM HR_ECM_WRITE_SECONDARY_INFTY –> HR_ECM_GET_BUSINESS_ADD_IN.
My thought was that this BADI must have bad logic in it that is causing an issue, but ultimately I found that to not be true. The BADI does some customer specific logic to determine which wage type should be created for Infotype 15 based upon your country, and then goes into standard FM HR_ECM_INSERT_INFOTYPE. Within this FM it ultimately comes back with an error message with message ID PG 083 which has a MSGTY E which is for a hard error. This message did not have a description when looking at it from the debugger so I was not sure what it was in relation to, and it never gets displayed on the screen.
Next, I went to transaction SE91 and typed in Message Class PG and navigated to message 083 in order to try to understand the issue and found the text “Employee subgroup grouping for primary wage type “&1″ is invalid”. I knew that the issue was occurring when the program was trying to create the corresponding IT15 record. So to run a quick test I went to PA30 and tried to create a similar record manually, and I got the same error!
As someone who has worked extensively in SAP Payroll, I knew that this is an issue with configuration and with the grouping of an employee and it narrowed down the issue significantly. I eventually navigated to view V_503_G (IMG location = Personnel Management –> Personnel Administration –> Payroll Data –> Recurring Payments and Deductions –>Wage Types –>Define employee subgroup grouping for primary wage type) and saw that there was missing configuration for certain groups (The groups having issues). Once I added this configuration and we got it transported to production there were no more issues with activating the records!
I just wanted to share my experience and found this to be very similar to one of my past blog posts which had to do with a deceiving error message that does not give you the true story on what is going on and how when debugging you have to look beyond the initial error message to truly discover the underlying problem. Feel free to leave comments if you have any other thoughts, questions, or concerns.