BAdI Part 3: Designing Your Own BAdI — Fallback Class and Filters

📌 KEY POINTS
✅ You can define your own new BAdIs in Z programs so others can extend them without changing your code.
✅ Filters (e.g. BUKRS, LAND1) select the implementation for the current context.
✅ A fallback class provides default behaviour when no implementation matches the filter.
⚠️ For single-use BAdIs without fallback, GET BADI raises CX_BADI_NOT_IMPLEMENTED if no implementation exists — handle it.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 implemented SAP's BAdIs. Now you design one for your own code — typical for global templates.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHEN TO CREATE AN OWN BADI

• A Z program runs in several countries or companies with different rules.
• Other teams must extend your logic independently.
• A default behaviour exists, with exceptions for some units.

━━━━━━━━━━━━━━━━━━━━
▶ 2. BUILD IT (SE18 / SE20)

1. Create enhancement spot ZES_INVOICE_CHECK (package, transport).
2. In the spot, create BAdI definition ZBADI_INVOICE_CHECK.
3. Settings: single use or multiple use (Part 5); "Limited filter use"; instance creation mode.
4. Interface ZIF_EX_INVOICE_CHECK with method CHECK (IMPORTING is_invoice, EXPORTING et_messages or RAISING an exception class).
5. Filter: BUKRS (type BUKRS), compare operators allowed.
6. Fallback class: ZCL_INVOICE_CHECK_DEFAULT implementing the interface (and IF_BADI_INTERFACE).

━━━━━━━━━━━━━━━━━━━━
▶ 3. CALL IT
GET BADI lo_badi FILTERS bukrs = lv_bukrs.
CALL BADI lo_badi->check EXPORTING … .

• With a fallback class, a single-use BAdI always finds an implementation.
• Multiple-use BAdIs call all matching implementations; with none, the call does nothing.

━━━━━━━━━━━━━━━━━━━━
▶ 4. IMPLEMENTATIONS
Company-specific teams create implementations with filter values (BUKRS = 1000, BUKRS = 2000). The core program stays unchanged.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DESIGN TIPS

• Keep the interface stable — changing it breaks all implementations.
• Pass data as structures/tables; return messages instead of displaying them.
• Document what each method must do and when it is called.

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

1. Create spot, BAdI, interface, filter and fallback class as above.
2. Call it from a Z report (code example).
3. Implement it for company code 1000 and compare output with company code 2000 (fallback).

✅ CHECKPOINT: you can provide your own filter-dependent BAdI with default behaviour.

A shared service centre ran one invoice verification program for 12 company codes. Local rules were first coded as IF bukrs = … blocks, and every change required retesting all companies.
A custom BAdI with filter BUKRS and a fallback class for the group-wide rule allowed each company team to maintain its own implementation. The core program was frozen, and a new company code only needed an implementation if it deviated from the default.

• No fallback class for a single-use BAdI (CX_BADI_NOT_IMPLEMENTED).
• Changing the interface after implementations exist.
• Displaying messages inside implementations.
• Filters that are too fine-grained or overlapping.
• Creating an own BAdI where a simple customizing table would do.

• Use a fallback class for default behaviour.
• Design a stable interface returning messages.
• Choose filters matching the organisational split.
• Document the BAdI contract.
• Catch CX_BADI_NOT_IMPLEMENTED where no fallback exists.

Questions: "How do you create your own BAdI?", "What is a fallback class?", "What happens if no implementation exists?"
Strong answer: enhancement spot + BAdI definition (single/multiple use, filter) + interface with IF_BADI_INTERFACE + optional fallback class; call with GET BADI … FILTERS and CALL BADI; fallback provides default behaviour; single-use without implementation raises CX_BADI_NOT_IMPLEMENTED, multiple-use simply calls nothing.