So I totally understand why we need them, but that doesn’t mean I gotta like ’em.
Student Payroll had this little flaw that was missed in the original design. The calculation algorithms grab the most recent payrate and multiply it with the # of hours to get an amount of $$ to pay them. When you live in the present, this works great. However, for those looking at past data it’s all wrong cuz the reports are all dynamically calculated … you guessed it… with their current payrate. So today I found out an auditor is arriving next week to review payroll and our pre-test failed due to this issue.
After SUPRISingly little time, I was able to reconcile to of the most important reports and make things synchronize. Now I just have to update any and ALL reports that use this algorithm. Easy right? Sure, should only take me another few hours, but here’s the REAL fun: Effective Jan 1 (most years) is a federal/state minimum wage increase. Our payperiods run the 12th-11th (for reasons I don’t even wanna start on). The short of it is that any report that covers multiple calendar years (Dec 2006-Jan 2007) are wrong. The original design was never intended to pay someone two wages during one payperiod. Bleah. What a mess. So today I also updated the timecard view allowing for 100% accurate (even across years) calculations. That can now be compared to the batch sent to payroll for audit purposes. And they balance. ‘Course.
Anyway, so not only do we have these updates to do (getting the report payrates to work) but Payroll requires some security updates, interface upgrades and a bit of retooling. This is all to be finished by July 12. Should be an adventure 😉