cancel
Showing results for 
Search instead for 
Did you mean: 

LPBEG with 2 RUN's!!!

Former Member
0 Kudos

Hello All,

For current month in LPBEG there are 2 RUN's (loop twice). In the first loop a custom PCR has to generate the new wagetype and its perfected generated and can be seen in output. In second loop processing, the PCR has been processed as before but in the output new wagetype is not appearing due to which its not getting further and not available in final RT.

Can anyone help in getting the wagetype generated in second loop.

Regards,

Vivek

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi,

Thank all for your inputs...

In my scenario the issue is with a custom PCR (ZP20) that gets processed in 'Gross to Net calculation' (INN1 customised to ZP87). In the first Run loop the ZP20 PCR is processed and generated the required new wagetype in output, but in the second loop the PCR is processed but wagetype in not generated.

So how to get that deduction wagetype generated in the second loop or get that in output.

Regards,

Vivek

Former Member
0 Kudos

Could you check if there is an entry in V_t51p6 for the wage type in question? Let us know the setting for this wage type in the column Arrears. As the others said, the second loop indicates that certain wage types cannot be deducted in the current month since net pay is insufficient.

Hence, in the second iteration of the loop, based on the settings in v_t51p6 for that wage type, it will get moved to DDNTK or ARRRS or both. This means that the deduction is not deducted in the current cycle (which is why you don't see it in RT) but you will see it in DDNTK or ARRRS in the cluster.

Former Member
0 Kudos

Hi,

There few other wagetypes maintained in the table V_T51P6, but the custom wagetype that I require is not maintained. If I need to maintain, what are the values to be entered in fields 'Priority', Arrears', .Retroacc.' and what are the other implication or checks to be taken care.

I want the wagetype to be getting in RT.

Regards,

Vivek

Former Member
0 Kudos

If the wage type is not maintained here, then what I previously thought(wage type getting transferred from RT to DDNTK/ ARRRS) is not the case.

Can you send a screenshot of the Z PCRs you mentioned? Send a screenshot of the input, processing & output of these in the payroll log, and highlight the point where the wagetype is removed from RT.

former_member193210
Active Contributor
0 Kudos

What Function calls pcr ZP20?

In the first loop, what are the Input values to ZP20?

Are they the same for the second loop?

jagan_gunja
Active Contributor
0 Kudos

The deduction w/t's are added from IT to RT in PCR e.g. X030 for Australia, based on the w/t's certain proc cl 05.  Gross salary (in /101) less statutory deductions like tax are added to w/t /550.

Then the function PRPRI applies the deductions on the basis of config in view V_51P6 fields - priority, arrears, retro.  A deduction may be configured for conditions such as: apply fully or to the extent possible, etc. It may also have config for whether the undeducted amt be added to the table DDNTK (deductions not taken, ARRRS arrears.  In some other countries' payroll, there may be other config tables/views used.  The arrears column in V_51P6 will have value 5, to write the undeducted amt to DDNTK and pass to next pay period.

If a deduction can not be applied, it may be written to the DDNTK table.

After all the deductions are processed, the XDNT sub-schema line IF    DDNT (par 2) checks if there is an entry in DDNTK table;  if so, the pcr XLPC sets the loop condition as true (SCOND=T AL).  This will start the loop again from the schema XTBL (where function PITAB reloads tables like IT, etc from the saved tables XIT, etc.).  Then all the functions/pcr's are executed again in the next loop.  In the next loop, the function PRDNT modifies the deduction w/t's values in IT, using entries in DDNTK - reducing the deduction amt by the amt in DDNTK.   Thus PRPRI will apply reduced deductions in this loop.

This looping continues till it is found that DDNTK does not have an entry.

To check this second or more loop/s happening, run payroll with log.  Display the log for PRDNT & PRPRI, sub-schema XDNT lines.

The pay results for a period may contain the tables DDNTK & ARRRS where such undeducted amt's exist.

Important note:  The payroll schema PCR's use variables in a number of places.  The schema XTBS & XTBL do not save/reload variables.  Hence all variables need to be cleared before use between the schema lines XTBL and XDNT.

Sanky
Active Contributor
0 Kudos

Hi,

Check the DDNTK table and priority table processing section part in payroll schema. a

Regards,Sankarsan    

former_member193210
Active Contributor
0 Kudos

Check out the DDNTK and ARRRS tables in the Payroll Results Tables Cluster.

To my knowledge, the second loop usually happens when some deductions can't be taken.