Mandantenmanagement

Grundlagen

Unter Mehrmandantenfähigkeit verstehen wir die mandantenbezogene Datentrennung innerhalb einer CURSOR-Instanz (=Systeminstallation). Die Mehrmandantenfähigkeit erlaubt den Betrieb mehrerer Einheiten (Units) in derselben Systemumgebung. Damit reduzieren sich die pro Einheit erforderlichen Systemressourcen und der damit verbundene Wartungsaufwand. Die Trennung der Daten zwischen den Mandanten kann – je nach Verfahren – vollständig oder partiell ausgelegt werden. Bei partieller Trennung reduziert sich die Datenpflege für gemeinsam genutzte Datenbereiche. Als Einheit (Mandant bzw. Unit) kommen sowohl Rechtseinheiten (Unternehmen, Betriebe, etc.), als auch unternehmensinterne Organisationseinheiten (Geschäftsbereiche, Markenbereiche, Profitcenter, o.ä.) in Betracht.

Vorteile der Lösung:

• Die Mehrmandantenfähigkeit führt zu einer Reduktion des Ressourcenbedarfs (Hauptspeicher, Platte, etc.)

• Die Mehrmandantenfähigkeit verringert den Administrationsbedarf (bei Installation, Konfiguration, Updates und Patches)

• Die relativen Betriebskosten pro Mandant reduzieren sich in einer Mehrmandantenumgebung

• Die Bereitstellung eines weiteren Mandanten erfordert minimalen Administrationsaufwand (Systeminstallation und -konfiguration)

• Für alle Mandanten identisches Customizing muss nur einmal durchgeführt werden

• Die Trennung von Geschäftsbereichen, innerhalb des gleichen Unternehmens, ist sehr einfach abbildbar (kein komplexes Rechtekonzept erforderlich)

Single-Database-Architektur

Es werden maximal 63 Mandanten unterstützt.

Mandantenführung

Alle Tabellen verfügen über ein Mandanten-Feld, um die Daten einem (oder mehreren) Mandanten zuweisen zu können. Alle Benutzer werden vom Systemadministrator einem (oder mehreren) Mandanten zugewiesen. Bei Zugriff auf die Daten wird - an allen Stellen - die Mandantenkennung des aktuellen Benutzers berücksichtigt. Für die Organisation der Daten innerhalb der gemeinsamen Datenbank, kommen folgende Verfahren zu Einsatz:

Diese werden in den nachfolgenden Use Cases beschrieben.

• In der Admin-Konsole ist es möglich die Mandanten zu pflegen und den Mitarbeitern zuzuweisen. Dazu sind gesonderte Rechte erforderlich.

• Die Lucene-Indextreffer werden auf die „sichtbaren“ Mandanten reduziert.

• Mit der Anmeldung am System gibt es pro Benutzer einen Hauptmandanten, weitere Nebenmandanten sind beim Joint Units Verfahren zulässig. Wurden Nebenmandanten zugewiesen, so sieht der Benutzer deren Daten zusätzlich.

Separated Units

Jede Tabelle ist mit einem Mandantenfeld (Unit) ausgestattet. Der Inhalt dieses Feldes bestimmt, zu welchem Mandant ein Datensatz gehört. Nur Benutzern, die unter dieser Mandantenkennung arbeiten, ist der Datensatz zugänglich (sichtbar bzw. änderbar). Neue Datensätze erhalten ihre Mandantenzuweisung aus dem Hauptmandanten des Mitarbeiters (MainUnit.Employee).

Anwendungsfall

• Ein Application-Provider stellt einer Vielzahl kleiner und selbständiger Unternehmen eine vorkonfigurierte Out-of-the-box-Lösung bereit.

• Erweiterungen oder Änderungen an dem System sollen allen Servicenehmern gleichermaßen zugutekommen

Shared Datasets

Das Shared Data Konzept erlaubt die Zuordnung eines Datensatzes zu mehreren Mandanten. Neue Datensätze erhalten ihre Mandantenzuweisung aus einem Mandantentemplate. Im Rahmen der Benutzerrechte können jedem Satz manuell weitere Mandanten zugeordnet werden.

