Finance | Project Operations, Human Resources, ...

OT calculation - Pay factor in Employee Pay Codes showing 5 decimals in SQL table (UPR00400) instead of 2 decimals.

(0) Share

Report

Posted on by JBurgess

Pay factor is set up as 1.50 in pay code setup and on the employee specifically. However when looking in the UPR00400 table this pay factor is showing as 1.50069. There is no option to use more than 2 decimals when entering, so how is GP adding this additional fraction in? This is causing the calculation of overtime, which should be 1.50 to be incorrect. Has anyone seen this behavior before? I can manually correct this, but that is not a good practice for any new employees going forward.

Jason Burgess

Categories:

Microsoft Dynamics GP

I have the same question (0)

All responses (5)

Answers (0)

Suggested answer

Isaac Olson on at

Like (0)

Report

Hello,

I would agree with you that this very unusual. My guess would be that the main setup was imported for this Overtime code and the UPR40600 table has the odd PAYFACTR. Every time that this pay code is set up on a new employee if they pulled the setup from the company it would then pull the 1.50069 amount.

select PAYFACTR,* from UPR00400 where PAYFACTR <> 0

select PAYFACTR,* from UPR40600 where PAYFACTR <> 0

If it is incorrectly showing in either table, you should be able to just update it in SQL and not have the issue going forward.

update UPR00400 set PAYFACTR = '1.5' where PAYFACTR = '1.50069'

update UPR40600 set PAYFACTR = '1.5' where PAYFACTR = '1.50069'

I cannot think of any possible front end way to data into the condition that you are seeing.

I hope this helps!

Isaac Olson

Microsoft Support

Was this reply helpful? Yes No
JBurgess 74 on at

Like (0)

Report

Isaac, thanks for your insight here.

I had already run the update you described on the UPR00400 table which corrected the immediate issue.

However, when reviewing the UPR40600 table the PAYFACTR value is set to 1.50000 like I would expect. I'm not seeing any that are set to the incorrect value of 1.50069.

After putting in two new employees and saving (using quick assigment) the incorrect value is pulled.

I'm not sure how this incorrect number is being populated!

Thanks again for taking the time to review and answer!

Was this reply helpful? Yes No
Suggested answer

Isaac Olson on at

Like (0)

Report

Hi Jason,

No problem. I ran a DEXSQL.log of the process of assigning an overtime code to my employee and other than the UPR00100 table for the employee master, and the Workers Comp table UPR40700, I didn't see anything else besides the 2 tables that I had mentioned previously that would come into play with this. My recommendation would be as follows to narrow down the issue.

1. Does the issue only occur if you use Quick Assignment? If you manually assigned the overtime pay code to a new employee do you see the same issue?

2. Do you have any Third Party Products or add-ons or products installed that could come into play here?

3. Can the issue be reproduced if you create a new Overtime pay code? This would help eliminate whether their might be an issue with the data on your specific overtime code versus an overall setup issue in your company.

It might be best to set up a test company with a copy of the live company for this testing.

"How to set up a test company that has a copy of live company data ":

support.microsoft.com/.../871973

If none of these suggestions end up helping you narrow down where the issue is, it might be best to open a support case where we can do some more hands on digging into this issue with you to figure out why is different in this company versus other instances of GP.

I hope this helps!

Isaac Olson

Microsoft Support

Was this reply helpful? Yes No
JBurgess 74 on at

Like (0)

Report

Issac, once again, thank you for taking the time to look at this.

As for the questions you asked. It appears that this is only happening when using quick assignment. There are no 3rd party products that I can see that would interfere with this at all, as only greenshades is used as far as 3rd party products go. They were also able to set up an additional OT code and the same behavior is happening with that one.

I've advised they not use quick assignment, but I'm curious what the root cause and fix would be.

Was this reply helpful? Yes No
Suggested answer

Isaac Olson on at

Like (0)

Report

Hi Jason,

You have me curious as well as to what would be causing this. I am not able to recreate this at all and I don't see any cases in our case history reporting this as an issue ever either. If they want to dig into the root cause, we could assist with that and run logs on the issue to figure it out but we would have to do that through a support case as that obviously would not be possible to do through a forums post.

At least you have a workaround for the time being.

Thanks,

Isaac Olson

Microsoft Support

Was this reply helpful? Yes No

Join the conversation

Community site session details

OT calculation - Pay factor in Employee Pay Codes showing 5 decimals in SQL table (UPR00400) instead of 2 decimals.

Helpful resources

Quick Links

Responsible AI policies

Neeraj Kumar – Community Spotlight

Congratulations to the November Top 10 Community Leaders!

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

Featured topics

Product updates

Community site session details

OT calculation - Pay factor in Employee Pay Codes showing 5 decimals in SQL table (UPR00400) instead of 2 decimals.

Helpful resources

Quick Links

Responsible AI policies

Neeraj Kumar – Community Spotlight

Congratulations to the November Top 10 Community Leaders!

Subscribe to this forum!

Select categories

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL

Featured topics

Product updates