Infotyp-Berechtigungen im HCM – Teil 3
Lesezeit ca. 5 Minuten
In den ersten zwei Artikeln haben wir eine Übersicht gegeben, die Allgemeine Berechtigungsprüfung beschrieben und aufgezeigt, welche Beschränkungen die Allgemeine Berechtigungsprüfung hat. In diesem dritten und letzten Teil der Reihe gehen wir näher auf die erweiterten Formen der Berechtigungsprüfung ein: Strukturelle Berechtigungen und Kontextabhängige Berechtigungen.
Strukturelle Berechtigungen
Strukturelle Berechtigungen funktionieren komplett anders als die bisher vorgestellte Allgemeine Berechtigungsprüfung. Wir kennen dort die Prüfung, ob bestimmte Stammdaten einer Personalnummer über Berechtigungsobjekte berechtigt sind. Bei der Strukturellen Berechtigung prüft das System – völlig unabhängig von Berechtigungsobjekten – ob eine Personalnummer in einer Liste von erlaubten Personalnummern enthalten ist. Dieses Konzept kommt aus dem Organisationsmanagement (OM) und ist für alle OM-Objekte relevant. Im Rahmen dieses Artikels gehen wir aber nur auf die Berechtigungen für Personalnummern (Objekttyp „P“) ein.
Diese Liste erlaubter Personalnummern wird über sogenannte Berechtigungsprofile erzeugt. Berechtigungsprofile sind Customizing-Tabellen, aus deren Inhalt das System nach bestimmten Regeln die erlaubten Personalnummern ermittelt. Die Regeln können durch verschiedene Kombinationen von Feldern aufgestellt werden.
Folgende Felder sind dabei relevant:
- Objekttyp: Hier wird angegeben, welcher Objekttyp berechtigt werden soll. Bei der Verwendung von Auswertungswegen muss hier der Wurzelobjekttyp eingetragen werden.
- Objekt-ID: Hier kann entweder ein einzelnes berechtigtes Objekt angegeben werden, oder die Wurzel-Objekt-ID für das Auswerten eines Auswertungsweges
- Auswertungsweg: Hier kann ein Auswertungsweg eingegeben werden, mit dessen Hilfe alle Objekte einer Struktur berechtigt werden können
- Funktionsbaustein: Eine programmierter Funktionsbaustein kann eingetragen werden, um die Spalte „Objekt-ID“ dynamisch zu füllen
Diese vier Felder dürfen auf fünf Arten kombiniert werden:
Generelle Erlaubnis für ein Objekt
Wenn Sie Berechtigung auf alle Personalnummern im Mandanten erteilen wollen, reicht es wenn nur das Feld „Objekttyp“ mit einem „P“ gefüllt ist. Objekt-ID, Auswertungsweg und Funktionsbaustein müssen leer bleiben.
Diese Regel kann für einen Controller oder einen Mitarbeiter der zentralen Personalabteilung sinnvoll sein, bei dem sichergestellt sein muss, dass er wirklich jede Personalnummer sehen darf.
Das Profilcustomizing in der Transaktion OOSP sieht dafür folgendermaßen aus:
Nur eine Personalnummer
Es wird direkt eine erlaubte Personalnummer eingetragen (und als Objekttyp das „P“). Ein Beispiel wäre: „Personalnummer 00000002 ist erlaubt“. Die Felder für den Auswertungsweg und den Funktionsbaustein bleiben leer.
Das Profilcustomizing in der Transaktion OOSP sieht dafür folgendermaßen aus:
Das ausgewertete Profil gibt dann Zugriff auf folgende Personalnummern (Objekt-ID in dunkelblau):
Wurzelobjekt und Auswertungsweg
Bei dieser Variante wird ein Wurzelobjekt und ein Auswertungsweg eingetragen. Aus diesen Angaben kann das System eine Liste von erlaubten Objekten erzeugen. Klassisch ist hier die Angabe von einer Organisationseinheit und einem Auswertungsweg, der alle der OE zugeordneten Personalnummern einsammelt. Das Feld für den Funktionsbaustein bleibt leer.
Ein Beispiel wäre: „Organisationseinheit 50000050 und alle zugeordneten Planstellen und Personalnummern sind erlaubt“
Das Profilcustomizing in der Transaktion OOSP sieht dafür folgendermaßen aus:
Das ausgewertete Profil gibt dann z.B. Zugriff auf folgende Personalnummern (dies ist natürlich abhängig vom Organisationsmanagement des Systems):
Auswertung eines Profils mit ID und Auwertungsweg
Auswertungsweg und Funktionsbaustein
Das Wurzelobjekt wird nicht fest eingetragen sondern über einen Funktionsbaustein ermittelt. Diese Kombination erlaubt eine hohe Flexibilität, es kann mit einem einigen Profil große Mengen an Benutzern „versorgt“ werden. Für die gängigsten Anwendungen können SAP-Standard-Bausteine verwendet werden. Das Feld für die Objekt-ID bleibt leer, da sie dynamisch aus dem Funktionsbaustein ermittelt wird.
Ein Beispiel wäre: „Genau die Organisationseinheit, die der aktuelle Benutzer leitet sowie alle zugeordneten Planstellen und Personalnummern sind erlaubt“
Das Profilcustomizing in der Transaktion OOSP sieht dafür folgendermaßen aus:
Das ausgewertete Profil gibt dann z.B. Zugriff auf untenstehende Personalnummern (dies ist natürlich abhängig vom Organisationsmanagement des Systems sowie vom spezifischen Benutzer):
Im hier verwendeten System ist der Benutzer der Leiter der Organisationseinheit 50000050, was zum gleichen Ergebnis führt, als wenn die Organisationseinheit fest eingetragen ist. Der Vorteil dieser Konstellation ist, dass ein einziges Profil für alle Führungskräfte ausreicht – und nicht jede Organisationseinheit ihr eigenes Berechtigungsprofil erfordert.
Ermittlung der Personalnummern per Funktionsbaustein
Bei dieser Variante wird weder Auswertungsweg noch Objekt-ID eingetragen. Alle erlaubten Objekte werden über einen Funktionsbaustein ermittelt. Die Variante ist sehr flexibel, erfordert aber kundeneigene Programmierung um auf kundeneigene Anforderungen einzugehen.
Das Profilcustomizing in der Transaktion OOSP sieht dafür folgendermaßen aus:
Da die Programmierung des angegebenen Funktionsbaustein die Personalnummern 2, 17 und 28 ermittelt, gibt das ausgewertete Profil Zugriff auf genau diese Personalnummern:
In der Praxis ist diese Lösung natürlich nur für komplexere Lösungen sinnvoll. Beispiele könnten sein:
- Alle Personalnummern, die als Sachbearbeiter Abrechnung den Sachbearbeiter eingetragen haben, der meinem User zugeordnet ist.
- Mitarbeiter die die Abwesenheit „Krankheit“ haben und aus der Lohnfortzahlung gefallen sind.
- Mitarbeiter, die in ihrer Leistungsbeurteilung ein „sehr gut“ erhalten haben.
Die Profile können Sie über die Transaktion OOSP pflegen, sie werden in der DB-Tabelle T77PR abgelegt. Über die Customizing-Tabelle T77UA oder über das BAdI HRBAS00_GET_PROFL wird festgelegt, welche Profile für welchen Benutzer gelten. Somit kann jedem Benutzer eine Liste von Personalnummern zugeordnet werden, auf die er Berechtigung hat.
Das Kontextproblem
Strukturelle Berechtigungen sind sehr gut dafür geeignet, festzulegen, wen ein Benutzer bearbeiten darf. Schwierig wird es, wenn ein Benutzer für einen Personenkreis bestimmte Daten bearbeiten soll, und für einen anderen Personenkreis ganz andere Daten. Wenn z.B. ein Sachbearbeiter für eine Organisationseinheit Zeitdaten verwalten soll und für eine andere die Gehaltsdaten, kommen die Strukturellen Berechtigungen an ihre Grenzen. Ist eine Personalnummer in der Liste der erlaubten Objekte, wird aus struktureller Sicht nicht mehr unterschieden, was an dieser Personalnummer gemacht werden darf. Die Folge ist, dass der Sachbearbeiter aus dem Beispiel oben für beide Organisationseinheiten sowohl auf Zeitdaten als auch auf Gehaltsdaten Zugriff hat.
Natürlich greift weiterhin (entsprechende Stellung der Hauptschalter vorausgesetzt) die allgemeine Berechtigungsprüfung. Aber wir wollten ja gerade weg von der Detailsteuerung mit 100 verschiedenen Rollen für 100 verschiedene Sachbearbeiter.
Kontextabhängige Berechtigungen
Vorhang auf für die Kontextabhängigen Berechtigungen. Diese kombinieren die Allgemeine Berechtigungsprüfung und die Strukturelle Berechtigungsprüfung. So können Sie differenziert die richtige Berechtigung für die richtige Zielgruppe vergeben.
Dies erreicht die SAP dadurch, dass sie an die „normalen“ Berechtigungsobjekte der Allgemeinen Prüfung ein weiteres Feld „Berechtigungsprofil“ (techn.: PROFL) angehängt hat. Neben allen Zuordnungen aus dem Infotyp 0001 muss auch die Zuordnung über das strukturelle Profil „stimmen“, damit das System die Berechtigung erteilt. So kann festgelegt werden, dass bestimmte Infotypen nur bei Personalnummern erlaubt sind, die aus bestimmten Profilen stammen.
Zum besseren Verständnis stellen wir hier die Lösung für das oben geschilderte Kontextproblem dar:
Ein Benutzer soll Gehaltsdaten für die Organisationseinheit 5000182 und Zeitdaten für die Organisationseinheit 50000075 pflegen. Ihm sind zwei Berechtigungsprofile zugeordnet:
- PROFILE_PAYR, dieses Profil gibt Zugriff auf die Personalnummern 14 und 21
- PROFILE_TIME, dieses Profil gibt Zugriff auf die Personalnummern 4, 6, 7, 8 und 18
Die entsprechende Rolle gewährt über zwei Berechtigungen Zugriff auf Gehaltsinfotypen und Zeitinfotypen. Bei Struktureller Berechtigung dürfte der Benutzer jetzt bei allen Personen alle erlaubten Infotypen pflegen.
Prinzip Kontextberechtigung
Bei den Kontextabhängigen Berechtigungen wird aber nur Berechtigung für die Personalnummern gewährt, die aus dem „richtigen“ Berechtigungsprofil kommen. Welches das richtige Profil ist, ist im Feld „Berechtigungsprofil“ festgelegt.
So erlaubt die obere Berechtigung den Zugriff auf Gehaltsinfotypen nur, wenn die entsprechenden Personen aus dem Profil PROFILE_PAYR stammen (also 14 und 21). Die untere Berechtigung erlaubt Zeitinfotypen nur für Personen, die aus dem Profil PROFILE_TIME stammen (also 4, 6, 7, 8 und 18). Diese Logik vermeidet eine Vermischung von Berechtigungen. Selbst wenn dem Benutzer noch andere Personalnummern aus anderen Berechtigungsprofilen erlaubt wurden, hat das keinerlei Auswirkung auf die hier gezeigten Berechtigungen.
Festzuhalten ist noch, dass alle Berechtigungsobjekte der Allgemeinen Berechtigungsprüfung auch in einer „Kontext-Variante“ existieren. Es gibt sowohl die Prüfung auf die organisatorische Zuordnung (P_ORGIN) als auch die Prüfung auf Sachbearbeiter (P_ORGXX) als auch das kundeneigene Berechtigungsobjekt (P_NNNNN) in einer Version für Kontextabhängige Berechtigungen.
Ausblick
Natürlich lösen sich auch mit Kontextabhängigen Berechtigungen nicht alle Berechtigungsprobleme in Luft auf. Der geschickte Aufbau von Berechtigungsprofilen z.B. bei dezentralen Zuständigkeiten ist ein großes Thema. In großen Unternehmen kann die Performance in den Fokus rücken. Auch der Umgang mit Personalnummern, die nicht ins OM integriert sind (z.B. Rentner) ist häufig kompliziert. Aber als Grundlage für ein Berechtigungskonzept ist dieses Modell eine sehr solide Grundlage.
Wie im ersten Teil der Artikelreihe geschrieben gibt es noch verschiedene andere Faktoren die bei der Berechtigungen auf PA-infotypen wichtig sind. Außerdem gibt es im HCM viele andere Dinge die berechtigt werden müssen. Das fängt mit Infotypen des Organisationsmanagements an und hört mit der Berechtigung auf Zeit- und Entgeltnachweise nicht auf.
All diese Themen würden den Umfang dieses Blogs sprengen. Daher empfehlen wir bei tiefergehendem Interesse das Buch „Berechtigungen in SAP ERP HCM“ vom Rheinwerk Verlag. Oder Sie schreiben einen Kommentar oder kontaktieren uns direkt.
