Does running of payroll prevent entry of benefits?

For whatever reason, Lawson has not seen this as a priority (to build into the system a flag, or switch or whatever) to prevent entries during payroll processing. So to answer your question: No. Lawson does not prevent access to BN32 or any other screen when payroll is processing.

I have out here, an older post that we still employ today here at Genesis. Blocking certain web-pages from ESS. Our benefit's and HR personnel understand to not make changes... I'll see if I can locate my older post for you.

I found a link: https://www.lawsonguru.co...-payroll-is-running/

For ESS, the parameters on your BS01 determine when benefits are updated. Sounds like yours is set to pend, which means you'll need to update them via BS531 (I'm pulling this off the top of some very scant memory cells at the moment, because we aren't using ESS for benefit enrollment here)

Good point Stephanie.   Since ours are set to "immediate" I didn't even think about that.

Here's the scripts and config (.dat) file that we use for blocking ESS access during our Payroll processing.  (*In case you'd like to implement/copy/paste/steal shamelessly)  Please do so.

You will have to come up with your own "ghs_lawblock.htm" page with whatever wording you and your site decide on- 

all I just ask that you leave my name in the comments as original author- modify to your hearts content otherwise.

We just have the script set up in root's crontab file to be called every Monday (block) and every Wednesday (unblock) ---  since we are on a biweekly payroll, only needed script to actually execute every other time, so therefore the implementation of the .lck files.

Cheers,
-Greg

Thanks for the responses everyone!

I already have a script built, which runs in synch with payroll to block access to Address Changes & Direct Deposit changes. This was done similar to what Joe O'Toole from Quick Check suggested in the thread referenced by Greg's link above. However, our HR folks didn't want elections blocked when we do this because the open enrollment window is so short. (They didn't want to deny employees the ability to make their elections at any time during the open enrollment period.)

We don't pend, so the elections do go right to BN32 and we don't run BS531. I wanted to ask the community about this because they (HR) are telling me that they have multiple employees who've gone through & made their elections completely & successfully, but whose BN32 doesn't reflect those elections. So, I wondered if their elections were systematically "blocked" by Lawson code.

Thanks folks...and Greg, thanks again to you for your willingness to share your experience & coding solutions with the community...(you had previously shared your code with me on how you convert all ESS entries to upper case as well)...

If HR is sure that the employees enrolled during the payroll cycle, then the other possibility is pure timing - if the elections were updated after your PR140 was run, but your cycle was still in process, the change wouldn't be picked up on that particular payroll - it would be during the next one. You could confirm it by checking the benefit audit history - it provides the last date and time a benefit was changed.

I think the timing issue referenced by Stephanie is part of the reason our site chose not to allow benefit elections during payroll. Plus, if someone moves (we are a border state and have locations in both Iowa and Illinois) it can really screw up the taxes.

I'm joining this discussion a little late, so forgive me for asking some basic questions. I am in agreement with all who have posted previously in the belief that Lawson does not block benefit changes during a payroll run. If the employee goes back into ESS, do they see the new election or the old one? I'm guessing they see the old one...? Do you know how many people have been affected in each payroll run?

I can think of two possibilities:
1) There was some kind of error during the "change/add" process that was not communicated to the employee correctly on the ESS form. This should be easily confirmed or refuted. If the employee can go back into ESS and make the change again, and BN32 is updated, then it is not a processing error, and it must be a timing issue. If, after the payroll completes, HR enters the change, for the employee directly on BN32, they would receive an error message which they would have to resolve to get a successful change/add.

2) If it is a timing issue, I suppose it could that the employee is hitting change/add at exactly the same time PR140, or some other program run during payroll, is on that record. At least I think that would cause some kind of record-lock problem... But the chances of that happening are so small that I find it hard to believe it's the cause.

And of course, there's always the possibility that the employee thinks they completed the changes successfully, but they didn't. Since you're using the Immediate option, unless you're looking right at the screen at the time the employee hits change/add, you'd have no way of knowing if they really did get a successful transaction. Speaking of... is there some kind of notification/confirmation that is sent to the employee or to HR?

Sorry I can't be of more help. I hope I've at least given you some ideas. Karen

Thanks Karen.

Posted By Greg Moeller on 12/06/2011 01:18 PM
For whatever reason, Lawson has not seen this as a priority (to build into the system a flag, or switch or whatever) to prevent entries during payroll processing. So to answer your question: No. Lawson does not prevent access to BN32 or any other screen when payroll is processing.

I stumbled across this one today.  There is now a Lawson solution delivered for this as part of ESS 10.0.2.
JT-114437, JT-336319
For 9.0.x, apps requires 9.0.1 MSP#9 or higher
For 10.0.x, apps requires 10.0 MSP#2 or the CTP for JT-336319

Thanks John!

Is EMSS one of the products you can update to 10.x while you're still on 9.0.1.x environment and apps? Thank you.

Yes, EMSS can be updated to 10.0.2 with LSF 9 and apps 9.0.1.9+. You will also need to update the Common Browser Library (CBL) to 10.0.2.

We are running ESP10, MSP8 (not 9) and EMSS 10.0.1.0.07. Yes, the CBL has to match the EMSS release.

The documentation for EMSS v10 doesn't indicate a specific MSP (that I can see) ?? Where did you get the information from? Or is that just for the "Lawson-delivered" solution to the blocking, not for installation of EMSS v10?

It is the release notes for a couple of the new features, including the payroll lockout.

We are on 9.01 now but still use the steps I outlined in the thread link that Greg posted above. I am not sure how Lawson is doing this in V10 or how adjustable it is, but by manipulating the bookmarks you have the greatest degree of flexibility as far as timing and what employees have access to during critical business cycles.

Another option is that when payroll is being processed you change the BS01 from immediate to equal N.  It will still allow employees to input their data however it would go into a pending table.  Then you would run the BS531..BN531/BN532 to pull in those changes after payroll is finished processing. Then flip the flag back on the BS01