New Hires active in HR11 before hire date

Does anyone key new hires into active status prior to their hire date? We currently use PA52.4 to hire, but we don't pull in employee records until the date of hire or thereafter and we are in need of trying to get data on the Employee table sooner to allow new hires to enroll in benefits sooner. If you hire them to HR11 prior to hire (especially if you use Hire an Applicant), would you share your basic steps to get the data there, and what things we might need to consider if we start bringing the hires onto HR11 before their hire date? Back in the day when I was keying, we couldn't hire someone with a future date via PA52.4, but that may have changed.

Any help or ideas are appreciated!

Find more posts tagged with

Comments

Legacy Contributor

We have pretty much always loaded new hires in advance of their start date. When we first went live (2007), we would enter our PA52.4 in pending status (Hire1 and Hire2 because of the number of fields we loaded) and then ran PA100 to update them up to 6 months in advance. We later updated our process to automate most of it but still loaded prior to hire date. The only caveat is that our ESS security does not kick on until the hire date is reached. So this helps us set up the events ad the security access prior to the start date. Then everything is ready for them to enroll on their first day. We have day 1 benefits so they have 7 days from their start date to enroll.

Another thing to consider is reporting/LBI processes. Once they are in the system as active, they will show up on any reports or listings that include "active" employees even if they have a future start date unless you set date parameters.

Legacy Contributor

We also load new hires in advance to get their system access set up. PA52.4 allows immediate actions on future dates. We also use date parameters in all our reports to keep the future hires from appearing ahead of time. One thing to consider is how you will handle the situation where a future hire does not start as expected. Sometimes they start earlier, sometimes they start later and some never start at all. We have processes created to handle each of those situations.

amy-willbanks

We created a status of Pending New Hire and then bring them into the system early. On their actual start date, we move them to an active status. We then had to set up our benefit groups to allow those with the Pending New Hire status into the benefits.

Legacy Contributor

Thank you for responding!

Imelda and Sharon, do you all use a "pre-hire" status and change it once they have begun? If not, how do you ensure they don't get paid too early? We use Kronos and our current import would grab them and may (if they are exempt) accidentally pay them. I would prefer not to have a pre-hire status, I think, because we want to make them benefits enrollment eligible, and if we have them in a pre-hire status it would make it very difficult to do. But I don't want them to get paid too soon, either.

Legacy Contributor

I believe Lawson will not process a payment for someone prior to their effective date. When an employee ends up starting prior to their effective date we have to edit the record in Lawson to allow them to be paid. In addition, we do our import daily and do not bring the employees in to kronos until their effective date.

Legacy Contributor

Yes. What Sharon said...We don't have a pre-hire status. Lawson payroll will not trigger a payment until after their hire date arrives. We use API and though API will load their timecard with a future start date the system will reject any punches that come in before the start date. If they punch in before their start date, we have to adjust the hire date in order to pay them for those hours.

Nagib MESSAOUDI

Can you provide more detail on the process you use for a person hired in advance and then rescinds their offer? How do you 'terminate' them when they actually haven't started yet? Appreciate anyone's thoughts....

slivak

We use an OUTPROCESS personnel action and make their termination date the same as their hire date, and use an appropriate reason code (Didn't show, Offer rescinded, Offer refused, Failed BG, etc.) I'm careful to exclude all employees where DATE_HIRED = TERM_DATE on all reports.

sriman-shivakoti

We just began a process similar to what Mark describes. Prior to that we deleted them. That caused some downstream/upstream items with regard to their system setups.

Jennifer Riddick

We use PA52.4 to hire employees prior to the start date. In most cases, we run a bulk MS-Addins upload into PA52.4 a week prior to their start date for initiating system access and transmitting data to the benefits enrollment vendor. We run the PA100 with a future date to bring the HIRE records active after the load.

If we just have one or two records to update, we have added immediately onto PA52.4 - it allows you to enter/update immediately with a future date.

If the new hire doesn't start or is going to start at a later date, we terminate the record (to deactivate their system access). Process a rehire on the new date if they are starting later.

We also have acquisitions that we bring on 3 or more months prior to the go-live date. For these cases, because they go through several training classes prior to the go-live date and need to be active in systems, we hire them with the future date but listed them in a Casual/PRN status so they are not imported into Kronos with a schedule. This especially helps with the exempt employees. When the go live date comes up, we converted them to their true status (full-time or part-time) and adjust their FLSA flag.

Hope this helps.

0712131256598360.doc

Legacy Contributor

We are pretty much like Mark also except we hire in our Physicians in a AP (Active Pending) status. This way if any kind of bonus prior to them starting has to be paid out we can and our benefit package not kick in during this status. Some physicians can be hired up to a year prior to coming. Once the physician arrives, we change their status to A (Active) and all the benefits start just like a regular employee and access is built by IT.

Nagib MESSAOUDI

Thank you all for your responses. We also are setting the Term Date = Hire Date, but the Effective date of the action is the current date. We are not including a Reason (i.e. Offer Rescinded), but that is a good idea!

Legacy Contributor

Hello, would you be willing to share the PA52.4 Addin upload?

Thank you!

Ageda

Copyright © 2025 Infor. All rights reserved.