For those of you that werenโt able to join us, and those who may want to see the presentation again, we have included a link to the recording from Tuesdayโs webinar.
Click the link below to access the agenda/setup document discussed during the webinar.
If you specific questions, please submit a help desk ticket. ย If you feel you need one-on-one training, please see the attached proposal, and Mimi English will contact you to schedule.
We received some great questions, as well as suggestions for future enhancements. The questions and answers from Tuesday and Thursday are listed below:
Q: Are the Group Health Insurance enhancements currently in 4.0 and 3.0?
All of the enhancements have been made, and will continue to be made, in both 3.0 and 4.0. As long as you have the latest programs, and have run your module updates, you will see all the new fields and processes in Personnel and Payroll. ย Watch out for News Articles/Blogs for future enhancements
Q: Who is considered an RDA โ101 customerโ versus an โEnterprise customerโ?
Enterprise customers have all modules and processes available in their OpenRDA directory (some modules such as Budget Preparation are purchased separately), including Position Tracking, whereas 101 customers have purchased individual modules and bundles of the software.
Q: Would I use the Set GHI Eligible Using Employee Type process to assign “1H” on all of our substitutes?
That is a perfect example of when you might use that in-mass process, provided that all your substitutes fit the definition for Coverage Code 1H. Depending on your setup, you may be able to range on the Pay Group of SUBSTITUTES.
Q: What date should we put in the Group Health Insurance Eligibility Date: the date they are eligible to receive benefits, or the date their coverage will start?
An employeeโs Eligibility Date is the date on which he/she was eligible to receive group health insurance benefits. Typically, this is the employeeโs Hire Date or Job Start Date, but that depends on your organizationโs benefits policy.
Q: Can you search under Personnel Demographics on the Group Health Code fields to see which ones are blank?
Yes, you can click the Search (binoculars) button on the Personnel Demographics Browse screen, and range on any one of the GHI-related fields, leaving the โToโ and โFromโ fields blank. Also, if you want any of the GHI fields to display in columns on the Browse screen, you can click the Define List button, and assign a column/position number; if you want that field to appear in the 1st column, so that the employees sort by the field, then assign it a position โ1โ. This will be a future enhancement in 4.0.
Q: ย Also, we would like to be able re-define the list in Deduction Descriptions to see Coverage Code on the Browse screen.
We will add this as a future enhancement to add Coverage Code to the Define List, so that you can click the Define List button, and assign a column/position number to the Coverage Code field, which will display it on the Deduction Description Browse screen. If you want to sort deductions by their Coverage Code, then assign it a position of โ1โ, so it will appear in the 1st column.
Q: What about seasonal workers, for example, summer rec staff that work for two months. This brings us to over 50 employees for two months of the year.
To determine whether your organization has 50 or more full-time equivalent employees, is considered a small or large employer, and which forms you need to file and distribute to your employees, refer to http://www.irs.gov/Affordable-Care-Act/Employers ย ย ย http://www.irs.gov/pub/irs-pdf/i109495c.pdf and http://www.irs.gov/pub/irs-pdf/i109495b.pdf
Q: If we have bus drivers that are contracted but also have a sub job, if I use the Set GHI Eligible Using Employment Type to set the 1H on our subs, would that change their code from 1A to 1H?
All the Group Health Insurance flags and fields are on the employee level. The IRS only cares whether each person is eligible. So, if an employee is eligible for group health insurance in any capacity/job, then he/she should not be assigned 1H. In your example, you can use the in-mass process to assign 1A to all your bus drivers, and then you can use the process to assign 1H to all your subs, and in the latter process, you can individually select the subs that are also bus drivers, and override their 1H to 1A (you are able to make individual overrides since itโs a process exceptions report).
Q: I have substitutes who are ineligible, and would have the 1H code; however, if they do not receive any pay, there is no update to their calendar. Do I need to do a manual entry to correct this?
Youโre correct that if employees are not paid in a month, then there would be no update to their Personnel Calendar Summary, so you would need to manually enter 1H in their Personnel Calendar Summary for that month. You can do this on an individual employee basis, or you can use the in-mass backload process, which will be a system enhancement in the Fall.
Q: We have married employees who are on a dual plan. Right now, we have the dependent spouse marked as eligible, but not participating, as he/she is a dependent. Is this correct?
That seems to be appropriate, however, you should check with your benefits provider for confirmation.
Q: Are you saying that all of our employees who have a yearly salary need to be converted over to hourly or daily rate?
No. True salaried jobs need to continue to be paid by salary. However, if you have been paying some hourly or daily jobs by Salary, or a lump sum Adjustment amount, you can no longer do that. You need to determine which jobs are truly hourly or daily, and pay them by the hour or day as appropriate.
Q: By contract, our hourly employees are allowed to have their pay evenly divided over the entire year. ย Their hours are never entered. How should these be handled?
If they are truly hourly employees, then they must be paid by the hour, not by salary, so that their hours can be tracked. You will have to estimate the hours they work in a calendar year, and divide their annual pay by that number of hours to determine their hourly rate of pay.
Q: How are coaches handled that are considered part-time salaried, and are paid in several installments over the year?
If their positions are truly salaried, then they can continue to be paid by salary. However, if their jobs are really hourly, then they should be paid as such, using the calculation above. If their jobs are daily, as coach jobs often are, then you will have to estimate the number of days they work in a calendar year, and divide their annual pay by that number of days to determine their daily rate of pay.
Q: Our Bus Drivers are not eligible for health insurance, but they are paid a salary on a monthly basis. ย Do we still have to break them down hourly?
All hourly and daily jobs must be paid by the hour/day, regardless of whether the employees are eligible for health insurance. You must determine whether the jobs are truly salaried, hourly or daily, and pay them accordingly.
Q: How would we set up hourly employees that work 9 months, but have their pay divided over 12 months?
They must be paid on scheduled pay dates and at an actual hourly rate based on the nine months of employment.
Q: Our subs are paid a daily rate, so do we have change that from a daily rate to hourly rate now?
No. You can continue to pay them at a daily rate, as long as they are considered daily, and not hourly, jobs. You would just need to make sure that the Hours Per Day field is populated at the Position or Job level, as appropriate with your setup, so that the system can project the number of hours that the employee worked (the days you enter in payroll will be multiplied by whatโs in the Number of Hours field).
Q: Do you recommend employees who are currently paid on a daily rate be converted to an hourly rate?
You would only need to convert jobs from a daily rate to an hourly rate if the jobs are actually hourly jobs, rather than jobs that should be paid by the day. Refer to the previous question and answer.
Q: Does it matter what the Hours Per Day are in the Job Master if we are manually entering hours in payroll?
If you are entering hours in payroll, under the HOURLY UNIT or MISC UNIT, then those hours are what will appear on the reports; the Hours Per Day on the Job/Position Master will not be taken into consideration. Hours Per Day factor in only when days are entered in payroll, under the DAILY UNIT rate; in that case, the system will multiply the days entered by the hours/day .
Q: For the jobs that have Rate IDโs of DAILY UNIT or MISC UNIT, do they need to have a Hours Per Day in the Job Master? (The pay rate and the hours worked are not connected)..correct?
For jobs paid at the DAILY UNIT rate, Hours Per Day must be populated in the Job/Position Master, so that the reporting can project the hours the employees work per day at that job. For jobs paid at the MISC UNIT rate, Hours Per Day does not need to be populated, since hours will be entered directly in payroll.
Q: If we have an Hours Per Day listed in the setup for a daily position, will the reporting use our Hours Per Day, rather than the 8 you were speaking about?
Yes. 8 hours/day was just an example.
Q: We have an employee with RET-DAILY, and we just tried to put the # of Hours Per Day under their job description, but it did not go. Why?
To make the Hours Per Day field accessible on the Job Master, you may need to go into the Position Tracking module, to Setup -> Gross Definitions, select each Gross ID thatโs assigned to your unit-based jobs, go to the Block Flags tab, and turn off (un-flag) the โBlock PAYJMST Hours Per Dayโ.
ADDITIONAL CLARIFICATIONS:
Rounding up daily units is one of three options that the IRS recommends. RDAโs reports provide the option to round up.
Each month of each dependentsโ eligibility can currently be manually tracked on the Health Insurance Coverage tab under Personnel ย -> Dependents. This tab is only available when the Self Insured GSV is set. In a future enhancement, we will remove the Health Insurance Coverage tab, and add a dependent calendar, which will be similar to the employeeโs Personnel Calendar, and will have a virtual field for age that will calculate based on the dependentโs birth date.