ABAP Developmentintermediate

IDoc Part 8: Status Codes and Reprocessing with BD87

Key takeaway

Interpret the most important IDoc status codes (outbound 01, 02, 03, 12, 30; inbound 50, 51, 53, 56, 64, 68, 69), decide the right action, reprocess with BD87 or edit with WE02/WE19, and understand status 68/69 when editing IDocs.

Explanation

📌 KEY POINTS
✅ Outbound: 30 ready to send, 03 passed to port, 02 port error, 12 dispatch OK (after confirmation).
✅ Inbound: 64 ready to process, 51 application error, 53 posted, 56 partner profile error, 69 edited, 68 no further processing.
✅ BD87 reprocesses IDocs by status after the cause is fixed; programs RBDMANI2 (reprocess 51) and RBDAPP01 (process 64) do it in jobs.
⚠️ Editing IDoc data (WE02 → status 69) changes the business content — only with a documented approval, and keep the original (status 70).

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 3–7 produced status records. Support work starts with reading them correctly.

━━━━━━━━━━━━━━━━━━━━
▶ 1. OUTBOUND STATUS

01 IDoc generated, 30 ready for dispatch (collected, RSEOUT00 pending).
03 data passed to port OK (sent from SAP's view).
02 error passing data to port (RFC/port) → check SM58, SM59.
12 dispatch OK / 16 functional acknowledgement (when acknowledgements are configured).
29 error in ALE service, 26 syntax error (outbound).

━━━━━━━━━━━━━━━━━━━━
▶ 2. INBOUND STATUS

50 added, 64 ready to be passed to application (waiting for RBDAPP01 or immediate processing).
62 passed to application, 53 application document posted.
51 application document not posted (business error) → read status message.
56 IDoc with errors added (partner profile not found/incorrect).
60/65 syntax/ALE service errors.
69 IDoc was edited, 70 original of an edited IDoc, 68 error — no further processing (manually closed).

━━━━━━━━━━━━━━━━━━━━
▶ 3. DECIDING THE ACTION

51: fix master data/customizing/mapping → reprocess.
56: create/correct partner profile → reprocess.
64 old: check job RBDAPP01 / processing mode.
02/30: fix port/RFC, schedule RSEOUT00 → resend.
Duplicate or obsolete: set to 68 (RC1_IDOC_SET_STATUS or BD87 "set status" where allowed) with documentation.

━━━━━━━━━━━━━━━━━━━━
▶ 4. REPROCESSING TOOLS

BD87: select by status/message type/partner → "Process".
RBDMANI2: job for status 51 (e.g. automatic retry after master data replication).
WE19: create a new IDoc from an existing one (for tests or corrected resubmission).
WE02 edit: segment data change → status 69 → process (BD87/RBDAGAI2).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

BD87: select all IDocs with status 51 of the last week, group by message.
Read the status message; fix one cause in a test system.
Reprocess and check status 53 and the document.

✅ CHECKPOINT: you read IDoc statuses correctly and choose the right corrective action.

Code example

ABAP Code

* ===== Daily IDoc status overview by message type =====REPORT zidoc_status_overview. PARAMETERS p_days TYPE i DEFAULT 1. TYPES: BEGIN OF ty_sum,         direct TYPE edi_direct,         mestyp TYPE edi_mestyp,         status TYPE edi_status,         cnt    TYPE i,       END OF ty_sum. DATA: lt_sum  TYPE STANDARD TABLE OF ty_sum,      ls_sum  TYPE ty_sum,      lv_from TYPE sy-datum. START-OF-SELECTION.  lv_from = sy-datum - p_days.   SELECT direct mestyp status COUNT(*) AS cnt    FROM edidc    INTO CORRESPONDING FIELDS OF TABLE lt_sum    WHERE credat >= lv_from    GROUP BY direct mestyp status.   SORT lt_sum BY direct mestyp status.  LOOP AT lt_sum INTO ls_sum.    WRITE: / ls_sum-direct, ls_sum-mestyp, ls_sum-status, ls_sum-cnt.    CASE ls_sum-status.      WHEN '51'. WRITE 'application error - fix cause, reprocess BD87'.      WHEN '56'. WRITE 'partner profile - WE20'.      WHEN '02'. WRITE 'port/RFC - SM58/SM59'.      WHEN '30'. WRITE 'waiting - RSEOUT00'.      WHEN '64'. WRITE 'waiting - RBDAPP01'.    ENDCASE.  ENDLOOP. * ===== Reprocessing =====* BD87     : interactive reprocessing by status* RBDMANI2 : job, reprocess status 51 (variant: message type, partner, error message)* RBDAPP01 : job, process status 64* RSEOUT00 : job, send status 30

Real project scenario

Every Monday, customer service manually reprocessed 200 ORDERS IDocs in status 51 with "material blocked for sales". The materials were unblocked by master data on Monday mornings after weekend changes.
The team scheduled RBDMANI2 for that specific error message after the master data job, and set up an alert only for other 51 messages. Manual reprocessing effort dropped to a few IDocs per week.

Common mistakes

Reprocessing 51 without fixing the cause.
Treating 03 as "posted at receiver".
Editing IDoc content without approval (69).
Leaving obsolete IDocs open instead of 68 with documentation.
No monitoring of 64/30 backlogs.

Best practices

Monitor statuses daily by message type.
Fix root causes; reprocess via BD87 or jobs.
Automate recurring retry cases with RBDMANI2.
Controlled, documented IDoc editing.
Close obsolete IDocs deliberately.

Interview angle

Questions: "What do IDoc status 51, 53, 64, 03, 30 and 56 mean?", "How do you reprocess IDocs?"
Strong answer: 53 posted, 51 application error, 64 waiting (RBDAPP01), 56 partner profile, 03 passed to port, 30 waiting for RSEOUT00, 02 port error, 69/70 edited/original, 68 closed; BD87 reprocessing after fixing the cause, RBDMANI2 for 51, RBDAPP01 for 64, RSEOUT00 for 30; WE19 for tests.

Practice this lesson

Quick check

1. What does inbound status 53 mean?

2. What does inbound IDoc status 51 usually mean?

3. An IDoc status record with status category '53' in the status record table generally indicates what about the IDoc?

Interview questions

1. An inbound IDoc is stuck in status 51. How do you troubleshoot?

Answer it in your own words first, then compare.

2. A batch of inbound invoice IDocs remains in status 64. What does it mean and what do you do?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.