Hallo,

ich möchte bei einem Mitarbeiter, der frisch eingestellt wurde (der Fehler tritt auch bei bereits eingestellten Mitarbeitern auf) die Abwesenheitszeiten, sprich Urlaub, eingeben. Das wird auch akzeptiert es erfolgt allerdings beim Speichern die Meldung der Mitarbeiter sei nicht gesperrt --> die Eingabe kann nicht erfolgen.
Man kann zwar einen Infotyp sperren, aber das wirkt sich überhaupt nicht auf die Sachlage aus.
Wo könnte hier der Fehler stecken?

dello

Hallo,

hier nochmal ein paar zusätzliche Infos. Der Fehler tritt auf wenn das Urlaubskontigent während der Neueinstellung eines Mitarbeiters eingegeben wird. Die Urlaubsart ist Tarifurlaub. Die Systemeinstellung/-vorgabe von 30 Tagen soll lediglich auf 25 geändert werden.

Weitere Fehlermeldungen waren:
... dass die Sperrung nur durch eine exklusive Programmänderung hergestellt werden könnte...

dello

hi dello,

ich kann das problem nicht wirklch verstehen!

bei deinem 1. thread sagst du, dass der mitarbeiter nicht gesperrt werden kann. kann es sein, daß hier ein report läuft der diese Pernr gerade im zugriff hat?

bei dem 2. thread sieht es doch wieder ander aus!?
kann es sein, daß hier einfach noch nicht alle infotypen zur errechnung des urlaubes gepflegt sind? es ist ja die einstellungsmaßnahme.

wir lassen einen report laufen, der nen batch aufzeichnet. dieser wird dann abgespielt.

über welchen infotypen läuft euer urlaubskontingent?

gruß
daniel A.

Hallo,

also ich habe mich vielleicht auch etwas schlecht ausgedrückt. Während der Einstellung des Mitarbeiters werden die erforderlichen Infotypen gepflegt, darunter dieser: Abwesenheitskontinggente. Mit der Sperrung verhält es sich so: der Urlaub läuft über Abwesenheitskontinggente (2006). Während der Pflege dieses Infotypen konnten keine eigenen Angaben gemacht werden, sprich die vorgegebenen 30 Tage in 25 zu ändern. Der Anspruch des MA von 30 Tagen Urlaub blieb bestehen und ist auch nach wie vor erhalten geblieben, obwohl beim Abspeichern des Infotypen die Meldung erscheint: "Der Mitarbeiter ist noch nicht gesperrt"

Deine Aussage ".. der Mitarbeiter kann nicht gesperrt werden ..." ist nicht ganz richtig, denn es ist ja nicht klar wie der MA gesperrt werden kann, sonst käme ja die Meldung nicht.

dello

hallo dello,

nun bin ich völlig verwirrt!
du hast doch geschrieben, daß der mitarbeiter nicht gesperrt werden kann!? egal.

da wir eh nicht den 2006er im einsatz haben, weiß ich da eigentlich auch nicht bescheid.

guck doch mal ob dir der it2013 in sachen umbuchung weiterhilft.

vielleicht helfen auch die tabellen t559* weiter.

gruß
daniel A.

Hallo,

ich kann Dir zwar leider nicht sagen, wo der Fehler liegt  :'(, aber ein paar Sachen kann ich zumindestens ausschließen.

Aber erst mal eine Frage, ob ich das richtig verstanden habe:
Der Fehler tritt nicht nur in der Maßnahme auf sondern auch, wenn Du z.B. über die Transaktion PA61 (Zeitdaten pflegen) mit ändern den IT2006 aufrufst ?

Wenn der Fehler nur in der Maßnahme auftritt, wäre er ja zumindest schon mal umzingelt  :).

Wenn der Fehler auch außerhalb der Maßnahme auftritt,
dann habt Ihr in eurem System irgendwelche Einstellungen die zumindest für mich) ungewöhnlich sind, oder es ist ein Fall füs OSS (falls in letzer Zeit irgendwelche Korrekturen eingespielt wurden, und es vorher funktioniert hat).

Ich betreue ca. 8 verschiedene Kunden die alle den IT2006 seit Jahren nutzen, und bei keinem ist (bisher) so ein Problem aufgetreten. Im Customizing für den IT2006 ist mir auch nichts dazu bekannt.

Es kann zumindet nichts damit zu tun haben, ob Ihr den IT über Programm und/oder manuell anlegt, das macht im Customizing keinen grundsätzlichen Unterschied.

Mein Aussagen sind natürlich <ohne Gewähr> 😉,
es gibt ja nichts, das es nicht  gibt...

