ABAP Developmentintermediate

BAdI Part 7: Using Filter-Dependent BAdIs

Key takeaway

Implement filter-dependent BAdIs correctly: filter characteristics and values, comparison operators and value ranges in new BAdIs, FLT VAL in classic BAdIs, overlapping filters, one implementation for several org units vs one per unit, and testing filter behaviour.

Explanation

📌 KEY POINTS
✅ A filter-dependent BAdI chooses implementations by a value such as country, company code or document type.
✅ New BAdIs: filter conditions are maintained per implementation in SE19 (e.g. BUKRS = 1000, LAND1 CP 'D*').
✅ Classic BAdIs: filter values are assigned to the implementation, and the caller passes FLT_VAL to each method.
⚠️ Overlapping filter conditions in a single-use BAdI cause errors; in a multiple-use BAdI they cause both implementations to run.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 designed a filter for your own BAdI. Now you implement SAP (or colleague) BAdIs that already have filters.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY FILTERS
Different countries, companies or document types need different logic. Filters keep the logic separate without IF blocks, and each implementation can be owned by a different team.

━━━━━━━━━━━━━━━━━━━━
▶ 2. NEW BADI FILTERS

The definition lists filter characteristics (name, type, allowed operators).
In SE19, the BAdI implementation gets a filter combination, e.g. BUKRS = '1000' OR BUKRS = '1100'.
GET BADI … FILTERS bukrs = lv_bukrs selects implementations whose condition matches.
Several characteristics combine with AND inside one combination; several combinations with OR.

━━━━━━━━━━━━━━━━━━━━
▶ 3. CLASSIC BADI FILTERS

One filter type in the definition (e.g. LAND1).
Implementation has a list of filter values.
Each method has IMPORTING flt_val; the exit handler passes it and calls only matching implementations.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ONE OR MANY IMPLEMENTATIONS?

Same logic for several units → one implementation with several filter values.
Different logic → separate implementations per unit.
Default for all → fallback class (new BAdI) rather than a "catch-all" filter.

━━━━━━━━━━━━━━━━━━━━
▶ 5. PITFALLS

Wrong value format (leading zeros, case) → no match.
Overlap: two single-use implementations for BUKRS 1000 → activation error or runtime conflict.
New org units (new company code) automatically fall to the fallback — make sure that is intended.

━━━━━━━━━━━━━━━━━━━━
▶ 6. TESTING
Test each filter value, a non-matching value (fallback/no implementation), and boundary cases (patterns).

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

SE18: find a filter-dependent BAdI in your area and read its filter definition.
Create an implementation for two filter values in a sandbox.
Debug GET BADI for a matching and a non-matching value.

✅ CHECKPOINT: you can implement filter-dependent BAdIs with correct, non-overlapping filters.

Code example

ABAP Code

* ===== New BAdI: filter set in SE19, not in code =====* BAdI implementation ZBI_INVOICE_IN   filter: BUKRS = '3000' OR BUKRS = '3100'* BAdI implementation ZBI_INVOICE_DE   filter: BUKRS = '1000'* Fallback class ZCL_INVOICE_CHECK_DEFAULT for all others CLASS zcl_bi_invoice_in DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_badi_interface.    INTERFACES zif_ex_invoice_check.ENDCLASS. CLASS zcl_bi_invoice_in IMPLEMENTATION.  METHOD zif_ex_invoice_check~check.    DATA ls_msg TYPE bapiret2.*   Runs only for company codes 3000/3100 - no IF on BUKRS needed here    IF is_invoice-gstin IS INITIAL.      ls_msg-type   = 'E'.      ls_msg-id     = 'ZFI'.      ls_msg-number = '020'.                   " 'GSTIN is required'      APPEND ls_msg TO et_messages.    ENDIF.  ENDMETHOD.ENDCLASS. * ===== Caller =====*   GET BADI lo_badi FILTERS bukrs = ls_invoice-bukrs.   " selects IN, DE or fallback*   CALL BADI lo_badi->check EXPORTING is_invoice = ls_invoice IMPORTING et_messages = lt_msg. * ===== Classic filter-dependent BAdI: FLT_VAL parameter =====* METHOD if_ex_<badi>~method.            " filter type LAND1, values IN, LK assigned in SE19*   CASE flt_val.*     WHEN 'IN'. ...                     " only needed if logic differs within one implementation*     WHEN 'LK'. ...*   ENDCASE.* ENDMETHOD.

Real project scenario

A group added company code 3200 in India. Invoices for 3200 were posted without GSTIN validation because the Indian BAdI implementation had filter values 3000 and 3100 only, and 3200 fell to the fallback class.
The team added 3200 to the filter combination and introduced a go-live checklist item for new org units: review filter-dependent BAdI implementations and customizing tables.

Common mistakes

IF blocks on org units inside a filter-dependent implementation.
Missing new org units in filter values.
Overlapping filters in single-use BAdIs.
Wrong value format (leading zeros).
Catch-all filters instead of a fallback class.

Best practices

Let filters select; keep implementations free of org-unit IFs.
Group units with identical logic in one implementation.
Use the fallback for defaults.
Review filters when adding org units.
Test matching and non-matching values.

Interview angle

Questions: "What is a filter-dependent BAdI?", "How do filters differ in classic and new BAdIs?", "What happens with overlapping filters?"
Strong answer: filters select implementations by values like country/company code; new BAdIs define filter conditions per implementation (operators, combinations) and GET BADI … FILTERS selects; classic BAdIs pass FLT_VAL to methods; single-use overlap is an error, multiple-use runs all matches; non-matching values use fallback; review filters for new org units.

Practice this lesson

Quick check

1. Company codes 3000 and 3100 share one tax rule in a filter-dependent BAdI. Best setup?

2. What is the purpose of a filter-dependent BAdI?

3. A filter BAdI is called…

Interview questions

1. What is a filter-dependent BAdI?

Answer it in your own words first, then compare.

2. Different company codes require different tax validations in a filter-dependent BAdI. How would you set up the implementations?

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.