Code: Alles auswählen.
* Besetzte Leiterplanstelle gefunden?
LOOP AT ch_responsibles TRANSPORTING NO FIELDS
WHERE employee IS NOT INITIAL.
EXIT.
ENDLOOP.
IF sy-subrc = 0.
* Mindestens 1 besetzte Planstelle vorhanden
DELETE ch_responsibles WHERE employee IS INITIAL.
ELSE.
* KEINE besetzte Planstelle vorhanden, suche aufwärts -> Rekursivaufruf
Code: Alles auswählen.
DELETE ch_responsibles WHERE employee IS INITIAL.
if sy-subrc <> 0.
* KEINE besetzte Planstelle vorhanden, suche aufwärts -> Rekursivaufruf
In bezug auf den SY-SUBRC ist der TRANSPORTING NO FIELDS aber eigentlich bedeutungslos.Okay ich hatte hier einfach einen Denkfehler bezgl. des TRANSPORTING NO FIELDS ... habe das selber noch nie verwendet, daher kannte ich das nicht.
An der Stelle wären wieder ergänzende Hintergrundinformationen interessant, insbesondere die, auf welche Weise Du Deinen Code denn in die PA20/PA30 eingebunden hast. Ich kenne dafür zwei Wege: Über die ZXPADU01/ZXPADU02 (klassischer User Exit) oder über den BADI HRPAD00INFTY (und darin dann wieder über verschiedene Methoden).Sind für die PA20 / PA30 irgendwelche Userparameter vorhanden oder etwas derartiges, dass die Art und Weise wie man auf die Transaktion zugreift ( denn Berechtigungen - also Rollen und Profile sind identisch ) bestimmt? Das ist das einzige was ich mir vorstellen kann ...
Nicht, dass ich wüsste (wobei Du neben den regulären natürlich auch an - möglicherweise sogar kontextsensitive - strukturelle Berechtigungen denken musst, falls ihr die im Einsatz habt). Aber auch hier stellt sich wieder die Frage, was Du mit "zugreift" meinst. In der PA20/30 gibt man ja zunächst mal nicht mehr ein als die Personalnummer; der Rest ist dann infotypspezifisch. Unter welchen Umständen wird Dein Code überhaupt ausgeführt? Da fehlen deutlich zu viele Randinformationen. Wenn Du hier eine nützliche Antwort haben möchtest, wirst Du Dein Problem so detailliert beschreiben müssen, dass man es nachvollziehen kann.Sind für die PA20 / PA30 irgendwelche Userparameter vorhanden oder etwas derartiges, dass die Art und Weise wie man auf die Transaktion zugreift ( denn Berechtigungen - also Rollen und Profile sind identisch ) bestimmt?
Strukturelle Berechtigungen sind häufig in HCM-bezogene Probleme verwickelt. Trotzdem liebe ich sie, denn man kann eine Menge damit machen, und die strukturellen Berechtigungen als solche sind ja nicht schuld am jeweiligen Problem, sondern ein Fehler im Umgang damit.Das Programm hat aufgrund eines Customizingfehlers von einem Kollegen bezgl. strukturellen Berechtigungen ( die fürs MSS gedacht sind ) den Code aufgerufen
Das ist aber trotzdem Mist, denn dass eine Person mehrere Planstellen besetzt, ist ja absolut legitim (weswegen SAP auch den jeweiligen Besetzungsprozentsatz führt). Selbst wenn ihr davon in eurem Haus keinen Gebrauch macht, würde ich den Code so schreiben, dass er damit umgehen kann (wer weiß, was in Zukunft noch kommt). Im Zweifel bei jeder neu gefundenen Planstelle prüfen, ob sie schon in der Liste der bereits durchlaufenen Planstellen mit drin ist und wenn ja, den LOOP dort beenden.Da war dann allerdings noch das Problem mit der Endlosschleife .. diese wurde durchlaufen, weil sich mein Kollege für eben das MSS Reporting auf die Stelle des Personalchefs und seine aktuelle Stelle gleichzeitig gesetzt hat. Daraus ist dann dieser Loop entstanden.
Es lag nicht daran, dass er mehrere Planstellen hatte, das ist bei uns tatsächlich üblich ..DeathAndPain hat geschrieben:Das ist aber trotzdem Mist, denn dass eine Person mehrere Planstellen besetzt, ist ja absolut legitim (weswegen SAP auch den jeweiligen Besetzungsprozentsatz führt). Selbst wenn ihr davon in eurem Haus keinen Gebrauch macht, würde ich den Code so schreiben, dass er damit umgehen kann (wer weiß, was in Zukunft noch kommt).Da war dann allerdings noch das Problem mit der Endlosschleife .. diese wurde durchlaufen, weil sich mein Kollege für eben das MSS Reporting auf die Stelle des Personalchefs und seine aktuelle Stelle gleichzeitig gesetzt hat. Daraus ist dann dieser Loop entstanden.
Da hast du natürlich recht .. wobei ich noch nicht wirklich 100%ig hinter diese gestiegen bin ..DeathAndPain hat geschrieben:Strukturelle Berechtigungen sind häufig in HCM-bezogene Probleme verwickelt. Trotzdem liebe ich sie, denn man kann eine Menge damit machen, und die strukturellen Berechtigungen als solche sind ja nicht schuld am jeweiligen Problem, sondern ein Fehler im Umgang damit.Das Programm hat aufgrund eines Customizingfehlers von einem Kollegen bezgl. strukturellen Berechtigungen ( die fürs MSS gedacht sind ) den Code aufgerufen
Ok, mit sowas kann man sogar den SAP-Standard in eine Endlosschleife schicken. Wenn Du in Deinem Orgbaum einen Ring baust (Orgeinheit 1 > Orgeinheit 2 > Orgeinheit 3 > Orgeinheit 1), dann läuft er z.B. in der PPOSE bei der strukturellen Berechtigungsprüfung (!) in eine Endlosschleife, weil Du einen Auswertungsweg von der Form O-O-S-P haben wirst und er den Auswertungsbaum niemals komplett aufgespannt bekommt. Das hatten wir schon mal; da habe ich mir auch mit dem Debugger über die SM50 geholfen, um das zu finden.Es lag nicht daran, dass er mehrere Planstellen hatte, das ist bei uns tatsächlich üblich ..
Er hat sich hier dann allerdings zum Chef von seinem Chef gemacht. Dadurch wurde dann wieder sein chef gesucht, dann wurde er wieder gefunden .. dann wurde wieder der chef gesucht .. dann wieder er .. usw.
Einen Fall gibt es freilich, bei dem die strukturellen Berechtigungen ziemlich dicht dran sind, selbst die Ursache zu sein, und zwar wenn Du dafür die Pufferung eingeschaltet hast. Was hab ich mir schon einen Wolf gesucht, warum die strukturelle Berechtigung eines Users nicht funktioniert, obwohl ich sie korrekt eingestellt habe, bis ich auf den Trichter gekommen bin, dass ja erst nachts der Job (Report RHBAUS00) läuft, der den Puffer aktualisiert...Sie waren hier auch nicht das Problem .. sondern eben, wie du sagtest, der Umgang damit .. ^^