Key User Extensibility vs. Developer Extensibility: Wann nutze ich was?

┌────────────────────────────────────────────────────────┐
│                    Clean Core                          │
├────────────────────────────────────────────────────────┤
│                                                        │
│  ┌────────────────────────────────────────────────┐   │
│  │         In-Stack Extensibility                  │   │
│  │  ┌──────────────────┐  ┌────────────────────┐  │   │
│  │  │   Key User       │  │    Developer       │  │   │
│  │  │   Extensibility  │  │    Extensibility   │  │   │
│  │  │   (No-Code)      │  │    (ABAP Cloud)    │  │   │
│  │  └──────────────────┘  └────────────────────┘  │   │
│  └────────────────────────────────────────────────┘   │
│                                                        │
│  ┌────────────────────────────────────────────────┐   │
│  │         Side-by-Side Extensibility              │   │
│  │         (BTP ABAP Environment, CAP, etc.)       │   │
│  └────────────────────────────────────────────────┘   │
│                                                        │
└────────────────────────────────────────────────────────┘

" Beispiel: Komplexe Preisfindung mit externem Service
METHOD calculate_special_pricing.
  " Externe API aufrufen
  DATA(lo_http_client) = cl_web_http_client_manager=>create_by_http_destination(
    i_destination = cl_http_destination_provider=>create_by_comm_arrangement(
      comm_scenario = 'Z_PRICING_SERVICE' )
  ).

  " Komplexe Berechnung über mehrere Tabellen
  SELECT FROM I_SalesOrderItem AS item
    INNER JOIN I_ProductValuation AS val
      ON item~Product = val~Product
    WHERE item~SalesOrder = @iv_sales_order
    INTO TABLE @DATA(lt_items).

  LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<item>).
    " Algorithmus mit mehreren Faktoren
    <item>-custom_price = calculate_tiered_price(
      iv_quantity   = <item>-quantity
      iv_base_price = <item>-net_price
      iv_customer   = <item>-customer
    ).
  ENDLOOP.
ENDMETHOD.

1. Ist die Anforderung ein einfaches Custom Field?
   → JA: Key User Extensibility (Custom Fields App)
   → NEIN: weiter zu Frage 2

2. Beschränkt sich die Logik auf einen einzelnen Datensatz?
   → JA: weiter zu Frage 3
   → NEIN: Developer Extensibility (Tabellenlogik)

3. Ist die Logik mit IF/THEN-Regeln abbildbar?
   → JA: Key User Extensibility (Custom Logic)
   → NEIN: Developer Extensibility (ABAP-Code)

4. Muss ein externes System aufgerufen werden?
   → JA: Developer Extensibility (HTTP Client)
   → NEIN: weiter zu Frage 5

5. Sind ABAP-Entwickler verfügbar?
   → JA: Developer Extensibility (bessere Wartbarkeit)
   → NEIN: Key User Extensibility (pragmatischer Ansatz)

✅ Beide Modelle sind Clean Core-konform
✅ Keine Modifikation von Standard-Objekten
✅ Stabile APIs durch SAP garantiert
✅ Automatische Upgrade-Tests durch SAP

┌─────────────────────────────────────────────────────────┐
│                 ANFORDERUNG                             │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           1. BEWERTUNG (Extensibility Board)            │
│  • Ist Erweiterung nötig? (Standard prüfen)             │
│  • Welcher Extensibility-Typ passt?                     │
│  • Ressourcen und Timeline                              │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           2. ENTSCHEIDUNG                               │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │  Key User   │    │  Developer  │    │ Side-by-Side│  │
│  │Extensibility│    │Extensibility│    │   (BTP)     │  │
│  └─────────────┘    └─────────────┘    └─────────────┘  │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           3. IMPLEMENTIERUNG                            │
│  • Nach Standards und Namenskonventionen                │
│  • Mit Dokumentation                                    │
│  • Mit Tests                                            │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           4. LIFECYCLE-MANAGEMENT                       │
│  • Regelmäßige Reviews                                  │
│  • Upgrade-Vorbereitung                                 │
│  • Stilllegung obsoleter Extensions                     │
└─────────────────────────────────────────────────────────┘

Key User Extensibility:
├── Automatisch vergeben: YY1_*, ZZ1_*
└── Keine manuelle Einflussnahme

Developer Extensibility:
├── Namensraum: Z* oder /KUNDE/*
├── Extension Structures: ZZ1_<OBJEKT>_EXT
├── BAdI Classes: ZCL_<BEREICH>_<FUNKTION>
├── CDS Extensions: ZE_<BASIS>_<ZWECK>
└── Behavior Extensions: ZBP_<ENTITÄT>_EXT

Quartalsmäßige Überprüfung aller Extensions:
├── Wird die Extension noch genutzt?
├── Entspricht sie noch den Anforderungen?
├── Gibt es Performance-Probleme?
├── Ist die Dokumentation aktuell?
└── Plant SAP einen Release, der die Extension betrifft?

Phase 1: Vorbereitung
├── Anforderungen dokumentieren
├── Key User Logic analysieren
└── Developer-Konzept erstellen

Phase 2: Implementierung
├── BAdI oder Behavior Extension erstellen
├── Logik in ABAP Cloud implementieren
└── Unit Tests schreiben

Phase 3: Migration
├── Parallelbetrieb (beide aktiv, Key User nur Logging)
├── Validierung der Ergebnisse
└── Key User Logic deaktivieren

Phase 4: Abschluss
├── Dokumentation aktualisieren
├── Schulung der Fachbereiche
└── Key User Logic löschen (optional)

Kundenpriorisierung:

1. Custom Field (Key User)
   └── YY1_CUSTOMER_PRIORITY: Priorität A/B/C/D

2. Simple Logic (Key User)
   └── Default bei Anlage: "C"

3. Complex Calculation (Developer)
   └── Automatische Neuberechnung basierend auf:
       • Umsatz letzte 12 Monate
       • Zahlungsverhalten
       • Reklamationsquote

4. Integration (Developer)
   └── Sync mit externem CRM-System

App: Custom Fields and Logic (F1481)
Business Context: Business Partner - Customer
Field: Industry Classification
Type: Code List (Automotive, Retail, Manufacturing, ...)

CLASS zcl_credit_check_badi IMPLEMENTATION.
  METHOD check_credit.
    " Externes Credit Rating abrufen
    DATA(lo_client) = get_http_client( ).
    DATA(lv_rating) = lo_client->get_credit_rating(
      iv_customer = is_order-sold_to_party
    ).

    IF lv_rating < minimum_rating( is_order-net_amount ).
      RAISE EXCEPTION TYPE zcx_credit_block
        MESSAGE e001(zcredit) WITH is_order-sold_to_party.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

App: Custom CDS Views (F2170)
Basis: I_SalesOrder
Felder: Region, Sum(NetAmount), Count(SalesOrder)
Gruppierung: Nach Region
Filter: Aktuelles Geschäftsjahr