IDoc status 32 — IDoc Status 32 - Outbound IDoc Was Edited

Status 32, 'IDoc was edited', only ever appears on an outbound IDoc that was created by editing another IDoc's data through the test/edit tool. It is not a state that a normal IDoc transitions into on its own; the system generates a brand-new IDoc number to hold the edited segment content, marks that new IDoc 32, and reclassifies the IDoc it was copied from as status 33, 'Original of an IDoc which was edited'. So finding a 32 means someone deliberately produced an edited variant of an existing outbound IDoc, generally to correct bad data or to replay a message with a manual change, and that variant sits outside the normal dispatch cycle waiting to be sent.

Before touching the 32, decide whether editing was the right tool at all. If the underlying document data was wrong, correct it on the source document first; a patched IDoc without a corrected source document leaves a permanent inconsistency between what SAP holds and what was actually sent externally. If the edit is confirmed correct, a genuine one-off fix or a deliberate reroute, the reprocessing route is to dispatch the edited IDoc itself, not the original. That is triggered from within the edit tool's own processing function, which pushes the copy through outbound processing toward status 03 and then 12 in the normal way. The critical check before dispatch is whether the original IDoc, now at status 33, already reached the receiving system. If it did, sending the edited copy duplicates the business message on the partner side unless the receiving interface can dedupe by document number, or unless the original transmission is formally cancelled with the partner first. If the original never left SAP, it can be left at 33 with no further action, and only the edited copy needs dispatching.

The habitual move is to select the 32 IDoc in the status monitor and mass-reprocess it alongside genuine error statuses, on the assumption that 32 just means stuck and needs pushing. That skips the question of whether the paired original IDoc already went out. If it did, the partner ends up holding two versions of the same business document, one wrong and one corrected, with no system-level link tying them together, and reconciling that on both sides becomes a manual exercise.

Whoever holds edit authorization on the IDoc test/edit tool owns the decision to create a 32 in the first place, and that authorization should be tightly restricted outside development and support activity. When one turns up in a production system, hand it to the interface or basis team to establish who created it and why, and to the functional owner of the source document to confirm whether the real underlying data was ever corrected upstream.

Status 32 looks like a processing failure when scanning a status list sorted numerically near the error statuses, but it carries no error at all; it is a deliberate artifact of manual editing, not a rejection from the port or the receiving system. The paired original at status 33 is easy to miss because standard IDoc list transactions do not group the two together by default. Change document logging on the segment edit is only available if that logging was switched on beforehand, so the exact delta between original and edited copy is often unrecoverable after the fact. A 32 with no corresponding fix on the source document is effectively invisible to anyone who only checks the application side.