Filter-Dependent BAdIs

Explanation

A filter-dependent BAdI allows different implementations to run based on filter values such as company code, country, application, process type or plant. This is useful when business behavior differs by region or organizational unit. Instead of writing one huge IF/CASE block inside a single implementation, separate implementations can be created for each filter value. This improves readability and ownership. However, filter values must be maintained correctly, and fallback behavior should be considered when no matching implementation exists.

Code example

* Purpose:* Filter-dependent BAdI lets the framework select implementation by filter value.* Example filter could be company code. DATA lo_badi TYPE REF TO zif_ex_tax_validation. * Step 1: Get BAdI implementation for company code filterGET BADI lo_badi  FILTERS    bukrs = ls_document-bukrs. * Step 2: Call validation method* Only matching implementation for the filter should runCALL BADI lo_badi->validate_tax_code  EXPORTING    is_document = ls_document  CHANGING    ct_return   = lt_return. * Why this is useful:* Company-code-specific logic stays isolated and easier to maintain.

Real project scenario

Different company codes need different tax validation rules. A filter-dependent BAdI implementation can isolate each company code rule cleanly instead of placing all logic in one large method.

Common mistakes

- Forgetting to maintain filter value. - Hardcoding company code inside implementation instead of using filter. - Not designing fallback behavior. - Creating too many filter implementations without governance.

Best practices

- Use filters for real business variants. - Keep each filter implementation focused. - Document filter values. - Design fallback behavior when needed.

Interview angle

A strong answer should explain that filters select implementation based on business values and reduce large IF/CASE blocks.