PR39 deductions not taking

Starting Jan 1st we outsourced our benefits to a 3rd party and are using the PR539 to load our benefit deductions to the PR39 screen. We are finding that random employees are not getting their PR39 benefit deductions taken even though some of them have sufficient net. Has anyone else run into this issue? Also, for those of you who have outsourced their benefits and only use the PR539 to process the deductions, have you run into this as well?

0712131256598360.doc

Find more posts tagged with

Infor Lawson Human Resources Group - Discussion

Accepted answers

All comments

joseph-carfagno

Do you load this every pay period? We use a 3rd party for Benefits and we load the deductions to PR14 and they only send Adds/changes/removals when they change. If you use PR39 - I would think it would have to be every pay since that is One-Time Deductions.

deanna-plant

Yes, we receive a one time deduction file every pay period. The benefit vendor determines what is deducted based on benefit changes in the 3rd party benefit application.

Jill

This is a long shot, but a solution we found. Is there a record for this employee on PR14? If so, is there some kind of balance in the "balance amount" field? If there is, it may be that the "balance" for the deduction to be taken is greater than the "balance amount" allowed. If there is a balance amount, try removing it from PR14 so the one-time deduction can process. Again, it's a long shot but definitely a reason why that one time deduction won't process.

jreese

We were having a similar issue with GHR Benefits One time deductions not being taken. I don't know all the details but there was a flag they said we needed to set on PR05, Used for Benefits, and that when we then entered a record on PR39, form PR39.6 would then pop up. We had to change security to get the PR39.6 screen to work so it sounds like it is fairly new.

Sorry, can't be more specific but hope this gives you some starting point to look.

deanna-plant

No balance on the PR14. But good suggestion!

Jill

Bummer. Maybe this will help someone else at some point.

deanna-plant

jreese, I am not seeing any field like that on our PR05 but I can ask Support about it. Thanks

jreese

For us it is on the More tab at the very bottom.

deanna-plant

This is how our's looks:

denise-buggs

For the deduction setup PR05, there is an Arrears Processing rule, that states how many one time deductions are taken in a payment. If it is sporadic for certain employees, it may not be the issue.
Make sure the Deduction cycles are flagged on the PR14 record for the employees that are having issues. And verify the deduction does not have an end date. We also had the same issue on Descending balance deductions, where if the balance was 0, the deduction would not come out.

karin-jensen

Make sure the date being loaded in the PR39 is within the effective dates of the PR14 record. We used to be able to use any date, but somewhere along the line that changed.

paula-brooks

We've been having this same issue so was following the thread. From what we can see in our version, that PR39.6 screen is for GHR so I'm wondering if that screen only works with that version.

unknown

Hi guys, I work on the technical side, not the business side, so I am curious: Is there a reason that you all load the benefit deductions as one time deductions, rather than just updating PR14? If the deductions are loaded on PR14 as descending balance deductions, and the balance amount is the same as the deduction amount, the deduction would still only take one time. And PR514, PR14 are a little more straightforward to use, I think. Is there an advantage to having the deductions load to PR39 instead? Thanks for any insight you can offer! I would appreciate the learning.

paula-brooks

We only use PR39 for adjustments at our company. Deductions are setup on PR14 but if any payments are missed or over deducted for any reason, the adjustments are processed on PR39. When we move to a closed loop payroll, the benefit vendor will be sending us the adjustments each week that will be loaded to PR39.

deanna-plant

Our benefits team wanted the 3rd party vendor to only send a deduction - they didn't want to require the complexity of determining what would be Add's & Change's to the PR14. Hindsight this may have not been the best decision.

unknown

We have also run into an issue uploading to PR39. We have been using the same upload format for years and this time PR39 only populated for some staff. We are doing a one-time override of benefits for all staff.

unknown

Thank you! So Deanna, it sounds like the benefits folks were thinking that they would have to set up a plan and then use BN32 to create/update PR14, then. That would definitely be a lot more work! The reason I asked is that one of our divisions whose benefits we administered, recently contracted with a benefit TPA, and the TPA is sending us a file with payroll deductions on it. Currently we are using the plan information from the vendor and updating the deductions through the plan, but using BN531. But I am hoping to work towards just loading the deductions, and my first thought was to set up new deduction codes for them that were just straight deductions, not benefit deductions, and use PR514 to load them. So I was surprised to read that most people are using PR539 for this. Very interested to hear more about it!

tbobo

How are table to get to this screen? Our IS department says it is embedded somewhere

Copyright © 2025 Infor. All rights reserved.