As many of you are aware, the new Payroll Control Center provided by SAP gives powerful and user friendly functionality to the execution and validation of payroll within SAP.
The Rapid Deployment Solution (RDS) for the new Payroll Control Center has just been released (here) along with many great validation rules and KPIs that you can use to rapidly implement the PCC for your business / customers.
However, it will also be important that you can add additional value to your customer by implementing customer specific validation rules over and above what is provided in the RDS. This Blog goes through, at a high level, how to create a new validation rule. It should be read in conjunction with the PCC RDS overview on SCN available here. This Blog is merely a summary with high level aspects. To go through it all in detail would be more of a training course than a blog.
Firstly – the purpose of any validation rule is to, as quickly and easily as possible, provide the information required to resolve the issue.
Secondly – it is also as important to build a validation rule’s solutions in a way that mean the issue can be resolved directly from the PCC (and even potentially automatically).
Thirdly – be creative. The validation rules are not restricted to information in a particular logical database (i.e. PNP or PNPCE etc). You can write validation rules or KPIs that look across aspects of the system that are not just HR. For example, in the PCC RDS there is a KPI that checks all posting documents are successfully posted in SAP Finance. It does this by reading finance tables to check that the posting run ID from payroll is within the documents posted in the BKPF finance table. Due to the PCC not being restricted to just the HR and Payroll module, you could create a KPI for things like establishing all vendor payments posted from payroll to accounts payable have been paid (for example), whether all inbound interface files have been received, etc etc.
Fourthly – performance. It’s important that what you write will run in a reasonable time-frame so it’s practical to be used. Therefore it’s of significant benefit if you use declustered payroll results rather than traditional function modules and macros to read payroll results.
For the purpose of this blog we’ll stick to creating an example employee related validation rule. The example I’ll give here is a validation rule to establish where employees are assigned to multiple positions in the Org Chart and their total FTE assignment for the sum of those positions is above 100%.
Validation Rule Structure
To create a new validation rule, it’s best to copy one of the existing ones provided in the RDS, such as class /SMBERP/CL_PYD_PA_MAIN_BANK.
/SMBERP/CL_PYD_PA_MAIN_BANK has the below class structure:
I’ll highlight some of the key methods and their purpose:
IF_PYD_TY_RT~EXECUTE – This method is used to establish which employees have the issue of the type that your validation rule is looking for. It’s the main engine to search for errors.
ERR_OV_GET_LIST – Provides information as to the reason why the employee came up as an error in the validation rule
ERR_SOL_GET_LIST – Provides the options to guide the Payroll Administrator to correct the error
There are also several methods called RDTs or Results Detail Types (These are the YSMB* methods). The purpose of these is to show information in the detailed section of the Error Management view of the PCC. For example, method YSMB_WAGE_TYPE_REPORT shows the below information in the detail section of the Error Management view:
Once you have copied an example RDS class to your class name (and activated it), you’ll need to perform some configuration steps so that the class gets called. Only once you’ve validated you can get your copied class to work would I suggest you start changing it to meet your needs.
The configuration steps for the validation rules are in section Payroll -> Payroll: International -> Payroll Data Source Framework of the IMG. Note – these configuration steps are explained in far more detail in the Implement Configuration Guide “Implementing Payroll Control Center Validation Rules (FM1)” document in the PCC RDS (here).
Step 1 – Create Data Source Types – Create Data Source Types. This step is used to create the linkage between the Data Source Type and the validation rule class you are creating, see below:
It defines what parameters you will be passing to your class (Personnel Area for example), what results detail types (RDTs) you will be displaying for your validation rule, and what reasons you’ll present the user to be able to select in order to mark the validation rule as ‘Resolved’ for that employee.
Step 2 – Define Data Source Instances is the step I normally then jump to in the IMG. This step holds the values of the parameter you will be passing to your validation rule. For example, in the Personnel Area parameter mentioned in Step 1 above you may be passed Personnel Area US01 in order that your validation rule class can restrict the employees the rule is run for to only be those in Personnel Area US01
Step 3 – Classify Data Sources -> Set Up Data Source Classes. This step defines what folders the validation rule will appear in and is used for logical grouping. You may define your groupings by the type of validation rule or the team that will process a group of validation rules so the Payroll Manager can easily assign out those validation rules in the Monitoring step of the PCC.
Perform the above steps by copying the entries for the validation rule you are copying from. Once the above 3 steps have been setup, when you run the “Initiate Policies” step of the PCC, it will execute your validation rule:
Validation rule logic – Execute Method
The purpose of the Execute Method is to identify the employees that have an issue in the quickest possible way. Here we are not concerned with periphery information about the employee like their name, basic pay etc, we simply want to get a list of employees that have the problem that this validation rule is there to identify, nothing more.
Now you have got this copied validation rule to run from the PCC, you need to look at altering the code to perform the validation you want for your customer. Below is my example.
BEGIN OF t_hrp1001,
sobid TYPE sobid,
prozt TYPE prozt,
END OF t_hrp1001.
LOOP AT it_par INTO ls_par.
l_abkrs = ls_par–low.
l_period = ls_par–low.
l_persa = ls_par–low.
lo_payroll_area = cl_hr_payroll_area=>get_instance( imp_area = l_abkrs ).
IF lo_payroll_area IS BOUND AND l_period IS NOT INITIAL.
lv_pabrj = l_period(4).
lv_pabrp = l_period+4(2).
lo_payroll_area->get_period_info( EXPORTING imp_pabrj = lv_pabrj
imp_pabrp = lv_pabrp
IMPORTING exp_begda = lv_begda
exp_endda = lv_endda ).
* Get all positions with 008 relationships between period start and end date
* Sum the FTE percentage for each day within the pay period
lv_date = lv_begda.
WHILE lv_date <= lv_endda.
“Note OpenSQL below in order to establish using one database query what items have an error
SELECT hrp1001~sobid, SUM hrp1001~prozt
INTO TABLE @lt_hrp1001 FROM hrp1001 AS hrp1001
INNER JOIN pa0001 AS it01 ON hrp1001~objid = it01~pernr
WHERE it01~begda <= @lv_begda AND
it01~endda >= @lv_begda AND
it01~sprps = ‘ ‘ AND
it01~abkrs = @l_abkrs AND
it01~werks = @l_persa AND
WHERE hrp1001~begda <= @lv_begda AND
hrp1001~endda >= @lv_begda AND
hrp1001~otype = ‘S’ AND
hrp1001~rsign = ‘A’ AND
hrp1001~relat = ‘008’ AND
GROUP BY hrp1001~sobid.
SORT lt_hrp1001. DELETE ADJACENT DUPLICATES FROM lt_hrp1001.
DELETE lt_hrp1001 WHERE prozt <= 100.
LOOP AT lt_hrp1001 INTO ls_hrp1001.
APPEND ls_hrp1001 TO lt_hrp1001_final.
CLEAR: lt_hrp1001, ls_hrp1001.
lv_date = lv_date + 1.
SORT lt_hrp1001_final. DELETE ADJACENT DUPLICATES FROM lt_hrp1001_final.
ls_result–par_type = if_pyd_cont_types=>gcs_par_type–pernr. “Note the results parameter type always has to be pernr
“Note the only item you can pass out of this method is a list of employee numbers. You can’t pass out anything else in the structure like their name, location, employee group etc. You can fill that information per employee later in the IF_PYD_TY_RT~RESULT_DETAILS_GET method
LOOP AT lt_hrp1001_final INTO ls_hrp1001.
ls_result–id = ls_hrp1001-sobid.
APPEND ls_result TO rt_result.
Now, in order to debug your code to check that it is getting called and establish any errors or changes you may need to make to it, you can debug the job in SM37. To do that put a break point in your EXECUTE method, select the ‘00001/Execute Check Instances’ job in SM37 and then enter jdbg in the transaction box on the top left.
This will then debug the job and you can hit F8 to run to your break-point:
Now you should be able to debug your validation rule to see if it’s not working as you want and adjust accordingly. It’s not practical to debug the rule using the normal method of running it via SE24 or SE80.
Additional information to enable the Payroll Administrator to resolve the error
Once you have adjusted your EXECUTE method to the correct logic to identify the employees with an error, you can then move onto presenting information about that error to your Payroll Administrators in a way that will enable them to resolve the error as quickly as possible, i.e. the second principle in the intro section above.
There are 3 sections of the PCC Error Management view that you can alter in order to present relevant information to the user, they are:
ERR_KV_GET_LIST – This method is used to populate key values in the error screen. It has not been used significantly in the PCC RDS, but is available to use if of value.
ERR_OV_GET_LIST – This method provides information as to the reason why the employee came up as an error in the validation rule
ERR_SOL_GET_LIST – This is a very important method as it enables you to give the possibility of enabling the users to resolve the issue with as little effort as possible. This doesn’t necessarily mean the effort for the business users is small, but rather you have the chance here to set things up for the user to that they have the most efficient path available to them to resolve the issue. Where possible call transactions directly in SAP or SF in order to allow the administrator to directly resolve the issue.
You’ll need to update the code in the above methods to provide the user information as to why an employee has come up in error and provide a means to resolve that error.
For example, in my validation rule here I call SAP WEBGUI when the user clicks on the link “Remove Excess Position assignment” in method ERR_SOL_GET_LIST to allow the user to alter the position assignment of this employee:
Once you have done the above, your validation rule is setup, working and tailored to the business need.
This blog is at a very high level, and there are additional things that can be done to further add value to the business users. You can create KPI’s which can be used for things like reconciliations, payroll status tracking etc. These work on a similar, but less complex way to the validation rules.
Also, there are several Results Detail Types provided in the RDS, but you can also define your own if there is particular information you may want to show the Payroll Administrator. For example, if you have a validation rule in the time management area you may want to have an RDT that shows a time statement for the employee who has an error. Remember we want to make sure the Payroll Administrator has all they need to be able to resolve the issue without having to exit the PCC and run a transaction or program in ECC (or SF) to find out further information about this error.
Hopefully this blog helps to clarify that validation rules in the PCC are generally not onerous to build and are very powerful from a user experience perspective. Additionally, if you can structure your rules and solutions so that the solutions provide a means to resolve the issue automatically or with minimal input you can significantly reduce the work your customers will need to do in order to complete their payroll correctly and accurately.