ABAP Developmentintermediate

IDoc Part 3: Inbound IDoc Processing

Key takeaway

Follow an inbound IDoc from arrival to posted document: port and partner profile lookup, process code and function module, immediate vs background processing (RBDAPP01), status 64/50/51/53, and how inbound processing uses standard FMs like IDOC INPUT ORDERS.

Explanation

📌 KEY POINTS
✅ Inbound flow: IDoc arrives → control record checked → partner profile (WE20) inbound parameters → process code → function module posts the document.
✅ Processing mode: "trigger immediately" or "trigger by background program" (RBDAPP01 job), set in the partner profile.
✅ Status 64 = ready to be processed, 51 = error (not posted), 53 = posted successfully.
⚠️ Inbound FMs often call the same transactions/BAPIs as users — business errors (master data, customizing) are the most common cause of status 51.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 described IDocs. Now we follow an inbound order from EDI into SAP.

━━━━━━━━━━━━━━━━━━━━
▶ 1. ARRIVAL

IDoc arrives via port (tRFC from middleware, file port, or HTTP).
Status 50 (IDoc added) → 64 (ready to be transferred to the application); IDocs created in WE19 get status 74.

━━━━━━━━━━━━━━━━━━━━
▶ 2. PARTNER PROFILE LOOKUP (WE20)
Key: sender partner number + partner type (KU customer, LI vendor, LS logical system) + partner function + message type (+ message code/function). The inbound parameters specify:

Process code (e.g. ORDE for ORDERS).
Processing: immediately or by background program.
Post processing: agent/responsible for errors.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 3. PROCESS CODE → FUNCTION MODULE\n• WE42 shows inbound process codes; each points to a function module, e.g. ORDE → IDOC_INPUT_ORDERS (creates sales orders).
Other examples: INVL → IDOC_INPUT_INVOIC_MRM (logistics invoice verification), MATM → IDOC_INPUT_MATMAS01.

━━━━━━━━━━━━━━━━━━━━
▶ 4. POSTING
The FM reads the segments, maps them into the application (call transaction in background, BAPI or direct application FMs), and returns status records: 53 with the document number, or 51 with the error messages.

━━━━━━━━━━━━━━━━━━━━
▶ 5. BACKGROUND PROCESSING
With "background program", IDocs stay in status 64 until job RBDAPP01 runs (variant with message type/partner). This allows packaging and scheduling outside peak hours.

━━━━━━━━━━━━━━━━━━━━
▶ 6. AFTER POSTING

Status 53 message contains the document number (e.g. "Sales order 12345 saved").
Errors: fix cause (master data, customizing, mapping) → reprocess in BD87 (Part 8).

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

WE20: open a customer partner profile and check inbound parameters for ORDERS.
WE42: display process code ORDE and its function module.
WE19: copy an existing inbound ORDERS IDoc and process it in a test system (standard inbound or with debugging).

✅ CHECKPOINT: you can explain and follow the inbound path of an IDoc to the posted document.

Code example

ABAP Code

* ===== Schedule background inbound processing (RBDAPP01) =====* SM36 / program with a variant:*   Message type : ORDERS*   Partner      : (optional) sender partner*   Packet size  : e.g. 20 IDocs per LUW*   Status       : 64 (ready) * ===== Checking inbound status of IDocs from a partner =====REPORT zidoc_inbound_check. PARAMETERS: p_sndprn TYPE edi_sndprn DEFAULT 'CUST001',            p_mestyp TYPE edi_mestyp DEFAULT 'ORDERS',            p_date   TYPE sy-datum   DEFAULT sy-datum. DATA: lt_edidc TYPE STANDARD TABLE OF edidc,      ls_edidc TYPE edidc,      lv_51    TYPE i,      lv_53    TYPE i,      lv_64    TYPE i. START-OF-SELECTION.  SELECT * FROM edidc INTO TABLE lt_edidc    WHERE direct = '2'                          " inbound      AND sndprn = p_sndprn      AND mestyp = p_mestyp      AND credat = p_date.   LOOP AT lt_edidc INTO ls_edidc.    CASE ls_edidc-status.      WHEN '53'. lv_53 = lv_53 + 1.             " posted      WHEN '51'. lv_51 = lv_51 + 1.             " error      WHEN '64'. lv_64 = lv_64 + 1.             " waiting for processing    ENDCASE.  ENDLOOP.   WRITE: / 'Posted (53)       :', lv_53,         / 'Errors (51)       :', lv_51,         / 'Waiting (64)      :', lv_64. * ===== Inbound chain =====* Port -> EDIDC/EDID4 -> WE20 partner profile (inbound, message type)*      -> process code (WE42, e.g. ORDE) -> FM IDOC_INPUT_ORDERS -> status 53/51

Real project scenario

A retailer sent 5,000 orders every morning at 6:00. With immediate processing, the inbound IDocs competed with users for work processes and order entry became slow.
The team switched the partner profiles to background processing and scheduled RBDAPP01 every 15 minutes with packet size 20 in a dedicated server group. Order entry performance recovered, and errors (status 51) were routed to the customer service team via the post-processing agent.

Common mistakes

Partner profile missing for the sender/message combination (status 56).
Background processing set but RBDAPP01 not scheduled (IDocs stuck in 64).
Reprocessing status 51 without fixing the cause.
Not knowing which FM a process code calls.
Ignoring the message code/function in partner profile keys.

Best practices

Document partner profiles and process codes per interface.
Use background processing for high volumes.
Assign post-processing agents for errors.
Monitor 51/64 daily.
Test with WE19 before go-live.

Interview angle

Questions: "Explain inbound IDoc processing.", "What is a process code?", "Why do IDocs stay in status 64?"
Strong answer: port receives IDoc, partner profile (WE20) determines inbound parameters by partner and message type, process code (WE42) points to FM (e.g. ORDE → IDOC_INPUT_ORDERS) which posts and sets status 53/51; processing immediately or via RBDAPP01; status 64 = waiting (job not scheduled); fix errors then BD87.

Practice this lesson

Quick check

1. Inbound IDocs stay in status 64 although the partner profile says "trigger by background program". What is missing?

2. Failed inbound IDoc status is:

3. IDoc status 51 means…

Interview questions

1. IDoc processing floods the system at month-end. How do you handle it?

Answer it in your own words first, then compare.

2. An inbound invoice IDoc (INVOIC) is not posted. How do you trace the inbound processing chain?

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.