IDoc status 64 — IDoc Status 64 Ready for Application Transfer

Status 64 belongs to the inbound processing chain. By the time an IDoc reaches 64, it has already passed syntax and semantic checks, partner profile determination, and any inbound filtering or version conversion. It is sitting in a dispatch queue, waiting to be handed off to the posting function module associated with its message type. The next status should be 53 if posting succeeds or 51 if the application rejects it. Status 64 is designed to be transient, typically lasting seconds. When IDocs accumulate at 64 in volume, or sit there for hours, the dispatch mechanism itself, not the IDoc data, is usually the problem. This status exists mainly for partner profiles configured to process inbound IDocs via background scheduling or queued RFC rather than immediate synchronous processing.

Identify and clear the actual blockage before touching the IDocs. If a qRFC queue is stopped, restart the blocking entry in SMQ2 once its underlying cause is understood; do not just delete it. If the background dispatch job was not scheduled or excluded the message type, correct the job variant or schedule and let it run rather than manually forcing posting outside the standard path. Once the queue or job is confirmed healthy, reprocess through BD87, selecting the affected IDocs and message type, and let the standard posting function module run. Duplicate-posting risk is low at this stage because no application document has been created yet, but verify this is true for every IDoc in the batch before mass reprocessing, since a mixed batch can include some that already advanced to 53 through a parallel job run. Reprocess in the same sequence the IDocs were received if the message type is sequence-dependent, for example master data before dependent transactional data.

Never run a custom program to post the underlying business document directly while the original IDoc is still queued at 64. Once the queue resumes normal operation, it will dispatch the same IDoc and post it again, creating a duplicate document that then requires manual reversal and reconciliation on the application side.

The reflex is to select every IDoc stuck at 64 in BD87 and hit process, assuming reprocessing itself clears the backlog. If the real cause is a stopped qRFC queue or a locked resource, mass reprocessing just resubmits the same IDocs into the same broken pipe, and they land right back at 64 or move to a worse error status. Worse, if someone also manually posts the business document in parallel to unblock the business user, the queue eventually recovers and posts the original IDoc too, producing a duplicate.

Queue and job monitoring is a Basis or integration team responsibility, since the fix usually involves SMQ2, SM58, or job scheduling rather than IDoc data. Functional teams get involved only to confirm whether the affected message type is sequence-dependent and whether it is safe to release a backlog in bulk once the underlying queue or job issue is resolved.

IDocs at 64 look identical to genuinely healthy in-flight IDocs when the display is refreshed slowly, so a monitoring dashboard can under-report a growing backlog until someone checks the actual queue. A single erroring IDoc at the head of a shared queue can silently stall dozens of unrelated interfaces, so the fix belongs to that one entry, not to every IDoc showing 64. Sequence-dependent message types compound the problem: releasing the queue and letting a backlog process out of order can cause application errors further downstream that look unrelated to the original stall.