Anwendungsfall

• In einem Unternehmen werden drei eigenständig agierende Markenbereiche differenziert. Die drei Marken sprechen jedoch teilweise dieselben Kunden an.

• In diesem Fall ermöglicht das Shared Data Konzept die betreffenden Kunden mehreren Mandanten zuzuweisen.

Joint Units

Beim Joint Unit Konzept können den Benutzern mehrere Mandanten zugewiesen werden. Neue Datensätze erhalten ihre Mandantenzuweisung aus einem Mandantentemplate.

Anwendungsfall

• Zwei Business-Units A und B innerhalb der gleichen Unternehmung bedienen unterschiedliche Märkte (Kunden, Aufträge, etc.). Das operative Geschäft ist strikt getrennt, jedoch verwenden die Units denselben Produktstamm.

• In diesem Fall kann neben Mandant A und B ein weiterer Stammdatenmandant C eingerichtet werden. Dieser wird für alle Benutzer als Nebenmandant fungieren, um ihnen den Zugriff auf den Produktstamm zu ermöglichen.

Aktivierung Mandantenmanagement

Für die Aktivierung des Mandantenmanagements muss die Lizenz "Mandantenmanagement" aktiviert werden.“

Das Mandantenmanagement kann in einem Modulbausystem (Modul "Partnermodule erstellen" aktiv) nicht importiert werden

Initialmigration für Mandanten

Nach dem Einspielen des Moduls muss ein Mandant im System angelegt werden, der allen Benutzern zugewiesen wird. Alle bestehenden Datensätze werden ebenfalls diesem Mandanten zugewiesen.

Da alle Daten im System migriert werden, kann dieser Vorgang je nach Datenmenge und Performance des Datenbank Servers einige Zeit dauern. Hierbei dürfen keine anderen Benutzer angemeldet sein. Die Migration auf dem Referenzsystem von CURSOR mit einer ca. 12 GB großen Datenbank unter Oracle brauchte 4 Minuten.

• Bei der Migration wird das Feld ClientNo in jeder Tabelle überschrieben. Kundenspezifische Daten darf es in diesem Feld nicht geben.

• Nachdem die Konfiguration des Mandantensystems durch den Administrator abgeschlossen ist, muss der Lucene-Index komplett neu aufgebaut werden.

Mandantenspezifische Benutzerlizenzen

Auf der Mandantenmaske befinden sich die Felder "Anzahl Benutzer" und "Anzahl App-Benutzer".

Der Administrator muss mindestens so viele Lizenzen einem Mandanten zuweisen, wie bereits Benutzer des Mandanten der App- bzw. Client-Lizenz zugewiesen sind. Wird keine Anzahl der Lizenzen hinterlegt, so können beliebig viele Benutzer den Lizenzen zugewiesen werden, sofern genügend App- bzw. Client-Lizenzen insgesamt zur Verfügung stehen.

In der Modulverwaltung in der Admin-Konsole wird bei der Benutzerzuweisung neben der Gesamtzahl der App- bzw. Client-Lizenz auch die freien Lizenzen des Hauptmandanten des Mitarbeiters geprüft.

Der Administrator kann im Administrationsmenü im Bereich Berechtigungen weitere Mandanten anlegen.

Mandantenverwaltung

Über den Internationalisierungsschalter kann die Beschreibung für den Mandanten mehrsprachig hinterlegt werden. Die Pflege von Mandanten wird über das Aktionsrecht "Mandanten administrieren" (admin.unit.permission) gesteuert. Im Auslieferungszustand ist der Administrator berechtigt.

Mandanten werden per Customizing-Transport übertragen.

Ein Mitarbeiter muss immer einem Hauptmandanten zugewiesen sein. Über den Unterbereich können weitere Mandanten zugewiesen werden.

Abweichender Systembetreiber für Mandanten

