SAP IDoc Incident Doctor

The status number tells you which layer failed. The message text tells you why. Both together usually settle the cause in one pass.

Inbound statuses split into two families, and treating them as one is the most common reason a simple IDoc problem takes a day. Status 51 and 52 mean the posting function module was called, ran, and rejected the data. Status 60 to 66 mean the posting module was never reached: ALE could not find a partner profile, a process code, a receiver or a usable segment structure.

The consequence is practical. A 51 is a business problem — master data not extended to the organisational scope, customising missing, a determination that cannot resolve. Nobody in Basis can help you, and the fix belongs to the functional owner. A 63 or 64 is a configuration or timing problem, and the functional team has nothing to fix. Reading the status before opening the ticket puts it on the right desk the first time.

When an IDoc fails with status 51, no document was created — the application rejected the data before saving. Reprocessing after the fix is safe. That is the normal case, and it is why BD87 is used so freely.

The dangerous cases are the exceptions. If the message says the document already exists, the posting either succeeded on a previous attempt or a partial posting happened; pushing the IDoc through again either fails or produces a second document that somebody will find at month end. If the failure happened mid-transaction with an update termination, part of the data may be committed. And if serialisation rejected the IDoc as obsolete, a newer IDoc has already applied the change and forcing the old one through will roll data backwards.

The habit worth building is simple: before reprocessing a backlog, look for the document the IDoc would create. Reprocess one, verify what it produced, then release the rest. When the answer is that the document is already there, set the IDoc to status 68 with the document number in the note rather than leaving a red entry that somebody will retry next month.

Outbound statuses below 43 mean the business document exists in your system and only the transfer failed. Nothing needs to be re-entered. The chain is short — the application creates the IDoc, ALE determines the receiver, the port hands it to the transactional RFC layer, and the destination delivers it — and each link has one obvious place to look: BD64 for the receiver, WE20 for the parameters, WE21 for the port, SM59 for the destination and SM58 or SMQ1 for a stuck call.

Two causes account for most of them. After a system copy or client refresh the logical system name no longer matches what the partner profile expects, and everything queues. And the communication user behind an RFC destination gets locked or its password expires, which produces an error that looks like a network problem and is not.

The full IDoc status code index lists every standard status with its meaning and first check. There is a detailed walkthrough of IDoc status 51, and the IDoc reference library covers message types and segments. For a non-interface error, paste it into the error diagnosis tool. To prepare for interviews on this topic, see the IDoc and ALE interview questions.