IDoc status 30 — IDoc Status 30 Ready for Dispatch

Status 30 is exclusively an outbound status. It marks the point where the application has generated the IDoc, the receiver port and partner profile have been resolved, syntax checking has passed, and the IDoc is queued for the ALE dispatch service. Nothing has actually left the system yet: the IDoc has not been handed to tRFC or qRFC for transmission, it has not touched the receiver's inbound queue, and no acknowledgement can exist. The next expected move is into status 01 or 03 once the outbound processing program picks it up and passes it to the port. An IDoc can sit in 30 indefinitely if the dispatch mechanism behind it is not running or is blocked, with no error raised anywhere.

Resolve the underlying blockage before touching the IDoc itself. If a queue is blocked, clear or fix the offending entry in SMQ1/SMQ2 first, since reprocessing behind a still-blocked queue achieves nothing. If the RFC destination is broken, fix the connection in SM59 and confirm a successful test call. If the partner profile is on collect mode and immediate delivery is actually required, either switch the mode or trigger the scheduled dispatch job manually rather than editing the IDoc. Once the transport path is confirmed working, reprocess through BD87, selecting the affected IDocs by status 30 and message type and executing outbound processing. Because status 30 means the IDoc has never actually reached the receiver, straightforward reprocessing carries no duplicate-posting risk on the receiving side. The risk appears only if someone has already resent the underlying business document manually through another channel while the IDoc sat stuck; check for that before mass-reprocessing a backlog.

The reflex is to select every status-30 IDoc in BD87 and hit reprocess repeatedly, assuming the dispatch will eventually take. If the queue is blocked or the RFC destination is down, this does nothing except reset timestamps and clutter the monitor, since the same connection problem stops each attempt. A worse variant is manually forcing the status forward to 03 (data passed to port) through direct status edit, which marks the IDoc as sent when it never left the system; the receiving side never gets the document, but every downstream report now believes it did, producing a silent gap that is far harder to find than the original stuck queue.

Basis or the integration team owns RFC destination health, port configuration, and queue unblocking. The functional or application team owns whether the partner profile should run in immediate or collect mode and confirms whether any business document was already sent through another route. Hand over the IDoc number, message type, port, and queue name together, not the IDoc alone.

Status 30 does not read as an error, so it rarely appears on error-status alerts or exception dashboards, and a growing count can go unnoticed for days while orders, deliveries, or shipping notifications simply never arrive at the partner. It is also easy to mistake a blocked serialized queue for a one-off dispatch failure and reprocess only the newest IDoc, when the actual fix is unblocking the oldest entry holding up the whole queue behind it.