Wird das Mandantenmanagement z.B. für das Hosting eingesetzt, so reicht ein Systembetreiber für das gesamte System nicht mehr aus. Hier kann im Mandant ein Systembetreiber-Datensatz optional angegeben werden. Für den Benutzer wird dann der Systembetreiber über den Hauptmandanten ermittelt und für z.B. die CTI-Schnittstelle genutzt.

Mandantenzuordnung von Datensätzen

Bei der Neuanlage von Datensätzen wird immer der Datensatz dem Hauptmandanten des aktuellen Mitarbeiters zugewiesen. Beim Laden von Datensätzen wird die Mandantenzuordnung des Datensatzes und des Benutzers geprüft und nur die Datensätze geladen, deren Mandantenverknüpfung übereinstimmt. Bei aktiver Stellvertretung nutzt der aktuelle Benutzer die Mandantenkonfiguration des stellvertretenden Benutzers.

Die Mandantenzuordnung des Datensatzes kann der Benutzer über den Mandantenschalter in der Toolbar ändern. Hierbei können nur die Mandanten des aktuellen Benutzers angepasst werden. Es muss immer mindestens ein Mandant gewählt sein, da der Benutzer sonst keine Möglichkeit mehr hätte, den Datensatz zu laden. Ist der Datensatz noch anderen Mandanten zugewiesen, die dem Benutzer nicht zugewiesen sind, so werden diese bei der Bearbeitung nicht angezeigt oder geändert.

Die Mandantenzuordnung im Personen-Umfeld weicht hiervon leicht ab. Die Zuordnung kann für Personen, Adressen und Kommunikation nicht bearbeitet werden. Diese Daten erben die Mandantenzuordnung aus den betreffenden Rollen wie Geschäftspartner, Ansprechpartner und Mitarbeiter. Dabei kann die Person mehreren Mandanten angehören, wenn die zugeordneten Geschäftspartner jeweils verschiedenen Mandanten angehören.

Zu Angebots- und Vertragspositionen können ebenfalls keine eigenen Mandantenzuordnungen getroffen werden, diese erben die Zuordnung aus dem übergeordneten Angebot bzw. Vertrag.

Die Pflege der Mandantenzuordnung zu Datensätzen wird über das Aktionsrecht "Mandanten bearbeiten" (manage.unit.permission) gesteuert.

Vererbung von Mandanten

Hierzu wurde eine Vererbung der Mandantenzuordnung für das Personen-Rollen-Modell implementiert, welche die Einschränkungen sicherstellt. Hierzu wurden folgende Punkte umgesetzt:

1. Für die Adresse werden die zugeordneten Mandanten immer von der übergeordneten Entität Person bzw. Anschlussobjekt vererbt. Die Mandantenzuordnung kann hier nicht gepflegt werden.

2. Für die Kommunikation wird die Mandantenzuordnung immer über die übergeordneten Entitäten Geschäftspartner, Ansprechpartner, Mitarbeiter und Person vererbt. Eine Pflege der Mandantenzuordnung ist nicht möglich.

3. Die Person werden immer additiv die Mandanten der Rollen Geschäftspartner, Ansprechpartner und Mitarbeiter zugeordnet. Eine manuelle Pflege der Mandantenzuordnung ist nicht möglich.

4. Der Standardansprechpartner und dessen Geschäftspartner haben immer dieselbe Mandantenzuordnung.

Für die Angebots- und Vertragsbearbeitung wurde für die Entitäten Angebots- und Vertragsposition ebenfalls die Mandantenvererbung implementiert. Die Positionen haben damit immer dieselbe Mandantenzuordnung wie das Angebot bzw. der Vertrag.

Andere abhängige Daten wie z.B. Aktivitäten oder Dokumente ändern nicht ihre Mandantenzuordnung. Wechselt ein Geschäftspartner den Mandanten, so verbleiben die Aktivitäten und Dokumente weiterhin beim alten Mandanten.

Stellvertretung im Mandantenmanagement

Arbeitet der Benutzer als Stellvertreter eines anderen Benutzers, so werden neben den Gruppen der Stellvertretenden auch die Mandantenzuordnung übernommen. Der Benutzer arbeitet damit komplett in der Mandantenkonfiguration des Stellvertretenden, was sich auf die Selektion und Neuanlage von Datensätzen auswirkt.

