ALE & IDocs Masterclass: ORDRSP, ORDERS, DESADV, Partner Profiles & Custom Processing – Hands-On Tutorial | Part 42 | FreeLearning365

 

ALE & IDocs – ORDRSP, ORDERS, DESADV & Partner Profiles: A 25,000+ Word Hands-On Masterclass

Day 12 of the S/4HANA ABAP Development & Fiori Track

By @FreeLearning365 and Tech Partner @techbook24

Introduction: The Supplier Who Needed SAP‑to‑SAP Automation

TechBook24’s largest supplier, GlobalParts Ltd., runs SAP ECC 6.0. Every purchase order was being emailed as a PDF, manually entered into the supplier’s system, and confirmed days later via fax. This manual chain caused ordering delays, wrong deliveries, and a backlog of unconfirmed POs. Mr. Keller demanded automation: “Send our purchase orders directly into their SAP system. And when they confirm or ship, our system must update automatically.”

The answer is ALE (Application Link Enabling) and IDocs (Intermediate Documents). IDocs are the standard SAP format for electronic document exchange, both within SAP landscapes and with external partners. They carry structured data like purchase orders, invoices, shipping notifications, and more. With ALE, you control the routing: logical systems, distribution models, and partner profiles ensure that the right document reaches the right place at the right time.

In this tutorial, Arjun builds the entire B2B integration. He configures TechBook24’s S/4HANA to send an outbound ORDERS IDoc when a PO is released, sets up the inbound processing on the supplier side (simulated on the same system), and even processes incoming ORDRSP (order response) and DESADV (despatch advice) IDocs to update the PO and inbound delivery automatically. He extends a standard IDoc type with a custom Z segment for a vendor material number, writes the ABAP code for custom inbound processing, and monitors the whole flow with WE02 and BD87. By the end, you’ll be able to set up any IDoc interface from scratch. Let’s integrate.

1. ALE & IDoc Fundamentals – The Architecture

1.1 What Is an IDoc?

An IDoc (Intermediate Document) is a container for data exchange. It consists of three parts:

• Control Record (EDIDC): meta‑data — direction, message type, sender/receiver, IDoc number, status.
• Data Records (EDID4): the actual data, organized in segments (e.g., E1EDK01 for header, E1EDP01 for item). Each segment has a sequence number and hierarchy level.
• Status Records (EDIDS): history of status changes (created, dispatched, processed, error).

IDocs are independent of the technical transmission method; they can be sent via tRFC, file, or XML.

1.2 ALE – The Routing Layer

ALE provides the infrastructure to distribute IDocs across systems. Core building blocks:

• Logical System: a symbolic name for a client in a system (e.g., T24CLNT200). Used in partner profiles to identify sender/receiver.
• Distribution Model (BD64): defines which message types are exchanged between which logical systems.
• Partner Profile (WE20): the technical binding: for a given partner, specifies the message types, the function module to process inbound IDocs, the output mode, etc.
• Port (WE21): defines the communication channel (tRFC, file, etc.).

Arjun will configure all of these for the ORDERS message type.

2. Scenario Setup – TechBook24 to GlobalParts Ltd.

He defines two logical systems in transaction SALE (or BD54):

• T24CLNT200 – TechBook24 S/4HANA, client 200.
• GPCNT300 – GlobalParts ECC, client 300 (simulated in the same system).

Screenshot Description: SALE screen for Logical Systems, with the two entries.

He then assigns the logical system to the current client in SCC4: client 200 → logical system T24CLNT200.

3. Outbound IDoc: Purchase Order (ORDERS) – Step‑by‑Step Configuration

3.1 Message Type ORDERS and IDoc Type ORDERS01

The standard for purchase order output is message type ORDERS with IDoc basic type ORDERS01 (or ORDERS02 in newer versions). Arjun will use ORDERS01. The output determination in the purchase order (NACE) triggers the creation. He needs to ensure that output type NEU (for EDI) is configured for electronic transmission.

3.2 Partner Profile for Outbound (WE20)

Transaction: WE20 → Partner Type “LS” (Logical System) → Create. Partner number GPCNT300.

