IDoc status 52 — IDoc Status 52 - Application Document Partially Posted

Status 52 sits on the inbound side, past segment parsing and past the function module call, at the point where the application actually starts creating business documents. It differs from a clean failure because the processing did not stop before posting anything - it stopped in the middle of posting. Typically the IDoc carries more than one logical unit of work in its segments (several line items, several referenced documents, several sub-objects such as batches or serial numbers), and the inbound function module processes them in sequence with intermediate commits. One or more units post successfully and become real application documents; a later unit in the same run fails validation or hits a technical block, and the function module stops there. The IDoc is left flagged as partially processed, with no automatic indication in the segment data of which part actually made it through.

Before touching the IDoc again, establish a definitive list of what has already been posted by checking the application side directly, not by trusting the IDoc status alone. Fix the root cause of the failing line - missing master data, closed period, blocked account, tolerance breach - in the application, the same way it would be fixed for any manual entry. Then decide the reprocessing route based on whether the inbound function module performs an existence check before creating a document. If it does check for an existing reference and will skip or update rather than recreate, BD87 reprocessing of the full IDoc is safe. If it does not, do not resubmit the whole IDoc; instead complete the missing part manually in the application transaction using the same reference data the IDoc carried, then set the IDoc to a manually resolved status rather than a reprocessed one. Document which application document numbers correspond to the IDoc so a later audit does not mistake the partial post for a clean failure.

Selecting the IDoc in BD87 and clicking process again on the assumption that a partial failure just needs a retry. If the underlying function module has no duplicate check, this re-runs the entire posting logic from the top, including the lines that already succeeded, and creates a second set of documents for the same data - a second delivery, a second stock movement, a second invoice line. Even when a duplicate check exists, retrying without first fixing the line that actually failed just reproduces status 52 again with the same document gap.

Joint ownership between the interface or middleware team and the functional consultant for the affected document type. The interface side identifies where in the processing the abort occurred and whether a duplicate check exists; the functional consultant confirms exactly which documents were created and completes or corrects the missing piece in the application. Neither side should close this alone.

Status 52 looks superficially like status 51 and gets handled the same way by consultants who have not met it before, which is the wrong instinct because 51 means nothing posted and 52 means something already did. The segment data inside the IDoc never shows what committed, so the only reliable evidence is the application document itself. This status is uncommon enough that it is often missing from standard monitoring alerts tuned for 51 and 56, so partially posted IDocs can sit unnoticed until someone reconciles document counts against message counts.