SAP BAdI and Enhancement Interview Questions

Classical customer enhancements are predefined extension options delivered by SAP, such as function exits, screen exits and menu exits, grouped in enhancements that can be displayed in SMOD and implemented through a CMOD project. They keep customer code outside the SAP standard object, usually in customer includes generated for the enhancement component. The modern Enhancement Framework adds enhancement spots, BAdIs, explicit enhancement points/sections and implicit enhancement options, and is generally more flexible and better suited to new development. In an ECC system, SMOD/CMOD may still be the correct choice when SAP's standard application explicitly provides a classical customer exit and no released BAdI offers the required context. The choice must be based on the enhancement options actually available in that release, not on familiarity. For new S/4HANA development, prefer released BAdIs, released APIs and clean-core compliant extension points wherever possible. Do not modify SAP standard code merely because a classical exit is unavailable.

I would go through the standard decision order. First, check whether customizing covers it (e.g. incompletion procedure — making BSTNK an incompletion field for ZOR may solve it without code). If code is needed, use the SAP-intended place: for sales orders at save, USEREXIT_SAVE_DOCUMENT_PREPARE in MV45AFZZ, or a released/available BAdI in S/4HANA. Implicit enhancements are the last option before a modification because they depend on SAP internals. I would also check whether the validation must run for BAPI and IDoc order creation (the user exit runs there too, but messages must not be popups). The code stays thin and calls a validation class; the choice and alternatives are documented.

SMOD is used to display and research SAP-delivered classical enhancements and their components. CMOD is used to create a customer project, assign one or more enhancement definitions, implement the available components and activate the project. A typical workflow is: identify the business transaction and underlying program/package; search for an appropriate enhancement in SMOD or the Repository Information System; review its documentation and function/screen/menu components; create a Z-named CMOD project; assign the enhancement; open the component and implement the customer include or subscreen/menu function generated by SAP; activate the include and project; then test the exact business scenario. Function exits use SAP-delivered EXIT_* function modules whose source typically delegates to a customer include such as ZX*. The developer implements the customer include; the signature of the SAP function module must not be changed.

I would use classic BAdI ME_PROCESS_PO_CUST, which SAP provides for Enjoy purchase order processing. In SE18 I check its methods and that it is multiple-use, in SE19 I review existing implementations, then create my own implementation (ZIM_PO_CHECK) with class ZCL_IM_PO_CHECK. In method CHECK I read the header via im_header->get_data( ), and if BSART = 'ZNB' and EKGRP is initial, I issue an error through the MM message macros (INCLUDE mm_messages_mac, mmpur_message_forced) and set ch_failed = abap_true to prevent saving. The rule itself sits in a small class for reuse and unit tests. I test ME21N/ME22N and PO creation via BAPI_PO_CREATE1, which also runs the BAdI.

Field exits are an older, data-element-based enhancement mechanism that can run custom logic when a screen field based on a particular data element is processed. They were historically used for simple field-level checks or conversions, but they are obsolete or deactivated in many modern SAP landscapes and are not recommended for new development. Their scope and behavior can be difficult to predict because the same data element may be used on many screens, creating unintended side effects and performance risk. They also lack the explicit business context available in BAdIs, customer exits or application-specific validation frameworks. For a new requirement, use an application-specific released BAdI, validation framework, screen enhancement or other supported enhancement point. Discuss field exits in interviews as a legacy mechanism and explain their limitations.

A user exit is usually a FORM routine placed by SAP in a customer include such as MV45AFZZ, where customer code can be added at a predefined point. A classical customer exit is an SMOD/CMOD enhancement component, often represented by an SAP-delivered EXIT_* function module, screen area or menu function that delegates to customer-owned objects. Neither category has a universal execution priority. The actual order is determined solely by the call positions in the standard SAP program flow. For a sales-order save requirement, first determine whether the need is validation, field transfer or post-processing. Then inspect the standard call sequence and available exits/BAdIs in the system release. Use an exit that has the complete document state and officially supports rejecting or influencing the save. Do not assume that USEREXIT_MOVE_FIELD_TO_VBAP is appropriate for final document validation; it is intended mainly for transferring or deriving item fields.