• Under “Outbound Parameters”, add message type ORDERS.
• Receiver port: A000000001 (tRFC port, see below).
• Output mode: “Transfer IDoc immediately”.
• Basic type: ORDERS01.
• Application log: optional.

He also adds the DESADV and ORDRSP for inbound later.

Screenshot Description: WE20 outbound parameters screen for message type ORDERS.

3.3 Port Configuration (WE21)

For ALE, the standard port is a transactional RFC port. WE21 → “Transactional RFC” → Create port A000000001. This port will be used to send IDocs via tRFC to the receiving system. Actually, for outbound, the port is assigned in the partner profile; the system uses the destination from the port definition. Arjun creates the port and specifies the RFC destination (already defined in SM59) for GlobalParts.

3.4 Distribution Model (BD64)

BD64 → Create model view ZPO_TO_GLOBAL. Add BAPI? Actually, you add message types: select message type ORDERS, sender T24CLNT200, receiver GPCNT300. Then distribute the model (menu “Edit → Model view → Distribute”). This generates the necessary partner profiles automatically, but Arjun already created them manually; he distributes to verify consistency.

3.5 Testing the Outbound IDoc Generation

He creates a purchase order in ME21N with vendor 1000 (which should trigger output NEU). In the PO, under “Messages”, the output type NEU is automatically determined. He saves the PO. Then he checks transaction WE02 → IDoc list. He sees a new IDoc with message type ORDERS, direction 2 (outbound), and status 30 (IDoc ready for dispatch). He double‑clicks to view the segments: the control record shows the partner numbers; the data records contain the PO header (E1EDK01) and items (E1EDP01). The data is complete.

Screenshot Description: WE02 display of an ORDERS IDoc, highlighting the segment tree and data content.

If the port and RFC destination are configured correctly, the IDoc status moves to 12 (Dispatch OK) after processing. Arjun simulates the receiver not being reachable to demonstrate error status 29 (Error in ALE service). He then uses BD87 to reprocess.

4. Inbound IDoc Processing – Order Response (ORDRSP)

4.1 The Requirement

GlobalParts confirms the PO by sending back an ORDRSP IDoc (e.g., confirming delivery date). TechBook24 must process this IDoc to update the purchase order confirmation in SAP. Arjun will create an inbound function module and assign it in the partner profile.

4.2 Creating a Custom Inbound Function Module

The standard inbound function for ORDRSP is IDOC_INPUT_ORDRSP, but Arjun wants to add custom validation. He creates a new function module Z_IDOC_INPUT_ORDRSP that calls the standard one and then performs additional updates. The function module interface must follow the standard: importing INPUT_METHOD, MASS_PROCESSING, tables IDOC_CONTRL, IDOC_DATA, IDOC_STATUS, etc.

He copies the structure from the standard and adds a call to BAPI_PO_CHANGE to update the confirmation date. The code (simplified):

FUNCTION Z_IDOC_INPUT_ORDRSP.
*"----------------------------------------------------------------------
  DATA: lt_edidd TYPE TABLE OF edidd,
        ls_edidd TYPE edidd,
        lv_ebeln TYPE ekko-ebeln,
        lv_conf_date TYPE ekpo-eindt,
        lt_return TYPE TABLE OF bapiret2,
        ls_header TYPE bapimepoheader,
        ls_headerx TYPE bapimepoheaderx,
        lt_items TYPE TABLE OF bapimepoitem,
        lt_itemsx TYPE TABLE OF bapimepoitemx.

  LOOP AT idoc_data INTO ls_edidd WHERE segnam = 'E1EDK01'.
    " get PO number from segment E1EDK01 field EBELN
    lv_ebeln = ls_edidd-sdata+0(10). " offset depends on structure
  ENDLOOP.
  LOOP AT idoc_data INTO ls_edidd WHERE segnam = 'E1EDP01'.
    " read item confirmation date from field EINDT
    " ... update confirmation
  ENDLOOP.

  " Call standard processing first
  CALL FUNCTION 'IDOC_INPUT_ORDRSP'
    EXPORTING
      input_method  = input_method
      mass_processing = mass_processing
    TABLES
      idoc_contrl   = idoc_contrl
      idoc_data     = idoc_data
      idoc_status   = idoc_status
    EXCEPTIONS
      OTHERS        = 1.

  " After standard success, update PO with confirmation
  IF sy-subrc = 0.
    ls_header-po_number = lv_ebeln.
    ls_headerx-po_number = 'X'.
    " fill itemx and items with new confirmation date
    CALL FUNCTION 'BAPI_PO_CHANGE'
      EXPORTING
        purchaseorder = ls_header
        purchaseorderx = ls_headerx
      TABLES
        return = lt_return
        purchaseitem = lt_items
        purchaseitemx = lt_itemsx.
    IF line_exists( lt_return[ type = 'E' ] ).
      " add error status to idoc_status
    ENDIF.
  ENDIF.
