SAP Backup: was Sie selbst sichern müssen

9. Sept.

Verfasst von Wlad

In einem SAP-System gibt es zwei Arten von Sicherung, und sie werden regelmäßig verwechselt. Der Betreiber sichert das System. Was Sie darin gebaut haben, sichern Sie selbst.

Kurz gesagt: Das Datenbank-Backup des Betreibers schützt vor einem Ausfall des Systems, nicht vor einem gelöschten Programm oder einer verstellten Einstellung. Ihre eigenen Objekte holen Sie über vier Wege heraus: abapGit für den Code, Transportaufträge für Entwicklung und Customizing, den Quelltext-Download für den schnellen Zwischenstand und SE16N für Tabelleninhalte. Was dabei jeweils mitgeht und was nicht, steht in der Zuordnungstabelle weiter unten.

Es ist gerade etwas weg

Was jetzt noch zu retten ist, hängt davon ab, was verloren ging und was Sie in den nächsten Minuten tun. Die häufigste Rettung kennt fast niemand.

Zur Soforthilfe

Ich will vorbeugen

Der häufigste Verlustfall und die Zuordnungstabelle: welches Objekt mit welchem Werkzeug gesichert wird und wo die typischen Lücken sind.

Wie es meistens passiert

Soforthilfe

Es ist etwas weg. Was jetzt?

Zuerst die wichtigste Regel: nicht weiterarbeiten, nicht erneut sichern und nicht aktivieren. Jedes Sichern überschreibt den Quelltext im System. Solange Sie nichts weiter anfassen, bleiben Ihnen die meisten Rettungswege offen.

ABAP-Code ist überschrieben oder gelöscht

Nicht weiterarbeiten, nicht erneut sichern und nicht aktivieren. Jedes Sichern überschreibt den Quelltext im System.
Haben Sie nur gesichert und noch nicht aktiviert, lässt sich im Editor der zuletzt aktive Stand noch anzeigen und zurückholen. Das ist die Rettung, die am häufigsten funktioniert und die kaum jemand kennt.
Versionsverwaltung öffnen: im Editor über Hilfsmittel, Versionen, Versionsverwaltung. Wichtig ist zu wissen, wann überhaupt eine Version entsteht: bei der Freigabe eines Transportauftrags, der das Objekt enthält, und wenn Sie im Editor selbst eine Version sichern. Beim Sichern und beim Aktivieren entsteht keine. War Ihr Objekt nie in einem freigegebenen Auftrag, etwa weil es als lokales Objekt in $TMP liegt, ist die Versionsverwaltung leer.
Ist das Objekt ganz weg, prüfen Sie freigegebene Transportaufträge. Ein einmal freigegebener Auftrag enthält den Stand von damals. Ein gelöschtes Programm holen Sie zurück, indem Sie es unter exakt demselben Namen neu anlegen und dann die alte Version ziehen.
Existiert ein Git-Repository, holen Sie den letzten Commit zurück.
Erst wenn all das nichts bringt, ist der Weg über das Backup des Betreibers zu prüfen, und der geht nur bei einem System, das Ihnen allein gehört.
Danach einmal in SE16N die Tabelle TADIR aufrufen und das Feld DEVCLASS mit dem Muster $* filtern. Damit sehen Sie alle lokalen Pakete, nicht nur $TMP, denn jedes Paket mit einem $ am Anfang ist lokal. Alles, was dort steht, ist beim nächsten Systemwechsel weg, wenn Sie es nicht vorher einem transportfähigen Paket zuordnen.

Customizing wurde verstellt

Zuerst prüfen, ob überhaupt protokolliert wurde. Die Tabellenprotokollierung greift nur, wenn im Systemprofil der Parameter rec/client aktiv ist und die betroffene Tabelle als protokollpflichtig gekennzeichnet ist. Der Standardwert von rec/client ist AUS, und in Test- und Schulungssystemen ist er es oft auch. Rückwirkend lässt sich das nicht einschalten.
Läuft die Protokollierung, werten Sie sie mit der Transaktion SCU3 aus. Dort sehen Sie alten und neuen Wert und können die Einstellung von Hand zurücksetzen, meist schneller als jede Wiederherstellung.
Existiert ein bereits freigegebener Customizing-Auftrag von vorher, enthält seine Datendatei den Stand von damals. Ein noch offener Auftrag hilft nicht: Dort stehen nur die Schlüssel der Einträge, die Werte selbst werden erst bei der Freigabe aus der Tabelle gelesen, also im heutigen, bereits verstellten Zustand.
Hilft beides nicht, bleibt der Vergleich mit einem anderen Mandanten, in dem die Einstellung noch stimmt.