Explanation: Directly modifying database tables in exit functions is dangerous because: 1) Updates bypass normal business logic and validations, 2) Creates data consistency issues, 3) Defeats audit trail and change logs, 4) Interferes with standard SAP processing logic. Root Cause: Exit functions run synchronously within transaction context; direct table updates create implicit transactions and can lock resources. Correct Approach: Instead of direct VBAK modification, use parameters and tables provided in exit interface (HEADER, ITEM tables in memory) to modify data before standard code saves. These in-memory changes are captured in normal save operation with full audit trail. Real Project Example: Sales order enhancement attempted VBAK update directly. Caused data inconsistencies where order appeared to have different values in report vs transaction, and change log showed nothing. Corrected approach: Modified data in function module parameters (VBAK table parameter), allowing standard save to persist changes with proper audit trail. Best Practice: Never directly update database tables in exit code; use only memory structures provided by exit interface; let standard SAP code handle database operations. Common Mistakes: Assuming direct table updates will sync properly; not understanding memory vs database distinction; missing side effects of bypassing standard logic. Interview Tips: Explain exit interface design philosophy; mention audit trail issues; provide sales order example; discuss data consistency risks.

Use more than one discovery technique because user exits and customer exits are stored differently. For classical customer exits, search SMOD by enhancement name, package or description, or use the Repository Information System in SE84. Review each enhancement's documentation and components, then inspect the EXIT_* function module interface and where-used list. For FORM-based user exits such as routines in MV45AFZZ, inspect the main program and customer includes, search for USEREXIT_* routines, use package/source search and debug the transaction to confirm the real call path. Do not claim that USEREXIT_SAVE_DOCUMENT is an SMOD component merely because it is an exit. Finally, compare available BAdIs using SE18/SE19 and enhancement searches, because the best supported option may not be classical.

Includes such as MV45AFZZ and RV60AFZZ are SAP-provided customer includes containing FORM-based user exits for specific application programs, for example sales-order or billing processing. Customer code is added only inside the designated user-exit routines. They are not CMOD projects and they do not automatically represent function-module exits. CMOD customer exits are separate enhancement definitions managed through SMOD/CMOD and may use EXIT_* function modules, screen exits or menu exits. The two mechanisms can exist in the same application, but their execution order depends on where each call is placed in the standard source. Before coding, inspect the actual include and call sequence in the target release, confirm the purpose of the selected FORM exit and avoid placing unrelated business logic in a convenient but incorrectly timed routine.

Begin with CMOD and verify the project, assigned enhancement and generated customer include are active. Inspect the enhancement documentation and the standard call location. Set a breakpoint in the actual customer include or EXIT_* function module, then reproduce the exact transaction, user and data path. If the breakpoint does not trigger, work backward through the standard conditions and compare active versions, switches, customizing and authorizations. If it triggers but produces the wrong result, inspect import/changing parameters, document buffers and subsequent logic that may overwrite the value; a watchpoint can help identify later changes. Use SAT/ST12 for runtime flow and ST05 only when SQL performance or returned data is relevant. Do not infer execution by looking for MODACT table access in ST05, and avoid adding database logging inside frequently executed exits merely for basic debugging.

A CMOD solution can involve several transportable objects: the CMOD project/assignment, generated customer includes or subscreens, message classes, classes, DDIC objects and configuration used by the implementation. Assign changes to transport requests as prompted, then inspect the object lists in SE09/SE10 and document the required import sequence. Do not modify or transport the SAP-delivered EXIT_* function module as if it were a customer implementation; customer code normally resides in the generated customer include. Keep tightly coupled objects in coordinated requests, release dependencies in the correct order, import to QA, activate and execute regression tests before production. After import, verify active versions and project activation rather than assuming the transport log alone proves runtime readiness.

For a final, document-level validation before a sales order is saved, use the save-stage exit that is documented for validation in the target release, commonly USEREXIT_SAVE_DOCUMENT_PREPARE or another supported BAdI/exit depending on the requirement and system version. USEREXIT_MOVE_FIELD_TO_VBAP is intended mainly to move or derive customer-specific item data into VBAP during item processing. It may run multiple times and before the complete document state is available, so it is not the preferred location for cross-item or final save validation. The correct choice must be confirmed by inspecting the standard call sequence and available data. Keep validation free of direct database updates, issue messages only as supported by the transaction flow, and test create/change, copy, background, BAPI and IDoc scenarios where relevant.

