Submit Your Suggestions for Vista

This may be related to / the same as a separate idea - "Make 'New Pay Rate' affect existing timecard entry lines"

I hope that any changes as suggested below would be optional, as the extra validation required to check effective dates on individual employees, pay rates, etc. will really slow the process down.

I believe that every rate - whether it be the hourly wage or a deduction/liability should have an effective date, and both one old rate and the current rate should be maintained.  This way, you can enter a new rate (say someone gets a raise as of next week, but still gets paid this week) and the system would know to check the date to see which it would be.  This is also especially helpful with things such as 401k deductions that are supposed to take place as of a certain date (i.e., we have a quarter-entrance date, so we may get the info now but it doesn't take effect until July 1).  Same thing happens if employee deductions such as insurance change on a specific date.  Finally, liability rates would be VERY helpful to track in the same manner; for instance, our work comp rates change effective 7/1 but I may still be reconciling payrolls in June and have to re-run one or more of them and need the system to still have the old rate.

Hi Gary, I would expect the changes to take effect as of the effective or posted date. So let's say we had our pay period 4/7-4/13, the change should be effective as of 4/7. Any timecards entered for that period should get updated. We cannot wait to start entering time until all rates are in. In most cases, we have already started time entry. To manually go in the batch and update each individual rate is very time consuming and completely inefficient. We currently have +/- 260 employees.

Hi Gary,

We are only talking about the open batches, so yes if there are any timecards already posted than rates definitely should be updated for those timecards as well. In the open batch employees are not being paid yet, I don’t see any issues rerunning OT process, reprocessing any DL calculations and etc. Currently, this is how our weekly payroll processing works:

- Update Benefits/salary to payroll

- PR timecard entry – bring all employees to payroll for processing via portal batch

- Post batch – if any employees have salary/rate change they will be posted with an old rate.

- Via timecard entry bring back all employees with salary/rate changes. Update rates and post the batch.

- Run OT process

- Post Auto earnings

- PR payroll process
Often, we have to make changes on employees DL calculations ( paying back benefits, paying retro car allowance …)

In my opinion, the only time salary/rate change should not be updated in the open batch is if employee has been paid and check has been issued. In that case we could void a check or pay him retroactively on the next pay period.

Samra Bubalo
Accounting Supervisor| BERNARDS

Please follow us on: Twitter | Facebook | LinkedIn | YouTube

Would you expect a rate change to update posted timecards as well?  If yes, this would effectively require correcting and rerunning all downstream payroll processes (e.g. Auto OT,  DL calcs, JC and other ledger updates)

Totally agree with this post. We keep many pay periods (batches) open for employee convenience such as fill out their timecards prior to leaving for vacations. We usually have at least 4 batches open at the same time. Not having updated rates/salary changes in the open batches causes that current payroll processing is slow and out of the balance. Once a year we perform companywide increases and this task so far has been extremely difficult considering that payroll batch has been already opened for some time and everyone in it has an old rate. We strongly recommend to consider implementing this suggestion.