Ich würde trotzdem erst mal im OSS schauen, ob es dazu einen Hinweis gibt.

Grüße + Viel Erfolg
Sandra

Hallo,

danke für die Tipps, ích habe nun ein Kontingent anlegen können. Allerdings ging dies nur über die direkte Anwahl mit Angabe des Typs. DAnn konnte ich die vom System vorgeschlagenen Werte in einer Art Eingabemaske ändern. Es blieb die Frage offen, was man im Bild "Abwesenheitskontingente pflegen" machen kann, denn es war nicht möglich hier ein neues anzulegen -> beim Sichern kam wieder die oben beschriebene Fehlermeldung, das der Bewerber/Mitarbeiter noch nicht gesperrt ist. Der weiter lautende Text dazu ist wie folgt: Sie versuchen die Daten eines Mitarbeiters/Bewerbers zu verändern. Dies kann nur in einem exklusiven Zugriff geschehen, das heißt, daß die Daten für andere Benutzer gesperrt werden müssen. Dies  ist bisher noch nicht geschehen.
Das Problem kann sehr wahrscheinlich nur durch eine Änderung des Programms gelöst werden.
Meldungsnummer: PG184

dello

Hallo Dello,
welchen release habt Ihr im ??? Einsatz ?

Gruss RalfB

---

Hallo

bei uns läuft SAP Enterprise.... mit SAP HR 4.7..

dello

Hallo,

sorry aber deine Angaben sind etwas verwirrend.Normalerweise  ;) kann man in dem Bild "Abwesenheitskontingente pflegen" eben Abwesenheitskontingente pflegen 🙂.
Der Abwesenheitskontingenttyp muss dabei immer vorhanden sein (ob als Vorschlagswert oder durch Selbsteingabe), da man ja sagen muss, welches Abwesenheitskontingent man pflegen will...

Wenn Du schreibst, dass beim Sichern die Meldung erscheint, dass der Mitarbeiter nicht gesperrt werden konnte, dann deutet dass darauf hin dass das Problem darin liegt, wie in Eurem System der IT 2006 aufgerufen wird. Da normalweise die Personalnummer gesperrt wird, wenn ich sie über eine Pflegetransaktion aufrufe.

Bei den Abwesenheitskontingenten gibt es grundsätzlich nur 2 Arten wie sie generiert werden:
1. Über manuelle Eingabe, eventuell mit Vorschlagswerten. Das kann dann direkt über eine Pflegetransaktion passieren oder mittels Generierungsprogramm.
2. Die Kontingente werden über die Zeitauswertung generiert (RPTIME00), dann ist das Feld <Kont.Anspruch> nicht Eingabebereit (also grau hinterlegt) und alle Änderungen der Anzahl laufen über die Zeitauswertung und eventuelle noch über den It 2013 Kontingentkorrekturen.

Das alles hat aber eigentlich nichts damit zu tun ob der Mitarbeiter bei der Pflege der Kontingente gesperrt ist oder nicht.

Die Sperrung muss eigentlich vorher schon passieren und ist normalerweise für alle Infotypen identisch.

Wenn also der Infotyp 2006 ganz normal z.B. mit der Transaktion PA30 (Personalstammdaten pflegen) aufgerufen werden kann. Und wenn man dann mit <ändern> ganz normal in das Kontingent hineinkommt.
Wenn dann noch das Feld <Kont.Anzahl> nicht grau hinterlegt ist (also eingabebereit ist) und somit überschrieben werden kann. Und wenn dann beim Sichern die Meldung kommt, das der Mitarbeiter nicht gesperrt ist, dann stimmt etwas nicht, was nicht unbedingt an dem Infotyp 2006 liegen muss.
Da die Personalnummer schon beim Aufruf der Pflegetransaktion (z.B. PA30, PA61....)gesperrt sein müsste

Deshalb bin ich der Meinung, dass es nur  2 Ursachen für Deinen Fehler geben kann:

1. Einen SAP Programmfehler (falls in letzter Zeit Korrekturen eingespielt wurden) =>Dann müßte es im OSS schon einen Hinweise geben, oder Ihr müsst eine OSS Meldung aufmachen
2. In eurem System wurde irgendetwas "gebastelt"/modifieziert (direkt am IT 2006 oder wo auch immer)

Grüße
sandra

Ergänzung

Hallo,
ich habe mal im OSS geschaut.
Für das von Dir beschrieben Problem finde ich zwar nichts aktuelles, aber 😉 nach den Hinweisen gibt es immer mal wieder Probleme, dass eine Personalnummer nicht sauber geperrt oder entsperrt wird