A screen exit allows a customer subscreen to be embedded in a screen area predefined by SAP. The customer creates the subscreen and implements the data transfer logic defined by the enhancement. It is suitable for adding customer-specific fields to a standard transaction when SAP has delivered an appropriate subscreen area. It is not a generic mechanism for arbitrarily changing every standard screen element. A menu exit allows customer functions to be added to a GUI status at predefined points; the customer handles the function code in the associated enhancement logic. A valid screen-exit use case is adding approved Z-fields to a standard master-data transaction. A valid menu-exit use case is adding a 'Display External Reference' action to a standard application menu. Both require the corresponding SAP-delivered enhancement component and should be tested for authorizations, usability and upgrades.

A function-module exit is an SAP-delivered function module, normally named EXIT_<program or function group>_<number>, called from standard application code at a defined point. Its interface exposes the data SAP permits the enhancement to read or change, and its source typically contains or calls a customer include where the implementation is written. The function module name alone does not reliably describe its business purpose or execution timing. Before implementing it, read the enhancement documentation in SMOD, inspect the function module interface in SE37, perform a where-used search to locate the standard call, review the surrounding source code and debug the transaction with representative data. Never change the SAP-delivered function module signature. Do not claim that a particular numbered exit is a header or item exit without verifying the enhancement documentation and call context in the target release.

A correct CMOD workflow is: identify the SAP-delivered enhancement in SMOD or the Repository Information System; review its documentation and components; create a Z-named project in CMOD; assign the enhancement definition to the project; open each required component; implement the generated customer include, customer subscreen or menu function; activate all implementation objects; activate the CMOD project; assign the objects to transport requests; and test the exact business process. Function exits are not normally implemented by changing an 'Interface tab'; their SAP interface is fixed, and customer code is written in the generated customer include. A project can contain one or more enhancement definitions, subject to SAP's activation rules. Before transport, verify the object list and dependencies in SE09/SE10 and repeat testing in QA.

Implicit enhancements depend on SAP's internal code at that position — after a support package the variables or the sequence around them may have changed, so the enhancement now works on different data or at a different moment. I would compare the old and new SAP code (version management / SPAU_ENH), debug a failing order and see what the enhancement reads and changes. The fix: move the logic to the explicit enhancement point (designed by SAP for extensions, more stable context) or, better, to the intended pricing mechanism (condition technique, pricing routines in VOFM, or a pricing BAdI). Then add regression tests for the pricing scenarios and document the change.

I would open the include in Enhance mode, create an enhancement implementation for that ENHANCEMENT-POINT in my Z package with a transport, and write a small plug-in: guard conditions (sales org, condition type or customer group), then a call to a class method that performs the adjustment on the available structures. Watch-outs: other implementations of the same point may exist and all run in undefined order, so I check them first and avoid depending on them; declarations needed across plug-ins go into a STATIC point; no COMMIT or dialogs; and I test all pricing paths (order entry, copy control, repricing, billing). I would also confirm that pricing configuration (condition types/routines) cannot do the same without code.

A delivery block can come from several sources: customizing (e.g. automatic blocks by order type or credit management), other BAdI implementations (multiple-use BAdIs can have several), explicit/implicit enhancement implementations, user exits or customer exits. I would check SE20/SE19 for all active implementations of the relevant spots, search for enhancement implementations in the related programs, and look at MV45AFZZ/MV50AFZ1. The most reliable method is debugging: a watchpoint on the block field (e.g. VBAK-LIFSK) shows exactly which code sets it, and the call stack shows whether it is SAP standard, an enhancement implementation or an exit. Once found, I document it and decide where the rule should live.

Pricing exits run per item and repeatedly (on every change, repricing, copy and billing). One SELECT per item multiplies into thousands or millions of reads in mass processing — slow order entry and long billing runs. It can also read inconsistent data if the customer data in the document differs from the database. The fix: first check whether the data is already in the pricing communication structures (KOMK/KOMP) or document tables — then no SELECT is needed. Otherwise buffer: a hashed table keyed by customer in a class, read once per customer. Add guard conditions so the code runs only for relevant condition types. Measure before/after with ST05 and SAT, and test billing runs with volume.

I would first define the moment: before save, with all items and batch splits determined. Then I debug VL02N with statement breakpoints on CALL CUSTOMER-FUNCTION, CALL BADI and GET BADI and on the user exits in MV50AFZ1, and press Save. At each stop I check which data is available — for delivery exits typically LIKP, XLIPS (items including batch split items) and related tables. USEREXIT_SAVE_DOCUMENT_PREPARE in MV50AFZ1 is a common candidate because the item table is complete at that point. I would also check whether the same exit runs for deliveries created by VL10 background jobs and by IDocs, and look for existing implementations. Then I implement the check thinly, calling a validation class.