Tabelleninhalte oder Stammdaten sind weg

Prüfen, ob ein Export existiert, in SE16N oder aus einem eigenen Report.
Bei Stammdaten hilft oft der Wiederaufbau über das Migration Cockpit oder LSMW aus einer alten Liste.
Bewegungsdaten lassen sich nicht zurückholen, sie werden neu gebucht. Bei Testdaten ist das meist schneller als jede Wiederherstellung.

Das ganze System oder der Mandant ist nicht mehr nutzbar

Betreiber informieren, mit Uhrzeit und dem, was zuletzt passiert ist.
Solange die Ursache unklar ist, im System nichts weiter verändern.
Wiederherstellung aus dem Backup ist Sache des Betreibers. Bei einem geteilten System betrifft sie alle Mandanten und wird deshalb nur bei einem echten Ausfall gemacht.

Diese Schritte gelten unabhängig davon, bei wem Ihr System läuft. Nur der letzte Punkt, die Wiederherstellung aus dem Backup, hängt vom Betreiber und vom Systemtyp ab.

Der häufigste Fall

Wie Entwicklungen tatsächlich verloren gehen

Kein Einzelfall, sondern das Muster, das sich in Foren und Projekten immer wieder gleich liest:

Jemand baut über Wochen Reports und Hilfsprogramme in einem Testsystem. Beim Anlegen fragt das System nach einem Paket. Die Auswahl Lokales Objekt ist einen Klick schneller, und aufräumen kann man später immer noch. Es funktioniert alles, wochenlang.

Dann wird das System neu aufgesetzt, der Mandant überschrieben oder der Zugang läuft aus. Alles, was als lokales Objekt gespeichert war, ist weg. Nicht weil etwas kaputtging, sondern weil es nie in einem Transportauftrag lag und damit nie das System verlassen konnte.

Das Tückische daran: Der Verlust fällt erst auf, wenn es zu spät ist. Bis dahin gibt es keine Fehlermeldung und keinen Hinweis, im Gegenteil, es läuft ja alles.

Was in fünf Minuten Klarheit schafft

Rufen Sie in SE16N die Tabelle TADIR auf und filtern Sie das Feld DEVCLASS mit dem Muster $* sowie Ihren Benutzernamen im Feld AUTHOR. Das Muster statt $TMP ist wichtig: Jedes Paket, dessen Name mit einem $ beginnt, ist lokal und nicht transportierbar. Was dort steht, verschwindet beim nächsten Systemwechsel.

Zwei Dinge dazu, damit Sie sich nicht in falscher Sicherheit wiegen. AUTHOR ist der Verantwortliche des Objektverzeichniseintrags, nicht zwingend der Anleger, sehen Sie also einmal auch ohne diesen Filter nach, sonst fehlen Objekte, die ein Kollege für Sie angelegt hat. Und ein Z-Paket ohne Transportschicht ist genauso wenig transportierbar wie $TMP, taucht bei diesem Filter aber nicht auf. Das prüfen Sie in SE21 oder im Objektnavigator.

Was Sie behalten wollen, ordnen Sie danach über den Objektnavigator einem transportfähigen Paket zu und legen es in einen Auftrag. Das dauert pro Objekt einen Moment und ist die wirksamste Einzelmaßnahme auf dieser ganzen Seite.

Die Zuordnung

Was Sie gebaut haben und womit Sie es sichern

Diese Tabelle ist der Kern der Seite. Links steht, was in einem SAP-System entstehen kann, rechts das Werkzeug, mit dem Sie es aus dem System bekommen. Umschalten zwischen Kurzfassung zum Überfliegen und ausführlicher Erklärung.

