12/21/2015 7:06:21 PM

Outbound IDocs stuck with status 30-Outbound IDocs remain in status 30. Outbound IDocs stuck with status 30. Outbound IDocs not sent. IDocs remain in status 30. IDocs stuck in sending system. IDocs not received. IDocs not moving to status 03. Immediate processing option does not work.Cannot process IDocs in the foreground.Function module MASTER_IDOC_DISTRIBUTE causes IDoc to stay in status 30.

When you send IDocs to another system using the "Transfer IDoc immed." option in WE20 but they just hang in status 30 (IDoc ready for dispatch) and are not changed to status 03 (Data passed to port OK)

If you are using SAP standard IDoc, please check the following.

1.) Consider whether all IDocs actually have to be sent separately and immediately to the recipient.

If possible, the setting "Collect IDocs" should be made in the partner profiles for the outbound.

This way, the IDocs are created in the status 30 and can be sent using the report RSEOUT00. This saves a lot of RFC resources and prevents that IDocs remain in status 30 when this is not required.

If the recipient can only receive one IDoc at a time, you can still make the setting "Collect IDocs".

For this, you can set the relevant parameter (Maximum number of IDocs) to 1 in the report RSEOUT00.

2.) If you want to send IDocs separately and immediately, the application that creates the IDoc must ensure

that the IDocs are unlocked before the send process is triggered, for example, by a COMMIT WORK. Implement the source code corrections contained in the notes referenced below.

3.) If the send modules in the tRFC queue cannot be processed, you can restart them in transaction SM58 or by starting the report RSEOUT00.

If you are using custom message type or if you are calling MASTER_IDOC_DISTRIBUTE from a Z program, you shouldn't call the FM directly. The problem is probably that locks are remaining on the idoc tables after calling the ALE layer. When calling the ALE/Idoc layer from your custom program you have to run a COMMIT WORK after the call. At this time the communication will be triggered and the idocs have to be dequeued. When you raise the COMMIT WORK, the background processing which sends the IDocs from status 30 to status 03 is started. At this moment the ID is still locked by your program. This lock will be automatically deleted when the program ends, but for this short delay/ bottleneck, it is recommended not to use a single COMMIT WORK but a manual dequeuing before this COMMIT WORK.

Solution 1)

Change to "Collect Idocs" in WE20 and schedule RSEOUT00 to process the idocs in the background.

Solution 2)

Implement the following "triple" into your program that creates the idocs:




Note: Function module DEQUEUE_ALL dequeues all locks. In case you need to delete the lock of your single IDoc only, please use function

module EDI_DOCUMENT_DEQUEUE_LATER. This function module dequeues the IDoc with the imported IDoc number only.

If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.


  • Uk Free Classifieds -4/16/2016 6:47:48 AM

    Hey there are using Wordpress for your site platform? I'm new to the blog world but I'm trying to get started and create my own. Do you need any coding expertise to make your own blog? Any help would be really appreciated! my webpage: www.ukclassads.com
  • Internet Advertising -4/14/2016 9:06:44 PM

    Attractive section of content. I just stumbled upon your weblog and in accession capital to assert that I get in fact enjoyed account your blog posts. Anyway I will be subscribing to your feeds and even I achievement you access consistently quickly. my web site; www.ukclassads.com