Beispiel OSS :
Symptom                                                                
In den Transaktionen der Personalstammdaten (PA30, PA40, PA70, ...) kann
es vorkommen, daß nach mehrfachem Wechseln der Personalnummer die      
Sperren für die zentrale Person (CP) nicht mehr sauber gesetzt werden.  
.....

Es würde mich wirklich interssieren, ob der Fehler ein SAP Programmfehler ist, da ich mehrere Systeme betreue, in die demnächst Support Packages eingespeilt werden..

grüße
Sandra

Hallo,

danke für die umfangreiche Antwort.
Wenn ich über PA30 mit dem Abwesenheitskontingent reingehe, dann ist das Feld <Abwesn.Kont.> eingabebereit, läßt sich ändern und auch abspeichern.
Der beschriebene Fehler tritt nur dann auf, wenn ich nicht ändern, sondern Anlegen wähle. Dann erscheint eine Tabelle mit Übersicht der Kontingente welche das System vorschlägt. Diese sind änderbar, allerdings kommt dann beim Abspeichern die Fehlermeldung "Der Mitarbeiter/Bewerber ist noch nicht gesperrt.
Ich interpretiere dass so, das wenn ich für einen Mitarbeiter ei neues Kontingent anlegen will er ebenfalls gesperrt sein muß, die Frage ist nur wie Sperre ich den Mitarbeiter, oder müßte das eigentlich auch so wie beschrieben mit dem Starten der Transaktion geschehen.
dello

Hallo,

die Sperre der Personanummer, passiert (normalerweise) schon durch den Aufruf einer Pflegetransaktion (PA30, PA61,PA40) Eingabe der Personalnummer und Enter.

Welcher Infotyp gewählt wird und ob dann ändern, anlegen oder Übersciht gewählt wird ist egal (normalerweise)

Wenn nur der Infotyp 2006 eingegeben wird und dann anlegen ausgewählt wird, ist es auch normal, dass eine Liste mit den Kontingenttypen kommt.
Wenn man dann aus der Liste das Kontingent auswählt, das man anlegen möchte, müsste man in das Einzelbild <Abwesenheitskontingete pflegen> kommen.
In diesem kann man dann die Anzahl des Kontingentes ändern (die Personalnummer müsste immer noch gesperrt sein) und sichern.

Fazit: Was ich mit welchem Infotyp in einer Pflegetransaktion (PA30, PA61...) auch immer mache, die Personalnummer wird bei Aufrauf der transaktion, Eingabe der personalnummer und Enter gesperrt.

Ist Sie nicht gesperrt, dann müsste es sich um einen Programfehler Handeln, der mit der Transaktion direkt oder spezeill mit dem IT (fall alle anderen Infotypen korrekt funktionieren) zusammenhängt.

Grüße Sandra

Hi Dello ,
aha, release 4.7 , aber welches R/3 HR Support Package ?
Gehe über Menü: System, Status dann auf die Lupe,dann auf patches. ???

Schau doch mal vor dem Sichern des IT in der SM12, ob in der Tabelle PREL eine Satzsperre für die betreffende
Persnr gesetzt ist.


rb

---

Hallo,

sorry, also hier der Status  des Support Packages von SAP HR: Level 0016, SAPKE47016.

Mit der Sperre schaue ich noch nach, allerdings vermute ich, das die Sperre nicht gesetzt ist.

Ich möchte an dieser Stelle auch nochmal einiges zur Aussage von Sandra vermerken:

Wenn ich in 2006 nur Abwesenheitskontingente auswähle und ANLEGEN drücke, dann erscheint eine eingabebereite Liste mit zwei Kontingenten: 09 (Urlaub-Tage) und 10 (Urlaub-Stunden). Mein Problem ist hier nun, dass ich hier obwohl im Titel steht "Abwesenheitskontingente anlegen", keine Kontingente, wie z.B. Fortbildungsurlaub anlegen kann, da dann die Fehlermeldung aufftritt.
Hier kann ich auch eines der Kontingente nicht auswählen um es zu bearbeiten. Es ist lediglich eine Übersicht möglich, in der allerdings nur das bereits definierte Kontingent (Urlaub-Tage) auftaucht - aber ändern geht auch nicht, da das hier nur eine Übersicht ist.
dello

Hallo,

ist  ein bißchenschwer zu analysieren, wenn man den screen nicht direkt vor Augen hat. ???