Zuordnung von Objekten zu Sicherungswegen in SAP ERP und S/4HANA. Stand: 9. September 2026.
Was Sie gebaut haben	Womit Sie es sichern
ABAP-Code: Programme, Klassen, Funktionsbausteine	abapGit oder Workbench-Auftrag
CDS-Views, Fiori-Entwicklungen	CDS wie Code, Fiori zusätzlich Customizing fürs Launchpad
Tabellen, Strukturen, Datenelemente	Definition automatisch, Inhalte nur auf Umwegen
Inhalte Ihrer eigenen Z-Tabellen	SE16N-Export
Customizing: Organisationsstruktur, Belegarten, Preisfindung	Customizing-Auftrag
Rollen und Berechtigungsprofile	Transportauftrag aus PFCG
Wer welche Rolle hat	Standardmäßig nicht im Transport, Liste über SUIM
Stammdaten: Material, Kunde, Lieferant, Geschäftspartner	SE16N-Export, Rückweg über Migration Cockpit
Bewegungsdaten: Belege, Aufträge, Buchungen	Export nur zum Nachlesen
Nummernkreise	Nur über Intervalle transportieren, Zählerstand immer veraltet
Report-Varianten	Report RSTRANSP
SAP Queries, Infosets, Benutzergruppen	Global im Workbench-Auftrag, Standardbereich über RSAQR3TR

Die drei Zeilen, die am häufigsten überraschen: Die Inhalte einer normalen Z-Tabelle gehen nicht von allein mit dem Transport mit, die Zuordnung von Benutzern zu Rollen nur, wenn Sie sie ausdrücklich anhaken, und Zählerstände von Nummernkreisen kommen im Zielsystem immer veraltet an.

Die Trennlinie

Was der Betreiber sichert und was nicht

Alles in der Tabelle oben ist Ihre Aufgabe. Auf der Systemebene darunter beginnt die Zuständigkeit des Betreibers, egal ob das System im eigenen Rechenzentrum steht oder gemietet ist.

Systemebene: Zuständigkeit des Betreibers.
Was	Wie und durch wen
Die Datenbank mit allen Mandanten des Systems	Datenbank-Backup durch den Betreiber. Bei IDES24 täglich, 14 Tage Aufbewahrung.
Ein kompletter Mandant als Kopie	Mandantenkopie durch den Betreiber. Auf einem geteilten System nicht auf Zuruf, weil sie andere Mandanten berührt.
Systemparameter, Anmelderegeln, Protokollierung	Wirken systemweit und liegen beim Betreiber. Auf einem dedizierten Server können Sie sie selbst setzen.
HTTP-Dienste und Schnittstellen	Systemweit, also Betreibersache. Bei IDES24 richtet das Technik-Team sie für Ihren Fall ein.

Der Satz, auf den es ankommt: Der Betreiber sichert das System, nicht Ihre Arbeit darin. Ein Datenbank-Backup hilft, wenn die Festplatte ausfällt. Es hilft nicht, wenn Sie am Freitagnachmittag eine Klasse überschreiben, denn dafür müsste das gesamte System auf einen früheren Stand zurückgesetzt werden.

Bei einem gemieteten System

Läuft Ihr System bei einem Anbieter, übernimmt dieser die gesamte Systemebene. Bei IDES24 heißt das: tägliches Backup, 14 Tage Aufbewahrung, kostenfreie Wiederherstellung nach einem Ausfall auf unserer Seite. Systemweite Einstellungen richtet unser Technik-Team ein, auf einem dedizierten Server können Sie sie auch selbst setzen.

Ein Unterschied ist dabei wichtig: Auf einem dedizierten Server lässt sich ein früherer Stand auf Ihren Wunsch wiederherstellen, gegen Aufwand. Auf einem geteilten System nicht auf Zuruf, weil immer die ganze Datenbank zurückgesetzt wird und nie ein einzelner Mandant. Es bliebe der Umweg über ein Ausweichsystem und eine Mandantenkopie, der dauert und kostet. Dort ist Ihre eigene Sicherung deshalb nicht Komfort, sondern die Absicherung, auf die Sie sich verlassen können.

Die Werkzeuge

Die vier Wege aus dem System heraus

abapGit: Ihr Code in einem Git-Repository

abapGit ist ein offenes Werkzeug, das im SAP-System läuft und Ihre Entwicklungsobjekte als Dateien in ein Git-Repository schreibt. Damit haben Sie eine Versionsgeschichte außerhalb des Systems, die niemand außer Ihnen löschen kann.

