A client reported that when reprinting a remittance via the “Recreate Check Stub” option it was correctly reprinting the remittance however another remittance for a totally different vendor was also printing at the same time?
The option being used for the remittance reprint is below
To troubleshoot I looked at the main table used on the “Reprint Check Remittance” layout in report writer.
As you can see from the image above this is the “PM Remittance Temp” table which on investigation is the PM80950 table.
When I queried this table in SQL I found a single row and the Vendor ID matched that of the remittance that was being tagged onto the reprint.
I therefore removed this row from the table by running a DELETE statement in SQL and now when I reprint the remittance it prints correctly.
I hope this helps someone else in the future if they come across the same issue.
I recently had an issue where a user was stuck in a batch in the Bank Management module. You can usually run the “Clear Activity” option to resolve the issue however on this occasion it didn’t work. I found I had to manually delete a row in an SQL table to clear the lock and allow the user access to the batch.
The exact issue they received is as follows:
With this error message the first thing to try is to clear activity and although this didn’t work on this occasion I’ll detail the steps below.
Ensure there are no users in Dynamics GP and click “Yes” to the message below. (rather than asking everyone to log out I usually just ensure there’s nobody doing any Bank Management activities)
After doing this you will be prompted with the message below confirming activity is cleared
However I found I still couldn’t access the batch. On investigation there is still some activity for the batch in the CBEU1020 table which needed clearing. I therefore ran the SQL query below in the company database to delete the row. (replace TWO18 with the name of your company database)