Ermittlung interner/externer Mitarbeiter

Ermittlung interner/externer Mitarbeiter

Hallo zusammen,

welche Möglichkeiten habe ich denn, um anhand der UserID festzustellen, ob es sich um einen internen oder externen Mitarbeiter handelt?

Das Problem aktuell ist, dass ich die Personalnummer über die Tabelle PA0105 selektieren möchte. Dies scheint aber nicht bei allen Usern zu funktionieren. Warum genau, kann ich aktuell nicht sagen, da ich keine Berechtigugn für diese Tabelle habe.
Bei den IDs mit P123456 oder X123456 funktioniert es. Jedoch bei IDs mit GPGF123 oder SCGHUUJ nicht. Da es sich um ein CHAR 30 Feld handelt, kann es eigentlich nicht daran liegen, ob ich Zahlen oder Buchstaben habe. Ich vermute eher, dass der Eintrag gar nicht vorhanden ist.

Mit der gefundenen Personalnummer geht es dann in die Tabelle PA0001 um das Feld PERSG abzufragen nach 1 = aktive oder 9 = externe.

Liege ich mit meiner Vermutung richtig, dass es zunächst nicht am Aufbau der UserID liegen kann?

Vielen Dank.

Re: Ermittlung interner/externer Mitarbeiter

Das habe ich auch noch nie gesehen, dass Externe im HR erfasst werden

Re: Ermittlung interner/externer Mitarbeiter

Den Infotyp 105 liest man einfach per SELECT auf die PA0105 über USRTY und USRID (da hat die PA0105 extra einen Sekundärindex auf der Datenbank drauf, daher nicht SUBTY und USRID nehmen!). Dieser Funktionsbaustein macht auch nichts anderes. Er ist nur dahingehend aufgebläht, dass er auch per RFC von externen Systemen aus angesprochen werden kann und Berechtigungsprüfungen macht, ob man die betreffenden Datensätze überhaupt lesen darf. Soweit ich Michi83 verstanden habe, braucht er weder das eine noch das andere und sollte daher einfach den SELECT machen.

Bei den IDs mit P123456 oder X123456 funktioniert es. Jedoch bei IDs mit GPGF123 oder SCGHUUJ nicht. Da es sich um ein CHAR 30 Feld handelt, kann es eigentlich nicht daran liegen, ob ich Zahlen oder Buchstaben habe. Ich vermute eher, dass der Eintrag gar nicht vorhanden ist.

Davon gehe ich auch aus.

Liege ich mit meiner Vermutung richtig, dass es zunächst nicht am Aufbau der UserID liegen kann?

Ja. Wenn der IT 105 vorhanden ist und die dort im Subtyp 0001 hinterlegte User-ID tatsächlich so lautet, wie Du es in Deiner Abfrage formulierst, dann ist ganz sicher nicht das Problem, wieviele Zahlen oder Buchstaben Du in der Kennung hast. Achte allerdings darauf, dass im IT 105 alles in Großbuchstaben gespeichert wird. Wenn Du mit Benutzerkennungen in Kleinbuchstaben dort suchst, wirst Du also nichts finden.

Habt ihr kein Testsystem, in dem Du erweiterte Rechte hast und Dein Programm gescheit mit Debugger und vollem Datenzugriff testen kannst? Ansonsten brauchst Du ggf. erweiterte Rechte auf dem Produktivsystem. Debug ohne Replace finde ich schon sinnvoll. Minimal aber sollte man Dir SE16-Zugriff auf die PA0105 für wenigstens den Subtyp 0001 geben. Da stehen ja keine Geheimnisse drin.

Re: Ermittlung interner/externer Mitarbeiter

Wieso, der ist doch im HCM gar nicht unterwegs und kann daher gar nicht beurteilen, was in der PA0105 drin steht. 😉 Und man kann Tabellenzugriffsberechtigungen ja sehr gut mit den Berechtigungsobjekten S_TABU_NAM und S_TABU_DIS steuern. Dafür gibt es die ja. Weil eben nicht alle Tabellen gleich kritisch sind. Allenfalls könnte man den Einwand erheben, dass man mit diesen beiden Berechtigungsobjekten nicht nach dem Subtyp unterscheiden kann und insofern die ganze PA0105 öffnen würde.

