System- und Mandanteneinstellungen 
System- und Mandanteneinstellungen
Einsystemlandschaft
Jeder Mandant besitzt eine bestimmte Konfiguration, die von seiner Rolle innerhalb des Systems abhängt. Diese Konfiguration kann aufgrund der speziellen Anforderungen in einer Einsystemlandschaft während der Projektlaufzeit variieren.
Systemeinstellung
Die Systemänderbarkeit definiert die vorhandene Customizing- und Entwicklungsfunktionalität in einem R/3-System. Diese Einstellungen stellen die Grundlage dar, auf der die Mandanteneinstellungen aufbauen. In den folgenden Abschnitten wird detailliert auf die Konfiguration der einzelnen Mandanten eingegangen.
Besitzen Sie ein Ready-to-Run-R/3-System, so ist die Systemänderbarkeit für Ihr Produktivsystem wie in folgender Tabelle eingestellt. Sollten Sie kein Ready-to-Run-R/3-System besitzen, so empfehlen wir Ihnen, das System anhand der unten aufgeführten Einstellungen zu konfigurieren.
Systemeinstellung in der Einsystemlandschaft
R/3-System |
Optionen |
Produktivsystem <PRD> |
Alle Objekte (mit Workbench Organizer) |
Die Einstellung der Systemänderbarkeit erlaubt es, beliebige Änderungen an allen Objekten im Produktivsystem vorzunehmen! Deswegen ist eine strikte Einhaltung der vorgeschlagenen Mandantenkonfiguration unbedingt notwendig.
Mandanteneinstellungen für <PRD>
Die Mandanteneinstellungen definieren die Customizing- und Entwicklungsfunktionen im R/3-System. Diese Einstellungen übersteuern die Systemänderbarkeit nicht.
Übersicht der Mandanten im Produktivsystem <PRD>
Die folgende Abbildung zeigt die Detailansicht eines ausgewählten Mandanten am Beispiel des Customizing- und Entwicklungsmandanten 200:
Mandanteneinstellungen am Beispiel des Mandanten 200 im System <PRD> (Das Ändern von mandantenunabhängigen Objekten ist in diesem Mandanten standardmäßig gesperrt. Er soll nur temporär für mandantenübergreifende Änderungen geöffnet werden.)
Beschreibung der Mandanten im Produktivsystem <PRD>
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen.
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen.
Die Standardmandanten 000 und 001 dürfen niemals verändert oder gelöscht werden!
Im Mandanten CUST (200) werden alle Änderungen automatisch aufgezeichnet und in Änderungsaufträgen abgelegt. Nur in diesem Mandanten ist mandantenunabhängiges Customizing erlaubt. Dieser Mandant wird auch für Programmentwicklungen verwendet. Es sollen keine Testdaten angelegt und keine Tests durchgeführt werden. Am Ende dieser Phase müssen alle mandantenübergreifenden Aufträge freigegeben werden.
Das Ändern von mandantenunabhängigen Objekten ist standardmäßig gesperrt. Dieser Mandant soll nur temporär für mandantenübergreifende Änderungen geöffnet werden. Beachten Sie hierbei unbedingt, daß sich diese Änderungen unmittelbar auf alle anderen Mandanten auswirken.
Der "Spielmandant" bietet die Möglichkeit, sich mit dem System vertraut zu machen und Anwendungen oder Customizing-Funktionen zu testen. In diesem Mandanten ist mandantenabhängiges Customizing erlaubt, Änderungen werden nicht aufgezeichnet. Alle Änderungen, die Sie hier vornehmen und dauerhaft in Ihrem System erhalten wollen, müssen Sie manuell im Mandanten CUST (200) wiederholen. Der Mandant SAND (210) kann vom Administrator über eine Mandantenkopie aus CUST (200) jederzeit aktualisiert werden.
Dieser Mandant erfüllt zwei Funktionen. Er wird für die Überprüfung der Customizing- und Entwicklungsänderungen vor dem Intregrationstest benutzt. Des weiteren wird er benutzt, um den Schulungsmandanten TRNG (310) vor einer Schulung initial aufzubauen und somit allen Schulungen die gleichen Startbedingungen zu bieten. Im Mandanten QTST können Sie keine Änderungen an Repository-Objekten durchführen. Mandantenunabhängiges Customizing ist ebenso wenig möglich, wie die Änderung mandantenabhängiger Objekte.
Dieser Mandant dient zur Ausbildung der Endanwender. Um ein realitätsnahes Training zu gewährleisten, sind in diesem Mandanten Stamm- und Bewegungsdaten vorhanden. Es sind weder Entwicklungen, noch mandantenunabhängiges Customizing erlaubt. Die Funktion zur Änderung mandantenabhängiger Objekte ist ebenfalls abgeschaltet.
Die Einstellung von TRNG über eine Mandantenkopie bedeutet einen Verlust aller Stamm- und Bewegungsdaten. Verwenden Sie für den Transport von Aufträgen stattdessen den Transaktionscode SCC1 .
In diesem Mandanten findet die produktive Arbeit des Unternehmens statt. Sie dürfen aus Sicherheitsgründen im Produktivmandanten keine mandantenabhängigen Customizingeinstellungen oder Änderungen an Repositoryobjekten durchführen.
Die Integrationstests werden im Vorproduktivmandanten durchgeführt. Das Testen kann bereits mit Stamm- und Bewegungsdaten, die aus dem Altsystem übernommen wurden, stattfinden. Im Vorproduktivmandanten können Sie keine Änderungen an Repositoryobjekten oder mandantenunabhängiges Customizing durchführen. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann. Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Produktivsystem <PRD>:
Einstellungen der Mandanten im Produktivsystem <PRD> (1)
Einstellungen |
000/001 |
CUST (200) |
SAND (210) |
QTST (300) |
Änderungen an mandanten- |
keine Änderungen erlaubt |
Änderungen werden automatisch aufgezeichnet |
Änderungen ohne automatische Aufzeichnung |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing, bei Bedarf temporär für Änderungen zu öffnen |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz vor Mandantenkopierern |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 0: Keine Beschränkung |
Rolle des Mandanten |
SAP-Referenz |
Customizing/ Entwicklung |
Spielmandant |
Test |
Einstellungen der Mandanten im Produktivsystem <PRD> (2)
Einstellungen |
TRNG (310) |
PROD (400) |
PPRD (410) |
066 |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz vor Mandantenkopierer |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Rolle des Mandanten |
Schulung |
Produktiv |
Vorproduktiv |
SAP-Early-Watch |
Aufbau der Mandanten
Die folgende Abbildung skizziert den Aufbau der Mandanten über Mandantenkopien bzw. Transporte in der hier vorliegenden Einsystemlandschaft:
Mandantenaufbau in <PRD>
Aufbau der Mandanten in <PRD>
Alle Mandanten im Produktivsystem <PRD> werden initial bei der Systeminstallation durch eine Mandantenkopie des SAP Standardmandanten 000 erzeugt.
Die beiden Mandanten SAND (210) und TRNG (310) werden bei Bedarf neu aufgebaut. Dies erfolgt durch den Systemadministrator über eine Mandantenkopie (Transaktionscode
SCCL ). Zum Beispiel kann vor Beginn einer Endanwenderschulung der Schulungsmandant TRNG (310) durch eine Mandantenkopie aus dem Mandanten QTST (300) aufgebaut werden, so daß jede Schulung auf einem identischen Stand aufsetzen kann.Die folgende Tabelle gibt einen Überblick:
Mandantenaufbau in <PRD> über Mandantenkopie durch den Systemadministrator
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<PRD> |
CUST (200) |
SAND (210) |
Mandantenaufbau |
nach Bedarf |
1 |
|
QTST (300) |
TRNG (310) |
Mandantenaufbau |
nach Bedarf |
2 |
Die beiden Mandanten QTST (300) und TRNG (310) werden zusätzlich noch mit den in Mandanten CUST (200) durchgeführten Customizingänderungen versorgt. Nach Abschluß jeder Arbeitseinheit kopiert jeder Projektmitarbeiter, der Customizingänderungen durchgeführt hat, seine eigenen Aufgaben in beide Mandanten (Transaktionscode
SCC1 ):Mandantenaufbau in <PRD> über Transportaufträge durch Projektmitarbeiter
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<PRD> |
CUST (200) |
QTST (300) |
Customizing |
nach Bedarf |
A |
|
TRNG (310) |
Customizing |
nach Bedarf |
B |
Der Produktivmandant PROD (400) und der Vorproduktivmandant PPRD (410) werden bei der Systeminstallation durch Mandantenkopie aus Mandant 000 heraus aufgebaut.
Die getesteten Transportaufträge mit den Customizingänderungen und den Entwicklungen aus Mandant CUST (200) werden, wie in der Tabelle oben skizziert, in den Mandanten PPRD (410) importiert. In diesem Mandanten PPRD (410) findet der Integrationstest statt. Nach Abschluß des Integrationstests wird auch der Produktivmandant PROD (400) mit den Transportaufträgen aus dem Mandanten CUST (200) versorgt.
Löschen Sie in der Projektphase keine Dateien in
Die folgende Tabelle gibt noch einmal einen Überblick über den Transport von Änderungsaufträgen in der Einsystemlandschaft. Die Transporte erfolgen durch den Systemadministrator. Soll in den Vorproduktivmandanten PPRD (410) transportiert werden, so müssen die Aufträge durch den Projektleiter freigegeben sein. Transporte in den Produktivmandanten PROD (400) erfolgen nach erfolgreichem Integrationstest
Transport von Änderungsaufträgen in einer Einsystemlandschaft
Quellsystem |
Zielsystem |
|||||||
R/3-System |
R/3-System |
Zielmandant |
Grund |
Zeitpunkt |
Referenz | |||
<PRD> |
<PRD> |
PPRD (410) |
Customizing + Entwicklungen |
Integrationstest |
D | |||
|
PROD (400) |
Customizing + Entwicklungen |
Nach erfolgreichem Integrationstest |
E | |||||
System und Mandanteneinstellungen in einer Zweisystemlandschaft
Jedes System hat innerhalb der Systemlandschaft eine bestimmte Rolle und somit auch eine dieser Rolle entsprechende Konfiguration. Ebenso hat jeder Mandant eines Systems eine ihm entsprechende Einstellung.
Systemeinstellung
Die Systemänderbarkeit definiert die vorhandene Customizing- und Entwicklungsfunktionalität in einem R/3-System. Diese Einstellungen stellen die Grundlage dar, auf der die Mandanteneinstellungen aufbauen. In den folgenden Abschnitten wird detailliert auf die Konfiguration der einzelnen Mandanten eingegangen.
Besitzen Sie ein Ready-to-Run-R/3-System, so sind die Systemänderbarkeiten für Entwicklungs- bzw. Produktivsystem wie in folgenden Tabelle eingestellt. Sollten Sie kein Ready-to-Run-R/3-System besitzen, so empfehlen wir Ihnen, das System anhand der unten aufgeführten Einstellungen zu konfigurieren.
Systemeinstellungen in der Zweisystemlandschaft
R/3-System |
Optionen |
Entwicklungssystem <DEV> |
Alle Objekte (mit Workbench Organizer) |
Produktivsystem <PRD> |
Objekte sind nicht änderbar. |
Mandanteneinstellungen für <DEV>
Die Mandanteneinstellungen definieren die Customizing- und Entwicklungsfunktionen im R/3-System. Diese Einstellungen übersteuern die Systemänderbarkeit nicht.
Übersicht Mandanteneinstellungen im Entwicklungssystem <DEV> (Zweisystemlandschaft)
Beschreibung der Mandanten im Entwicklungssystem <DEV> (Zweisystemlandschaft)
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 000 darf nie verändert oder gelöscht werden!
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 001 darf wie Mandant 000 nie verändert oder gelöscht werden!
Im Mandanten CUST (200) werden alle Änderungen automatisch aufgezeichnet und in Änderungsaufträgen abgelegt. Nur in diesem Mandanten ist mandantenunabhängiges Customizing erlaubt. Es sollen keine Testdaten angelegt und keine Tests durchgeführt werden
Dieser Mandant wird auch für Programmentwicklungen verwendet.
Dieser Mandant dient als Spielmandant, der Ihnen die Möglichkeit bietet, sich mit dem System vertraut zu machen und Anwendungen oder Customizing-Funktionen zu testen. In diesem Mandanten ist mandantenabhängiges Customizing erlaubt, Änderungen werden nicht aufgezeichnet. Alle Änderungen, die Sie hier vornehmen und dauerhaft in Ihrem System erhalten wollen, müssen Sie manuell im Mandanten CUST (200) wiederholen. Der Mandant SAND (210) kann vom Administrator über eine Mandantenkopie aus CUST (200) jederzeit aktualisiert werden.
Dieser Mandant erfüllt zwei Funktionen. Er wird für die Überprüfung der Customizing- und Entwicklungsänderungen vor dem Intregrationstest benutzt. Des weiteren wird er benutzt, den Schulungsmandanten TRNG (310) vor einer Schulung initial aufzubauen, um allen Schulungen die gleichen Startbedingungen zu gewährleisten. In diesem Mandanten können Sie keine Änderungen an Repositoryobjekten oder mandantenunabhängiges Customizing durchführen. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Dieser Mandant dient der Ausbildung der Endanwender. Um ein realitätsnahes Training zu gewährleisten, sind in diesem Mandanten Stamm- und Bewegungsdaten vorhanden. Es sind keine Entwicklungen und kein mandantenunabhängiges Customizing erlaubt. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Die Einstellung von TRNG über eine Mandantenkopie bedeutet einen Verlust aller Stamm- und Bewegungsdaten. Verwenden Sie für den Transport von Aufträgen stattdessen den Transaktionscode SCC1 .
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann.
Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Entwicklungssystem <DEV>:
Einstellungen der Mandanten im Entwicklungssystem <DEV> (1)
Einstellungen |
000 |
001 |
CUST (200) |
SAND (210) |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen werden automatisch aufgezeichnet |
Änderungen ohne automatische Aufzeichnung |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Änderungen an Repository und mand.unabh. Customizing erlaubt |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 0: Keine Beschränkung |
Rolle des Mandanten |
SAP-Referenz |
SAP-Referenz |
Customizing/ Entwicklung |
Spielmandant |
Einstellungen der Mandanten im Entwicklungssystem <DEV>(2)
Einstellungen |
QTST (300) |
TRNG (310) |
066 |
Änderungen an mandanten |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 1: |
Rolle des Mandanten |
Test |
Schulung |
SAP-Early-Watch |
Mandanteneinstellungen für <PRD> (Zweisystemlandschaft)
Im Produktivsystem sind folgende Mandanten angelegt:
Übersicht Mandantenpflege im Produktivsystem <PRD> einer Zweisystemlandschaft
Beschreibung der Mandanten im Produktivsystem <PRD>
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 000 darf nie verändert oder gelöscht werden!
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 001 darf wie Mandant 000 nie verändert oder gelöscht werden!
In diesem Mandanten findet die produktive Arbeit des Unternehmens statt. Obwohl die eingestellte Systemänderbarkeit des Produktivsystems für alle Mandanten maßgebend ist, dürfen Sie aus Sicherheitsgründen keine mandantenabhängigen Customizingeinstellungen oder Änderungen an Repositoryobjekten durchführen.
Die Integrationstests werden im Vorproduktivmandanten durchgeführt. Das Testen kann bereits mit Stamm- und Bewegungsdaten, die aus dem Altsystem übernommen wurden, stattfinden. Im Integrationsmandanten können Sie keine Änderungen an Repositoryobjekten oder mandantenunabhängiges Customizing durchführen. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann. Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Produktivsystem <PRD>:
Einstellungen der Mandanten im Produktivsystem <PRD>
Einstellungen |
000 / 001 |
PROD (400) |
PPRD (410) |
066 |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Rolle des Mandanten |
SAP-Referenz |
Produktiv |
Vorproduktiv-mandant Integrationstest |
SAP-Early-Watch |
Aufbau der Mandanten
Die folgende Abbildung skizziert den Aufbau der Mandanten über Mandantenkopien bzw. Transporte in der hier vorliegenden Zweisystemlandschaft:
Mandantenaufbau in <DEV> und <PRD>
Aufbau der Mandanten im <DEV>
Alle Mandanten im Entwicklungssystem <DEV> werden initial bei der Systeminstallation durch eine Mandantenkopie des SAP Standardmandanten 000 erzeugt.
Die beiden Mandanten SAND (210) und TRNG (310) werden bei Bedarf neu aufgebaut. Dies erfolgt durch den Systemadministrator über eine Mandantenkopie (Transaktionscode SCCL). Zum Beispiel kann vor Beginn einer Endanwenderschulung der Schulungsmandant TRNG (310) durch eine Mandantenkopie aus dem Mandanten QTST (300) des Entwicklungssystems <DEV> aufgebaut werden, so daß jede Schulung auf einem identischen Stand aufsetzen kann. Die nachfolgende Tabelle liefert einen Überblick:
Aufbau der Mandanten in <DEV> über Mandantenkopie durch den Systemadministrator
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<DEV> |
CUST (200) |
SAND (210) |
Mandantenaufbau |
nach Bedarf |
1 |
|
QTST (300) |
TRNG (310) |
Mandantenaufbau |
nach Bedarf |
2 |
Die beiden Mandanten QTST (300) und TRNG (310) werden zusätzlich noch mit den in Mandanten CUST (200) durchgeführten Customizingänderungen versorgt. Nach Abschluß jeder Arbeitseinheit kopiert jeder Projektmitarbeiter, der Customizing-Änderungen durchgeführt hat, seine eigenen Aufgaben in beide Mandanten (Transaktionscode SCC1):
Mandantenaufbau in <DEV> über Transportaufträge durch Projektmitarbeiter
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<DEV> |
CUST (200) |
QTST (300) |
Customizing |
nach Bedarf |
A |
|
TRNG (310) |
Customizing |
nach Bedarf |
B |
Aufbau der Mandanten im <PRD>
Der Produktivmandant PROD (400) und der Vorproduktivmandant PPRD (410) werden bei der Systeminstallation durch Mandantenkopie aus Mandant 000 heraus aufgebaut.
Die getesteten Transportaufträge mit den Customizingänderungen und den Entwicklungen aus Mandant CUST (200) werden, wie in der Tabelle oben skizziert, in den Mandanten PPRD (410) importiert. In diesem Mandanten PPRD (410) findet der Integrationstest statt. Nach Abschluß des Integrationstests wird auch der Produktivmandant PROD (400) mit den Transportaufträgen aus dem Mandanten CUST (200) des Entwicklungssystems <DEV> versorgt.
Löschen Sie in der Projektphase keine Dateien in
Die folgende Tabelle liefert eine Zusammenfassung des Transportes von Änderungsaufträgen in der Zweisystemlandschaft. Die Transporte erfolgen durch den Systemadministrator. Soll in den Vorproduktivmandanten PPRD (410) transportiert werden, so müssen die Aufträge durch den Projektleiter freigegeben sein. Transporte in den Produktivmandanten PROD (400) erfolgen nach erfolgreichem Integrationstest.
Transport von Änderungsaufträgen in einer Zweisystemlandschaft
Quellsystem |
Zielsystem |
||||||||
R/3-System |
Quellmandant |
R/3-System |
Zielmandant |
Grund |
Zeitpunkt |
Referenz | |||
<DEV> |
CUST (200) |
<PRD> |
PPRD (410) |
Customizing + Entwicklungen |
Integrationstest |
C | |||
<DEV> |
CUST (200) |
<PRD> |
PROD (400) |
Customizing + Entwicklungen |
Nach erfolgreichem Integrationstest |
D | |||
System und Mandanteneinstellungen in einer Dreisystemlandschaft
Jedes System hat innerhalb der Systemlandschaft eine bestimmte Rolle und somit auch eine dieser Rolle entsprechende Konfiguration. Ebenso hat jeder Mandant eines Systems eine ihm entsprechende Einstellung.
Systemeinstellung
Die Systemänderbarkeit definiert die vorhandene Customizing- und Entwicklungsfunktionalität in einem R/3-System. Diese Einstellungen stellen die Grundlage dar, auf der die Mandanteneinstellungen aufbauen. In den folgenden Abschnitten wird detailliert auf die Konfiguration der einzelnen Mandanten eingegangen.
Wir empfehlen Ihnen, das System anhand der unten aufgeführten Einstellungen zu konfigurieren.
Systemeinstellungen in der Dreisystemlandschaft
R/3-System |
Optionen |
Entwicklungssystem <DEV> |
Alle Objekte (mit Workbench Organizer) |
Qualitätssicherungssystem <QAS> |
Objekte sind nicht änderbar |
Produktivsystem <PRD> |
Objekte sind nicht änderbar. |
Mandanteneinstellungen für <DEV>
Die Mandanteneinstellungen definieren die Customizing- und Entwicklungsfunktionen im R/3-System. Diese Einstellungen übersteuern die Systemänderbarkeit nicht.
Übersicht Mandanteneinstellungen im Entwicklungssystem <DEV> (Dreisystemlandschaft)
Beschreibung der Mandanten im Entwicklungssystem <DEV> (Zweisystemlandschaft)
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 000 darf nie verändert oder gelöscht werden!
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 001 darf wie Mandant 000 nie verändert oder gelöscht werden!
Im Mandanten CUST (200) werden alle Änderungen automatisch aufgezeichnet und in Änderungsaufträgen abgelegt. Nur in diesem Mandanten ist mandantenunabhängiges Customizing erlaubt. Es sollen keine Testdaten angelegt und keine Tests durchgeführt werden
Dieser Mandant wird auch für Programmentwicklungen verwendet.
Dieser Mandant dient als Spielmandant, der Ihnen die Möglichkeit bietet, sich mit dem System vertraut zu machen und Anwendungen oder Customizing-Funktionen zu testen. In diesem Mandanten ist mandantenabhängiges Customizing erlaubt, Änderungen werden nicht aufgezeichnet. Alle Änderungen, die Sie hier vornehmen und dauerhaft in Ihrem System erhalten wollen, müssen Sie manuell im Mandanten CUST (200) wiederholen. Der Mandant SAND (210) kann vom Administrator über eine Mandantenkopie aus CUST (200) jederzeit aktualisiert werden.
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann.
Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Entwicklungssystem <DEV>:
Einstellungen der Mandanten im Entwicklungssystem <DEV> (1)
Einstellungen |
000 |
001 |
CUST (200) |
SAND (210) |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen werden automatisch aufgezeichnet |
Änderungen ohne automatische Aufzeichnung |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Änderungen an Repository und mand.unabh. Customizing erlaubt |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 0: Keine Beschränkung |
Rolle des Mandanten |
SAP-Referenz |
SAP-Referenz |
Customizing/ Entwicklung |
Spielmandant |
Einstellungen der Mandanten im Entwicklungssystem <DEV>(2)
Einstellungen |
066 |
Änderungen an mandanten |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Rolle des Mandanten |
SAP-Early-Watch |
Mandanteneinstellungen für <QAS>
Die Mandanteneinstellungen definieren die Customizing- und Entwicklungsfunktionen im R/3-System. Diese Einstellungen übersteuern die Systemänderbarkeit nicht.
Übersicht Mandanteneinstellungen im Qualitätssicherungssystem <QAS> (Dreisystemlandschaft)
Beschreibung der Mandanten im Qualitätssicherungssystem <QAS> (Dreisystemlandschaft)
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 000 darf nie verändert oder gelöscht werden!
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 001 darf wie Mandant 000 nie verändert oder gelöscht werden!
Dieser Mandant erfüllt zwei Funktionen. Er wird für die Überprüfung der Customizing- und Entwicklungsänderungen vor dem Intregrationstest benutzt. Des weiteren wird er benutzt, den Schulungsmandanten TRNG (310) vor einer Schulung initial aufzubauen, um allen Schulungen die gleichen Startbedingungen zu gewährleisten. In diesem Mandanten können Sie keine Änderungen an Repositoryobjekten oder mandantenunabhängiges Customizing durchführen. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Dieser Mandant dient der Ausbildung der Endanwender. Um ein realitätsnahes Training zu gewährleisten, sind in diesem Mandanten Stamm- und Bewegungsdaten vorhanden. Es sind keine Entwicklungen und kein mandantenunabhängiges Customizing erlaubt. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Die Einstellung von TRNG über eine Mandantenkopie bedeutet einen Verlust aller Stamm- und Bewegungsdaten. Die Versorgung des Mandanten 310 mit allen Customizing- und Entwicklungsänderungen sollte daher durch Weiterleitung der in den Mandanten 300 importierten Transportaufträge erfolgen..
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann.
Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Qualitätssicherungssystem <QAS>:
Einstellungen der Mandanten im Qualitätssicherungssystem <QAS> (1)
Einstellungen |
000 |
001 |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Schutzstufe 1: |
Rolle des Mandanten |
SAP-Referenz |
SAP-Referenz |
Einstellungen der Mandanten im Qualitätssicherungssystem <QAS>(2)
Einstellungen |
QTST (300) |
TRNG (310) |
066 |
Änderungen an mandanten |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 0: Keine Beschränkung |
Schutzstufe 1: |
Rolle des Mandanten |
Test |
Schulung |
SAP-Early-Watch |
Mandanteneinstellungen für <PRD> (Dreisystemlandschaft)
Im Produktivsystem sind folgende Mandanten angelegt:
Übersicht Mandantenpflege im Produktivsystem <PRD> einer Dreisystemlandschaft
Beschreibung der Mandanten im Produktivsystem <PRD>
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 000 darf nie verändert oder gelöscht werden!
Dieser Mandant wird dazu benutzt, neutrale Mandanten per Mandantenkopie aufzubauen. Der Mandant 001 darf wie Mandant 000 nie verändert oder gelöscht werden!
In diesem Mandanten findet die produktive Arbeit des Unternehmens statt. Obwohl die eingestellte Systemänderbarkeit des Produktivsystems für alle Mandanten maßgebend ist, dürfen Sie aus Sicherheitsgründen keine mandantenabhängigen und -unabhängigen Customizingeinstellungen oder Änderungen an Repositoryobjekten durchführen.
Die Integrationstests werden im Vorproduktivmandanten durchgeführt. Das Testen kann bereits mit Stamm- und Bewegungsdaten, die aus dem Altsystem übernommen wurden, stattfinden. Im Integrationsmandanten können Sie keine Änderungen an Repositoryobjekten oder mandantenunabhängiges Customizing durchführen. Die Funktion zur Änderung mandantenabhängiger Objekte ist in diesem Mandanten ebenfalls abgeschaltet.
Dieser Mandant ist ein reiner Servicemandant, mit dem SAP remote auf das Kundensystem hinsichtlich Fehler- und Performanceanalyse zugreifen kann. Dieser Mandant darf nie verändert oder gelöscht werden!
Die folgende Tabelle gibt einen Überblick über die Einstellungen der Mandanten im Produktivsystem <PRD>:
Einstellungen der Mandanten im Produktivsystem <PRD>
Einstellungen |
000 / 001 |
PROD (400) |
PPRD (410) |
066 |
Änderungen an mandanten- |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
keine Änderungen erlaubt |
Änderungen an mandanten- |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
keine Änderungen an Repository und Customizing |
Schutz bzgl Mandantenkopierer |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Schutzstufe 1: |
Rolle des Mandanten |
SAP-Referenz |
Produktiv |
Vorproduktiv-mandant Integrationstest |
SAP-Early-Watch |
Aufbau der Mandanten
Die folgende Abbildung skizziert den Aufbau der Mandanten über Mandantenkopien bzw. Transporte in der hier vorliegenden Dreisystemlandschaft:
Mandantenaufbau in <DEV>, <QAS> und <PRD>
Aufbau der Mandanten im <DEV>
Alle Mandanten im Entwicklungssystem <DEV> werden initial bei der Systeminstallation durch eine Mandantenkopie des SAP Standardmandanten 000 erzeugt.
Der Mandant SAND (210) wird bei Bedarf neu aufgebaut. Dies erfolgt durch den Systemadministrator über eine Mandantenkopie (Transaktionscode SCCL). Die nachfolgende Tabelle liefert einen Überblick:
Aufbau der Mandanten in <DEV> über Mandantenkopie durch den Systemadministrator
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<DEV> |
CUST (200) |
SAND (210) |
Mandantenaufbau |
nach Bedarf |
1 |
Aufbau der Mandanten im <QAS>
Alle Mandanten im Qualitätssicherungssystem <QAS> werden initial bei der Systeminstallation durch eine Mandantenkopie des SAP Standardmandanten 000 erzeugt.
Der Mandant TRNG (310) wird bei Bedarf neu aufgebaut. Dies erfolgt durch den Systemadministrator über eine Mandantenkopie (Transaktionscode SCCL). Zum Beispiel kann vor Beginn einer Endanwenderschulung der Schulungsmandant TRNG (310) durch eine Mandantenkopie aus dem Mandanten QTST (300) aufgebaut werden, so daß jede Schulung auf einem identischen Stand aufsetzen kann. Die nachfolgende Tabelle liefert einen Überblick:
Aufbau der Mandanten in <QAS> über Mandantenkopie durch den Systemadministrator
R/3-System |
Quellmandant |
Zielmandant |
Grund |
Zeitpunkt |
Referenz |
<QAS> |
QTST (300) |
TRNG (310) |
Mandantenaufbau |
nach Bedarf |
2 |
Die beiden Mandanten QTST (300) und TRNG (310) werden zusätzlich noch mit den in Mandanten CUST (200) im <DEV> durchgeführten Customizingänderungen und Entwicklungen versorgt. Nach Abschluß jeder Arbeitseinheit gibt das Projektmitglied den Auftrag im <DEV> frei. Der Systemadministrator transportiert den exportierten Auftrag zunächst in den Mandant QTST im <QAS> und nach erfolgreichem Test per Weiterleitung in den Mandanten 310 im <QAS>.
Mandantenversorgung in <QAS> über Transportaufträge durch den Systemadministrator
Quellsystem |
Zielsystem |
||||||||
R/3-System |
Quellmandant |
R/3-System |
Zielmandant |
Grund |
Zeitpunkt |
Referenz | |||
<DEV> |
CUST (200) |
<QAS> |
QTST (300) |
Customizing + Entwicklungen |
nach Bedarf |
A (Transport) | |||
<DEV> |
CUST (200) |
<QAS> |
TRNG (310) |
Customizing + Entwicklungen |
nach Bedarf |
B (Weiterleitung) | |||
Aufbau der Mandanten im <PRD>
Der Produktivmandant PROD (400) und der Vorproduktivmandant PPRD (410) werden bei der Systeminstallation durch Mandantenkopie aus Mandant 000 heraus aufgebaut.
Die getesteten Transportaufträge mit den Customizingänderungen und den Entwicklungen aus Mandant CUST (200) werden, wie in der Tabelle oben skizziert, in den Mandanten PPRD (410) importiert. In diesem Mandanten PPRD (410) findet der Integrationstest statt. Nach Abschluß des Integrationstests wird auch der Produktivmandant PROD (400) mit den Transportaufträgen aus dem Mandanten CUST (200) des Entwicklungssystems <DEV> versorgt. In beiden Fällen handelt es sich um eine Weiterleitung des Transports A.
Löschen Sie in der Projektphase keine Dateien in
Die folgende Tabelle liefert eine Zusammenfassung des Transportes von Änderungsaufträgen in der Dreisystemlandschaft. Die Transporte erfolgen durch den Systemadministrator. Soll in den Vorproduktivmandanten PPRD (410) transportiert werden, so müssen die Aufträge bereits vorher in den Mandanten 300 im <QAS> importiert und getestet worden sein. Transporte in den Produktivmandanten PROD (400) erfolgen nach erfolgreichem Integrationstest.
Transport von Änderungsaufträgen in einer Zweisystemlandschaft
Quellsystem |
Zielsystem |
||||||||
R/3-System |
Quellmandant |
R/3-System |
Zielmandant |
Grund |
Zeitpunkt |
Referenz | |||
<DEV> |
CUST (200) |
<PRD> |
PPRD (410) |
Customizing + Entwicklungen |
Integrationstest |
C (Weiter-leitung) | |||
<DEV> |
CUST (200) |
<PRD> |
PROD (400) |
Customizing + Entwicklungen |
Nach erfolgreichem Integrationstest |
D (Weiter-leitung) | |||