A BAdI definition can be multiple-use with several active implementations, possibly in different enhancement implementations and packages; filters may activate different ones per org unit. Other spots, user exits or customizing may also set the block. So disabling one implementation is not proof. I would list all implementations of the BAdI and related spots in SE20/SE19 (including composite implementations), check their filters and active flags, and debug with a watchpoint on the block field to see which implementation sets it. Then I would consolidate the rule into one owned implementation and register it, so the next analysis is faster.

I would keep one implementation of the rule and control its activation by configuration rather than by transports per rollout. Options: a Z customizing table with a feature flag per sales organization (read once and buffered), or a filter-dependent BAdI with filter VKORG where each wave adds implementations or filter values. The Switch Framework (own switches and business functions) is possible but heavy for this purpose and switches are system-wide, not per sales org. The flag check is the first statement in the enhancement, so non-activated sales orgs are not affected. Activation is a customizing transport per wave, tested in QA with those sales orgs; deactivation is equally simple if problems appear.

Classic BAdIs (SE18/SE19) are single-use or multiple-use, based on interfaces and filter values, and are called via CL_EXITHANDLER=>GET_INSTANCE. New BAdIs are part of Enhancement Spots, support context-based filters, are called with GET BADI / CALL BADI, offer better performance (no cross-client lookup at every call) and support fallback classes.

I would check whether the correct business process is being executed, whether the BAdI is called in that process, whether the implementation is active, whether filter values match, whether multiple implementations exist and whether the breakpoint is placed in the correct method.

When SAP migrates a classic BAdI to the Enhancement Framework, the calling code uses GET BADI/CALL BADI, and existing classic implementations are still executed through the migrated definition. New implementations are created via the enhancement spot. So both can be active and both run if the BAdI is multiple-use. I would check SE18 for the migration status, list implementations of both kinds in SE19, check filters and activation, and debug the call to see the actual sequence and data changes. If both implement related rules, I consolidate them into one implementation (preferably the new one) to avoid order dependency and duplicate messages.

I keep the BAdI method small, use guard conditions, delegate business logic to a service class, avoid heavy database logic, use configuration where required, handle messages consistently and document the purpose. This keeps the implementation easier to debug, test and support.

Released BAdIs are intentionally provided extension points and are generally more upgrade-safe than implicit source-code enhancements. In S/4HANA clean-core strategy, teams should prefer released extensibility options such as BAdIs, APIs, key-user extensibility, RAP/CDS extensions or side-by-side extensions before using risky source-code enhancements.

I would find the BAdI through SPRO documentation for the process, SE18/SE84 by package, or by debugging with breakpoints on GET BADI and CL_EXITHANDLER=>GET_INSTANCE. In SE18 I check whether it is filter-dependent (e.g. by BUKRS) and single or multiple use. If it is filter-dependent, I create one implementation per company-code group with the corresponding filter values in SE19 — no IF on company code in the code. If it has no filter, I create one implementation with a dispatcher that selects rules via a customizing table or company-specific classes. I activate, test each company code and verify activation in each system after transport.

Filter-dependent implementations only run for the filter values they list. The new sales org matched no implementation, so either nothing ran (multiple-use) or the fallback class ran with only default behaviour. This is a design gap, not a coding error. For a custom BAdI I would define a fallback class containing the group-wide default rule, and add specific implementations only for deviations. For go-lives, reviewing filter values of all filter-dependent BAdIs becomes a checklist item. If a single-use BAdI has no fallback and no match, GET BADI raises CX_BADI_NOT_IMPLEMENTED — the caller must handle it deliberately.

I would make the implementing class a thin adapter: map parameters to an input structure, call a rule class, and map exceptions/messages back to the BAdI's mechanism. SQL goes into a DAO with buffering, validation rules into a rule class with unit tests, message formatting into one place. Email sending does not belong in a save-time validation at all: it has side effects and would be sent even if the save fails later. It moves to an after-save mechanism (output/workflow/event or an update task step). Each part becomes testable and the BAdI method shrinks to a few lines.