Drei Dinge prüfen Sie vorher. Es braucht mindestens SAP_BASIS 7.02, auf einem ECC 6.0 ohne Enhancement Package läuft es nicht. Für ein Repository im Internet braucht der Applikationsserver eine ausgehende HTTPS-Verbindung und die passenden Zertifikate in STRUST. Fehlt die Verbindung, arbeiten Sie mit einem Offline-Repository und exportieren den Stand als ZIP-Datei, für die Sicherung genügt das. Und abapGit deckt Entwicklungsobjekte ab, kein Customizing, keine Tabelleninhalte, keine Rollenzuordnungen.

Ein häufiges Missverständnis vorweg: Eclipse mit den ABAP Development Tools ist keine Sicherung. Es legt zwar einen Zwischenspeicher im Workspace an, und die Local History hält die letzten Stände auf Ihrem Rechner fest, begrenzt nach Anzahl und Alter und ohne das Objektumfeld. Als Rettung nach einem Fehlgriff taugt das, als Sicherung nicht. Für CDS-Views führt an Eclipse kein Weg vorbei, für die Sicherung führt keiner an abapGit vorbei.

Transportauftrag: Entwicklung und Customizing zusammen

Der Transportauftrag ist das einzige Format, das Entwicklungsobjekte und Customizing gemeinsam mitnimmt. Sie legen Ihre Objekte in einen Auftrag, geben ihn frei und sichern die entstehenden Dateien. Ein Transport besteht dabei aus zwei Dateien: dem Cofile K<Nummer>.<SID> im Unterverzeichnis cofiles und dem Datafile R<Nummer>.<SID> im Unterverzeichnis data, beide unterhalb des Transportverzeichnisses, meist /usr/sap/trans. Die Objekte selbst stecken im Datafile, das Cofile enthält Ablaufschritte und Status. Sichern Sie immer beide, denn nur dann lässt sich der Auftrag später über die normale Transportverwaltung importieren.

Es gibt zwei Arten von Aufträgen, und die Trennlinie verläuft nicht zwischen Entwicklung und Customizing, sondern zwischen mandantenabhängig und mandantenübergreifend. Ein Customizing-Auftrag nimmt mandantenabhängige Einstellungen mit, also alles, was nur in dem Mandanten gilt, in dem Sie es eingestellt haben. Ein Workbench-Auftrag nimmt Entwicklungsobjekte auf und zusätzlich das mandantenübergreifende Customizing, etwa Fabrikkalender oder Länder- und Währungseinstellungen. Das System schlägt beim Sichern den passenden Typ selbst vor.

Quelltext-Download: der schnelle Zwischenstand

Für einzelne Programme gibt es im Editor einen direkten Download als Textdatei. Das ersetzt keine der anderen Ebenen, aber es ist die richtige Antwort auf den Gedanken, drei Stunden Arbeit gerade nicht verlieren zu wollen.

SE16N: Tabelleninhalte als Datei

Alles, was in Tabellen steht, kommt über SE16N heraus: Inhalte Ihrer Z-Tabellen, Stammdaten, Auswertungen. Wer das regelmäßig braucht, schreibt einen kleinen Report mit GUI_DOWNLOAD und legt ihn selbst in einen Transportauftrag, dann ist das Werkzeug beim nächsten Mal gleich mitgesichert.

Wer die Transportdateien aus dem System bekommt, hängt von Ihren Rechten ab. In einer eigenen Systemlandschaft macht das die Basis-Abteilung, bei einem gemieteten System je nach Produkt Sie selbst oder das Team des Anbieters.

Fallstricke

Acht Dinge, die regelmäßig schiefgehen

Das ist der Teil, den es sonst nirgends gesammelt gibt. Jeder einzelne Punkt hat schon jemandem einen Arbeitstag gekostet.

Lokale Objekte lassen sich nicht transportieren

Der häufigste Grund für verlorene Arbeit. Was beim Anlegen als lokales Objekt gespeichert wurde, kommt in keinen Transportauftrag. Das trifft auch Varianten solcher Programme. Wer später transportieren will, ordnet das Objekt vorher einem transportfähigen Paket zu.

Die Struktur einer Z-Tabelle wandert automatisch mit, die Zeilen darin nicht

Das ist der Fehler, der am häufigsten erst nach dem Import auffällt. Eine Ausnahme gibt es: Bei Customizing-Tabellen mit Standardaufzeichnung zeichnet das System die Einträge bei der Pflege über SM30 selbst in einem Auftrag auf. Bei einer normalen Z-Tabelle passiert das nicht.

Eclipse mit ADT ist keine Sicherung

