ABAP Developmentbeginner

User Exits Part 1: What SD User Exits Are and How They Work

Key takeaway

Understand classic SD user exits: FORM routines in SAP includes like MV45AFZZ, MV50AFZ1 and RV60AFZZ, why they need a one-time access key, which global data they see, how they differ from customer exits (CMOD), and the basic rules for writing code in them.

What this complete series covers

Learn User Exits in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for: Best for SAP consultants, developers, and learners who want a practical understanding of User Exits.
Prerequisites: Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome: By the end, you should be able to explain User Exits clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.

Part 1: User Exits Part 1: What SD User Exits Are and How They Work
Understand classic SD/MM user exits as enhancement hooks inside standard processing, and use them safely by respecting transaction timing, internal buffers, performance and supported alternatives.
Part 2: User Exits Part 2: User Exits vs Customer Exits vs BAdIs — When to Migrate
Modernize classic user exits only when there is business or lifecycle value: first prove usage, extract the rule, test it, then move to a released BAdI or other supported extension
Part 3: User Exits Part 3: Finding User Exits in Real Transactions
Find the right classic user exit by tracing the exact transaction action, inspecting the active standard program and call stack, then confirming that the exit timing and available
Part 4: User Exits Part 4: MV45AFZZ — Sales Order Exits and Save Logic
Use MV45AFZZ sales-order save exits only for narrowly scoped, fast validation or derivation, working with current transaction buffers and avoiding database rereads, commits and unc
Part 5: User Exits Part 5: MV50AFZ1 — Delivery User Exit Patterns
Use MV50AFZ1 delivery exits with strict process guards and awareness of delivery buffers, background creation and item relevance so custom validation does not block unrelated delivery scenarios.
Part 6: User Exits Part 6: RV60AFZZ — Billing User Exit Patterns
Use classic billing exits such as RV60AFZZ narrowly and safely, with strict billing-type guards, no transaction control, regression coverage for invoices, credits, cancellations and background billing.
Part 7: User Exits Part 7: Safe Coding Rules Inside User Exits
Keep user-exit code production-safe with explicit activation guards, small deterministic logic, service-class delegation, no commits, no uncontrolled remote calls and a documented
Part 8: User Exits Part 8: Performance Risks in User Exits
Protect transaction performance by keeping user exits free of repeated SQL, remote calls and expensive logic, preloading shared data once and measuring with realistic high-volume documents.

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ SD user exits are empty FORM routines (USEREXIT_…) in SAP includes reserved for customer code, e.g. MV45AFZZ for sales orders.
✅ They run inside SAP's program and see its global data: VBAK, VBAP, XVBAP, YVBAP, VBKD, XVBPA …
✅ Technically they are modifications of SAP includes (access key needed once), but SAP designed them for customers.
⚠️ Because they see all global data, one wrong assignment can corrupt a document — change only what the exit is meant for.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

Part 1 — what SD user exits are (this lesson)
Part 2 — user exits vs customer exits vs BAdIs and when to migrate
Part 3 — finding user exits in real transactions
Part 4 — MV45AFZZ sales order exits
Part 5 — MV50AFZ1 delivery exits
Part 6 — RV60AFZZ billing exits
Part 7 — safe coding rules
Part 8 — performance risks

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHERE THEY ARE

Sales order (SAPMV45A): MV45AFZZ, MV45AFZB, MV45AFZA, MV45ATZZ/MV45ATZ1 (data declarations).
Delivery (SAPMV50A): MV50AFZ1, MV50AFZZ.
Billing (SAPLV60A): RV60AFZZ, RV60AFZC.
Pricing: RV61AFZA/RV61AFZB (pricing exits), routines in VOFM.
Copy control/data transfer routines (VOFM) — related, but configured per copy rule.

━━━━━━━━━━━━━━━━━━━━
▶ 2. HOW THEY ARE CALLED
SAP's program contains PERFORM userexit_save_document_prepare. at a defined point. The FORM exists empty in the include; you add code between FORM and ENDFORM.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ACCESS KEY
Changing MV45AFZZ requires an object key from SAP (SSCR) once per object and system. Afterwards changes are recorded as modifications, but SPAU usually shows no conflict because SAP doesn't change the content of these FORMs.

━━━━━━━━━━━━━━━━━━━━
▶ 4. GLOBAL DATA

