You can simplify bonus payments to a terminated US employee by setting up a Business Add-In to do the job. This approach is flexible enough to meet your own business requirements.
When you enter additional earnings on an infotype 0015 (additional payments) record for a separated employee, the next payroll run may not pick up these earnings automatically. To ensure that payroll processes them, set the Run payroll up to field on the infotype 0003 (payroll status) record to a date within a payroll period that has yet to run. Payroll discovers these records when running the payroll period for that date. However, it’s difficult to remember to do this every time. Put your mind at ease and set up a Business Add-In (BAdI) to do this for you automatically. You can easily adapt this technique to other business scenarios.
Picture this scenario. In many companies, individuals are eligible to receive bonuses after they separate from the company. Some HR departments enter bonus information for an individual on the infotype 0015 record. After employees leave, the payroll system no longer processes those individuals.
Manually updating these records involves two steps. First, you would have to enter the additional payments information on infotype 0015 via transaction PA30 (maintain master data). Then while you are on the Maintain Master Data screen, you need to select the infotype 0003 record so that the Run payroll up to field is adjusted.
For example, the employee in Figure 1 has a payroll Accounted to date of 01/01/2004, indicating that this was the last time that payroll ran for the individual. The most recent payroll ran on 05/01/2006. I updated the Run payroll up to field of this employee’s infotype 0015 record with an effective date of 05/15/2006, the date that the bonus was due. The date must equal or exceed 05/15/2006 for this bonus payment to process because payroll runs on 05/15.

Figure 1
Update the Run payroll up to field in infotype 0003 (payroll status)
This two-step process may frustrate users. Wouldn’t it be beneficial if you could consolidate this into a single process so that users could update the infotype 0015 record and have the infotype 0003 record update automatically with the validity date from infotype 0015? A simple dynamic action could update the infotype 0003 field whenever someone creates or changes an infotype 0015 record. This solution only works if users enter the infotype 0015 record in foreground mode. Batch Data Conversion (BDC) programs do not process dynamic actions because the processing happens in the background. To ensure that the infotype 0003 record is updated for every infotype 0015 record, you could create a BAdI that calls foreground processes from the background.
Set Up the BAdI
To set up this BAdI, I went to transaction SE19 and created an implementation name called ZP_HRPAD00INFTY_0015 with a definition name of HRPAD00INFTY (Figure 2). This BAdI consists of three methods: Before_output, After_input, and In_update. Before_output is for processing before output (PBO). R/3 executes code in this method before displaying the screen to the users. After_input is for processing after input (PAI). R/3 executes code in this method after users enter data. R/3 executes code in the In_update method when performing the system update. Because I want the infotype 0003 record to update when the system creates an infotype 0015 record, this code uses the In_update method.

Figure 2
Enter BAdI name ZP_HRPAD00INFTY_0015
The system calls this BAdI when performing any update, so it contains a few conditions to ensure that you don’t update the payroll status for every employee. The code is intended for a global company, but it needs to target only US employees who left the company and to update only their records. I located these employees by checking the employees’ MOLGA (their country code in ABAP). You could adapt the BAdI to another country, though.
Figure 3 shows an excerpt of the code. The full code is available in this download. The Z_READ_SEPARATION_IT3_DATA function module reads the Run payroll up to date from infotype 0003 to determine whether to update it. If infotype 0003 needs updating, then the Z_UPDATE_INFOTYPE function module actually performs the update to the Run payroll up to field with the new validity date from infotype 0015. These function modules are generic enough so that later programs might reference them. This code calls method in_update after users save the infotype 0015 record via transaction PA30.
Note
If you do not refresh the Maintain Master Data screen after updating infotype 0015, the system buffer does not refresh the changes to the infotype 0003 screen. For a second test, the developer could perform a BDC update to test the separated US employee’s infotype 0015 record and confirm the update of the infotype 0003 record.
METHOD if_ex_hrpad00infty~in_update . DATA: lv_infty_actions TYPE p0000, lv_infty LIKE LINE OF new_image, lv_begda TYPE d, lv_endda TYPE d, wa_molga TYPE molga, wa_werks TYPE werks, return TYPE infrc, ipspar_save LIKE ipspar, itab_initial_values TYPE TABLE OF pinit. CONSTANTS: lc_infty_addpay TYPE psoper-infty VALUE '0015', lc_opera_insert VALUE 'I', lc_opera_update VALUE 'U', lc_united_states TYPE molga VALUE '10', lc_infty TYPE infty VALUE '0003', lc_actio TYPE actio VALUE 'MOD '. ipspar_save = ipspar. *performs the update to IT3. ipspar-supdg = 'X'. ipspar-msgst = ' '. *verifying that this is infotype 15 CHECK ipspar-infty = lc_infty_addpay. *If the pernr does not have a value. IF NOT ipspar-pernr IS INITIAL. *selecting the ee's personnel area from IT1. SELECT werks FROM pa0001 INTO wa_werks WHERE pernr = ipspar-pernr. ENDSELECT.
|
Figure 3 |
Excerpt of code to update infotype 0003 records when the system creates an infotype 0015 record for separated employees
|
Note
For more information about how to use fast entry, refer to my article “Fast Entry Demystified” in the HR hub of SAPexperts.
Once the code is finished, an ABAP developer needs to activate it. To activate the BAdI, the ABAP developer goes to transaction SE19, types the name of the implementation, and selects the activate icon. To test the code, the developer creates an infotype 0015 record for a separated US employee via transaction PA30. After saving the infotype 0015 record, the developer refreshes the Maintain Master Data screen by entering PA30 into the transaction code box and pressing Enter. Then the developer displays the infotype 0003 screen to confirm that the BAdI updated correctly.
A situation may occur with multiple bonuses in the payroll status record. Say your employee left the company on 01/01/2006 and her Payroll Accounted to date on the payroll status record was 01/15/2006. On 01/17/2006, you enter her bonus with an effective date of 02/01/2006 and set her Run payroll up to date as 02/01/2006. On the same day, you enter an additional bonus to take effect on 03/01/2006. Given this scenario, the BAdI would override the Run payroll up to date with 03/01/2006. When you run payroll for the pay period that includes 02/01/2006, it only processes the first bonus with an effective date of 02/01/2006.
The system does not process the 03/01/2006 record until you run the payroll period. However, because the Run payroll up to date is set to 03/01/2006, the payroll run automatically includes this employee in the payroll run through 03/01/2006. This means that payroll processes both bonuses in correct sequence so you don’t have to keep readjusting the payroll status record.
In cases when you set the Run payroll up to date to a future date, the system processes several payroll and time-related infotypes including recurring payments, deductions, payments, and additional payments. However, payroll does not pay employees their salaried amount or hourly rate indicated on their infotype 0008 (basic pay) information.
Fast Entry and BAdIs
If you use a BAdI to trigger an automatic update of the payroll status record from infotype 0015, then you need to consider the impact on fast entry functionality. Normally, fast entry allows a user to update one specific infotype record for multiple employees. This means that you could enter multiple records for multiple employees using transaction PA70. This is helpful when you are typing several additional payments records at one time for various people. BAdIs do not process when users perform their updates via fast entry. Therefore, you could not enter separated US employees’ bonus information on infotype 0015 and have the system update infotype 0003 automatically using fast entry.
Dawn Burns
Dawn Burns is an SAP-certified human resources senior consultant and Quality Assurance Manager and HR Consultant with Howrey LLP. She is a former SAP Human Resources instructor for SAP America and has more than 12 years of experience in human resources and information technology.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.