Ganz ohne lokale Kopie arbeitet es zwar nicht: Im Eclipse-Workspace liegt ein Zwischenspeicher, und die Local History hält Ihre letzten Sicher- und Aktivierungsstände auf dem Rechner fest, abrufbar über Rechtsklick im Editor, Team, Local History. Nach einem Fehlgriff lohnt der Blick dorthin. Verlassen sollten Sie sich darauf nicht: Diese Stände sind nach Anzahl und Alter begrenzt, enthalten nur den Quelltext ohne Objektumfeld und verschwinden mit dem Workspace. Der belastbare Weg in ein Git-Repository führt über abapGit.

Cofile und Datafile gehören zusammen

Fehlt das Datafile, ist der Inhalt weg. Fehlt das Cofile, ist der Inhalt zwar noch da, die Rückholung wird aber zur Basis-Aufgabe. Und beide liegen im Dateisystem des Servers, nicht in der Datenbank: Sie werden turnusmäßig aufgeräumt und verschwinden mit dem System. Eine Sicherung sind sie erst, wenn Sie sie auf einen eigenen Datenträger kopiert haben.

Ein Export ist eine Sicherung, kein Wiederherstellungspunkt

Zurückspielen bedeutet Arbeit: Transporte importieren, Daten über Migration Cockpit oder LSMW laden. Wer nach einem Verlust sofort weiterarbeiten muss, braucht ein System mit Wiederherstellung auf Anforderung.

Transporte sind an das Release gebunden

Ein Auftrag aus einem neueren System lässt sich nicht in ein älteres importieren. Beim Wechsel der Version also vorher prüfen, wohin die Sicherung später soll.

Mandantenabhängig ist nicht dasselbe wie systemweit

Verlassen Sie sich nicht darauf, dass ein falsch gewählter Auftrag beim Freigeben auffällt. In einen Customizing-Auftrag kommen zwar keine Entwicklungsobjekte, umgekehrt ist es aber durchlässig: Ein Workbench-Auftrag darf mandantenabhängiges Customizing enthalten. Beim Import landet es dann im Standardmandanten des Transportwegs, nicht zwingend dort, wo Sie es haben wollen.

Auf einem geteilten System gibt es keinen Rücksprung auf Zuruf

Wiederhergestellt wird immer die ganze Datenbank, nie ein einzelner Mandant. Technisch möglich ist nur der Umweg: Der Betreiber spielt die Sicherung in ein Ausweichsystem ein und holt Ihren Mandanten von dort per Mandantenkopie zurück. Das setzt freie Hardware und ein Zielsystem mit gleichem Stand voraus, dauert und kostet. Schnell ist es nie, und deshalb ist die eigene Sicherung dort kein Komfort, sondern die Absicherung, auf die Sie sich verlassen können.

In der Praxis

Ein Rhythmus, der ohne Disziplin auskommt

Sicherung scheitert selten am Werkzeug und fast immer daran, dass sie nicht stattfindet. Für ein Team, das täglich im System arbeitet, hat sich dieser Ablauf bewährt:

Täglich: Commit über abapGit, oder Quelltext-Download für das, woran Sie gerade sitzen.
Einmal pro Woche: offene Transportaufträge freigeben, Dateien sichern, Ablageort notieren.
Monatlich: Inhalte der eigenen Tabellen exportieren, Rollenzuordnung aus SUIM ziehen, Zählerstände der Nummernkreise festhalten.
Vor jedem größeren Umbau: alle drei Schritte einmal vollständig, bevor die erste Änderung passiert.

Zehn Minuten pro Woche reichen dafür. Das ist weniger, als die Rekonstruktion eines einzigen verlorenen Reports kostet.

Häufige Fragen

Fragen zur Sicherung im SAP-System

Wer sichert ein SAP-System, der Betreiber oder ich?

Beide, aber Verschiedenes. Der Betreiber sichert das System als Ganzes, also Datenbank, Mandanten und Systemeinstellungen. Ihre eigenen Objekte, also Code, Customizing, Rollen und Tabelleninhalte, sichern Sie selbst über Transportaufträge, abapGit und Exporte.

Nimmt ein Transportauftrag meine Tabelleninhalte mit?

