Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
This is the fourth post in a series related to the new functionality introduced in Dynamics AX 2012 R3 CU8. Several new features were added in the HR and Payroll areas based on customer feedback. Features to be covered in the series include: Total compensation statement, FMLA tracking, Premium earning generation, Regular rate of pay, Benefit accrual enhancements, and Forecast position enhancements. Be sure to subscribe to updates for our blog to learn about this new functionality
The Fair Labor Standards Act (FLSA), which prescribes standards for the basic minimum wage and overtime pay, affects most private and public employment. It requires employers to pay covered employees, who are not otherwise exempt, at least the federal minimum wage and overtime pay of 1.5 times their regular rate of pay.
If a worker gets an hourly rate and nothing more, the regular rate of pay is simply the hourly rate. In this scenario, an overtime earning code can be created for 1.5 times the hourly rate and overtime hours are assigned against that code.
However, if a worker gets a shift differential, if productivity bonuses are given, or any other payment that is considered part of the compensation package, then those amounts have to be included in the regular rate of pay calculation. To enable the proper regular rate of pay calculation, you can now create an earning code using the new “Regular Rate of Pay” basis and the system will calculate the overtime premium in accordance with the FLSA.
The FLSA defines the most common workweek as a fixed and regularly recurring period of 168 hours (i.e. seven consecutive days). There are FLSA exceptions to the 168 hour workweek such as a 28-day work cycle for firefighters. Refer to the Federal FLSA guidelines to find other exceptions. The workweek does not have to coincide with the calendar week, but instead it may begin on any day of the week. Once the beginning time of an employee’s workweek is established, it remains fixed regardless of the hours the employee is scheduled to work. Overtime must be paid for every hour over 40 that is worked in the workweek.
In order to calculate the regular rate of pay, you must first establish work cycles and work periods. A “work period” is equivalent to an FLSA workweek and a “work cycle” refers to a fixed group of regularly recurring work periods. The steps for creating work cycles and work periods are as follows:
Your company may only need one work cycle but, it’s more likely that you have several. To ensure that the proper workweek is used in the Regular Rate of Pay calculation, the work cycle must be associated to the position. The steps to associate work cycles to positions are as follows:
An earning code group defines the list of earnings that are applicable to the Regular Rate of Pay calculation. For example: regular pay, shift differentials and performance bonus are counted as earnings in the calculation while vacation pay and a uniform allowance are not. The steps to create an earning code group are as follows:
A new rate basis called “Regular rate of pay” has been added to the earning code form. The steps to setup an Overtime premium using the new Regular rate of pay basis are as follows:
When you add an earnings statement line and select the earning code with this new basis on an earnings statement, the system automatically calculates the regular rate of pay for the work period and uses it to determine the amount of the overtime premium.
This new capability to set up an earning code with a Regular Rate of Pay basis, combined with the ability to create and maintain work cycles and periods, allows the system to accurately calculate the regular rate of pay and determine the overtime premium adjustment to ensure you are always in compliance with the FLSA.
There seems to be a piece missing from the accruals. You can accrue, financially, by posting the pay statements. However, the "used" transactions are not being posting to any expense account. Is this in the works, or will this generally be a customization?
Hi Cody, You are right there was a bug that prevented the usage from being recorded under some scenarios. We have release KB3133623 to fix this issue. You should be able to obtain that via the standard hotfix delivery channels.