Check Replacement Processing Date issue

Check Replacement Processing Date issue - T52OCP4

Debugging a process model

Debugging a process model- Note 1825873

You create or maintain a process by transaction PEST; A simple example which will be used throughout this article is the following:

In this model, the unique root node is the German payroll driver RPCALCD0. It constitutes the first step of this process model. In the second and third step, payslips are printed by the RPCEDTD0, and payroll accounts are generated by the RPCKTOD0. In other words, the node "Payroll" has two children, namely the nodes for RPCEDTD0 and RPCKTOD0, respectively. One also says that these two nodes have the "Payroll" node as a parent. Note that an e-mail notification will be sent after the execution of RPCEDTD0. This is indicated by the symbol in the upper right corner of the corresponding box. Associated with this model is the selection program H99_SELECT_PERNR.

A process model is executed via the HR Process Workbench which can be called by transaction PUST. The following diagram illustrates the program flow of a process in its simplest form:

With transaction SWEL you can monitor all events that have been raised by a process model. In our example the event trace looks as follows:

After these preparations, we are now in a position to collect some hints how to debug the above steps of a process model.

• How to debug the selection program:
  1. Create a process in transaction PUST.
  2. Start this process by pressing F8.
  3. Choose "Immediately" on the upcoming pop-up.
  4. On the selection screen of the report, fill in the data, enter "/h" in the command field, press Enter, and execute the program.
     

From now on, we assume throughout that a process has already been carried out by transaction PUST.

• How to debug the reports along with their variants used during a process:
  1. In transaction PUST, right-click on the number of the process you want to analyze. Go to "Display additional information" and keep in mind the starting time of this process.
  2. Start transaction SM37. Enter WF-BATCH as user name and choose the time appropriately around the starting time of the process. You obtain a list containing the jobs executed during the process. If you want to debug one of this jobs, mark the job in question, enter JDBG in the command field, and press Enter. 
      

                                                                                                                                                                                                                                                                

• How to debug a single step of a process:
  1. Set a breakpoint in method DETERMINE_SUPPLIED_OBJECTS of class CL_HR_PM_PW_PROCESS_PROG at line 47 for the command  CALL METHOD me->modify_parcel_objects.
  2. Go to transaction SE37, choose HRPY_PROCESS_WORK_ON_EVENT as  function module, and press F8 (Test/Execute).
  3. In the following screen click on "Debugging".
  4. Press "Save" on the two upcoming pop-ups without entering anything.
  5. Press F7. After that, you are at the coding of HRPY_PROCESS_WORK_ON_EVENT.
  6. Press F6.
  7. Change the values of the variables H52SPS-PROCESSID, H52SPS-STEPID, EVT_NAME, P_CONT as follows:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-PROCESSID	0000000001 for the first step, 0000000002 for the second step, etc.
     EVT_NAME	JOB_STARTED
     P_CONT	X

     
  8. At the breakpoint jump to the next statement by putting the cursor on the next statement in line 51 and choose "Goto Statement" in the "Debugger" menu. (Otherwise, the system recognizes that this step has already been performed and proceeds in a different way.)
  9. Note that the job generated by the function module is no longer planned by user WF-BATCH, but by the user who started the function module.

• How to debug all children of a process step. This also enables you to monitor how the STEP_ENDED event is raised:
  1. Proceed similarly as for the first step, but at point 7. choose the appropriate values for the parent node:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-STEPID	the step ID of the parent node
     H52SPS-RUNID	the run ID of a finished run of the parent node from transaction PUST, e.g. 0000000001 for the first run
     H52SPS-PARAID	e.g. 000001
     EVT_NAME	JOB_ENDED
     P_CONT	X

• How to debug the communication such as e-mail notifications after a step has ended:
  1. Go to transaction SE37, choose HRPY_PROCESS_COMMUNI_ON_EVENT as  function module, and press F8 (Test/Execute).
  2. In the following screen click on "Debugging".
  3. Press "Save" on the two upcoming pop-ups without entering anything.
  4. Press F6.
  5. Change the values of the variables H52SPS-PROCESSID, H52SPS-STEPID, EVT_NAME, P_CONT as follows:

     H52SPS-PROCESSID	process number from transaction PUST
     H52SPS-STEPID	step ID from PUST for the step you want to monitor, e.g. 0000000001