Administration Mandantenmanagement

Entitäten vom Mandantenmanagement ausschließen

Für kunden- (C2) oder partnerspezifische (C1) Entitäten kann der Administrator Entitäten vom Mandantenmanagement ausschließen. Über die Entitäten-Eigenschaften in der Entitäten-Konfiguration kann die Eigenschaft "Mehrmandantenfähig" gepflegt werden. Ist die Eigenschaft deaktiviert, so wird bei der Neuanlage keine Mandantenzuordnung für diese Entitäten mehr durchgeführt. Auch beim Suchen der Datensätze finde keine Prüfung der Mandantenzuordnung statt.

Wenn man die Mehrmandantenfähigkeit auf einer Entität nachträglich wieder aktiviert, muss die Mandantenzuordnung über die Datenbank explizit für bestehende Daten vorgenommen werden.

Mandantenfähige Schlüssel

Schlüssel werden bei der Migration bzw. Neuanlage automatisch allen Mandanten zugewiesen. Der Administrator kann Schlüssel aber auch nur bestimmten Mandanten zuweisen. Der Benutzer kann diese Schlüssel nicht mehr auswählen, wenn dieser einem anderen Mandanten zugewiesen ist. Hierzu kann die Mandantenzuordnung in der Schlüsselpflege durch den Administrator bearbeitet werden.

Mandanten Counter

Die Zähler in der Anwendung werden mandantenspezifisch in der Anwendung inkrementiert, je nachdem ob für die Entität das Mandantenmanagement aktiviert ist. Hierbei wird für den Hauptmandanten des Benutzers ein Zähler in der Counter Tabelle geführt. Falls bereits Zähler vor der Aktivierung des Mandantenmanagements existierten, so werden diese pro Mandant kopiert und separat weitergeführt. Ist ein systemweiter Zähler auf einer mandantenfähigen Entität gewünscht, so stehen neue Pattern in den Feldeigenschaften zur Verfügung. Siehe Feldeigenschaften.

Juhuuu Suche

Wird das Mandantenmanagement aktiviert, so muss der Lucene Index für die Juhuuu Suche neu erstellt werden, damit dort die Mandantennummer korrekt berücksichtigt wird.

Erweiterung Mandanten Management (leeren, löschen, klonen)

Das Mandanten-Management wurde um die Funktionen:

• Mandanten leeren

• Mandanten löschen

• Mandanten klonen

erweitert.

Mandanten leeren

Die Aktion kann in der Toolbar der Entität Mandanten gestartet werden

Diese löst eine Funktion aus, welche alle Bewegungsdaten (Business-Tabellen, keine C1, C2 CT Tabellen) löscht.

Es bleiben folgende Daten bestehen:

• Mitarbeiter und delegierte Daten

• Geschäftsstelle/Systembetreiber des Mandanten und delegierte Daten

• Schlüsseltabellen (S_KeyTab, Straße, ...)

• Konfiguration des DataCleaners, um z.B. eine C2-Entität nicht zu löschen

Sind Datensätze mehreren Mandanten zugeordnet, so wird die Mandantenzuordnung außer Vollmandanten-Tabellen entfernt. Offene Prozesse mit Benutzeraktionen müssen gelöscht werden, damit diese nicht auf einen Fehler laufen. Offene Jobs des Massendatenservers müssen entfernt werden (auch Prozesse).

Die Löschung erfolgt über eine Selektion der exakten Mandantennummer

Es werden alle Bewegungsdaten aus der Datenbank direkt und nicht über den Löschmandanten gelöscht.

Mandanten löschen

Die Aktion kann in der Toolbar der Entität Mandanten gestartet werden.

Der Schalter löst eine Funktion aus, welcher folgende Daten aus dem Mandanten löscht:

• Alle Bewegungsdaten

• Mitarbeiter und delegierte Daten

• Geschäftsstelle/Systembetreiber des Mandanten und delegierte Daten

