Would you like Dramatic Response Time Improvements?
WFC v5.1 and below:
Most Kronites know that this is the routine Workforce Central Timekeeper uses to calculate totals interactively when viewing employees. It invokes the Totalizer just for those employees whose totals have not yet been computed by the Background Processor (not up to date.) It doesn’t do anything with these results except display them on the screen. They are tossed out when done. They don’t update the database. They are just for the users viewing pleasure. Did you know that it’s used also by Group Edits to calculate totals and by Accruals to calculate accrual balances? It’s an important little process.
There are several settings available but the most important one to understand is site.totalizer.number_of_engines. Yep, you read that correctly. One can have multiple Callable Totalizers. Imagine the power! I’ve had success with up to four. To quote the brilliant Kronos docs:
"After the system is running, multiple Callable Totalizers can provide fast totalization requests throughput than a single Callable Totalizer can. Four Callable Totalizers may produce totalization request throughput that is four times as fast!" (emphasis mine)
Give it a try. If you have over 1000 emps I expect your users will notice a significant response time improvement with as few as two, more than 3-4000 emps and I suggest four. Of course your mileage may vary. It depends mostly on how many users are actually working on the system at the same time, not the employee population.”
Watch for some thoughts on the totalizers from 5.2 and newer in a later post!
Reprinted from Improv's TNT written 12/11/08
"150% 2/3rds Funeral Leave Pay". As far as I know, this pay code is still in play at a large corporation. It is apparently the intersection of two pay polices. One that says you get 2/3rds of your pay if you need to take leave to attend a funeral and another policy that pays time and a half if you are scheduled to work a schedule not your normal schedule. Yes, even if you were actually on leave. Apparently it was still in use...Why? Because everybody knew that if you had to go to a funeral you changed your schedule with a buddy and you got your full pay (actually 99.9 % of it) and he or she got time and half. On account of the funeral... Well, I suppose if it was your buddy's funeral and he failed to show up for your scheduled time he would only make 99.9% of his normal pay too. Which isn't half bad when you are 100% dead or not actually working.
You can tell a lot about a company from their pay codes and rules. More so than their pay policies in fact. I've said for many years that pay policies don't put dollars in people's hands; timecards and lines of code do. And in many companies there is still a lot of interpretive dancing going on when various time card situations appear and a human operator makes a judgment call as to how to code it for payroll. In a 100% code driven system the same timecard scenario should result in the same pay coding, dollars and credit towards or against benefits. This is usually verified, at least at the inception of the system, with test scripts. You can tell a lot about a company by their test scripts...or lack of them.
A comprehensive test plan made up of individual test scripts puts the company's money where their pay policy mouth is. Once you get beyond the easy stuff like simple overtime you need to dig into all the intersections and combinations of policies that A) Could happen and B) Could be coded or punched. Leave and exotic paid time off benefits are often the most challenging to simulate as well as develop airtight code based rules solutions for. I have found in the world of Kronos Timekeeper, however, that companies that maintain current test scripts (and have a Kronos test system to work in) tend to have the most streamlined and functionally capable automated pay and scheduling rules. The ones that don't keep such real-world testing in mind seem to have lower expectations for their payroll system and are much more tolerant of having to make manual adjustments on a regular basis.
A good test script is generally narrow in scope as to the scenario it is testing. The sum of the entire test scripts assembled into a comprehensive test plan, however, is a statement on the overall effectiveness of the timekeeping and pay system. In many states, once you start paying or benefiting an employee at a more favorable level THAT is their new compensation deal. Even if it was the result of an unintended confluence of pay rules executing pay polices that seemed good and fair individually. I can't prove it but what do you think came first in the funeral leave example above-someone creating the pay code ahead of time to accommodate a pay policy they wanted to execute, or after the fact to track something that was actually happening and now would continue?
If you have interesting pay codes and/or an interesting confluence of pay rules please send them to me... I promise to keep your name and company confidential although I'm sure the people benefiting from them already know!
I'm in a meeting with a local organization the other day and in response to some questions about this topic I say "Check the blog! I'm sure something is there..." So I check this morning and after pulling my foot out of my mouth I realize I have to get something up here. I said, so it has to be!
These configuration options in Kronos Timekeeper / ADP eTime determine how people get PAID and how ATTENDANCE is tracked.
Exceptions are flags that alert Supervisors when
employees work outside of their assigned shifts. Exceptions serve no other function
and they only work with accurate schedules in the system. They appear in the
Timecard Editor, outlined in red. and also on reports. They indicate missed
punches, absences, late punches, and so on.
Rounding rules ensure that pay rules are applied consistently
to a group of employees. (Some think that rounding also makes payroll
processing more efficient because rounded punches are easier to interpret than real-time 
punches. Others believe in not using rounding and pay minute to
minute.)
Rounding is defined using a round and a grace. The round divides an
hour into equal increments of time. The grace is the increment after which
the punch is rounded forward to the next round increment. You can use interval
rounding or punch rounding. Interval rounding rounds the time between an
in-punch and an out-punch. Punch rounding rounds the in-punch and the
out-punch.
One needs to decide how to handle this and it's often buried using different terms in the policy manuals. Don't be stuck by those though, implementation of Kronos is a great time to review what's really best for the organization. So often I find that the lack of understanding of this simple topic leads to inaccurate configuration and sometimes pay. With this in mind, please consider separating, first in your mind,
Pay from Attendance...
Chris Flanders adds a helpful note from a scheduling perspective...
"If you use rounding rules but do not keep your advanced scheduler start & end times on quarter hour increments, the schedule start/end times will OVERRIDE the rounding at the timecard. For example, if an employee is scheduled to start at 7:00am and punches in at 6:55am, the punch will be rounded to 7:00am. But if the scheduled start time is 6:55am just like the punch, the punch won't be rounded! The scheduled start time overrides the rounding rule."
In all my years of working with a 
wide range of clients I have come across many Kronos configuration mistakes, one common one are shift differentials. Just because a company pays shift differentials for certain hourly employees doesn't mean that it has to be configured in the Kronos Timekeeper Zone Rule as "Daily shift differential".
A good example is when shift differentials are paid for the whole shift worked. I have seen this configured in the zone rule with a wide *Early and *Late expansion margins. But there are always cases when the employee works too many hours and the pay rule does not calculate the shift differential for the entire shift.
The best way to configure this is to create a work rule with a pay code distribution that always pays shift differentials and then assign the Work Rule to the Pay Rule in the Assignment Rules tab.
Thanks to Luis Fernandez, our Kronos Timekeeper Configuration Guru for this tip!