Let the filter do the selection. Company codes with the same rule share one implementation with several filter values (e.g. BUKRS = 3000 OR 3100 for India), and a different rule gets its own implementation (BUKRS = 1000 for Germany). No IF on BUKRS inside the code. A fallback class (for own new BAdIs) holds the default rule. I ensure filter conditions don't overlap for single-use BAdIs, keep the tax rules in unit-tested classes, and review filters when new company codes go live. Tests cover each filter group plus a non-matching company code.

I would reproduce in a test system with that plant and debug the save: breakpoints at CL_EXITHANDLER=>GET_INSTANCE (classic, e.g. ME_PROCESS_PO_CUST) and GET BADI / CALL BADI, plus a watchpoint on the failure flag (CH_FAILED) or the message. The call stack shows which implementation sets it. Then I check that implementation: filter values or conditions on plant, customizing tables it reads, and data it uses. Plant-specific behaviour often comes from a filter or a Z table entry. I also list all implementations in SE19 and check other enhancements (user exits, validations). After finding the cause, I document it and add a test case for that plant.

In a multiple-use BAdI all active implementations run, one after another, in an undefined order, and each sees the CHANGING values of the previous. Two implementations changing the same field produce a result that depends on order — which may change after transports. I would find both implementations (SE19), decide which rule is correct or how they combine, and merge them into one implementation with a dispatcher class that calls the rules in a defined order, or split responsibilities so that each implementation changes different fields. If the BAdI must return a single decision, a single-use design (for own BAdIs) is the right choice. A register of implementations prevents repeats.

Vendor data is header-level, but PROCESS_ITEM runs for each item on every change or Enter, so the same SELECT runs items × interactions times. For large POs or mass creation this causes long response times. Fix: move the vendor check to a header-level method (CHECK or PROCESS_HEADER), use data available from the header object, and if a read is needed, buffer it by vendor/purchasing org in a hashed table. Add guard conditions (PO type). Verify with ST05 (identical selects) and SAT before and after.

Set an SE24 breakpoint on CL_EXITHANDLER=>GET_INSTANCE, run the transaction and observe which BAdIs are called. For new BAdIs, set a breakpoint on GET BADI/CALL BADI or search the transaction's package for enhancement spots in ADT.

A BAdI definition defines the enhancement option and method interface. A BAdI implementation contains the actual custom logic written by the developer. SE18 is commonly used to view definitions and SE19 is used to create or manage implementations.

When identical source code behaves differently, verify first that the same active versions, CMOD assignments and project activation are present. Then compare the exact transaction variant, user, master/transaction data, customizing, feature switches, authorizations, language/time-zone settings and RFC destinations. Reproduce with the same business keys where permitted and inspect the enhancement parameters at the breakpoint in both systems. Use ST05 only to compare SQL access and returned data, SU53/STAUTHTRACE for authorization differences and SM59 for RFC destinations. Do not invent or compare unrelated RZ11 parameters such as an 'EXIT_TIME' parameter, and do not use database-specific settings without evidence. Record every difference and isolate one variable at a time. The most common cause is environment data or configuration drift, not the ABAP source.

Inventory all 30 enhancements with business owner, enhancement definition, components, call locations, custom objects, data dependencies, usage evidence and criticality. For the target S/4HANA release, review simplification items, ATC findings and available released BAdIs/APIs. Classify each enhancement as: retain temporarily, replace with standard functionality, migrate to a released extension point, redesign as side-by-side extension, or retire. S/4HANA does not simply eliminate BKPF/BSEG; the Universal Journal centers financial actuals in ACDOCA while compatibility views and changed access patterns may remain. Therefore, assess every direct table dependency rather than applying blanket replacements. Convert logic into testable classes before moving call points, run regression and volume tests, validate clean-core compliance, and establish a rollback/cutover plan. Prioritize by business criticality and technical risk, not by enhancement count.

Maintain a central enhancement register containing project, enhancement definition, components, business purpose, owner, criticality, transactions, dependencies, test evidence, transport history and target-release status. Store ABAP source in the SAP repository and use normal transport/version management; abapGit may be added where organizational policy supports it, but it is not a replacement for CTS governance. Add structured application logging only where operationally necessary and avoid logging every invocation of high-frequency exits. Review dumps, performance traces and recurring incidents, and define a runbook for activation, debugging, rollback and retirement. Conduct periodic ownership and usage reviews so obsolete or duplicate enhancements can be removed safely.

