PTO paid without a Absence plan

The only way I know do allow pay codes to be used only by certain groups would be to set them up by process level and/or job code, which will potentially be a huge undertaking based on your set up. Might be easier to train your users to actually look at the messages, like the negative warning, when they enter or review data.

Setting up pay codes to a process level would be a huge undertaking.

What bothers me is the system will give us a warning for an employee with a Absence plan going negative but we receive no warnings for an employee that doesn't have an absence plan at all. Seems like a big bug in the code.

I agree it would be a major undertaking. However, I disagree that it's a bug. There are too many variables for the software to be programmed to determine if a pay code is valid or not - particularly when it comes to PTO. Maybe if Lawson provided the codes, instead of the client creating them - but then that would cause heartache with too many clients, too.

Stephanie makes a really good point. If you want greater confidence that things aren't falling through the cracks, you might want to set up a quick Crystal report against one of the LP tables, PGEMPLOYEE, and TIMERECORD to ensure that employees aren't getting time records that they should not. I'd run it prior to the PR140 and then delete the suspect records on PR35/PR36 prior to continuing. That might be the lesser of the evils.

With TA, we would get an audit message saying an employee used PTO but was not enrolled in any plans. I did enter an enhancement request 14779. Please vote "me too" if you are interested. I agree that right now the only option is editing the time records through another method.

We have experienced the exact same problem and the information on the Lawson Knowledge base is as follows: Actually, if the employee is not and has never been in any plan against which the hours (or earnings) would decrement a balance, you would not get an edit. It takes the presence of an employee master record (active or inactive) in a plan to trigger the editing. What will happen in the case below is the "event" (aka time record/service record) will not be updated by the LP cycle, and LP140 will provide a message on the "Unprocessed Event Records" report that tells the user that the employee had a time record that could not update ANY plan.
The editing on the PR side is aimed at preventing or warning against negative balances. Due to the amount of on-line editing that is already going on (and the impact to system performance) we did not make the time entry process a catch-all for all editing that could take place. Lawson handled this more through an auditing process in the LP cycle, since there are other ways to control the use of a pay code for an employee who is not (and never has) qualified for any LP plan.