Carry forward overtime to next month – (Pay 26th to 25th)
1. Objective
I hope this article gives you an idea how to use processing types in time management to flag your records n time evaluation in order to control their loading in payroll.
2. How can use this method
Almost companies in my country are running payroll in monthly period but not from 1st to 31th. The period usually is 21st to 20 or 26th to 25th. I had lots of issues to implement this solution and already have some because our legal reports for insurance must be report from 1st to 31th.
During considering different methods to solve this issues I learned a lot about time management, payroll and time and payroll integration.
One of common issues in time and payroll integration is pay overtime from last month. For example if you would pay the overtime in a period like 26th to 25th or any other an your regular payroll period and you would transfer the exact overtime hours from last period this is the solution for you.
Obviously there is other method for this issue which I would explain in second part of this article if I found time.
It’s my please to thanks a lot Luis and Pablo, my friends who are senior PY and PT consultants and helped me a lot during finding solution. I dedicate this article to them
3. Requirement
A client who is running payroll from 1st to 31th would pay overtime from last month 26th to 25th of current month.
4. Solution ( Time management side)
I am sure you are almost familiar with following 4 most common processing types in time management:
A: Absence
S: Planned work
M: Overtime
K: Break
4.1 Create your own processing type in V_T510V.
My processing type is Z and I call it “Delta overtime”. I will use this processing type to flag my overtime records from 26th till 31th of month.
4.2 Create time type selection rules in V_T510S. A rule for month overtime which comes from 1st to 25th
And the second for delta overtime(26th to 31th) which will pay in next month.
4.3 Make a copy of PCR TO20 and TO21 with a small change. I put my PCR’s name >O20 and >O21 as you see I just add a “Z” to GENOT operation. We use GENOT to create overtime pairs. To see help of GENOT please push F1 in this operation.
But to control the date you should add an IF… ELSE … ENDIF structure. So I prefer to replace GOT TO20 15 ASC with a subschema like this
In ZZOV subschema PCR: >TEP controls if current day is after 25th or not. If it’s after the PCR returns False and main schema(ZZOV) will consider >O20 otherwise the normal PCR(TO20) will run.
Maybe HRS=DSCDY is a bit strange for you because I had my own mapping of Shamsi calendar days into Gregorian so if you are using Gregorian calendar you can use HRS=BCURDY for example to return current day of payroll period.
You can use VARSTREDAY or VARSTCURMO but take care both are working based on time evaluation period not payroll period. To understand the difference of time period and payroll period please look at my document at http://scn.sap.com/docs/DOC-45887
4.5 Copy subschema into main schema and disable one line.
4.6 Put a line in your schema to process the delta overtime
Therefore system selects TO20 to run.
5.2 TO20 input TIP
5.5 Select time wage type
5.7 >O20 input TIP
5.10 Select time wage type
6. Solution (Payroll side)
I am running international version of SAP payroll (Schema X000). Go into subschema XT00
6.2 We need a change to loading data from previous payroll result also to read all overtime which has saved in previous payroll result(records with processing type Z). This is small PCR you should add after ZLIT to read the delta overtime from last result table.
7. Run payroll schema to see the result.
7.1 IMPRT B2 loads data of cluster B2
Omid
Hi Omid,
Its a good one. An interesting one too.
Thanks,
Madhav.
Thanks Madhav,
I am trying to add other screen shots and complete the document but unfortunately because of my awful internet connection speed I have not yet done! 🙁
Regards,
Omid
Hi Omid,
You kept your word. Thanks for your time and for sharing such good business scenario.
Thanks,
Madhav.
Dear Madhav,
You are welcome 🙂 . I should have some more screens to finalize this document. In second part I will explain how to implement the same scenario with another way 😉
In fact in this document I would to show how you can define your own processing code.
Cheers,
Omid
Hi Omid,
This is an excellent job,and will be very much usefull to all. In my experience, most of the companies having the same requirement what you have explained.
its realy great job. well done. 🙂
Regards,
Dinesh
Dear Shan,
It's my pleasure to have your encouragement 🙂
I hope to complete it as soon as possible and share more information by writing the second part.
Thanks a lot,
Omid
Excellent One Omid.. Loved it
Anil
Dear Anil,
Thank you very much indeed for your kindly message 🙂
Omid
Hi Omid..nice one..
thank you for sharing.
Warm Regards!
-Kanuku
Excellent and helpful post.
Regards,
Jyotsna Akula
Hello Omid,
Very nice article. I have a small doubt, usually when you evaluate overtime we use IT2005 here IT2007 as special requirement you said. Will it be applicable, if we use IT2005 as well?
Please confirm.
Thanks.
Best Regards,
Jayasree D
Dear Jayasree,
I have never used IT2005 for overtime because if you refer to SAP standard documents IT2005 is out of date and IT2002 supports whole functionality now. I recommend not to use IT2005 any more but maybe you have a implemented system which is use IT2005 already.
I think the infotype is no matter. You can generate any time type with special processing type and keep in B2 cluster. Then based on processing type you can develop your own load functionality in payroll side.
Regards,
Omid
Nice work Omid. very helpful though. Thanks for such content and we expect more from you.
Regards,
Praveen Agarwal
Thank you Omid 🙂 .
PD
Excellent work Omid..Thanks for sharing this ..
Regards,
Srinivas Katredddy.
Good Document
Valuable Info
Read worthy document
Awesome solution Omid. It also helped me to solve another issue I have been facing.
Brilliant work!!!
Hi Omid,
have all the screenshots are added.. is it a full document ? Part 2 has been written, because i am just reading this and hope Part 2 has been written already.
Thanks
Sriram
Instead of the above, can't we always run time eval from 26th of last month to end of current month. (TVAR table can be set up using a program for such values and used in the PT60 txn variant).
Then in the time schema PCR/s, before CUMBT function,
- if current day is past 26th of current month (using the pay period month),
- - delete time type values, time w/t's?