IDoc status 66 — IDoc Waiting for Predecessor IDoc

Status 66 is an inbound status. It sits before the application document posting step, at the point where SAP checks whether IDocs sharing a serialization key (typically object identifiers like material number, vendor code, or customer number) must be applied in a defined order. If a serialization rule is active for the message type and a predecessor IDoc carrying the same key has not yet reached a successful terminal status, the current IDoc is stopped here and marked 66 rather than being handed to the application posting program. It is a queue-hold status, not a data error status: the IDoc's own content may be perfectly valid. The block exists purely to prevent an older change from posting after a newer one, or vice versa, which would leave the master record in an inconsistent state.

The predecessor IDoc must reach a genuine successful terminal status before the waiting IDoc is touched. If the predecessor is an error, correct the underlying data or configuration issue that caused its failure and reprocess it through the normal error-status route, not through the 66 record. Once the predecessor posts cleanly, the serialization check clears automatically and the waiting IDoc becomes eligible for normal inbound processing, typically picked up by the next scheduled run of the inbound processing report or reprocessed manually through BD87. If the predecessor is genuinely gone, for example lost before entering the queue, the serialization link has to be removed or the wait condition manually released, and this should only be done after confirming with the sending system what the correct current state of the master object actually is, since posting the successor without its predecessor risks applying changes out of the intended order. Duplicate posting risk here is really a duplicate-application-of-stale-data risk: pushing the successor through while skewing the sequence can silently overwrite a newer value with an older one.

The reflex is to open the 66 IDoc in BD87 and force it straight to a processed status, treating the wait as an annoying technical block. This skips the sequencing the system was designed to enforce. If the predecessor actually contained a later change than the one already applied, forcing the successor through in the wrong order posts an outdated value on top of current data, for example reverting a price, address, or valuation change that was already correctly applied by something else. The record ends up factually wrong with no error status flagged anywhere, and the mistake is usually only found later during a reconciliation or audit.

First responsibility sits with whoever monitors the inbound IDoc queue, usually Basis or the middleware/interface team, to trace the chain back to the actual blocking predecessor. Resolution of the predecessor's error, however, belongs to the functional team that owns the master data or document type involved, for example MM for material replication or FI for vendor and customer master changes. Serialization configuration issues are an interface/technical design question and should go back to whoever set up the ALE or IDoc distribution model.

Status 66 does not look urgent because it carries no error message, so it is easy to leave unattended for days while the real problem sits quietly in the predecessor's error status elsewhere. A single failed predecessor can hold back a long chain of successors for the same master object, so the visible count of 66 entries can look far worse than the actual number of distinct problems. Serialization keys are sometimes set broader than intended, causing unrelated business documents to block each other for no real reason, which is a configuration defect rather than a data defect and needs a different owner to fix.