Control Record Earliest Retro Change

[Former Member]

Hi

  Thought of discussing and getting information from the group on these points listed below:

1) Is it a right/common practice to change the Earliest retro acctg period in the control record every year. For example if the customer decides the system should not retro back into previous year?

2) Ideally what is the right time to delete the existing control record and create a new one with the new Earliest retro period? We are currently planning to do it just to the start of the 1st period in the new year.

Thank you

[Former Member · Accepted solution]

1) In my opinion, rather than deleting and recreating the control record with a new Earl. retro period, a better approach is to restrict the Earl. Pers. RA date in Infotype 3 via report RPUTRBK0.

2) If you'd still rather delete the control record, I think the time suggested by you is ok. To be safe, you can lock HR users while the deletion is in progress. Or you can do it after working hours so that changes to HR data do not take place during the deletion.

[jagan_gunja]

As Tania said, the actual Payroll ERA date used by the system would be the later of the dates in control record and the employee's IT 3.

However, as observed in practice, this may not apply, if there is already a live payroll run previously for that period and the pay results contains retro periods prior to the later of the above two dates.  In that case, when payroll is re-run, it will retro to the same period as before.  To avoid this, the pay results for this run need to be deleted and the IT 3 dates checked/corrected before re-running the payroll. 

Same applies to Time eval results and time eval retroing.

Further, when a person is re-hired, common practice in many of my client sites is to set the IT 3 - ERA date for payroll as the pay period start date corresponding to the employee's re-hire date and the ERA date for Time eval = re-hire date.

This can be done through dynamic actions for IT 1, so that the payroll area in IT 1 is used for determining the payroll ERA date.  Also for this a function call is used to determine the payroll ERA date and the date is passed to the dynamic actions in RP50D-DATE1 and dynamic actions would update IT 3.

[former_member193210]

We recommend to our Payroll Supervisors to periodically modify the Earliest retro acctg period of the Payroll Area Control Record (t-code = pa03) to prevent calculations that go more than some 1 to 1½ years in the past.  This can be reversed at anytime that it is required, such as when retroactive salary grid change (due to Collective Agreement Negociations or Salary Equity Process).

I don't think that there is a "best time" to do that change.

We also recommend them not to change the dates on the Employee's IT0003 (t-code = pu03) unless there is a Time Evaluation problem or a Payroll Calculation problem that makes retroactive calculation before that date impossible.

[Former Member]

Hi Remi,

    Thank you, it sounds logical to do what you suggested.

     So when we are exiting the control record we need to change the ERA date as needed before saving. For example if we are exiting 24th period of monthly payroll before saving the control record we change the ERA date to 01 2016, so that starting from payroll period 01 2016 the system will not retro back past 01/01/2016? correct me if I am wrong.

Thank you.

[former_member193210]

After all Year-End Adjustments are done and the Year-End Reports are published (let's say in early March), you could set the PAA so that no retroactive changes would be allowed before the beginning of the new year (the first pay in January).

In this scenario, if a retroactive change is required, the PAA must be modified to allow it, and then reset to the beginning of the new year.

On the other hand, that is not required if you regularly execute a report on IT0003 to see if an employee has a retroactive date (for Time Evaluation or Payroll Calculation) that is out of the "normal" range, investigate why, and then take the appropriate action.

[Former Member]

Thank you all for the responses. Changing the IT 0003 ERA is a good suggestion we thought about it too, but I think the payroll schema gives more priority to the control record ERA date in some scenarios vs the ERA date in IT 0003. For Example for some employees if the ERA in IT 0003 is set to 01/01/2016 and the control record is set to 01/01/2015 the system retros back to 01/01/2015, not sure what scenarios trigger this but it happens for some.

Thank you

[Former Member]

This is strange. It should work this way-  if you have two different dates as the Earl. retro date in the control record & infotype 3, the system considers the later date as the Earl. retroactive accounting date.

So in your example, the system should retro back to 01/01/2016 & not 01/01/2015. I suggest you reconfirm.

[Sanky]

Hi Steve,

But I think you should check in the system. This is happening when you have run the live payroll and it's run with retro from 01.01.2015 after that if you will maintain IT3 as 01.01.2016 then system wouldn't run from 01.01.2016 since payroll cluster is already updated. So this case, you have to delete the retro payroll result and after that set the ERA as 01.01.2016 in IT3.

Now system won't go to retro from 01.01.2015 and will run from 01.01.2016.

Regards,

Sankarsan

[Sanky]

Hi Steve,

ERA is set as a go live date in the control record.

Now if you don't like to go to retro from previous year on every year after the Go-Live then you should control it at IT3 level for all the employee's.

But we can not say it's not required a retro. Since it's easy to control and have required many country's payroll process for tax relaxations or Payroll period and Time evaluation period is different.

So I think you should suggest to Client about ERA at Control record for Go-Live but later on it's should be controlled at IT3 level at employee level.

Regards, Sankarsan

[BalaAP]

Hi,

This depends on organization's requirements. I would share few scenarios based my experience:

1) When +ve Time Management implemented, time administrators enter overtime entries in the system. They started entering back-logged data of even more than 3 to 4 months old. This brought poor system performance, since system goes retro for many periods, and also the pay-slip went lengthier, because, they showed the arrear amount with *. To control this, company brought a policy to not to go back retro for more than 2 months.

2) Cross-financial retro brings many arrear wage types and bring some complications in tax calculations (depends on country versions). But when they want to claim some tax relaxations from previous year, it is required to allow cross financial retro. It purely depends on company requirements.

I feel, ERA date should be used judiciously.

regards,

Bala.