Skip to Content

LSMW Optimization Whitepaper for Parallel Posting

 In the LSMW transaction, when you have an Idoc defined in the Object Attributes and when you are at the Start Idoc Processing stage as shown below….


You will see this screen. You can use the “Parallel Proc.” Tab here



Use the Server Group that BASIS has created by pressing F4 on Server Group field. If there is none, you can contact BASIS and get it created.




Click the checkbox “Parallel Proc. Active”. Note that the Maximum number of attempts field is 1000. This means if it hits a user-lock error for the application document key, and this can happen since you are running things in parallel, it will still attempt 1000 times so by that time the user-lock will be removed.




There is also an SAP OSS for checkbox “Wait for End of Processing”. If you want to use this checkbox make sure you read through this OSS. An example from the Rel 2 Purchase Order load during Cut Over is given here, where the parallel processing was used. In all previous loads, without parallel posting there was a 4 to 5 hours of load time needed for around 43000 Purchase Order Headers. With Parallel Posting it takes 695 seconds to complete posting of 43276 records as seen below. Note that the LSMW idoc processing is done in background (RBDAPP01 program is scheduled in background)




SIMULATION Feature in IDocs


  1. Most of the LSMW jobs which use Idocs, will have a field of TESTRUN. We can utilise this to our advantage.


  1. If you set the TESTRUN = ‘X’, all processing will be in SIMULATION phase. You can use EDIDS table(shown in below snapshots) or any other custom program you might already have to look at the SIMULATION errors, fix them and then do the actual database load by removing the ‘X’ from the field.

EDIDS download of errors

  1. Once your IDoc processing is complete through LSMW, you can go to SE16, EDIDS table(you will need to have your IDoc number range ready) and download the following fields:
    1. DOCNUM
    2. STATXT
    4. STAMNO
    5. STAMID


    2. You can then pivot the STATXT field to get unique error types & you can also pull the descending count of IDocs so you can focus on the error type with the maximum failures





  1. SAP gives all errors and does not update database. This helps to analyse errors, correct them and then get a clean load.


  1. Also helps in identifying well in advance if you are going to meet an exit criteria % success rate for Trial Conversions

 Points to Remember: 

  1. When you want to move from Simulation Phase to Actual Database phase, you will need to re-set the E1PORDCR1-TESTRUN = SSE1PORDCR1-TESTRUN

image for BOR-LSMW integration

 I will cover this topic in the next document in this series, since I am running into authorization issues for the snapshots but didn’t want to hold up the above topics.

You must be Logged on to comment or reply to a post.
  • Shireesh – it was interesting reading your article on parallel processing of IDoc’s. Reminded me of my earlier days.

    Actually, I liked the article on building parallel processing using SAP workflows. Excellent article.

    Keep it up…