Greeting Solution Architects, Payroll Consultants & ABAP Developers!
Sometimes, our work challenges us to think differently. That happened to me with Managed Configurations. Maybe I was trying to take a shortcut, or I was just feeling a bit lazy, but I wanted 30 countries in my ECP PCC to follow same set of validation rules. Most people would set up a unique rule for each country, but I tried a different approach. And then, I found myself in a tricky spot. Thankfully, I discovered TableValue1 & TableValue2. In this blog, I’ll share how these tools helped me solve my problem.
But before we get into that, a word for those who haven’t moved from the old-style class-based Alerts, KPIs, and RCAs to the Managed Configuration Application: you’re missing out! Yes, changing from old rules to new ones might feel like a big task, especially if you have many old rules. But the new Managed Configuration makes handling and helping with rules so much easier. It really does live up to its name, ‘Managed Configuration’. 
If you want to learn more about Managed Configurations Application within PCC, please read this.
Now, about my challenge: I was trying to set up rules about:
1. Employees with net pay greater than threshold value,
2. Employees with retro pay diff. over threshold amount
3. Employees with Gross pay over threshold amount
You might think, why not make several rules for each country? But I was set on having the same rules for everyone. How did I manage? With some advice from my colleague, Arijit Barik, I turned to TableValue1 and TableValue2.
Think of TableValue1 like a simple VLookup search tool in Excel, where you use one piece of information to find another. TableValue2? It’s the same, but you use two pieces of information. Let’s dive into how I used these tools to solve my problem.
So, let’s take the first rule – Employees with net pay greater than threshold value. The below is a definition of the rule for this.
Now every country has a different threshold amount. How can I have different thresholds for every country. In Managed Configurations, the threshold value is typically calculated in Auxiliary Calculations Tab.
I used TableValue2 function to determine Threshold Amount. The TableValue2 function is defined as below in our product documentation –
So, in my case, I created a custom table ZGL_THSHLD_AMNT. I added two key fields and corresponding threshold amount as shown below:
An updated content in the table using SM30 as shown below: Please note these are dummy values for testing’s sake.
The first key field is type of the amount for the three different validation rules that I am addressing, Rule #1 for Net, Rule #2 for Retro and Rule #3 for Gross. I have added “>” sign just to show that these amounts in the rules will be greater than the threshold amount.
The second key field is the payroll area of that particular country for which the rule will be executed.
The third field is the actual threshold amount.
I defined the Threshold Amount in the Auxiliary Definitions as “CN_THRSHOLD” that uses TableValue2 function with ZGL_THSHLD_AMNT as the table, “AMOUNT” field of the table as the threshold amount, “AMOUNT_TYPE” as the first key field of the table, “NET >” is the constant value that’s I am feeding for that first key field. “ABKRS” as the second key field of the table with the value of the Payroll Area that’s there for that particular rule in the variable P2RX_VERSC-ABKRS.
When this validation rule is called, the TableValue2 function will take the value amount type “NET >” and abkrs as “9A” to determine the threshold amount as 20,000. Similarly, for A2, the threshold amount would be 7,000.
Similarly, we created the auxiliary definitions for Gross and Retro amount type as shown below:
When this Gross validation rule is called, the TableValue2 function will take the value amount type “GROSS >” and abkrs as “9A” to determine the threshold amount as 30,000. Similarly, for A2, the threshold amount would be 18,000.
When this Retro validation rule is called, the TableValue2 function will take the value amount type “RETRO >” and abkrs as “9A” to determine the threshold amount as 500. Similarly, for A2, the threshold amount would be 1,800.
So, this describes how the TableValue2 function was used. Now Let’s come to TableValue1 function. This was more interesting because here the requirement was for RCA and not for validation rule. Let’s check this now.
SAP Standard Best Practices have given two RCAs as below:
- SBP – RCA – Productive Payslip Current Period
- SBP – RCA – Productive Payslip Previous Period
Now the following solution is similar for the both the RCA. This RCA basically calls a program H99_HRFORMS_CALL with a custom variant PCC_ALERTS. The variant is kind of empty meaning all the values of the variant are determined dynamically by the pipeline of the PCC Process flow that generated that Alerts (those who know PCC can understand what I am saying). When one looks at the Alert in the My Alerts tab of the PCC, one can click on the rows of the employee and that will drill down to the RCA.
Below is the RCA – And as once can see, RCA shows the payslip of the employees for that particular payroll periods. And when one clicks on the preview icon(right side of the screenshot), one can see the full view of the payslip.
So, as mentioned above, this RCA basically calls a program H99_HRFORMS_CALL with a custom variant PCC_ALERTS. Now the Process was able to update every value of the PCC_ALERTS but not the HRFORMS of that particular country as shown below.
That’s where the TableValue1 function was helpful. So, I created a table ZGL_HRFORMS with key field as ABKRS for the payroll area for which the PCC Alerts were generated and the value field where the HRFORMs names were stored.
Now we called this table in the auxiliary definition for the RCA – As shown below, P_FNAME is the variable that is fed to the PCC_ALERTS form name field. P_FNAME calls TableValue1 function with table name as ZGL_HRFORMS, SMARTFORM as value field and ABKRS as key fieldname and [Employee Number]-[Payroll Area] ) as variable that’s there in the process pipeline.
Thus, I was able to feed the different HRFORMS to the PCC_ALERTS variant of the program H99_HRFORMS_CALL program.
Phew! If you’ve made it this far, give yourself a pat on the back – you’ve journeyed with me through the intricate maze of Managed Configurations. I must confess, my fingers are almost staging a protest after typing all of this out! 
Jokes aside, I genuinely hope that this deep dive into the world of TableValue1 and TableValue2 has shed some light on their potential within Managed Configurations Apps. For all you eager learners and tech enthusiasts out there, may this serve as a beacon next time you’re navigating similar challenges.
Stay curious, keep experimenting, and remember sometimes, the best solutions emerge from the most unexpected routes. Happy configuring!