• Schlüssel und alle C2-Daten, die nur diesem Mandanten zugeordnet wurden

Sind einem Datensatz mehrere Mandanten zugeordnet, so wird die Mandantenzuordnung entfernt. In Vollmandanten-Tabellen muss diese Mandantennummer immer gesetzt werden. Relationsdaten werden nachträglich bereinigt. Es ist möglich, mehrere Mandanten auf einmal zu löschen. Ein gelöschter Mandant wird an das Customizing-Paket gehängt. Es darf nur ein offenes Paket geben.

Mandanten klonen

Die Aktion kann in der Toolbar der Entität Mandanten gestartet werden.

Der Schalter löst eine Funktion aus, der den Anwender in einen Auswahldialog bringt, in dem er einen Quell-Mandanten auswählen kann. Von diesem Mandanten werden alle Customizings dem neuen Mandanten zusätzlich zugeordnet. Alle Vollmandanten-Tabellen werden auch behandelt. Bewegungsdaten werden nicht verändert. Der Hauptbenutzer (TECH_USER & Liste von Pks im PropertyMapper von Mitarbeitern, neuer PropertyMapper + PropertyConfig Eintrag, Typ de.cursor.StringList) erhalten den neuen Mandanten. Anwenderdaten des neuen Mandanten werden per XML-Import von einem Hauptbenutzer (angemeldet als neuer Mandant) angelegt.

Beim Customizing-Transport wird nur der neue Mandant angelegt. Die geänderten Customizings werden nicht an das Paket gehängt. Das Klonen und die damit verbundene Erzeugung der Customizings erfolgt beim Transport des Customizing Pakets automatisch im Zielsystem.

Es darf nur ein offenes Paket existieren, da z.B. bei Schlüsseln sonst die Mandantenzuordnung auseinanderlaufen kann. Beim Import des Pakets wird der Mandant geklont, bevor Daten mit Mandantenbezug importiert werden (z.B. Schlüssel). Das Klonen und Löschen von Mandanten kann nicht innerhalb desselben Customizing Pakets erfolgen.

"Mandanten klonen" und " Mandanten löschen" können nicht zusammen am Paket hängen.

Datenbank Schnittstellen im Mandantenmanagement

SQL Schnittstellen

Für mandantenfähige Entitäten muss das Feld ClientNo gefüllt werden. Analog zu den Berechtigungen (Bitright Tabelle) werden die Mandanten bitverschlüsselt im Feld ClientNo abgelegt. Für jeden Mandanten wird eine eindeutige Nummer (0-62) bei der Neuanlage festgelegt. Die Mandantenzuordnung wird dann mit 2^UnitNo.Unit berechnet und in das Feld ClientNo geschrieben. Sollen mehrere Mandanten zugeordnet werden, so müssen die Werte summiert werden.

Bei Entitäten, die über die Entitäten-Eigenschaften vom Mandantenmanagement ausgeschlossen wurden, ist der Wert null in das ClientNo Feld einzutragen. Dies gilt auch generell, wenn das Mandantenmanagement Modul nicht aktiviert ist.

Der Wert 0 im ClientNo Feld ist für den Löschmandanten vorgesehen und darf in Schnittstellen nicht verwendet werden.

Bei Änderung des ClientNo Feldes muss der Lucene Index für die Juhuuu Suche aktualisiert werden. Hier muss der Datensatz in die UnindexedEntity Tabelle aufgenommen werden.

Die Regeln für die Vererbung von Mandanten im Personen-Rollen-Modell sowie der Positionsentitäten müssen eingehalten werden.

Mitarbeiterschnittstelle

Jedem Mitarbeiter muss der Hauptmandant im doppelt persistenten Feld MainUnit.Employee eingetragen werden. Dieser muss analog in der Tabelle rEmUn verknüpft und das Flag DefaultUnit.rEmUn auf 1 gesetzt werden. Weitere Mandanten können mit dem DefaultUnit.rEmUn Flag = 0 verknüpft werden.

Schlüssel

