As mentioned in Payroll, the final durations and values for User Payrolls are derived via Shifts. That's where the buck stops. No matter the Locale's Shift Default values, or a User's default Pay Rate, the final values are reconciled in Payroll via the Pay Rate attribute on the Shifts themselves.
Suggested Rates
You can think of Pay Rates (and Billable Rates) that get loaded via Shift Defaults or User attributes (in the case of the Pay Rate) as suggestions that ultimately get carbon copied onto Shift attributes when the Shift is created or modified.
Adding Shifts to the Inteliguide Schedule via the Quick Add Form on the Schedule itself and/or via the full Shift Add Form results in Shift Defaults and User attributes being applied. There isn't really a conflict between those two things aside from the Pay Rate. The Pay Rate can be suggested via the Locale (Group or Location) OR via the User. That presents a problem. What if the two values disagree with one another?
Pay Rate Precedent
If there's a conflict where one rate is different than the other, then one or the other suggested Pay Rate values must take precedence. Here is the order of operations, so-to-speak:
- Pay Rates follow Employment Type, regardless of Role
- Pay Rates follow W2-Hourly Users, regardless of the Locale Pay Rate
- Pay Rates follow the Locale Pay Rate for Salary or 1099 Users, regardless of the User Pay Rate
- Pay Rates will finally always seek a nonzero value. This is to avoid a confirmation warning on the Full Shift Add Form… or a resulting zero value Shift Pay Rate attribute when adding Shifts via the Quick Add Form. All other precedence failing, the User or Locale that has the nonzero Pay Rate will apply
Note: Admins can Bulk Edit Pay Rates and other Shift attributes for past, present, and future Shifts. This is useful when adjusting Pay Rates to existing Shifts based on their Users and/or their Locales.
0 Comments