Outbound errors: 02, 26, 29, 30 and the 03 trap

Outbound errors are quieter than inbound ones. A purchase order is saved, the buyer sees a green message, and nobody notices that the supplier never got it until the parts do not arrive. That is why outbound monitoring matters as much as inbound, and why the outbound statuses deserve the same precision.

Status 30: ready for dispatch

Status 30 (IDoc ready for dispatch, ALE service) is a waypoint, not an error. SAP records it in both output modes, but with Transfer IDoc immediately the IDoc moves on to 03 at once; it stays in 30 only when the outbound partner profile says Collect IDocs. The IDocs then wait for a job running report RSEOUT00 (transaction WE14) that sends them in batches. At Contoso, customer invoices for Great Lakes Fleet Services are collected and sent every 30 minutes, so invoice 90001877 sits in 30 for up to half an hour by design. The problem case is an IDoc that stays in 30 for hours: the RSEOUT00 job is missing in CMP, scheduled with the wrong variant, or failing.

Searchers often ask why an IDoc shows "status 30" and nothing happens. The answer is almost always the output mode in the partner profile plus a missing or wrong job. Check the outbound parameters in WE20 first, then the job in SM37.

Status 02: error passing data to port

Status 02 means SAP could not hand the IDoc to the port. For a file port it can be a missing directory or a permissions problem. For an XML HTTP port it can be the HTTP destination. For tRFC ports the failure usually shows up later as an SM58 entry while the IDoc keeps 03, so a 02 on a tRFC port often means the port or its RFC destination itself is wrong or missing. Contoso's worst 02 incident came after a CMQ refresh: the RFC destination to XQ1 was overwritten with production settings, which Sam's Basis team caught because the post-refresh checklist compares SM59 destinations before anyone runs tests.

Status 29: error in ALE service

Status 29 appears in the ALE layer, before the IDoc reaches the port. The most common causes are a missing or wrong outbound partner profile for ALE distribution, a filter or conversion rule problem, or a distribution model that does not determine a receiver. You see 29 mostly in ALE scenarios such as master data distribution (MATMAS, DEBMAS, CREMAS). With EDI output from message control the situation differs: if the partner profile is missing, the output itself fails in the application (for example on the purchase order's output log) and no IDoc is created at all.

Status 26: syntax error, outbound

Status 26 (error during syntax check of IDoc, outbound) means SAP built an IDoc that breaks its own type definition. In a standard system this is rare. It usually follows custom code: a user exit that appends a custom segment under the wrong parent or more often than the extension allows. Contoso's first 26 appeared in CMQ when the extension for Great Lakes Fleet Services' fleet unit numbers was transported without the WE82 assignment, and the exit kept appending a segment the IDoc type did not know.

The 03 trap and acknowledgments

The most expensive outbound mistake is to treat 03 as delivered. Process Orchestration can fail after it received the IDoc, the partner's VAN can reject the interchange, or the partner's translator can reject the 850 with a negative 997. Unless middleware sends status information back (for example as STATUS IDocs, basic type SYSTAT01, which set statuses such as 16 or 17 on the original IDoc; an SAP receiver returns ALEAUD audit IDocs that set 39, 40 or 41), SAP will never know. Status 12, set by report RBDMOIND (BD75), only proves that the tRFC call reached Process Orchestration. That is why Contoso pairs every outbound IDoc check with a check in the Process Orchestration message monitor and, for EDI partners, with the 997 the partner returns.