ABAP Developmentadvanced

IDoc Part 7: Outbound Triggering — Output Control and Change Pointers

Key takeaway

Trigger outbound IDocs automatically: output types with medium EDI/ALE (NACE, e. g. BA00 order confirmation, RD00 invoice), process codes like SD10/SD09, change pointers for master data (BD50, BD52, BD61, BD21), and custom outbound FMs with MASTER IDOC DISTRIBUTE.

Explanation

📌 KEY POINTS
✅ Transactional documents (orders, deliveries, invoices) send IDocs via output control: output type with medium 6 (EDI) or A (ALE) → partner profile message control → process code (e.g. SD10 order confirmation ORDRSP, SD09 invoice INVOIC).
✅ Master data (materials, customers) sends IDocs via change pointers: changes are recorded, then program RBDMIDOC (BD21) creates IDocs for changed objects.
✅ Custom outbound IDocs use MASTER_IDOC_DISTRIBUTE, then COMMIT WORK.
⚠️ If output determination or change pointers are not active, nothing is sent and no error appears — check NAST/output log and BDCP2 first.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 4 described outbound processing. This lesson explains what triggers it.

━━━━━━━━━━━━━━━━━━━━
▶ 1. OUTPUT CONTROL (SD/MM)

Output type (NACE, e.g. BA00 order confirmation, LAVA dispatch advice, RD00 invoice, NEU for purchase orders) with condition records (VV11, VV31, VV21 / MN04).
Medium 6 (EDI) and partner function.
Partner profile outbound: message type + message control tab (application V1/V2/V3/EF, output type, process code).
When the document is saved, output is determined (NAST), processed (RSNAST00 or immediately), and the process code FM (e.g. IDOC_OUTPUT_ORDRSP) builds the IDoc.
Output log in the document (Extras → Output) shows success or error.
S/4HANA: many documents use Output Management (BRF+); EDI output still works through output parameters.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CHANGE POINTERS (MASTER DATA)

BD61: activate change pointers globally.
BD50: activate per message type (e.g. MATMAS, DEBMAS).
BD52: fields that create change pointers per message type.
Changes recorded in BDCP2; BD21 (RBDMIDOC) creates IDocs for pending pointers; schedule it as a job.
Distribution model (BD64) must include the message type and receiver.

━━━━━━━━━━━━━━━━━━━━
▶ 3. CUSTOM OUTBOUND

Own program or BAdI/exit after save → MASTER_IDOC_DISTRIBUTE with control and data records → COMMIT WORK.
Or own process code for output control with an FM following the outbound interface (OBJECT (NAST), CONTROL_RECORD_IN/OUT, INT_EDIDD).

━━━━━━━━━━━━━━━━━━━━
▶ 4. REDUCED MESSAGE TYPES
BD53 creates reduced message types (e.g. ZMATMAS) sending only selected segments/fields.

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

VA02: open an order → Extras → Output → Header → check BA00 with medium 6.
WE20: check the message control tab for the customer.
BD50: check change pointers for MATMAS; change a material and run BD21 in a test system.

✅ CHECKPOINT: you know how outbound IDocs are triggered for transactional and master data.

Code example

ABAP Code

* ===== Master data: change pointers =====* BD61 : activate change pointers generally* BD50 : activate for message type MATMAS* BD52 : relevant fields (e.g. MARA-MATKL, MAKT-MAKTX)* BD64 : distribution model sender -> receiver for MATMAS* BD21 : program RBDMIDOC, variant message type MATMAS, scheduled every 15 minutes * ===== Checking pending change pointers (table BDCP2) =====REPORT zidoc_changepointers. PARAMETERS p_mestyp TYPE edi_mestyp DEFAULT 'MATMAS'. DATA lv_count TYPE i. START-OF-SELECTION.  SELECT COUNT(*) FROM bdcp2 INTO lv_count    WHERE mestype = p_mestyp      AND process = space.                  " not yet processed by BD21  WRITE: / 'Pending change pointers for', p_mestyp, ':', lv_count. * ===== Transactional data: output control =====* NACE : application V1 (sales) -> output type BA00 -> medium 6 (EDI)* VV11 : condition record for BA00, customer, medium 6, dispatch time 4 (immediately)* WE20 : partner KU/<customer>, outbound ORDRSP, message control:*        application V1, output type BA00, process code SD10* On save: NAST entry -> process code SD10 -> IDOC_OUTPUT_ORDRSP -> IDoc ORDRSP * ===== Custom trigger (e.g. after save in own program) =====*  CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' ...   (see Part 4)*  COMMIT WORK.

Real project scenario

A new customer did not receive order confirmations by EDI. The order output log showed no BA00 output at all: the condition record VV11 existed only for print medium 1.
After adding a condition record with medium 6 and the message control entry in WE20, confirmations were sent. For material master distribution, the team found BD21 wasn't scheduled in the new system; pending changes in BDCP2 were processed after scheduling it.

Common mistakes

Missing condition record for medium 6.
Message control tab in WE20 missing or wrong process code.
Change pointers active globally but not per message type (BD50).
BD21 not scheduled.
No COMMIT after MASTER_IDOC_DISTRIBUTE.

Best practices

Check document output log first.
Document output types and process codes per partner.
Activate change pointers per message type and fields.
Schedule BD21 and monitor BDCP2.
Use reduced message types to limit data.

Interview angle

Questions: "How is an ORDRSP IDoc triggered?", "How does master data distribution with change pointers work?"
Strong answer: output type (e.g. BA00) medium 6 with condition record, WE20 message control with process code SD10 → IDOC_OUTPUT_ORDRSP; master data via change pointers BD61/BD50/BD52, BDCP2, BD21 (RBDMIDOC) plus BD64 model; custom via MASTER_IDOC_DISTRIBUTE + COMMIT; reduced message types BD53.

Practice this lesson

Quick check

1. Which job creates MATMAS IDocs from pending change pointers?

2. Sales order confirmations should go out by EDI (ORDRSP). Which setting links output type BA00 to the IDoc process?

3. Change pointers are activated for a message type in:

Interview questions

1. Material master changes stopped reaching a warehouse system, while BD10 manual sends work. What do you check?

Answer it in your own words first, then compare.

2. IDoc integration is replaced with OData/RAP. Migration plan?

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.