Aber für die Fehlerananlyse lang eigentlich, was ralfb beschrieben hat,
wenn Du in der Pflegetransaktion bist und gleichzeitig über Sm12 feststellst dass die Personalnummer nicht geperrt ist, dann hast Du einen Fehler der behoben werden muss.

dass heißt, wie Du, wenn dieser fehler behoben ist, dazu kommst ein Kontingent anzulegen ist erst mal zweitrangig. ;)

Welches Bild Du bekommst kann "sonstwo" gesteuert sein (dynamische Mapnahmen, Infotyp Bildsteuerung etc.). Das was ich beschrieben habe ist (soweit mir bekannt) der Standard.
Aber versuche es doch mal so:
Transaktion PA61 (Zeitdaten pflegen), Eingabe : personalnummer, It 2006 Art xx(wie immer das Kontingente heiß das Du anlegen möchstest) , Zeitraum eingeben Enter und dann auf anlegen, dann müsstest Du in das Einzelbild <Abwesenheitskontingte pflegen> kommen
Über System=> Status müsste bei <Repository-Daten> in etwa das folgende stehen:                        
Transaktion          PA61        
Programm(Dynpro)     MP200000    
Dynpronummer         2250        
Programm(GUI)        MP200000    
Oberflächenstatus    QUOTAINS    

Wenn das alles nicht passiert, bin ich mit meinem Latein am Ende. Von irgendwelchen technischen Hintergründen habe ich keine Ahnung :P

Grüße Sandra

Hallo,

also hier die Ergebnisse der Sperrprüfung.

Wenn ich über PA61 reingehe und Abwesenheitskontignete anlegen wähle erzeuge ich einen Sperreintrag für die entsprechende Personalnummer.

In dem Moment, in dem ich ein neues Kontingent anlegen will, weider das Beispiel Fortbildungsurlaub, erscheint die Fehlermeldung und auch der Sperreintrag ist weg.

dello

Hallo,

also zumindest hat sich das Problem numehr etwas gelichtet. Wenn ich den von Sandra beschriebenen Weg gehe, dann wird das neue Kontingent angelegt. Voraussetzung dafür ist aber, das das Kontigent mit der Infotypasuwahl spezifiziert wird. Das heißt die Art muß mit angegeben werden. Dann erfolgt die Eingabe wie beschrieben und alles klappt.
Haken ist eben nach wie vor, das wenn eben keine Art angegeben wird ein Kontingent nicht angelegt werden kann da die Fehlermeldung kommt.
Was mir noch nicht ganz klar ist, sind die Sperrprozesse. Wenn ich mit PA61 reingehe und ein Kontingent auswähle, dann wird ein Sperrprozess erzeugt, der beibt so lange erhalten bis ich wie oben beschrieben ohne Kontingentart versuche eines anzulegen -> Folge: Fehlermeldung MA nicht gesperrt. Der Sperrprozeß ist nun auch weg.
Wenn das ganz dann durchexerciert wird bis zum letzten, dann komme ich zu dem Schluß, dass irgendwas mit den Sperrprozessen nicht in Ordnung ist, denn wenn ich erfolgreich ein Kontingent angelegt habe oder geändert habe, sichere und dann über ZURÜCK zur Auswahl der Infotypen gehe ist der Sperrprozeß noch aktiv. Das heißt, (und das habe ich ausprobiert) solange eine Personalnummer auf diesem Bild steht, existiert ein Sperrprozeß und wenn die Nummer geändert wird und "über den grünen Haken" auch die Daten zur neuen Personalnummer sichtbar werden (das heißt ohne die Infotypen "anzufassen") wird der alte Sperrprozeß gelöscht und ein neuer für die neue Personalnummer erscheint.
Und das beste zum Schluß: Parallel an zwei Rechnern konnten wir die Stammdaten (Basisbezüge) einer Person ändern und auch sichern. Beide Daten existieren, einmal mit 1500 Euro und einmal mit 3000 Euro - wenn er das auch überwiesen bekommt kann er sich ja freuen.

dello

Hi Dello,
ups, das ist aber ein relativ alter SP.
Ich vermute, daß Hinweis 625601(verweist auf SP17) oder 740088 (verweist auf SP 31 -lese hier den letzten Satz: "Das gleiche Verhalten tritt auch beim Sperren eines nicht gesperrten ....) zutreffend ist.
Im Zweifelsfall würde ich jetzt eine OSS eröffnen, hier kommst Du sonst nicht weiter! Ich vermute die Ursache aber in einem Standard-Funktionsbaustein(bapi-...), aber wie gesagt - euer Sp ist realtiv alt!
rb

---