Troubleshoot in this order: confirm the CMOD project and relevant customer include are active; verify that the correct enhancement definition and component are assigned; inspect the standard call location and conditions using where-used or source search; set an external or session breakpoint in the generated customer include or EXIT_* function module as appropriate; reproduce the exact transaction variant, user and data; and inspect whether an upstream condition bypasses the exit. If it works in one system but not another, compare active versions, transports, switch/customizing conditions, authorizations and data. Do not use SQL trace merely to search for MODACT access; that does not reliably prove that an exit was called. The decisive evidence is the standard call path, breakpoint behavior and active implementation status.

Classical customer enhancement implementations are customer objects and are generally retained during an upgrade, but the surrounding SAP standard code, interfaces, call conditions and application data model can change. Before the upgrade, inventory all CMOD projects and user exits, identify their business owners, verify whether the extension point still exists in the target release, review simplification items and relevant SAP documentation, and determine whether a released BAdI or standard function now replaces the custom logic. After conversion, perform syntax checks, ATC analysis, SPAU/SPDD activities where applicable to modified SAP objects, and regression tests for every affected business scenario. Do not assume that a green transport history or unchanged customer include guarantees identical runtime behavior. For S/4HANA, assess clean-core compliance and remove obsolete custom logic where standard functionality now covers the requirement.

Classical enhancements remain necessary knowledge for supporting ECC and brownfield landscapes, but they should not drive new extension architecture. Organizations should retain enough SMOD/CMOD expertise to safely maintain, debug and retire existing customer exits. New S/4HANA work should start with standard functionality, key-user extensibility, released BAdIs, released APIs and side-by-side extensions aligned with clean-core and cloud-readiness principles. Each legacy CMOD enhancement should have an owner, usage evidence, regression tests and a disposition: retain temporarily, replace, migrate or retire. Training should therefore teach CMOD as legacy-support knowledge while investing most advanced learning in the modern Enhancement Framework, ABAP Cloud restrictions, released objects and clean-core governance.

For a new S/4HANA project, the default recommendation is to use a released BAdI, released API, key-user extensibility or side-by-side extension that aligns with clean-core guidance. SMOD/CMOD should be retained only when the SAP application in that release still exposes a classical customer exit that is the supported and necessary extension point and no suitable released alternative exists. Simplicity alone is not a reason to choose CMOD over a released BAdI. The decision should consider upgrade stability, cloud readiness, released status, testability and long-term ownership. For an ECC brownfield landscape, existing CMOD logic may remain temporarily, but every enhancement should be inventoried and assessed during S/4HANA conversion.

Explanation: Performance issues in exits often stem from: 1) Database loops (SELECT in loop), 2) Unoptimized queries without WHERE clause, 3) Repeated BAPI calls for same data, 4) Buffering not enabled. Root Cause: Exit functions execute synchronously during transaction processing; any delay directly impacts user response time. Debugging Approach: 1) Use SAT (SE30 only in older systems) to profile exit code; 2) Enable SQL Trace (ST05) to identify slow queries; 3) Check for implicit database commits; 4) Measure loop iterations. Real Project Example: Sales order enhancement called BAPI_MATERIAL_AVAILABILITY_CHECK for each line item (nested loop). For 50-item order, made 50 BAPI calls sequentially. Optimization: Moved BAPI call outside loop, batched availability check for all materials, reduced processing from 45 seconds to 3 seconds. Anti-patterns: 1) SELECT * in exit code—retrieve only needed fields, 2) Calling external systems (RFC, BAPI) for each row, 3) Table reads without index (missing WHERE), 4) Not using internal tables for lookups, 5) Performing report generation inside exit. Best Practice: Minimize database operations; batch operations where possible; cache frequently accessed data using internal tables; avoid external system calls. Use SELECT with WHERE clause; apply proper indexing. Common Mistakes: Complex queries in field exits (called frequently), unoptimized nested loops, repeated BAPI calls, not profiling before optimization. Interview Tips: Mention SAT runtime analysis and ST05 SQL trace; provide BAPI batching example; explain why exits must be fast; discuss internal table caching.

Map each requirement to a supported extension point available in the target billing release. Use a pre-save validation BAdI or exit only for checks that may block the document; use a derivation point for changing approved in-memory billing structures; write audit/application logs through a dedicated logging service; and perform external notifications only after a successful commit using a supported asynchronous mechanism. Do not assume EXIT_SAPRV60A_001/002 or a post-save user exit has a particular purpose without verifying the enhancement documentation and standard call flow. Keep the SAP enhancement implementation thin and delegate tax, validation, logging and integration responsibilities to separate classes. Avoid direct updates to VBRK/VBRP, avoid synchronous remote calls during save and use a correlation ID for tracing. Test VF01/VF04, cancellations, collective billing, background processing and interface-created documents.