Header: VBAK (current header), *VBAK (old values in change mode).
Items: XVBAP (all items with UPDKZ flag: I insert, U update, D delete), YVBAP (before image), VBAP (current item in item-level exits).
Partner: XVBPA; business data: VBKD/XVBKD; schedule lines: XVBEP.
Transaction type: T180-TRTYP (H create, V change, A display).

━━━━━━━━━━━━━━━━━━━━
▶ 5. USER EXIT VS CUSTOMER EXIT
Customer exits (SMOD/CMOD) are function modules with defined parameters — you only see what is passed. User exits see everything — more power, more risk.

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

SE38: display MV45AFZZ and read the comment above each FORM.
Set a breakpoint in USEREXIT_SAVE_DOCUMENT_PREPARE (in a test system) and save an order in VA02.
Inspect VBAK, XVBAP (UPDKZ) and T180-TRTYP in the debugger.

✅ CHECKPOINT: you know what SD user exits are, where they live and what data they see.

Code example

ABAP Code

* ===== Include MV45AFZZ (sales order) - structure =====*---------------------------------------------------------------------**       FORM USEREXIT_SAVE_DOCUMENT_PREPARE                           **---------------------------------------------------------------------**       Called before the document is saved; checks and final changes **---------------------------------------------------------------------*FORM userexit_save_document_prepare.* Guard: only for our order type and not in display mode  CHECK t180-trtyp <> 'A'.  IF vbak-auart = 'ZOR'.    PERFORM zz_check_po_number.            " own FORM in a Z include (see below)  ENDIF.ENDFORM. *---------------------------------------------------------------------**       FORM USEREXIT_MOVE_FIELD_TO_VBAK                              **---------------------------------------------------------------------**       Fill header fields (incl. append fields ZZ...) during entry    **---------------------------------------------------------------------*FORM userexit_move_field_to_vbak.  IF vbak-zzcountry IS INITIAL.    vbak-zzcountry = kuagv-land1.          " copy sold-to country into custom append field  ENDIF.ENDFORM. * ===== Own logic kept in a customer include (e.g. ZMV45AFZZ_CHECKS) =====FORM zz_check_po_number.  DATA ls_item TYPE vbapvb.  IF vbak-bstnk IS INITIAL.    MESSAGE e001(zsd).                     " 'PO number required for ZOR'  ENDIF.* Example: loop over all items that are not deleted  LOOP AT xvbap INTO ls_item WHERE updkz <> 'D'.    " item-level checks here  ENDLOOP.ENDFORM. * ===== Useful global data =====* VBAK / *VBAK      header, old header (change mode)* XVBAP / YVBAP     items new / old, UPDKZ = I, U, D* XVBPA             partners         XVBKD business data   XVBEP schedule lines* T180-TRTYP        H = create, V = change, A = display

Real project scenario

A company needed a custom "sold-to country" field on the order header, filled automatically from the sold-to party. The team appended ZZCOUNTRY to VBAK, filled it in USEREXIT_MOVE_FIELD_TO_VBAK and added it to the screen via the customer subscreen.
In the first version, the developer used VBAP in a header exit, where it only contained the last processed item. Switching to XVBAP loops fixed wrong results in multi-item orders — and became the team's first user-exit rule.

Common mistakes

Using VBAP in header-level exits (only the current/last item).
Ignoring UPDKZ = 'D' (deleted items) in XVBAP.
Running checks in display mode.
Writing large logic directly in the SAP include.
Changing fields the exit is not intended for.

Best practices

Read the SAP comment above each FORM.
Keep FORMs thin; put logic in Z includes or classes.
Guard by document type and transaction type.
Use X/Y tables correctly and respect UPDKZ.
Document every exit use in a register.

Interview angle

Questions: "What is a user exit?", "Name SD user exit includes.", "Difference between user exit and customer exit?"
Strong answer: FORM routines in SAP includes reserved for customers (MV45AFZZ, MV50AFZ1, RV60AFZZ), called via PERFORM; need an access key once; see all global data (VBAK, XVBAP/YVBAP with UPDKZ, XVBPA, T180-TRTYP); customer exits are function modules with parameters activated via CMOD; user exits are powerful but risky.

Practice this lesson

Quick check

1. In a header-level sales order exit, which table contains ALL items of the document?

2. User exits live in:

3. Which include is commonly used for sales order user exits?

Interview questions

1. Are user exits considered modifications?

Answer it in your own words first, then compare.

2. A header-level check in a sales order user exit read VBAP and gave wrong results for orders with several items. Why, and what should it use?