IDoc status 02 — IDoc Status 02: Error Passing Data to Port

Status 02 is an outbound status. The application document (sales order, delivery, material master change, whatever triggered the IDoc) has already been generated and the IDoc control and data records exist in the database. The failure happens at the next step, when the system tries to hand the IDoc to the port defined in the partner profile, whether that port is a file port, a tRFC/ABAP-PI port, or an XI/PI port. The IDoc never reaches the port successfully, so nothing has been sent anywhere. This is different from status 03, which means the transfer succeeded and the IDoc is sitting in the outbound queue or has left the system. Status 02 is a local, technical failure, not a receiver-side rejection.

Fix the connectivity or configuration problem first: correct the RFC destination, repair or recreate the port, restore file system access, or fix the partner profile assignment. Do not touch the IDoc until the underlying port test succeeds independently, for example a clean connection test in SM59 or a successful manual write to the file target. Once the port is confirmed working, reprocess the stuck outbound IDoc through the standard outbound processing report or mass reprocessing transaction rather than editing the IDoc data. Because status 02 occurs before the IDoc has left the system, there is generally no downstream duplicate-posting risk on the receiver side, since nothing was ever received. The real duplicate risk is upstream: if the business process was re-triggered manually while the original IDoc was stuck, a second IDoc for the same document may already exist. Check for a duplicate outbound IDoc with the same object reference before reprocessing the original.

The reflex is to select the IDoc and hit reprocess immediately, assuming a retry will succeed on its own. If the port or RFC destination is still broken, the retry fails again with status 02 and adds another status record without resolving anything. Worse, if someone instead deletes the stuck IDoc and re-triggers the source transaction to force a fresh one, and the original was actually still queued or partially processed, this creates two outbound IDocs for one business document, which then causes duplicate messages once the port issue is eventually fixed and both get dispatched.

This belongs to Basis or the integration/interface team, since the fault is in port, RFC, or file system configuration rather than business data. Hand over the IDoc number, message type, the exact status-02 error text, and the port and RFC destination name involved. Functional consultants only get involved if a duplicate business document needs correction after a mistaken retry.

Status 02 looks like a data or mapping error to anyone unfamiliar with the outbound chain, because the IDoc list shows an error, but the data records are almost always fine at this point. Another trap is a file port that reports success on a retry only because the directory was fixed, while the receiving side's polling job has meanwhile been paused, so the file sits unread and looks resolved when it is not. Environment refreshes are a frequent silent cause, since port and RFC entries copied from production often point to the wrong target after a client copy.