Extending the functionality of pay condition rule sets

Pay condition rules sets functionality

Pay condition rule sets are one of KeyPay's most powerful features. You can turn even the most complicated award or employment agreement into a machine that interprets even the humblest of timesheets into a costed shift in the pay run. The interpreted timesheet is compliant and consistent every time.

As this gets used more and more for our pre-built awards and by our users, we are continually updating the scenarios that can be handled. Today we have released a whole new bunch of rule conditions and actions, so lets take a look at each one:

Adjusting higher classifications

Previously we were able to tell our shift to apply a higher classification to a whole shift if criteria was met. e.g. if Johnny fills in as a level 3 for more than 2 hours in a shift, pay him as a level 3 for the entire shift.

This has now been extended to include more actions. We can now specify that we'd like the classification to apply to a whole day (not just the one shift), the entire week or an entire shift period. In contrast, sometimes we do not want to pay a higher classification e.g. only pay a higher classification if they have worked more than 4 hours at that higher level. We can cater for this now as well.

Pay condition rule sets

Number of units is less than or greater than / add remaining units

We have had the "time worked" condition (which is probably my favourite) for quite some time, but we've now added "number of shift units" as a condition which will work in the same way. If the number of units entered is less than a target number of units, all of the units will be matched. If the number of units is greater than a target number of units, the units in excess of the target are matched.

Where the number of units is less than the target number, we now have an action to "add remaining units", meaning we can now manipulate the amount employees are paid for unit based timesheets in much the same way that we can with a normal hours based shift. This one will be very popular for piece work and employers who pay rates or allowances based on something other than units e.g. kilometres.

Pay condition rule sets

Effective duration v actual duration

This one is great for salary employees who submit a timesheet. Lets assume the following timesheets submitted for a salary employee who is paid for 40 hours per week:

Monday: 10 hours
Tuesday: 7 hours
Wednesday: 7 hours
Thursday: 8 hours
Friday: 6 hours
Total: 38 hours (2 hours short)

This employer wants to make each day equal 8 hours, no more and no less. That was okay, because if we wrote a rule that said if time was worked in a day which was less than 8 hours, add remaining time. In the example above, it would have added 1 hour to Tuesday, 1 hour to Wednesday and 2 hours to Friday (a total of 40 hours). We could have also added a rule to cut off Monday at 8 hours.

However if we later want to fix up the total hours for the week, the rules would base this on the 38 hours we actually submitted as timesheets, not the extra hours we've added above. This would cause a few problems.

We've solved this with 'effective duration'. When using the 'time worked' condition, you can now specify if you wanted effective duration i.e. the duration with our extra hours added, or the actual duration. You can access this by clicking the cog on the right and selecting "compare to effective shift duration".

Pay condition rule sets

Matching based on a location's state

It is pretty common to have a pay condition based on a state. South Australia often have special conditions apply for certain public holidays. If you have transitional provisions in an Award or Employment Agreement, you still may need to pay different pay categories for different states of Australia.

We can now test if a shift was worked in a certain state of Australia. Choose the location option and we now have options for "state is one of" or "state is not one of".

Pay condition rule sets

Extending the 'Time since previous shift' rule

Previously if you hadn't had enough of a break between 2 shifts, say 10 hours, you may attract a penalty rate. Say if you'd only had a 7 hour break, your entire next shift would be a penalty. On occasion though, the pay condition would only relate to the first 3 hours of your new shift i.e. only the part that is within the required 10 hour break. Alternatively, it may only relate to the last 7 hours i.e. only the part that is not within the required 10 hour break We can now handle this with the 'time since previous shift' condition by using the new drop down menu.

Pay condition rule sets

Shifts with attached leave requests

There may be instances where you want to isolate or ignore shifts which have been generated from a leave requests. e.g. You may want to not pay any penalties on shifts that have come from leave requests. One we had recently is where our users apply an automatic meal break (say 30 minutes every 5 hours), we don't want this to happen on timesheets which have came from leave requests (because there is no meal break reflected when you're on leave - we don't want to deduct the extra 30 minutes). We now have a condition called "Associated leave request" and you can decide whether the shift should or shouldn't have one using the drop down menu as shown below.

Pay condition rule sets

Consolidate all shifts on the same day

While not a condition within the rule, this is a rule set setting which you can configure to treat any shift on the same day as one shift. This might be handy if penalties apply to all shifts on the same day, but there are two shifts worked. Now we have the option to consolidate all shifts on the same day as one shift, within the rule set settings:

Pay condition rule sets

And don't worry if you need to pay a split shift allowance, the consolidation will not apply to that rule. As a result, you can still apply a split shift allowance on the second shift of the day, and a penalty rate to all the shifts on the same day.

Wrap up

We hope you enjoy the additional capabilities of pay condition rule sets as a result of this release.

Garth Belic

Head of Customer Experience and Compliance Specialist at KeyPay. Follow me on:

Twitter

You might also like...

Changing payroll software mid-year and transitioning STP records
November 21, 2019

Changing payroll software mid-year and transitioning STP records

Thinking about changing payroll software? These are several ways you can transition Single Touch Payroll (STP) reporting from one payroll system to another.
Product
GDPR payroll obligations made easy with KeyPay
October 1, 2019

GDPR payroll obligations made easy with KeyPay

GDPR employee obligations are made easy with KeyPay by giving employers the tools to anonymise employee data and access to their personal data.
Product
Payday filing enhancements and seamless IRD gateway integration
September 19, 2019

Payday filing enhancements and seamless IRD gateway integration

Payday filing has been mandatory for NZ businesses since April 2019. KeyPay has just enhanced its Payday filing functionality with IRD integration.
Product
Automation illustration

Not using KeyPay yet?

Try it free for 30 days

Learn more