Kundenspezifische Erweiterungen

Kundenspezifische Erweiterungen in SAP RE-FX – praxisnah und modifikationsfrei umsetzen

In vielen SAP-RE-FX-Projekten kommt früher oder später die Frage auf: Wie können wir unsere Prozesse an individuelle Anforderungen anpassen, ohne dabei den SAP-Standard zu verändern? Gerade bei der Verwaltung von Immobilienobjekten und Verträgen reicht der SAP-Standard nicht immer aus – sei es, um zusätzliche Informationen zu speichern oder bestimmte Prüfungen einzubauen.

Zum Glück bietet SAP RE-FX dafür eine ganze Reihe von Erweiterungsmöglichkeiten, die modifikationsfrei umgesetzt werden können. In diesem Beitrag zeige ich euch, welche Werkzeuge SAP dafür bereitstellt, wann der Einsatz sinnvoll ist und wie ihr dabei am besten vorgeht.

Warum Erweiterungen in SAP RE-FX notwendig sind

In der Praxis gibt es zahlreiche Szenarien, in denen die SAP-Standardfunktionen nicht mehr ausreichen. Hier ein paar typische Beispiele aus RE-FX-Projekten:

• Ein Feld für „Energieausweis gültig bis“ soll im Vertrag erfasst werden.
• Warnungen sollen erscheinen, wenn Mietflächen außerhalb bestimmter Grenzen liegen.
• Verträge sollen beim Anlegen automatisch eine spezielle Nummernlogik verwenden.
• Im Infosystem sollen eigene Felder in Auswertungen berücksichtigt werden.

All diese Anforderungen lassen sich mit den richtigen Mitteln in SAP RE-FX umsetzen – ohne Modifikationen. Denn Modifikationen sind teuer in der Wartung, aufwändig beim nächsten Releasewechsel und in den meisten Fällen nicht erforderlich. Stattdessen greifen wir auf bewährte Mechanismen wie BAdIs (Business Add-Ins), Benutzerfelder über das BDT (Business Data Toolset) und Erweiterungspunkte zurück.

Werkzeuge für kundenspezifische Erweiterungen: BAdIs, BDT und Co.

SAP stellt in RE-FX verschiedene Werkzeuge zur Verfügung, mit denen sich Erweiterungen modular, flexibel und klar definiert implementieren lassen. Im Folgenden stelle ich die wichtigsten kurz vor:

BAdIs – Business Add-Ins

Mit BAdIs lassen sich an vordefinierten Stellen im SAP-Standard eigene Logiken einbauen. Das macht sie zur ersten Wahl, wenn es um Prüfungen, Vorbelegungen oder Anpassungen des Systemverhaltens geht.

Typische Anwendungsfälle sind:

• Prüfung von Kombinationen aus Nutzungsart und Raumtyp beim Anlegen eines Nutzungsverhältnisses
• Substitution von Feldwerten wie z. B. der Ablageort auf Basis des Miettyps
• Kundenspezifische Nummernvergabe für Immobilienobjekte oder Verträge
• Einbindung eigener Auswertungen in der Vertragsübersicht

Die Implementierung erfolgt in der Transaktion SE19, passende BAdI-Schnittstellen findet man über SE18, z. B. mit Suchmustern wie BADI_RECN* für Vertragsinhalte.

BDT – Business Data Toolset

Sollen zusätzliche Eingabefelder in den Transaktionen sichtbar werden (z. B. beim Vertrag oder beim Objekt), kommt das Business Data Toolset (BDT) ins Spiel. Es erlaubt die Oberflächenerweiterung – inklusive eigener Felder sowie tabellarischer Erweiterungen – ohne Änderung des SAP-Standards.

Die Daten werden dabei in einer eigenen Struktur verwaltet, die über Customizing mit dem Anwendungskontext verbunden wird. Das Gute: Die Felder verhalten sich nachher genauso wie Standardfelder – inklusive Validierungen, Feldhilfen und Pflegeunterstützung.

Object Navigator SE80

Die Zentrale für alle Entwicklungsobjekte in SAP ist die Transaktion SE80. Hier werden Strukturen, Funktionsgruppen, Programme oder Klassen gepflegt. Für RE-FX-Erweiterungen dient SE80 meist zur Pflege der Objekte, die hinter den Benutzerfeldern (z. B. Strukturen im DDIC) und den BAdIs (z. B. Klassen mit benutzerdefinierter Logik) stehen.

Beispiel aus der Praxis: Validierung eines Vertragsfelds mit BAdI

Ein Kunde möchte verhindern, dass in einem Gewerbemietvertrag die Fläche unter 50 m² liegt. Sobald ein Benutzer versucht, einen Vertrag mit kleinerer Fläche zu speichern, soll eine Fehlermeldung erscheinen.

Dazu setzen wir auf das BAdI BADI_RECN_CONTRACT. In dessen Methode CHECK_BEFORE_SAVE prüfen wir das entsprechende Feld (z. B. RECN_CONTRACT_AREA) und lösen bei Unterschreiten der Mindestfläche eine Fehlermeldung aus:

IF iv_area < 50.
  RAISE EXCEPTION TYPE cx_badi_contract
    EXPORTING 
      textid = cx_badi_contract=>invalid_data
      msgv1  = 'Fläche zu klein (min. 50 m²)'.
ENDIF.

Diese Implementierung ist sauber gekapselt, beim nächsten Release problemlos übertragbar und folgt der SAP-Erweiterungssystematik. Gleichzeitig sorgt sie beim Anwender für ein klares, prüfbares Verhalten – ohne dass externe Tools oder Tabellen notwendig sind.

Fazit – die "richtige Dosis" Erweiterung im Projekt

Kundenspezifische Erweiterungen sind im RE-FX-Umfeld nahezu unvermeidlich – sei es für Prüfprozesse, Oberflächenanpassungen oder Auswertungen. Wichtig ist dabei:

• Modifikationsfrei arbeiten – z. B. mit BAdIs und BDT
• Standardmethoden nutzen, um wartbar und upgradefähig zu bleiben
• Nur dort erweitern, wo es technisch und fachlich wirklich nötig ist

Wenn ihr diese Leitlinien beachtet, könnt ihr RE-FX flexibel an Kundenbedürfnisse anpassen und gleichzeitig die Vorteile des SAP-Standards erhalten.

Wenn du dich für SAP RE-FX interessierst oder Fragen zu kundenspezifischen Erweiterungen hast, vernetze dich gerne mit mir auf LinkedIn:
https://www.linkedin.com/in/steven-imig-479993a2/