Introduction

Understanding how MySCView's Pay Configuration system identifies and prioritizes employee payroll settings is essential for proper use of the tool. This article explains the core concepts of Identity and Specificity in Pay Configuration, demonstrating how the system determines which payroll rules apply when multiple configurations could match a single employee position. By mastering these concepts, administrators can configure precise payroll rules that target the right employees without unintended side effects.

A. Problem Statement

When configuring payroll settings in MySCView, administrators often need to apply different pay rules to different groups of employees, specific individuals, or particular job positions; however, employees may belong to multiple pay groups or hold multiple positions, creating situations where several configuration rules could potentially apply to the same person.

B. Solution

To follow along with this guide, navigate to Admin > Site Settings > Payroll.

For basic information on Pay Configuration site settings, please see Article: Time Sheets: Site Settings.

Step 1: Identity

Pay Configuration is built around the concept of employee "Identity". We assemble an Identity by combining the Pay Group, Employee ID, and Position columns, then we treat them as a single unit. No two rows in the Pay Configuration grid are allowed to have the exact same Identity. Further, the Pay Group or the Employee ID field must be filled out in every row. You can always have both, if you want.

By following these rules, there are six ways we can assemble the same Pay Group, Employee ID, and Position ID. (See Table: Pay Configuration Variants for the list.)

Table: Pay Configuration Variants

Step 2: Specificity

Pay Rounding only makes sense if only one of the six rows in Table: Pay Configuration Variants gets used, so we have to come up with a pecking order that decides which row wins. We call this Specificity. 

When there are multiple matches for a single employee's position in the Pay Configuration grid, the most specific match wins. Table: Specificity Order shows 

Table: Specificity Order

From this, we can see that the Employee ID is very specific. Not matching Employee ID makes Specificity drop all the way to rank 5 immediately. This makes sense, as an Employee ID is unique to a single person, while Pay Groups can be shared by entire departments, and absolutely everyone has a Position 1 in USPS.

Let's apply Specificity to Table: Pay Configuration Variants to show which rows are the most specific, and which are the least specific.

Table: Pay Configuration Variants Specificity Ranking

Let's break this table down, line for line, in words.

Line 1 - Position 1 for Bus Driver R. Williams is the most specific. It refers to one job in one pay group for one employee.

Line 2 - Position 1 for R. Williams is almost as specific as Line 1. Losing Pay Group "Bus Drivers" means that Line 2 will match if R. Williams's first position is not labeled as a Bus Driver job.

Line 3- Bus Driver R. Williams is less specific than the previous lines. While it still refers to one person, R. Williams may have a second job in Pay Group Bus Drivers, such as a special project for training new bus drivers, and this line would catch that second job. Lines 1 and 2 would not.

Line 4 - R. Williams is even less specific. Without a Pay Group, any non-bus positions that RWilliams holds, such as helping prepare lunch, would match.

Line 5 - Here, we are no longer referring just to RWilliams. This is less specific, as it matches everyone whose first job is Bus Drivers.

Line 6 - The least specific, anyone who has a Bus Driver position, primary or not, matches.

C. Best Practices

• Start broad, then refine: Begin with Pay Group-level configurations (Specificity 6) for organization-wide defaults, then add Employee ID-specific rules only when exceptions are needed.
  • If doing so, ensure that all positions in the Pay Group should be subject to rounding.
• Document your strategy: Maintain a separate document explaining why specific Pay Configuration rows exist, especially for employee-specific overrides (Specificity 1-4).
• Avoid redundant rows: Before adding a new configuration, check if a less specific row already handles the same scenario. Having multiple rows that could match the same employee creates maintenance complexity.

D. Troubleshooting

Issue: An employee's timesheet is rounding incorrectly

• Diagnosis: Check which Pay Configuration row is being applied by examining the employee's Pay Group, Employee ID, and Position.
• Solution: Verify that a more specific rule isn't overriding your intended configuration. Use Table: Specificity Order to determine which row wins.

Issue: Pay rules are applying to more employees than intended

• Diagnosis: Your configuration is likely too broad (Specificity 5-6).
• Solution: Add Employee ID or Position qualifiers to increase specificity and narrow the match criteria.

E. Related Articles

Time Sheets: Site Settings

Time Sheets - Pay Configuration Import

Conclusion

By following the quirks of Identity and Specificity, you can create a Pay Configuration Grid that efficiently serves your organization's needs.