Legen Schnittstellen Schlüssel an, so sollte hier der Wert "9223372036854775807" (=2^63) in das Feld ClientNo geschrieben werden. Da diese Zahl nicht direkt per SQL gesetzt werden kann, muss man auf die folgenden Datenbankfunktionen ausweichen.

• MSSQL:
  (POWER (cast(2 as bigint), 62) -1) + POWER (cast(2 as bigint), 62)
  oder
  cast(9223372036854775807 as bigint)

• ORACLE:
  (POWER (cast(2 as DOUBLE PRECISION), 62) -1) + POWER (cast(2 as DOUBLE PRECISION), 62)

Damit die Mandantenzuordnung erhalten bleibt, muss der alte Wert des ClientNo Feldes beim Löschen und Neuanlegen von Schlüsseln übernommen werden.

XML Import

Beim XML Import kann die Mandantenzuordnung über das ClientNo Feld mitgegeben werden. Hierbei muss der Import Benutzer allen betroffenen Mandanten zugeordnet sein, da sonst der Import mit einem Fehler abbricht. Wird keine Mandantenzuordnung angegeben, so werden die Datensätze dem Hauptmandanten des Import Benutzers zugewiesen. Auch für Schlüssel kann die ClientNo übergeben werden. Wird diese weggelassen, so werden die Schlüssel allen Mandanten (ClientNo=9223372036854775807) zugewiesen.

Massendatenjobs

Alle Aktionen, die an den Massendatenserver in Form von Massendatenjobs (CSV-Export, Reports und BPM-Massendaten) übergeben werden, werden unter dem Mandanten, den der User, der den Job angestoßen hat, zu diesem Zeitpunkt per Mandantenswitch eingestellt hatte, ausgeführt.

Customizing-Transport

Aktivierung des Mandatenmanagements im Produktivsystem

Ist der Customizing Transport im System aktiv, so wird bei der Aktivierung des Mandantenmanagements im Entwicklungssystem ein Customizing Paket erzeugt. Dieses muss zuerst in das Produktivsystem bzw. ein zwischengeschaltetes QS System importiert werden, bevor die Mandantenmanagement Lizenz auch im Produktivsystem aktiviert werden kann.

Hierbei wird immer ein neues Customizing Paket erzeugt. Nach der Bestätigung des Pakets wird der Mandant angelegt und alle Daten im System migriert. Beim Transport des Paketes werden im Zielsystem die Mandanten angelegt. Beim Einspielen der Modul Lizenz werden alle Daten migriert.

Transport von Mandanten

Werden Mandanten angelegt oder geändert, so werden die Änderungen an ein Customizing Paket gehängt. Die Änderungen können so in die anderen Systeme übertragen werden.

Transport von Schlüsseln

Beim Transport von Schlüsseln wird die Mandantenzuordnung automatisch mit übertragen. Dies gilt auch für neue Mandaten, die noch nicht übertragen wurden. Ist im Zielsystem kein Mandantenmanagement aktiviert, so wird die Mandantenzuordnung beim Import gelöscht.

Mitarbeiterabgleich

Beim Mitarbeiterabgleich wird der Hauptmandant des Benutzers in die anderen Systeme übertragen.

Systembetreiber-Abgleich für das Mandantenmanagement

Das Feld "Systembetreiber" im Mandanten kann, wenn der Mitarbeiterabgleich aktiv ist, nur noch in der Produktion gepflegt werden. Dafür wird der Eintrag und auch der dahinter liegende Geschäftspartner automatisch vom Mitarbeiterabgleich in die anderen Systeme transportiert. 

Die transportierten Daten werden durch die Suche "C0SYSTEM_OWNERS_TO_MERGE" bestimmt.

Mandantenmanagement in BPM

Die Mandantenzuordnung von Datensätzen kann in BPM Skripten über die UnitUtils bearbeitet werden.

Mandanten-Switch

In einem Mehrmandantensystem haben Benutzer mit mehrfacher Mandatenzuordnung die Möglichkeit, den Hauptmandanten zur Laufzeit zu wechseln.

Zwei fachliche Anwendungsszenarien:

