If there are no other criteria except the Class that you have set up, you could simply use the Class when processing payroll. On the calculate payroll screen, click on the tab labeled Selection and enter in the Class code for Hourly or Salary next to Class 1, 2, 3, or 4 (whichever is the right one in your setup) in both the FROM and TO boxes.

I tried that - and it works, but then you've got to remember to add the class to each employee when adding, re-activating them, etc - then syncing that with the open payroll process.

I'm just worried a data entry clerk might forget to set the class, then somebody doesn't get paid.  With 50+ new hires/fires per month it gets a little hectic.

I was running a quick SQL script to update and/or flag CLASS1 in the UPEMPL table.  Again, works, but hate coming up with a hack to handle something the old product did just fine.

You can create a custom screen with the salary/hourly as a required field and then tie that to CLASS1 in Open Payroll. Then make that custom screen part of your new hire/rehire processes as a required screen. This would force the data entry person to at least put a value in that screen upon hire/rehire.

It doesn't mean that someone can't forget to update it if someone switches from hourly to salary or vice-versa but at least it helps out.

The other option with your SQL script is you could use the SQL agent to schedule that script as a job every X minutes. That way it is automatic and no one has to remember. Alternately you could write a SQL trigger that updates CLASS1 when the value in hrpernsl.p_salhour is entered originally or updates.

I agree it isn't as user friendly as the Abra Paygroup, but it does have the advantage that you can move someone from salary to hourly or vice versa and not have to worry about where you are in the payroll process or quarter end process. Also it records in the history where they were when the payroll was processed rather than changing all of the history to reflect the current paygroup like Abra did.

You can create a custom screen with the salary/hourly as a required field and then tie that to CLASS1 in Open Payroll. Then make that custom screen part of your new hire/rehire processes as a required screen. This would force the data entry person to at least put a value in that screen upon hire/rehire.

It doesn't mean that someone can't forget to update it if someone switches from hourly to salary or vice-versa but at least it helps out.

The other option with your SQL script is you could use the SQL agent to schedule that script as a job every X minutes. That way it is automatic and no one has to remember. Alternately you could write a SQL trigger that updates CLASS1 when the value in hrpernsl.p_salhour is entered originally or updates.

I agree it isn't as user friendly as the Abra Paygroup, but it does have the advantage that you can move someone from salary to hourly or vice versa and not have to worry about where you are in the payroll process or quarter end process. Also it records in the history where they were when the payroll was processed rather than changing all of the history to reflect the current paygroup like Abra did.