Leave Encashment on Last Basic Salary in Retro

[Former Member]

Dear All,

We are paying Leave Encashment for year 2011-2012 in April,12 which will be calculated on BASIC of March, 12. (By creating a record in IT416 in April)

But From MAY, 12 employees will get appraisal with effect from April, 12. In this case when we are processing salary for May, 12 system will do the retro for April, 12 in which leave encashment of Last year leaves also will be there which actually should be encashed on March, 12 Basic.

Here system will encash the leaves on April, 12 BASIC which is more then March, 12.

Pls suggest a best way to address this isuue.

Pls suggest...

Kind regards

NAG

[Sujith_EM]

I have some doubts regarding ..

Are you doing off cycle or regular run for leave encashment ?

How you are taking march month basic as a basis of leave encashment in April ?

How the march month salary is considering while you enter IT0416 entry in April ?

Are you passing or storing the basic pay of March in to any variables and passing for the  encashment calculation ?

[former_member182232]

Hi Nag

You are referring that the Leave enchashment paid for last year dates in April will be recalculated due to the salary increase.

If this population is minimal i suggest a manual workaround.Like we in same case(were paying encashment via IT 2010) had corresponding wagetypes in IT 2010 where we had option of entering the valuation field with the rate in which case it would be unaffected by the basic salary changes. Not sure if IT 416 has valuation field

Another option would be to restrict the IT 416 to be processed only in the current period.This i am not sure how functionally would be possible

Regards

Ajay

[Former Member]

Hi,

I guess, you are running simulation and when u have not exited live payroll of March'12, the system will calculate retro effect of march'12 also into april'12 and so on.. as there is no updates in RT for march'12.

you can test in development by exiting the march'12 payroll and then check. it will resolve.

Thanks,

Nirali P.