ENDFUNCTION.

He activates the function. Then in WE20, for the inbound parameters of partner GPCNT300, he adds message type ORDRSP, process code ZORDR (he will create a process code in WE42 linking to his function). Process code configuration: WE42 → inbound process code ZORDR → function module Z_IDOC_INPUT_ORDRSP. He selects it in the partner profile.

4.3 Testing the Inbound ORDRSP

He creates a test IDoc manually in WE19 using an existing ORDRSP IDoc or by generating from an outbound IDoc with swapped control. He sets direction to inbound and processes via BD20 (or standard background job). The status changes to 53 (application document posted) if successful. He verifies the PO confirmation date is updated in ME23N.

Screenshot Description: WE02 showing an inbound ORDRSP IDoc with status 53, and ME23N showing the updated confirmation date.

5. Despatch Advice (DESADV) – Inbound Processing for Inbound Delivery

5.1 The Message Type DESADV

When GlobalParts ships the goods, they send a DESADV IDoc. TechBook24 wants to create an inbound delivery automatically. Standard processing uses function module IDOC_INPUT_DESADV1 which creates the inbound delivery if the necessary master data is present.

Arjun configures the partner profile for inbound DESADV, links to the standard process code. He tests with a sample IDoc (from WE19). He then monitors with VL33N (display inbound delivery) to confirm creation.

6. Extending IDocs – Adding a Z Segment for Vendor Material

6.1 Why Extend?

The business requires that the purchase order IDoc carries not only the TechBook24 material number but also the supplier’s material number (field IDNLF in EKPO, but it’s not part of the standard ORDERS01 segments). Arjun extends the IDoc type to include this field in a custom segment.

Step 1: Create a new segment type Z1EDP01 in WE31. It contains field IDNLF (char 35). Activate.

Step 2: Extend the basic type ORDERS01 in WE30. Add segment Z1EDP01 as a child of E1EDP01, with occurrence 0..1. Activate the extended IDoc type.

Step 3: Populate the segment during outbound. The standard output program RSNAST00 calls the processing program RVEDI001 for ORDERS. To fill the custom segment, Arjun uses a user exit. He implements EXIT_SAPLVEDI_001 (or BAdI for IDoc enhancement). In the include ZXEDIU01, he adds:

IF segment_name = 'E1EDP01'.
  READ TABLE int_edidd INTO custom_segment WITH KEY segnam = 'Z1EDP01'.
  custom_segment-sdata = lv_idnlf.
  APPEND custom_segment TO int_edidd.
ENDIF.

He tests by generating a new outbound IDoc; it now contains the Z segment with the vendor material number.

Screenshot Description: WE02 outbound IDoc showing the Z1EDP01 segment with the vendor material.

7. IDoc Monitoring and Troubleshooting

7.1 Essential Transactions

• WE02: IDoc list and display. Use dynamic selection to filter by partner, status, date. Double‑click to see segment data.
• WE05: IDoc statistics (by status, partner).
• BD87: Reprocess IDocs (status 51 or errors).
• SM58: tRFC errors for IDoc transmission.
• WE19: Manual IDoc creation and test tool.
• WE09: IDoc search by content.

Arjun shows common status codes:

• 30: IDoc ready for dispatch (outbound) or waiting to be processed (inbound).
• 12: Dispatch OK (outbound sent).
• 53: Application document posted successfully (inbound).
• 51: Error during application processing (e.g., missing data).
• 29: Error in ALE service (tRFC failure).

He demonstrates a status 51 scenario: inbound DESADV with a missing material master. The status record contains the error message. He fixes the master data, then reprocesses in BD87. The IDoc goes green.

7.2 Debugging Inbound IDoc Processing

He sets an external breakpoint in his function module Z_IDOC_INPUT_ORDRSP for the background user (which processes IDocs). In WE19, he triggers processing; the debugger pops up. He can step through the segment reading and BAPI call. This is the most effective way to troubleshoot mapping errors.

8. Complete Hands-On Lab – Building the Entire B2B IDoc Chain

Arjun now documents a full lab that can be executed in a sandpit:

1. Define logical systems T24CLNT200 and GPCNT300 in BD54.
2. Create RFC destination GLOBALPARTS in SM59 (pointing to the same system for testing).
3. Create tRFC port A000000001 in WE21 with that destination.
4. Configure outbound partner profile in WE20 for LS GPCNT300 with message type ORDERS, port A000000001, output mode immediate.
5. Configure output type NEU for purchase orders (NACE) if not already, ensuring it triggers output determination.
6. Create a purchase order; verify IDoc is generated (WE02) with status 30.
7. Manually create an inbound ORDRSP IDoc using WE19 (based on the outbound IDoc structure, with adjusted direction and some confirmation data).
8. Implement custom inbound function module Z_IDOC_INPUT_ORDRSP (code as earlier), create process code ZORDR in WE42, assign in WE20 inbound parameters.
9. Process the inbound IDoc (via BD20 or background job); verify PO confirmation update in ME23N.
10. Extend IDoc with Z segment, modify user exit, generate new outbound IDoc, verify segment presence.
11. Monitor all IDocs in WE02 and BD87; document status transitions.

Each step includes screenshot descriptions, expected results, and troubleshooting notes.

9. Pros, Cons, and Alternatives to IDoc Integration

IDocs (ALE)	Pros	Cons
Robust, transactional (tRFC guarantees delivery)	Guaranteed once‑only delivery, mature, standard for EDI	Complex configuration, asynchronous by nature (not for real‑time request‑reply)
OData / REST	Real‑time, lightweight, modern	Requires network stability, no built‑in retry (must be implemented)
RFC / BAPI	Synchronous, direct function call	Tight coupling, no standard monitoring, harder to handle large data

Arjun recommends: use IDocs for B2B and EDI, OData for Fiori and external portals, RFC for internal real‑time where guaranteed delivery is not a concern. Often, IDocs are the translation layer between different ERP versions.

10. Best Practices and Common Pitfalls

• Always create a new process code for custom inbound functions rather than modifying standard ones.
• Use WE19 for testing – never transport untested processing code.
• Regularly archive processed IDocs to keep WE02 performance good.
• Handle IDoc status codes 51 quickly; set up alerts (via ABAP report) for stuck IDocs.
• In outbound extensions, use user exits or BAdIs, never modify standard include code directly.
• Test with real partner connectivity early – network and authorizations often cause status 29.

11. Conclusion – The Inter‑System Backbone Is Yours

Arjun has successfully automated the entire purchase‑to‑confirmation cycle with GlobalParts. The IDocs flow seamlessly, PO confirmations appear automatically, and the procurement team no longer chases suppliers by email. He has mastered the ALE/IDoc stack and can now integrate any SAP system with confidence. The knowledge you’ve gained — from logical systems and partner profiles to custom segments and inbound processing — puts you in the elite league of integration developers.

Tomorrow, in Part 43, we’ll explore SAP Business Workflow – task definitions, agents, deadlines, and linking to the purchase order approval process. You’ll build a workflow that automatically routes POs to managers based on value, using the very IDoc and RFC skills you’ve acquired. The journey toward a fully automated enterprise continues.

Keep integrating, keep automating.

End of Part 42 – ALE & IDocs Deep Dive. Brought to you by @FreeLearning365 and tech partner @techbook24.