807
We reprint a paystub. The wrong address in printing on the paystub. The employee has two address records. One is called PRIMARY, the other is OLD. The employee card has PRIMARY selected, but the reprint is pulling the OLD address. I assume that is because it is just pulling the first address, OLD comes before PRIMARY, instead of looking at the employee card.
Dynamics GP2016
Hello Bob,
I didn't say it wasn't going to be fixed, i said i assumed it will not be fixed as we have the package file that will fix the issue.
Once it is submitted, Development will determine if this gets fixed in a later release or not. Development prioritizes these by:
1. Is it data damaging?
2. Number of customers running into the issue.
3. Is there a workaround and how complex is the workaround.
As this is not data damaging and this is the first time it has been reports, it is very low priority as it is only the check reprint and not the actual check.
One tool at our disposal is to submit a product suggestion. The more upvotes it received the higher chance it has of getting implemented/fixed. You can create these suggestions using the link below.
https://ideas.dynamics.com/ideas/
Thank you!
So if a user doesn’t know about the error, they will be sending statements to the wrong address. Sending confidential information to the wrong address.
Once they discover the error, they will spend time to figure out what the error, maybe paying for a support incident for an issue that Microsoft created and won’t fix. In either case it does cost the end user time and money.
Why doesn’t Microsoft just fix this?
Hello Bob,
This is still an issue in current versions. The report modification that i made was on the latest and greatest GP version.
I will get this documented. As we have a package file to fix this now, my thought is this will not be fixed due to how easy it is correct the report.
Thank you!
So the report definition has been wrong in GP2016 all along. Has this been fixed in future versions?
Thanks for your answer.
Hello Bob,
Thank you for your response and additional information.
I dug into this further and see what is happening. If we look at the report and the link from the Payroll Master to the Payroll Address Master, we dont have one for the Address Code.
It wont allow us to change this. I believe this is because it ends up linking to the main table of the report.
I was able to get this to pull based on what is assigned to the Employee Maintenance window by adding a second Address Master link to the Employee Master. You can give this a test and see if it will work for you.
Now when you test print, it will pull the address based on the Address ID assigned to the Employee in the Employee Maintenance window instead of the first address id based on alpha characters.
I hope this helps!
I added the Package file i corrected this on. This is As Is:
[View:/cfs-file/__key/communityserver-discussions-components-files/32/Reprint-Pay-Statement-to-pull-addres-based-on-address-id-assinged-to-the-employee-Package0.Package:320:240]
Microsoft Support Engineer | Brandon Jarrett.
Here is what I found by further testing. We were using a modified report, but the results are the same either way and it doesn't follow your explanation.
Two address ID's, OLD and PRIMARY. Employee card is PRIMARY when paycheck was created. Recreated PayStub prints OLD. Change Employee Card to OLD. Recreated PayStub prints OLD.
Now delete OLD address and it prints PRIMARY. Add ZZZ address, it prints PRIMARY. Add OLD address, it prints OLD.
So it seems to always print the first one alphabetically.
This is GP2016.
A trace shows this SQL statement:
exec LHI.dbo.zDP_UPR00102F_1 'SMITCHRI','','SMITCHRI','ÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞ'
which is selecting all addresses for the employee.
Where does it store the address that was used originally used?
Hello Bob,
Thank you for posting your question on the forums today. I will provide information pertaining to your question.
When we see this in support, it is usually because the check with printed with one Address ID. The Address ID was changed on the employee. When we reprint checks, it reprints with the exact information that was printing originally. It will not print with the changes made after the check was already printed.
This information also gets put into a Temp Table when reprinting. You could restart the SQL instance to clear out any stuck records to see if this corrects the issue if the check was printed with the Address you want to see.
If the address is different than what was printed on the check and you want to see the new Address, you could modify the report to pull the Address from the UPR00102.
If you are seeing this on a new check, what third party products are using? Do you use Mekorma or Greenshade? I would test disabling these to see if the issue still occurs.
I hope this helps!
Microsoft Support Engineer | Brandon Jarrett.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
290,552
Super User 2024 Season 2
#2
Martin Dráb
228,552
Most Valuable Professional
#3
nmaenpaa
101,148
Share
Report
All responses (
Answers (