You’re offline. This is a read only version of the page.
I get an error on trying to void a payroll check.
On printing the edit list i get the error "Check or transaction history has been removed since you selected it; cannot be voided"
I am sure the check history is not deleted. Can anyone help me in this issue.
*This post is locked for comments
A couple years later, and with a similar scenario, I may have the answer to the original issue.
I was working on a payroll issue where my client had their payroll process freeze before they could post. When they got back into GP, they reprinted checks to the screen to try and post again, but it still failed, and this happened twice. They had 2 sets of duplicate checks printed to the screen. The only history in GP that could be seen was from the original set of checks, and it was complete for all employees.
When attempting to fix, I got to the point where I wanted to void the originals and have them reprocess. I received the error message from the OP, and in the Edit List, it only occurred for the first employee. After reviewing tables in SQL, I was able to discover incomplete records in payroll tables from the reprinted checks. There was an Audit Trail code from the reprinted checks verified by the check number, and it only included the first employee, the employee that couldn't have their original check voided due to the error message from the OP.
After running the PayrollPostingInturruption.sql script for the Audit Trail of the reprinted checks, along with reconcile and check links, I was able to successfully void the original set of checks.
Additional steps required to resolve the issue that I had, was to create a back out entry of the void since the original checks did not post to the GL. This could also be accomplished by changing the settings to Post-To instead of Post-Through, and then deleting the batch created by the voids. My client doesn't use Bank Rec, so I didn't have to worry making any corrections to that part.
Client was then able to re-process their payroll. Hope this helps to anyone in the future, just make sure you create backups and double/triple check your work before editing data in SQL.
not yet., but did some begning balance and gl entries to cancel it
Any update on the resolution? This is a post that has a large number of views so we would like to find out what the resolution was if possible. Thanks
Hi again Rubeesh,
I just remembered another situation I had several years ago. What happened then is that two payroll transactions had the same document number. The transactions were years apart, but it prohibited me from voiding the transaction. I can't remember the error message, but what I did was to temporarily change the old trx doc number, void the current trx and then go change the historical doc number back to its original.
All of this doc number changing happened at the table level. For me, the reconcile check helped tremendously in confirming whatever I did worked. In my case, as is usual for this kind of thing, the reconciled amount is the WRONG amount.
Please let us know what you finally do in order to help the other poor souls who will find themselves in this situation.
Kind regards,
Leslie
I think at that time i updated it directly from the table
Hi,
I just noticed on the 'related' pane to the right, you had this exact problem back in 2008. Do you remember how you resolved it back then?
community.dynamics.com/.../4371.aspx
Kind regards,
Leslie
Hi Rubeesh,
I don't know if this will help, but I ran into this the other day and had to delete the transaction with SQL. I adjusted the checkbook register CM table, made an adjusting journal entry, changed the tax liability history and reconciled payroll for that employee (be sure to just print the report first).
This was a last resort - certainly NOT the first choice. Be sure to back up before embarking on this adventure.
Look for the transaction in the following
UPR30100 Payroll Check History - this table feeds the summary information & YE info
UPR30200 Tax Liability History - this table feeds the 'checkbook register' report
UPR30300 Payroll Trx History - this table shows the header information for posted payroll trx.
UPR30301 Payroll Trx History header - this table shows the individual transactions that includes employee, paycode, hours, etc.
UPR30400 & UPR30401 - Payroll Distribution Header - this table shows the JE presented to the GL
DD30100 - Direct Deposit Trx Hist Hdr
DD30101 - Direct Deposit Trx Hist Detail
The transaction did not show up in all of the tables, but the above are the tables I looked at.
Also, following Richard's path, check all of the tables numbered UPR10200 and above to make sure you have no unposted transactions floating around.
Kind regards,
Leslie
Please let me know if you would like me to take a look a this. At this point in time I cannot thing of anything else to try. Send me a private message and we can schedule something.
Sorry for the delay. Even this couldn't fix the issue.
Did anybody face this kind of issue
Do you know how to run SQL Profiler? If so, get to that screen and then jsut before you try to void the check, start up SQL Profiler and capture the SQL statements. YOu can then paste them in SSMS and watch what happens.
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...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (