cancel
Showing results for 
Search instead for 
Did you mean: 

Payroll Operation for more than 2 WPBP splits

0 Kudos

Hi Experts,

I have three splits in a month in WPBP.

01.10.2019 to 29.10.2019 with first split, emp is active

30.10.2019 to 30.10.2019 with 2nd split, emp is active

31.10.2019 to 31.10.2019 with 3rd split where is inactive (Separation is updated)

We have written PCR for some other functionality with last split to process futher, all further IT tables WT is updated with 02 split and XVAL function is factoring with working days rule /802 and calculating only one deduction of WT and not processing first 29 days of first split.

Please suggest workaround to achieve solution for first two splits through XVAL.

Example - Ded WT - 50 per month active days in Oct 2019 - 23

Calculation - 50/23 = 2.17 Output table showing only 2.17 as deduction where it should be 45.57 for first split + 2.17 for 2nd split.

Thanks.

Chanakya Boruvancha

Accepted Solutions (1)

Accepted Solutions (1)

former_member630342
Participant
0 Kudos

Hi Chanakya,
Neither country version nor currency is specified. You put the tag "hcm payroll uk", but XVAL is not used in GB solution, there is a country specific rule for factoring there.

Not quite clear what you are trying to do. It looks like you broke the solution with some PCR for "some other functionality" and now trying to build crutches to get about on further.
This is a dead-ended approach and it's useless to discuss your deduction wagetype case without considering your previous change, as to me it makes sense to dive into the factoring process in general.

I also don't agree with Saisanjay as making new branches in the rules, with the wagetype codes as a condition is not a long-range shot. What if someone wants to make the similar deduction later on?
Instead of simply copying the existing wagetype a new PCR changes would be needed - again research, again time, again errors. Not good.
Standard functionality, existing rules, processing classes - these are your three pillars.

At first, from the process point of view, that factoring in inactive period is quite a tricky thing - you'll have to get your workschedule (IT0007+2003) always in place in the inactive period of a month, meaning that these infotypes should be never delimited on separation as it is usually done.

Then, technical-wise, seems you have your deduction entered in the last working day of the employee. This is an assumption only, considering the information I get from your post as your WT comes to XVAL with the 02 split. So that you get that 50 x 1/23 = 2.17 (in unknown currency).

Here if you want to get the deduction factored across all active periods, then it makes sense to start solving the task as it is formulated.

You have to visualize your business process clearly.
I would put it this way: if you really need factoring in inactive period for some reason and don't have such a factoring coefficient currently, then better use a custom coefficient that is not used as of standard (/8XX, where XX stands for an unused number, as usually only a few are occupied). So it's better not to touch those already in use (like /802), but use a custom one (e.g. /812 whatever, for every country unused range is different) for custom logic like inactive periods. Any (more or less experienced) consultant taking a look at /801 or /802 knows it means factoring in calendar or working days; and taking a look at somewhat like /814 also knows it's a custom one and he'd better open a blueprint and a rule to check what was it made for.

At first, you might want to distribute the wage type along all the workplaces while reading your IT0014/0015 infotype - processing classes 47/10 manages that for every country version I came across; look into your infotype reading rule and check what processing classes and their specification engages the operation WPBPC that distributes your wagetype by all the WPBPs.

Then, check the rule forming /802 that I believe you already changed (as you're getting /802 for the inactive period if I understood correctly). The one that forms partial coefficients prior to XVAL for your country version.

Thus, in the rule forming factoring coefficients (copy of a standard one), avoid the checks for inactive period done by the international operation PPPAR to engage formation of your custom /8XX where needed, without changing the formation of the standard coefficients.
Use the right specification in processing class 10 to engage factoring needed wagetypes with your custom /8XX, what is initially assumed to manage your factoring. Thus, for the wage type for which you need your inactive factoring, use custom /8XX, for others including your deduction, use standard /802.

Thus, /802 will factor only across your active periods and you should get the correct amount. I suppose it is 50×22/23 = 47.83 in unknown currency, I don't understand why you wrote 45.57 - it looks like an error, as for the first split having 21 working days the correct calculation is 50 × 21/23 = 45.65 (in unknown currency).

Kind regards,
Alex

0 Kudos

Hi Alex,

Thanks for your time in explaining the solution in detail. Its for Great Britain, and currency is GBP.

We will try to fix the issue with above given solution, if we still have issue then I will post here for further help on this.

Regards,

Answers (2)

Answers (2)

former_member193210
Active Contributor
0 Kudos

Hello Chanakya,

You should check the configuration parameters of that Deduction WT (specially in V_T511 and V_512W_D), and those related to the Payroll Function that reads the relevant Infotype.

former_member50501
Participant
0 Kudos

Hi Chanakya,

Please find below the workarounds I can think of is:

1) If the split removal is happening in a PCR, then add another node with this deduction wagetype and send it to the OT.

2) Without disturbing the previous PCR or config: 1) write a PCR to read the original deduction wagetype into another Wagetype(copy wagetype) and send the same to OT. Then write another PCR which reads the splits from copy wagetype) . If it is last split ignore, and all other splits pass onto the original deduction wagetype.

Hope this helps.