There is no generic SAP rule that all customer exits run first or that numbered EXIT_* function modules define a universal sequence. Each enhancement runs where the standard program calls it. To determine the real order, inspect the standard source and call stack, set breakpoints in every relevant user exit, function exit and BAdI, then execute the same business scenario. Multiple enhancements can conflict when they modify the same structures, assume different intermediate states, issue contradictory messages or perform duplicate database access. Prevent this by assigning one responsibility to each enhancement, centralizing shared logic in reusable classes, documenting dependencies and avoiding direct updates. If order is business-critical but not contractually guaranteed by SAP, redesign to remove that dependency.

Compiling is not the same as behaving correctly. The implicit enhancement sits at the start or end of an SAP routine and may overwrite values that SAP's corrected logic now calculates differently, or run at a different moment after SAP restructured the code. SAP's correction is effectively neutralised by the custom code. Approach: reproduce, debug with and without the enhancement (deactivate in a test system), compare old and new SAP code. Then either adapt the enhancement to the new logic or, better, move the requirement to a supported mechanism (pricing routine, condition configuration, BAdI). Add pricing regression tests to the upgrade test plan and register all implicit enhancements for review in SPAU_ENH and testing.

I would apply the clean core decision sequence: standard configuration (e.g. incompletion or credit settings) → key user extensibility (Custom Logic app implementing a released BAdI for sales document checks, if available) → developer extensibility with a released BAdI in ABAP Cloud → side-by-side if the logic is external. Only if none fits would a classic user exit (tier 3) be accepted, with documentation and a replacement plan. An implicit enhancement would need architecture approval as it is the least stable option. The validation logic itself goes into a class with messages returned (not displayed), so it works in Fiori, BAPI and IDoc processing. ATC with cloud readiness checks confirms only released objects are used.

Start by defining the rule precisely, for example blocking a purchase order when a custom supplier exposure threshold maintained in an approved Z-configuration table would be exceeded. Search the purchase-order application package and SMOD/Repository Information System for a classical customer enhancement that provides complete header/item data at the correct validation point. Do not assume a particular EXIT_* name; verify its documentation, interface and standard call location in the target system. Create a Z-named CMOD project, assign the verified enhancement, implement the generated customer include and delegate the rule to a reusable validation class. Read only required data with selective Open SQL, handle currency conversion explicitly, return an application message through the supported interface and never update EKKO/EKPO directly. Test create/change/copy, multiple currencies, service items, background/BAPI processing and missing configuration. Activate the project, verify all dependent objects in the transport, test in QA and obtain business approval before production.

Use descriptive Z/Y CMOD project names aligned to module and purpose, for example ZSD_SO_VALIDATION, and document the SAP enhancement definition and customer include rather than renaming SAP-delivered EXIT_* function modules. Maintain a register with owner, requirement, call point, dependencies, messages, test cases, transports and upgrade status. Keep exit code thin and delegate business logic to reusable classes where possible. Handle expected business errors through the application-supported message/exception mechanism; do not write database logs indiscriminately from every exit. Require peer review, ATC checks, negative/edge-case testing and knowledge-transfer notes. Use CTS/version management and optionally abapGit under approved governance. Define how the enhancement will be monitored, deactivated and retired.

Profile with SAT the exact call, remove any DB SELECT inside the loop, buffer master data at session start, batch DB reads with FOR ALL ENTRIES, and consider a background job if the logic is not strictly real-time.

New BAdIs pass parameters by value by default; declare parameters as CHANGING in the interface and confirm the standard code uses the returned values. If the standard reads a separate copy, you may need a different hook.

Following clean core, I first check standard and configuration, then a released BAdI for sales document checks: simple rules via the Custom Logic app (key user extensibility), more complex ones as a released BAdI implementation in ABAP for Cloud Development using only released APIs. If data needed is not released, a tier 2 wrapper provides it. The implicit enhancement is removed after the new implementation is tested in all channels (Fiori, VA01, APIs). ATC cloud readiness checks confirm the new code, and the decision is documented in the extension register.

Keep the BAdI implementation class thin — delegate immediately to a service class in a domain package. This isolates business rules from framework code and enables ABAP Unit tests independent of the BAdI runtime.