• Ein Call-Center-Agent arbeitet für viele Mandanten. Je nach eingehendem Call möchte er zum betreffenden Mandanten wechseln und möchte dann auch nur die Daten dieses Mandanten sehen (exklusiver Mandantenwechsel).

• Eine Firma betreibt zwei Business Units. Bestimmte Benutzer haben Zugriff auf die Daten beider Units. Wenn sie neue Daten anlegen (z.B. Angebote erstellen) so müssen diese fallspezifisch einer bestimmten Unit zugeordnet werden. Zu diesem Zweck will der Benutzer den aktuell gültigen Hauptmandant zur Laufzeit wechseln können, ohne die Sichtbarkeit auf die Daten des Nebenmandanten zu verlieren (inklusiver Mandantenwechsel).

Exklusiver und inklusiver Mehrmandantenmodus

Es gibt zwei unterschiedliche Modi für den benutzerspezifischen Mehrmandantenbetrieb:

• inklusiver Modus: Hat ein Benutzer das Zugriffsrecht auf mehrere Mandanten, so werden ihm die Daten aller Mandanten angezeigt. Der Hauptmandant wirkt sich lediglich auf das Erzeugen neuer Daten aus.

• exklusiver Modus: Hat ein Benutzer das Zugriffsrecht auf mehrere Mandanten, so werden ihm zur Laufzeit nur die Daten des aktuellen Hauptmandanten angezeigt.

Wechsel des Hauptmandanten zur Laufzeit

In der Brandingbar der Anwendung ist der aktuell gültige Hauptmandant zu erkennen:

• Windows Client

• Web Client

Eine Drop-Down-Box ermöglicht den Wechsel des Hauptmandanten. Die Box bietet alle Nebenmandanten des angemeldeten Benutzers an.

Beim Wechsel des Hauptmandanten ist im Mehrmandantenmodus des Benutzers zu beachten:

• inklusiver Modus: Die Daten aller Benutzermandanten bleiben sichtbar. Der neue Hauptmandant wirkt sich auf die Mandantenzuordnung bei neuen Datensätzen aus.

• exklusiver Modus: Mit dem Wechsel des Hauptmandanten sind nur noch die Daten des neuen Mandaten sichtbar

Einstellungen

Über Benutzereinstellungen kann der Call-Center-Modus aktiviert werden.

• Windows Client

• Web Client

Ist dieser aktiviert, so kann der Benutzer über einer Combobox in der Haupt-Toolbar den aktiven Mandaten auswählen.

• Windows Client:

• Im Web Client kann der Benutzer immer den Mandaten wechseln.

bzw. Call-Center Modus 

Neue Datensätze werden für den aktiven Mandanten erfasst. Der Benutzer hat weiterhin Zugriff auf alle seine zugeordneten Mandanten.

Im exklusiven Modus hat der Benutzer nur noch exklusiven Zugriff auf den gewählten Mandanten. Vor dem Wechsel müssen alle offenen Ebenen geschlossen werden. MyCRM und Favoriten werden aktualisiert. Die Mandantenverwaltung auf Datensätzen ist hier deaktiviert, da in diesem Modus nur der gewählte Mandant nutzbar ist.

Darstellung an der Oberfläche

Über einen Anwendungsschalter kann die Platzierung des Mandanten-Switchs gesteuert werden. Im Modus "Standard" befindet sich der Switch nicht im Header der Anwendung.

• Windows Client

Im Windows Client kann er über das Menü Optionen > Mandantenwechsel erreicht werden. Dieser öffnet ein Submenü mit den verfügbaren Mandanten. Der aktuell gewählte Hauptmandant ist im Menü hervorgehoben (durch einen vorgestellten Haken). Klickt man einen Eintrag in diesem Submenü an, so ändert sich der Hauptmandant.

• Web Client

Im Web Client wird der Wechsel des Hauptmandanten über ein Menü in der Brandingbar vorgenommen. Der aktuell gewählte Hauptmandant ist im Menü hervorgehoben (durch einen vorgestellten Haken). Im Tooltip des Button steht der aktuell ausgewählte Mandant.