Inbound vs Outbound IDoc Processing

Outbound and inbound are mirror flows, not identical configurations. Outbound logic extracts application data and creates an IDoc with sender/receiver information. Receiver determination can come from application output or ALE distribution. The outbound partner profile tells SAP how the message should be dispatched and which port/output mode applies. Inbound logic receives the technical document, checks the inbound partner profile, determines the process code and invokes application processing—typically a function module/workflow layer—to create or change business data. Status codes are direction-sensitive and the diagnostic path must follow the side on which the failure occurred.

Understand direction before debugging any IDoc. For outbound 'nothing created', inspect the business trigger, receiver determination/change pointers, outbound partner profile and output/process logic. For inbound 'document failed', inspect received control/data, inbound partner profile/process code and application messages. In two-SAP-system scenarios, the sender's outbound success and receiver's inbound success must be correlated by control record/business references; one system's green status is not enough.

Outbound IDocs can be generated by NAST/output, change pointers, message control, ALE, BAPI/custom logic or application-specific frameworks. Inbound IDocs are received through tRFC/qRFC/file/other ports and dispatched via process codes. WE20 has separate outbound and inbound parameter sections. WE02/WE05 shows status per system. SM58/SMQ* may expose transport-layer failure underneath. Application reprocessing tools differ by message/process.

A delivery is created but no DESADV IDoc exists. Since no outbound IDoc number exists, searching inbound process code is pointless. The team first checks the output/event trigger and receiver determination, then WE20 outbound parameters. In a different incident the IDoc exists in the receiver with status 51; transport is complete, so the team reads EDIDS message and debugs inbound application processing rather than SM59 connectivity.

Inbound/outbound IDoc flow remains part of S/4HANA classic integration. New Output Management may change how some outbound business messages are triggered, while APIs/events may replace IDocs in specific scenarios. The IDoc direction concepts remain relevant wherever IDoc is retained.

Outbound trigger ownership usually begins with the sending application plus integration configuration; inbound application errors belong to the receiving functional/application team. Basis owns communication transport. Integration teams coordinate correlation and reprocessing end-to-end.

The IDoc architecture topic explains records/status. WE20, WE21, WE42 and BD64 are central configuration objects. RFC/qRFC topics cover transport beneath the IDoc layer.

Production verification: Capture the IDoc number when one exists, sender/receiver logical systems, message type/basic type/extension, current and prior statuses, partner type, process code/port, and the exact timestamp. Use WE02/WE05, WE20/WE21/BD64 and EDIDC/EDID4/EDIDS as appropriate so the incident can be placed at trigger, routing, transport, or application-posting layer.

Operational readiness: For production readiness of Inbound vs Outbound IDoc Processing, add an operational runbook that names the source owner, integration/platform owner and target application owner; defines correlation, retry/replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed/business-invalid payloads and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue/retention/order behavior and how a corrected message is reprocessed without duplicating a business transaction.

Review checkpoint: Review checkpoint for Inbound vs Outbound IDoc Processing: document one successful message and one intentionally failed message from source to target, including the correlation key visible in every participating monitor. Record whether the operation is synchronous, queued, retried or event-driven and what constitutes final business success. Verify secret and certificate ownership, expiry monitoring, destination or endpoint promotion between environments, timeout behavior, and the exact manual replay procedure. A support engineer should be able to determine within minutes whether the failure belongs to source data, BTP connectivity or security, middleware processing, target API validation, or downstream business posting.