Re: Ermittlung interner/externer Mitarbeiter

DeathAndPain hat geschrieben: ↑

01.10.2019 18:16

Wieso, der ist doch im HCM gar nicht unterwegs und kann daher gar nicht beurteilen, was in der PA0105 drin steht. 😉

viewtopic.php?f=20&t=23947
Ich glaube er hat dein Posting gelesen und will das widerlegen 😂

Re: Ermittlung interner/externer Mitarbeiter

Jep, wundert mich auch. Aber gut, vielleicht braucht er das nur für ein größeres Projekt oder will die Strukturen mal kennen lernen, oder so ^^
Bezgl. der S4/Hana integration glaube ich, dass die schon für jeden verfügbar sein wird - zumindest die jetzt auch schon HCM haben. Nur ob es viel Sinn macht, weiß ich nicht. Schätze nämlich, dass diese HCM Variante auch nur bis 2030 supported wird und bis dahin dann die Payroll komplett auf SuccessFactors umgestellt wird.
SF-Payroll funktioniert auch jetzt schon. Nur eben nicht bei weitem in dem Maße wie auf der jetztigen on-prem welt.

Bin einfach mal gespannt, was sich SAP so einfallen lässt... Aber wie es aktuell aussieht werde ich mir wohl für die Zeit nach 2030 n anderes Modul suchen müssen oder eben in die SF-Beratung gehen... uff..

Re: Ermittlung interner/externer Mitarbeiter

DeathAndPain hat geschrieben: ↑

08.10.2019 13:29

Gut denkbar, dass SAP HCM doch noch länger unterstützt werden wird. Das müsste es sogar aus heutiger Sicht, denn nach meiner Erinnerung hat die SAP für das "neue SAP HCM on premise", das es ab 2022 geben soll, mindestens 10 Jahre Support versprochen.

hat es das? Konnte in der Mitteilung der DSAG nichts derartiges rauslesen... aber gut, vielleicht habe ich auch nur etwas übersehen. Aber ja, ich geb dir recht, dass es für alle wohl das Beste wäre, wenn SAP, HCM noch länger supporten würde.

DeathAndPain hat geschrieben: ↑

08.10.2019 13:29

Auf der anderen Seite mehren sich die Gerüchte, dass die Cloud immer weiter für Eigenentwicklungen geöffnet wird - auch in ABAP. Nix genaues weiß ich nicht, aber das könnte ja durchaus auch ein sehr spannendes Betätigungsfeld sein.

Jap. Ich werde versuchen meine neue Firma dahin zu bewegen ihre Kernanwendung ( welche auf dem Veranstaltungsmanagement basiert ) auf die Cloud zu bringen. Dies könnten wir in ABAP umsetzen. Wäre wirklich ein interessantes Projekt.

DeathAndPain hat geschrieben: ↑

08.10.2019 13:29

Bezgl. der S4/Hana integration glaube ich, dass die schon für jeden verfügbar sein wird - zumindest die jetzt auch schon HCM haben.

Na ja, Du wirst obendrauf auch noch S/4 HANA haben müssen. Solch In-Memory-Datenbank ist ja nicht ganz billig; was Du da an Arbeitsspeicher brauchst, kostet ordentlich!

Da hast du natürlich recht. Nur muss auch jeder auf S4/Hana umstellen, zumindest wenn ich das richtig verstanden habe. Denn SAP beendet auch den Support fürs klassische SAP ERP und setzt auf S4/HANA --> Die Datenbank kosten erhöhen sich so oder so. Heißt für mich, man könnte auch die HCM Schiene dann darauf laufen lassen.
Auf kurz oder lang bleibt aber für HCM nichts anderes als SF übrig, was mich sehr traurig macht. ( verstehe dieses modul wesentlich besser als andere.... )