IDoc status 70 — IDoc Status 70 - Original of an Edited IDoc

Status 70 is an inbound status and it is terminal. It appears on an IDoc that was originally sitting in some error status - commonly a data or application error - and was then manually corrected using the IDoc edit function available from the error handling worklist. When a user edits segment field values on an erroneous inbound IDoc and saves, the system does not overwrite the original document. It writes a brand new IDoc containing the corrected segments and assigns status 70 to the original to record that it has been superseded by that new document. The status 70 IDoc keeps its original, uncorrected data forever, purely as an audit trail. Any further processing, successful or not, happens against the new IDoc number, not this one.

There is nothing to reprocess on the status 70 IDoc itself. It has no active processing function and reprocessing tools will not act on it in any way that changes the business situation. The actual resolution work happens on the successor IDoc identified in the status text. First confirm the successor's current status: if it already completed and created the downstream application document, the situation is closed and no further action is needed. If the successor is still sitting in an error status, fix the true root cause there - not by editing again unless genuinely necessary - and reprocess it through the normal route (BD87 or the equivalent monitor) after confirming the corrected field values are actually correct business data, not just values that satisfy validation. Never attempt to force the status 70 original back into a reprocessable status. Track how many generations exist in the edit chain before declaring the case closed, since only the last generation in the chain reflects the current state of the data.

The reflex is to see status 70 in a worklist, assume it is an error waiting for action, and try to force it back into a processable status - typically resetting it to a ready-for-processing status and running it through BD87 again. The status 70 IDoc still carries its original, uncorrected data. Reprocessing it means the system attempts to post that bad data a second time. If the successor IDoc already created the target document, this produces a duplicate posting or a second application document, and the two IDocs now disagree about which one is authoritative.

Owned by whoever performed the manual edit, usually a functional consultant or key user on the receiving side of the interface. Basis and interface monitoring teams should treat status 70 as informational volume, not an incident queue. Escalate to the person who made the original edit only if the successor IDoc still shows an unresolved error, and document the business justification for the field change alongside the successor IDoc number.

Status 70 looks alarming in a monitoring report because it lands in the same worklist as genuine errors, but by design it represents a closed, successful transition, not a stuck document. In interfaces where edits happen repeatedly for the same recurring data problem, chains of two or three generations accumulate and it becomes easy to act on an intermediate generation instead of the final one. Long text on the status record is the only reliable pointer to the successor number; if it was cleared or the IDoc was archived, tracing the chain becomes a manual search by timestamp and partner.