References

This document refers to:

SAP Help Portal

Executing Processes

Maintenance of Process Models

SAP Payroll-Tax calculation during Cross Year Retro:

NOTE on processing Class 71 :

Tax Class 0 and 1 does not have major differences. You can check the tax combo from all the 3 tables or run S_AHR_61018777 - Taxability models/tax types by tax authority report...and filter tax class 0 and 1 to see the difference.

In the standard client you wont see any difference.

PC 71 spec 0 is always for regular taxable wages that are recurring in nature

PC 71 spec 1 is customer specific which can used for any reasons..like to group all the one time payments from recurring or group all wages taxed at supplemental rate or any customer specific taxation which may be little different than regular taxable wages. Then use 01 and change the combo.

SAP Payroll-Tax calculation during Cross Year Retro:

If a retroactive change crosses the year, the payroll driver does not go back and recalculate taxes for the prior year. This is controlled by function UOTX0 within Payroll schema .

 Payroll function UOTX0 is only performed when the check dates of the  in-period and the for-period belong to different calendar years.

 To this end, function UOTX0 extracts from table ORT (Old Results Table) all tax-related  technical wage types - that is, all wage types belonging to the name ranges /4**, /D**, /H** and /N**. The function then adds the tax authorities of the earlier period to the current table TAX, assuming  that these tax authorities are not already found there. Finally, function UOTX0 copies the earlier tax wage types from table ORT to table RT.

 

As delivered, the payroll driver does not allow retroactive taxes to be higher than the taxes withheld in the original period, i.e. a 'cap' is placed on retroactive taxes. This cap could lead to errors when performing a retro calculation where a state change is involved. You can control whether a cap is placed on retroactive taxes in function UTPRI within schema U000.

Cross-quarter retro calculation

When you make a cross-quarter retro calculation, the system identifies and records key data for the run in the Cross-Quarter Retro calculation table. This data is critical for both Tax Reporter and the Payroll Reconciliation Report. Payroll creates entries in this table whenever it detects a cross-quarter retro calculation of payroll results that were already included in a productive Tax Reporter form generation run, as indicated in the Tax Reporter Control Record. Entries are made in the Cross-Quarter Retro calculation table for any retro change that adjusts taxable or tax wage type amounts in the original period.

Other retroactive adjustments not impacting tax reporting are not flagged in this table. Tax Reporter uses the entries in this table to pre-select employees for correction forms, allowing more efficient runtimes during tax form generation

- Suresh Kalimahanthi

US Medicare tax calculation getting a difference of $0.01 - NOTES

US Medicare tax calculation getting a difference of $0.01

Issue:

The EE medicare tax was calculated at the rate of 1.45% on taxable earning amount(/605 Amount). This calculation is performing by BSI and it returns the tax amount (/405 amount) to SAP.  For an employee  for period 16.2010 & 17.2010 have the same taxable earning but the tax amount is different was calculated differently by BSI. There was difference of $0.01.
Period     /405 Amount     /605 Amount
16.2010     34.65     2,389.44
17.2010     34.64     2,389.44
We have approached BSI for the same but they asked us to refer Lawson article #558668 (Tax Deduction Table Off By 1 Penny).  

Answer

The rate is .0145. It has four decimal places, so the system has rounding issues. The total of the rounded numbers (34.65 +34.65 = 69.30) does not equal the total of the wages multiplied by the rate. The total is 69.29, when that total is rounded. The system has to occasionally report differences of $ 0.01 in order for the math to work. So it reports 34.65 for one payroll and 34.64 for one payroll. See below.
This happens in any vendor's payroll system in the US.  

rounded        unrounded 
34.65            34.64688       2,389 .44    Wages & Taxes

34.65            34.64688       2,389.44    Wages & Taxes 
69.30            69.29376       4,778.88   Total