Änderungsbelege
Berechtigungsfehler durch Debugging ermitteln
Änderungsbelege der Berechtigungsvorschlagspflege können Sie sich mit dem Report SU2X_SHOW_HISTORY anschauen (verfügbar mit dem im SAPHinweis 1448611 benannten Support Package). Falls der Hinweis nicht implementiert ist, verwenden Sie die Tabellen USOBT_CD und USOBX_CD. Wir empfehlen Ihnen, den Korrekturreport SU24_AUTO_REPAIR regelmäßig auszuführen. Dieser Report bereinigt Inkonsistenzen und ergänzt fehlendende Modifikationsflags in den Daten der Transaktion SU24, die bei der Ausführung der Transaktion SU25 als Fehler auftauchen können. Lesen Sie hierzu den SAP-Hinweis 1539556. Modifikationsflags werden jeweils bei den Datensätzen in der Transaktion SU24 angefügt, wenn diese von Ihnen verändert wurden. Sie sehen diese Flags in den Tabellen USOBT_C und USOBX_C.
Der Funktionsbaustein wurde offensichtlich nicht für diese Verwendung vorgesehen, unser Vorgehen beeinflusst aber nicht den Programmablauf, und es sind uns keine Einschränkungen durch diese Nutzung bekannt. Diese Vorgehensweise können Sie auch bei anderen BTEs anwenden, die in ähnlicher Form Daten übergeben. Dabei sollten Sie aber immer Vorsicht walten lassen und prüfen, ob die Anwendung bereits Summendatensätze gebildet hat oder ob es andere Abhängigkeiten gibt. Abschließend müssen Sie noch ein von Ihnen entwickeltes Produkt (den Namen können Sie selbst definieren) in der Transaktion FIBF anlegen und dieses zusammen mit dem kundeneigenen Funktionsbaustein dem Business Transaction Event 1650 zuordnen, wie es in der folgenden Abbildung zu sehen ist. Zu einem kundeneigenen Produkt können mehrere Erweiterungen gehören. Es bildet eine logische Klammer um die Erweiterungen und sorgt so für eine bessere Übersicht. Zusätzlich ermöglicht es eine gezielte Aktivierung bzw. Deaktivierung der Implementierungen.
Kommunikationsbenutzer
Einen Überblick über die aktiven Werte Ihrer Sicherheitsrichtlinie erhalten Sie, indem Sie auf den Button Effektiv klicken. Beachten Sie dabei, dass nicht nur die von Ihnen geänderten Werte der Attribute aktiv sind, sondern auch die Vorschlagswerte, die Sie nicht geändert haben.
Diesen Rollen können Sie nun Transaktionen zuordnen. Die Erfahrung zeigt, dass Rollen applikationsspezifisch bleiben sollten und ferner eine Unterscheidung zwischen buchenden bzw. anlegenden, ändernden und lesenden Rollen sinnvoll ist. Es wird regelmäßig Transaktionen geben, die in mehreren Rollen verwendet werden. Die oft geforderte Redundanzfreiheit sollten Sie nicht zu hoch bewerten. Für kritische Transaktionen oder für Transaktionen, die Anteil an einem Funktionstrennungskonflikt haben, empfiehlt es sich aber, diese in einer eigenen Rolle vorzuhalten. Generell sollten Rollen nicht zu viele Transaktionen enthalten; kleinere Rollen sind einfacher zu warten und einfacher abzuleiten. Ihre Vergabe führt auch nicht so zügig zu dem Problem, dass Benutzer über zu viele Berechtigungen verfügen. Sofern Sie die notwendigen Funktionstrennungen gleich festhalten, haben Sie diese auch schon als Take-away vorbereitet.
Die Zuweisung einer Rolle für einen befristeten Zeitraum ist mit "Shortcut for SAP systems" in Sekundenschnelle getan und erlaubt Ihnen die schnelle Fortsetzung Ihres Go-Live.
Und falls doch, ist die Frage, welches Berechtigungskonzept im SAP HCM das richtige ist.
Da gewisse Arten von Berechtigungen, wie z. B. Analyseberechtigungen, für SAP BW oder strukturelle Berechtigungen in SAP ERP HCM nicht auf SAPBerechtigungsprofilen beruhen, werden diese Berechtigungen im Berechtigungspuffer auch nicht angezeigt oder aufgefrischt.