Ermittlung Vorgesetzten und Vertreter

Ermittlung Vorgesetzten und Vertreter

Hallo,

Ich bin auf der Suche nach einem Fuba oder Klasse/Methode zum Ermitteln des Vorgesetzten beziehungsweise dem Vertreter, sollte der Vorgesetzte gerade Krank, im Urlaub o. Ä. sein.

Danke!

Re: Ermittlung Vorgesetzten und Vertreter

Ja, der sieht geeignet aus.

Ich persönlich pflege sowas freilich selbst auszuprogrammieren oder von mir selbst erstellte Fubas oder Methoden zu verwenden, da das, was die SAP in diesem Zusammenhang bietet, in aller Regel eine erbärmliche Performance aufzuweisen pflegt. Wenn man es nur für eine einzelne Personalnummer braucht, mag man mit einem Fuba wie diesem zufrieden sein. Aber spätestens, wenn man z.B. eine Mitarbeiterliste mit Vorgesetztem drin erstellen möchte, dann braucht man ein Coding, das die Werte mit einem einzigen Datenbankzugriff alle aus der Datenbank holt und sie in einer mit geeignetem Schlüssel versehenen internen Puffertabelle ablegt, von wo man sie sich dann abholen kann.

Re: Ermittlung Vorgesetzten und Vertreter

DeathAndPain hat geschrieben: ↑

28.04.2023 17:56

Ich persönlich pflege sowas freilich selbst auszuprogrammieren [...]

da bin ich im HR vorsichtig. Erstens, weil ich mich da nicht so dolle auskenne und zweitens, weil es dort glaube ich einige Fallstricke gibt, oder?
Sobald es über Auswertungswege geht, ist man mit einem Select glaube ich aufgeschmissen.

Re: Ermittlung Vorgesetzten und Vertreter

ewx hat geschrieben: ↑

28.04.2023 18:04

DeathAndPain hat geschrieben: ↑

28.04.2023 17:56

Ich persönlich pflege sowas freilich selbst auszuprogrammieren [...]

da bin ich im HR vorsichtig. Erstens, weil ich mich da nicht so dolle auskenne und zweitens, weil es dort glaube ich einige Fallstricke gibt, oder?
Sobald es über Auswertungswege geht, ist man mit einem Select glaube ich aufgeschmissen.

Vorgesetztenbeziehungen gehen nicht über Auswertungswege. Bzw. der Auswertungsweg zur Vorgesetztenbestimmung ist klar. (Der HR_ASR_GET_LEADER macht es auch nicht anders: Wenn Du da in den Quellcode schaust, siehst Du z.B. das hart codierte Lesen der A008-Verknüpfung für den Schritt S -> P.) Wenn Du von der Person P ausgehst, musst Du dazu die Planstelle S bestimmen (die ggf. nicht eindeutig sein kann, wenn der Mitarbeiter mehrere Planstellen anteilig besetzt. Dann kann er dementsprechend auch unterschiedliche Vorgesetzte zu seinen jeweiligen Planstellen haben) und dann zu der Planstelle S die Orgeinheit O bestimmen. Letztere Zuordnung ist eindeutig (es sei denn, die Planstelle ist verwaist, aber eine Planstelle ohne Orgeinheit wäre wohl als Pflegefehler einzuschätzen).

Hast Du das O, kannst Du ermitteln, welche Planstelle(n) dieses O leiten und dann die zugehörigen Planstelleninhaber ermitteln. Gibt es keine, gehst Du solange den Orgbaum hoch, bis Du eine Orgeinheit findest, die eine 012er-Verknüpfung hat (deren Planstelle auch besetzt ist).

Ich habe da schon herrliche Megaselects gebaut. Das ist einer der wenigen Fälle, in denen Aliasdefinitionen im Select in meinen Augen Sinn ergeben, da man hier mehrfach dieselbe Tabelle (nämlich die HRP1001) braucht. Ein Alias for P->S, einer für S->O, die beiden JOINen, und schon liest man mit einem einzigen SELECT direkt die Orgeinheit zur Person. 😎 Wenn man es für mehrere Mitarbeiter braucht, dann gleich richtig mit einem FOR ALL ENTRIES IN.

Klar, ein paar Datenbankzugriffe braucht man schon, denn man wird nicht alles, was ich oben geschrieben habe, mit einem einzigen SELECT bis zum Manager abbilden können. Aber nur ein SELECT pro Bearbeitungsschritt statt pro Mitarbeiter, das macht schon Welten aus.