Skip to Content
Actions

PRATE Functionality- Recurring Payments/ Deductions

August 4, 2016 | 262 Views |
 hcmmodifyingmodifyingpcrpayrollpcrprateprorate
Follow RSS

Greetings my fellow Scnians

Introduction

I just finished a document which I have uploaded in SCN couple of days ago on Absence and Quota Configuration Made Easy. The link for the same is http://scn.sap.com/docs/DOC-73121 . This actually made me in the mood to make one more document as I enjoyed the process and request you all to do the same for the below reasons-

You’re learning on the topic increases when documented.

  1. You can refer the same in future as memory fades over time which is of course a god given gift
  2. You’re helping other Scnians to learn and also increase your respect and not to mention your opportunities to move into your dream jobs etc…

I had encountered this issue in the past which I would be detailing below which any consultant can come across and so thought to document the same.

As part of the document, I would be covering on one of the approaches on how to pro-rate a single wage types in IT0014 in UAE Payroll without impacting other wage types processed via IT14.

Our common understanding is that when a wage type is created with validity dates for a certain period, then that would mean that the amounts are meant to be paid for that period only.

Eg: If an employee is eligible for 1000 USD and it is for a certain period say Jan 15, 2016- Jan 31,2016, then below would be our logical assumption:

The payroll period January’ has 31 days. The infotype record is valid as of the 15.01 and is therefore valid for 17 calendar days in January

Calculation- 1000 * (17/31) = USD 548.39

But as per SAP, the amounts entered in infotype 14 is meant to be paid/ deducted as a whole and not prorated for the month so in the above scenario, even though the validity of the record is only for 17 days, the entire 1000 USD would be paid out in payroll.

My objective would be to cover step-by-step configuration of the entire solutioning of this requirement with the approach of using PRATE Operation insync with Processing class and PCR specific for UAE Payroll.

Assumption

You must use operation PRATE within a personnel calculation rule that is  accesed by the functions of the infotypes Recurring Payments/ Deductions  (0014), Membership Fees (0057) or other similar wage types. Otherwise the operation does not produce meaningful results.

Requirement

Laying out the requirements based on which the implementation part would be designed and executed.

                           

  Sl. No   Functionality Dates   AS-IS   TO-BE

1

IT 0014 Prorated based
  on start date. Amount 1000 USD

Jan 15, 2016 – Jan 31, 2016

The entire amount is paid out

Prorated amount should be paid out

2

IT 0014 Prorated based
  on start date and end date. Amount 1000 USD

Jan 16, 2016- Jan 27, 2016

The entire amount is paid out

Prorated amount should be paid out

3

IT 0014 Prorated based
  on end date. Amount 1000 USD

Jan 01, 2016- Jan 15, 2016

The entire amount is paid out

Prorated amount should be paid out

Implementation

Our first approach would be to identify which schema, PCR’s etc should be customized so that we meet our requirements. Also placing the PRATE function in the appropriate line in the PCR matters else again it would impact the calculations negatively. For the purpose of the document, I am using UAE payroll and hence would be mentioning specific to UAE only.

For UAE payroll, this functionality would need to be implemented in the below PCR’s and Schema sequentially:-

  1. AE11- PCR
  2. AE39- PCR
  3. AEP9- Schema
  4. AE00- UAE Payroll Schema

Note: Whenever you have requirements to modify the standard solutions given by SAP, the best approach would be to copy the standard solution, rename it and use the same for modifying as per the client requirements. Its always in the best interest of the user to ensure that standard programs are not modified.

Step 1: We shall first copy the payroll schema for UAE so that the changes can be made in the custom schema and not impact the standard SAP Solution.

PRATE DOC 1.png

Step 2: We shall then copy the sub-schema which calls the below PCR for payroll processing and rename the custom schema.

PRATE DOC 2.png

Step 3: We shall copy the standard PCR which calls the below PCR in its codes and rename the custom PCR

PRATE DOC 3.png

Step 4: We shall then copy the standard PCR which would be called in our program so that we can build the functionality and make custom changes to the same.

PRATE DOC 4.png

Step 5: We shall then modify the Processing class of the wage type which needs to be prorated based on the start and end date. Lets give this a unique value so that it does not impact other wagetypes. This way all other wage types can be processed as per normal process except the one we are going to use here.

PRATE DOC 5.png

Step 6: Now we shall build the logic in PC47 with Value A. Here we would include the PRATE function for factoring the wage types.

PRATE DOC 6.png

Results

Scenario 1: IT 0014 Prorated based on start date. Amount 1000 USD

PRATE DOC 7.png

PRATE DOC 8.png

Scenario 2: IT 0014 Prorated based on start date and end date. Amount 1000 USD

PRATE DOC 9.png

PRATE DOC 10.png

Scenario 3: IT 0014 Prorated based on end date. Amount 1000 USD

PRATE DOC 11.png

PRATE DOC 12.png

To make this document suit your project requirements, you can simply identify the country specific schema your working in and then follow the above steps.

This would bring me to the conclusion of this document and sincerely hope this comes in handy for our HCM consultants and need not reinvent the wheel.

Thanks and regards,

Shine Sebastian Joseph

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

    1. Srinivas Vajhala

      Hi Joseph,

      Thank you for the document. I agree with the PRATE functionality, because i’ve worked on similar requirement.

      For other country Grouping s such as US / CA / India, Processing Class doesn’t come with the same processing for Specification ‘A.  Specification ‘A” stands for – No processing.

      I believe we should go with new specification or handle it differently. But certainly a good document for publishing new information on this forum which might be useful for others.

      Thanks

      Madhav.

      (0) 
      1. Shine Sebastian Joseph Post author

        Dear Srini,

        Sincere thanks for your comment.

        Your understanding is correct. For illustration purpose, I used Spec A, we can use any spec from the list as the logic is only to ensure we have a separate value for the wage type which we would like to prate where as other wages types would have a different value and thereby not be pro rated.

        Happy reading..

        Regards,

        Shine

        (0) 

Leave a Reply