IDoc status 01 — IDoc Status 01 Outbound Generated

Status 01 is set the instant an outbound IDoc's control record and data segments are written by the generating program, whether that program is output determination (NAST), a change pointer report, a distribution model trigger, or a custom function module call. At this point the IDoc exists in the database with a number but has not been passed to the ALE/EDI layer for actual transmission. The next expected status is 02 (error passing data to port) or 03 (data passed to port successfully). Because the gap between creation and port handoff is normally a synchronous call within the same program, IDocs sitting at 01 for more than a few minutes indicate the dispatch step was skipped or failed silently rather than a normal in-flight condition, except where collection-mode processing is deliberately configured.

Identify why the dispatch step never ran before touching anything: missing job, wrong output mode, blocked queue entry, or a code path that never calls the distribution API. If it is a missing or failed background job, fix the job schedule and let the next run pick up the IDoc — no manual reprocessing needed. If the partner profile output mode is wrong, correct it, but be aware the correction only affects future IDocs unless the existing one is manually pushed forward. If a queue entry is blocking qRFC, clear the blocking entry first, then let normal processing resume rather than forcing the specific IDoc. Manual reprocessing from BD87 should only be used once the root cause is confirmed fixed, and only once per IDoc number — reprocessing pushes the existing control record forward to the port, it does not create a new IDoc, so the duplicate-posting risk here is lower than for mid-chain statuses, provided the fix is applied to the configuration or job rather than to the source document.

The common mistake is going back to the source document and re-triggering the output — reprinting an invoice, re-releasing a delivery, or re-running output determination — instead of pushing the existing IDoc that is already sitting at 01. This generates a second, brand-new outbound IDoc for the same business document with a different IDoc number, while the original stuck IDoc is still sitting there unresolved. If the underlying job or queue issue is later fixed and the original also gets dispatched, the receiving system ends up with two IDocs for one document, producing a duplicate goods receipt, duplicate invoice, or duplicate order confirmation downstream.

Basis or the integration/interface team owns the job scheduling, RFC destination health, and queue diagnostics behind a stuck 01. The functional or application consultant owning the source document confirms whether the outbound message is still needed before anything is reprocessed or reissued, since the document's business state may have moved on since the IDoc was created.

A batch of IDocs sitting at 01 is not automatically an incident — collection-mode partner profiles are designed to leave IDocs there until the scheduled dispatch job runs, so the first check is always whether that job exists and is due, not whether something is broken. IDoc numbers appearing to skip around 01 can also mislead investigators into thinking data was lost, when the gap is simply concurrent creation by other processes. Because the failure at this stage is often silent — no application error, no dump, just a program that returned without calling the port step — status 01 volume needs to be watched over time rather than judged from a single snapshot.