Yesterday, I received a support request from one of our users who tried posting a batch full of receivables transactions and received an error message for one transaction whose distribution amounts did not match document amount.
It was suppose to be a simple task to release this transaction for edit, but due to some reason this transaction got stuck in between. It did not come back to it's original batch and quite obviously it did not get posted either due to that error.
Following are the steps involved in releasing that transaction:
CHECKS
1. Check whether the transaction is still in RM10301 (RM Sales Work) table.
In my case it was still in RM10301 table.
2. Check the fields BACHNUMB (Batch Number) and BCHSOURC (Batch Source) in RM10301 table for that transaction.
In my case, BACHNUMB contained the USER ID who tried posting the batch; BCHSOURC contained XRM_Sales instead of RM_Sales, since it was in the middle of posting process and got stuck.
3. Check whether a batch with that user's USER ID is created in SY00500 (Batch Header) table.
In my case, there was indeed a batch with that User ID. Because of which, this user could not open Receivables Transaction Entry window and was receiving the (in)famous error message "A previous transaction level posting... ... ...".
CORRECTION STEPS
1. I first created a Receivables batch (I named it as RM-RECOV).
2. Through SQL Server Management Studio, I updated RM10301 table fields BACHNUMB and BCHSOURC as follows:
BACHNUMB = 'RM-RECOV'
BCHSOURC = 'RM_Sales'
3. Deleted the batch [USER ID] from SY00500 table, to remove user's transaction posting session lock.
4. Tried opening that transaction on Receivables Transaction Entry form. Since the batch number RM-RECOV was updated through backend, it did not obviously update batch information. Due to which, I still could not open this transaction.
5. As a final step, I ran Receivables Reconcile Batch Information (Tools => Utilities => Sales => Reconcile). This step updated the amount from that erroneous transaction on to batch RM-RECOV.
After above steps, user was then able to reopen that transaction and edit it.
Bottomline: SQL approach is not always the only option for consultants to clear such issues. We need to perform some crucial application level tasks that would compliment SQL methods.
VAIDY
It was suppose to be a simple task to release this transaction for edit, but due to some reason this transaction got stuck in between. It did not come back to it's original batch and quite obviously it did not get posted either due to that error.
Following are the steps involved in releasing that transaction:
CHECKS
1. Check whether the transaction is still in RM10301 (RM Sales Work) table.
In my case it was still in RM10301 table.
2. Check the fields BACHNUMB (Batch Number) and BCHSOURC (Batch Source) in RM10301 table for that transaction.
In my case, BACHNUMB contained the USER ID who tried posting the batch; BCHSOURC contained XRM_Sales instead of RM_Sales, since it was in the middle of posting process and got stuck.
3. Check whether a batch with that user's USER ID is created in SY00500 (Batch Header) table.
In my case, there was indeed a batch with that User ID. Because of which, this user could not open Receivables Transaction Entry window and was receiving the (in)famous error message "A previous transaction level posting... ... ...".
CORRECTION STEPS
1. I first created a Receivables batch (I named it as RM-RECOV).
2. Through SQL Server Management Studio, I updated RM10301 table fields BACHNUMB and BCHSOURC as follows:
BACHNUMB = 'RM-RECOV'
BCHSOURC = 'RM_Sales'
3. Deleted the batch [USER ID] from SY00500 table, to remove user's transaction posting session lock.
4. Tried opening that transaction on Receivables Transaction Entry form. Since the batch number RM-RECOV was updated through backend, it did not obviously update batch information. Due to which, I still could not open this transaction.
5. As a final step, I ran Receivables Reconcile Batch Information (Tools => Utilities => Sales => Reconcile). This step updated the amount from that erroneous transaction on to batch RM-RECOV.
After above steps, user was then able to reopen that transaction and edit it.
Bottomline: SQL approach is not always the only option for consultants to clear such issues. We need to perform some crucial application level tasks that would compliment SQL methods.
VAIDY