Our customer is getting the below message:
"Your previous transaction-level posting session has not finished process. Please allow time for it to finish." This is across all users in Receivables Transaction Entry. It will not clear upon log out and log in as instructed on error message.
How can they fix this problem? What is causing it?
*This post is locked for comments
If deleting logs from control tables re: SY00500 SY00800 SY00810 DEXLOCK DEXSESSION tables don't work, chances are that the posting process did not complete.
Likely that the work transactions was not deleted.
You may check the tables RM10201 and RM10301 and RM20101.
If the transactions are already in RM20101 and also in the Work tables (RM10201 and RM10301) for Cash receipts and Invoices respectively or the SOP work tables...Its causing the problem.
You may do checklinks or back end editing.
LSandhawalia, did you ever receive an answer to this question. I understand how to remove the error using the scripts mentioned in this post, but did you ever find out the root cause and how to correct it?
David1955 did you ever receive an answer to this question. I understand how to remove the error using the scripts mentioned in this post, but did you ever find out the root cause and how to correct it?
Hi,
This happened to me about a week ago. I found the scripts mentioned in this forum and ran them. The issue was resolved at the time. Now it seems to be a daily issue that we encounter. I will run the scripts to delete the bad rows, but the message will appear the next day. This all of the sudden started happening last week. We had never had the issue before. Does anyone know why we would keep having the issue?
Thanks in advance,
David
This is usually the query that you want to use:
Select * from SY00500 where BCHSTTUS<>0
Select * from SY00500 where MKDTOPST<>0
And then with you find the correct transaction, you copy the Dexterity Row and put in place of the x's in the following:
DELETE from SY00500 where DEX_ROW_ID= 'xxx'
The key tables are really the SY00500 table in the company database, and the SY00800 table in DYNAMICS.
As other have said, look for results where the batch id is eithre blank or the affected users GP login ID.
Delete these, and you should be able to log back in to GP as that user, and continue without error.
You definately should backup the databases before running the scripts.
Ian.
Hi -
The customer wrote back:
"Attached is a schedule of the results from our inquiry. We found nothing in the DYNAMICS tables, but these results come from our company table for these scripts. The 3rd script returned nothing, but we included what was in that table. Hopefully this will provide some insight."
I can send you the excel file (if you have time to look at it)... please let me know...
Thanks so much.
Hi
Can you run the following scripts and let us know if it returns any records?
SELECT * FROM SY00500 WHERE BACHNUMB = ''
SELECT * FROM SY00500 WHERE BACHNUMB = '<User ID who faces the issue>'
SELECT * FROM RM00301 WHERE BACHNUMB = ''
SELECT * FROM RM10301 WHERE BACHNUMB = '<User ID who faces the issue>'
That's what the customer said.
#1
André Arnaud de Cal...
291,735
Super User 2024 Season 2
#2
Martin Dráb
230,466
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