Von allein nicht. Der Auftrag transportiert die Definition der Tabelle, nicht die Zeilen darin. Zwei Ausnahmen: Bei Customizing-Tabellen mit Standardaufzeichnung werden die Einträge bei der Pflege über SM30 automatisch aufgezeichnet, und in jeden Auftrag lässt sich von Hand ein Eintrag R3TR TABU ergänzen. Für Stamm- und Bewegungsdaten und für größere Mengen bleibt der SE16N-Export oder ein eigener Download-Report der Weg.

Wie sichere ich ABAP-Code außerhalb des SAP-Systems?

Über abapGit in ein eigenes Git-Repository. Eclipse mit den ABAP Development Tools ist dafür kein Ersatz: Der Workspace hält nur einen begrenzten Zwischenspeicher und eine Local History vor, beides verschwindet mit dem Workspace.

Was passiert, wenn ich versehentlich ein Programm überschreibe?

Nichts weiter sichern und nicht aktivieren. Haben Sie nur gesichert, lässt sich der zuletzt aktive Stand im Editor noch anzeigen. Danach die Versionsverwaltung prüfen: Versionen entstehen bei der Freigabe eines Transportauftrags, nicht beim Aktivieren. Lag das Objekt nie in einem freigegebenen Auftrag, ist dort nichts. Bleiben freigegebene Transportaufträge und ein eventuelles Git-Repository.

Kann ich auf einem gemieteten SAP-System einen Stand von gestern zurückholen?

Auf einem dedizierten Server ja, gegen Aufwand. Auf einem geteilten System nicht auf Zuruf: Wiederhergestellt wird immer die ganze Datenbank, nie ein einzelner Mandant. Bliebe der Umweg über ein Ausweichsystem und eine Mandantenkopie, der freie Hardware voraussetzt, dauert und kostet.

Wandern Benutzer und ihre Rollenzuordnung mit einem Transport?

Die Rolle mit ihren Berechtigungsdaten ja. Die Benutzerzuordnung nur, wenn Sie es beim Transport aus PFCG ausdrücklich anhaken, und auch dann kann sie im Zielsystem über den Schalter USER_REL_IMPORT in der Tabelle PRGN_CUST gesperrt sein. Für eine Sicherung ist der verlässliche Weg die Auswertung in SUIM oder ein Export der Tabelle AGR_USERS.

Warum sind meine Entwicklungen nach einem Systemwechsel weg?

Meistens, weil sie als lokales Objekt gespeichert wurden. Lokale Objekte liegen in keinem Transportauftrag und können das System nicht verlassen. In SE16N zeigt die Tabelle TADIR mit dem Filter DEVCLASS gleich $* , welche Objekte davon betroffen sind, denn jedes Paket mit einem $ am Anfang ist lokal.

Wie transportiere ich eine SAP Query?

Das hängt am Arbeitsbereich. Im globalen Bereich sind Query-Objekte mandantenübergreifend und gehen im normalen Workbench-Auftrag mit. Im Standardbereich, der Voreinstellung, läuft es über den Report RSAQR3TR, und die Reihenfolge ist wichtig: erst die Benutzergruppe, dann das Infoset, dann die Query.

Wie oft sollte ich sichern?

Code täglich, wenn Sie täglich entwickeln. Customizing und Transporte einmal pro Woche. Tabelleninhalte monatlich und immer vor einem größeren Umbau.

Wenn Ihr Testsystem gemietet ist

Diese Seite schreibt jemand, der SAP-Systeme vermietet. Das ist der Grund, warum die Trennlinie zwischen Betreiber und Anwender hier so genau steht: Wir bekommen die Frage regelmäßig, und die ehrliche Antwort verkauft manchmal das kleinere Produkt.

Welches System zu Ihrem Vorhaben passt, zeigt der Sandbox-Finder in wenigen Fragen, ohne Anmeldung.

Passendes System finden

Quellen und Werkzeuge

Die genannten Transaktionen und Reports sind SAP-Standard und in jedem ERP- oder S/4HANA-System vorhanden: SE09 und SE10 für Transportaufträge, SE38 und SE80 für den Quelltext, SE16N für Tabelleninhalte, SNRO für Nummernkreise, SUIM für Benutzer- und Rollenauswertungen, RSAQR3TR für Queries, RSTRANSP für Varianten. abapGit ist ein offenes Werkzeug und nicht Teil des SAP-Standards, es wird im System installiert. Die ABAP Development Tools für Eclipse stellt SAP bereit.

Wlad

https://winim.com