Title: Future Payments
Description: Future Payments
MikeDrischler - January 12, 2007 02:41 PM (GMT)
Questions,
We are encountering more and more situation where we want to set up future payments for an employee. It is my understanding that we can do this with Lawson but there may be some issues. I am not fully aware of the "issues", but wanted to throw the following scenario out for your input.
I have an employee who is to receive a stipend which will be paid out in 4 equal payments of $250. The payment schedule is as follows:
Feb 15, March 31, May 15 and June 30 Can these payments be pre-loaded into Lawson such that the payroll staff will not have to worry about the payments and also so that these payments do not impact any payroll where they do not come into play (i.e. the Feb 28, March 15... payrolls.)
TIA
Mike Drischler
Geri Gradl - January 12, 2007 03:03 PM (GMT)
We load our irregular future payments into PR36 with a time record date that corresponds to the pay period in which it's to be paid. Just remember to load in an "F" for future in the "ST" (Status) column when adding the line item. When you run the PR38 or PR137, it will change the "future" time record to "current" and be pulled in with the PR140 run.
Hope this helps,
Geri Gradl
Manager - Payroll
American Medical Assn
SAH - January 12, 2007 04:45 PM (GMT)
Hi Mike - hope all is well. From a slightly different perspective, our users enter time records into batch status as opposed to PR36. Although I've never been a huge fan of any type of smart coding when it relates to batches, we use the pay date as our batch number, so its actually fairly easy to enter the time records into the appropriate batch, which gets processed on the appropriate pay date. Good luck!
KarenPloof - January 12, 2007 05:19 PM (GMT)
And I would have suggested putting the payments on PR30 (Standard Time Records). The date ranges would control when the payments are processed by PR134. However, if you're not currently using PR134 to create time records, using it for this one employee for this one reason would be much too cumbersome.
So now you've got three options :)
jedmiston - January 19, 2007 05:35 PM (GMT)
For what it's worth, I think the PR30 option is "safer". Maybe it was fixed in a CTP at some point, but we had a lot of problems with time entries with a future status being released by PR137 prior to the date we wanted them to be processed (it seemed to ignore the select date parameter).
We don't do a lot of future time entries, so we just started putting them in a tickler file for the cycle in which we want to process them.