You’re offline. This is a read only version of the page.
2,469
I know this has been covered before, but I've had a similar problem recently, with a strange twist.
Last week, a user created a credit memo, and for whatever reason, a record got put in the SY00500 table with their UserID as the batch ID, and they were getting the "Your previous transaction-level posting...." message. I followed the previously described processes and all was well for a few days.
Now, today, he told me he was getting that same "Your previous transaction-level...." message again. I checked the SY00500 table and again, a record was sitting out there with his UserID in the batch ID field. However, the weird part was the batch total amount on the record had nothing to do with what he was working on today - instead, it's the amount from the record I deleted last week! If it matters, the BCHSOURC field is XRM_Sales, the RCLPSTDT is today, and the BCHTOTAL value is $828.00 - the amount he posted LAST week (not today's amount).
Where can this mysterious record be coming from??
*This post is locked for comments
I'm not an expert on the use of that table, but I think it should be empty if no one is using the system (I believe it's a temporary work table that should only have records if people have a transaction in process). Any others more knowledgeable, please chime in.
If there is a record in there, see if it's related to the problem you're having. That's how I realized it was what was causing my problem - no one was logged in, and the particular customer was the one I was having the issue with.
And don't forget Aaron's comment above about checking the RM10101/RM00401 tables, too.
Wow, you expect me to remember that far back? I can't remember what I had for lunch yesterday :-)
Actually, when we deleted that rogue record from the RM10301 table it took care of the problem - we haven't experienced it since then.
Did you find a bad record in the RM10301, too?
Bcool,
I came across your post today and we are having the exact same problem with GP2010. I noticed you said you found a remnant of the original transaction that started with this error and had deleted it. Did that give you a permanent solution? I have been pulling my hair out for the past few months dealing with this same error. I am able to clear but maybe a few times a day or a few times a week it will come back. I have tested for network connectivity issues but have found none. Our gigabit network is current and runs great throughout the building. I don't know what else to do to tackle this problem.
If you can pull that document up within the GP Client, then go ahead and delete. if not, then also make sure the RM10101 and the RM00401 tables are also cleared out as well when you remove the record from the table.
Thanks!
Thanks for the quick reply. I guess at this point, I am not to concerned about the batch total component of the story just yet as I think once the resolution as to WHY the transaction level posting is failing is found, it will shed light on what we are seeing getting written to the SY00500 table.
With that said, it must be safe to say that this issue can be reproduced fairly easily. If you have a test company, can you try and perform a transaction level postings to see if the interruption occurs? If so...then capture the script log and get a case open so we can figure out what is causing the interruption. My hunch (guess) is that there is a data issue hanging out there is the RM Work tables...but that is only a guess; since the batch posting runs through just fine the same posting code is running whether or not the posting is transactional or batch based. It may also very well explain why you are seeing the same total amount if the posting process is picking up more data than it should be.
Hope this give you the guidance and direction you need to move forward.
Thanks!
Aaron
Aaron, thanks for your response.
I may have narrowed down the problem a bit. When this happened last week, I discovered the user wasn't putting the credits into a batch - he immediately posted them. I suggested he start putting things in batches, and lo and behold, the problem went away.
I just went back to verify that he had put today's credits in a batch, and he said he did for the first two he created, but didn't for the last one(!). So, it appears that the problem is happening whenever he doesn't batch the transactions.
Other than wondering why this is happening when the transactions aren't batched, I'm also wondering why the record that got created in SY00500 has LAST week's total - not today's total. It's almost as if something is hanging around on his workstation that causes the total to be wrong. With that in mind, I removed and reinstalled GP (including the GP folder) on his workstation yesterday, but that didn't help.
Bcool,
Unfortunately, you are not going to solve this issue by simply looking at the data in the SY00500 after the fact. In order to troubleshoot the issue, you are going to need to do some investigative work with the end user in reproducing the error. It is clear that a transactional level posting is getting aborted...the real question is WHY?
For starters, I assume that most of the Receivables Transaction Entry documents end up in a batch to be posted and that the transaction level posting is more of an exception than the norm? If this isn't true, then please re-state. With the assumption made and true, anytime there is a need to do a transactional level post, sit with the end user and watch what they are doing as the keystrokes the end user is making can be the difference between a successful post and an unsuccessful post. Trust me...seen many instances of this.
After the data entry and prior to initiating the transaction level posting, enable the script log (either manually with the Debug menu or with the SDT), but you need to capture a script log of the transaction level posting process. Keep doing this until the expception occurs again. Once it does, you will need to get a case opened with support so the script log can be reviewed. They are also going to need your Dynamics.set and any form/VBA modifications/SQL Triggers you have in place regarding the Receivables module.
Just to be clear...the record being inserted in the SY00500 table is coming from the GP Client. The correct question to be asking is WHY is the posting process getting interupted. Find that answer to that...and the problem will be solved.
Thanks!
Aaron Donat
Sr. Escalation Engineer
Dynamics GP - Microsoft
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,228
Super User 2024 Season 2
#2
Martin Dráb
230,056
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (