Nein, genau andersherum. record muss den Datensatz enthalten, so wie er sein soll. Über validityend und validitybegin wird er gefunden. Wenn Du allerdings das Endedatum selbst ändern möchtest, müsste man ausprobieren, ob das so geht, denn ENDDA ist ein Schlüsselfeld der PA2001 und damit nicht änderbar. (Es kann aber sein, dass der Fuba selbst intelligent genug ist, das zu erkennen; das müsste man prüfen.)
Ich hatte auch manchmal Probleme mit dem Verbuchen bei NOCOMMIT = SPACE, obwohl es theoretisch funktionieren sollte. Deshalb habe ich mir angewöhnt, stets NOCOMMIT = 'X' zu setzen und hinterher den FB BAPI_TRANSACTION_COMMIT mit gesetztem WAIT-Parameter aufzurufen.
(Theoretisch wäre der gesetzte WAIT-Parameter auch nicht nötig, aber erst seit ich es so mache, habe ich wirklich keine Probleme mehr.)
Dir ist natürlich vorzuwerfen, dass Du mit Deinem EXCEPTIONS OTHERS = 1 offenbar noch nicht mal schaust, ob was schiefgelaufen ist. Dass da Fehlermeldungen kommen können, die Dir zeigen könnten, wo das Problem liegt, ist offensichtlich. Insofern probier doch bitte erst mal einen sauberen Funktionsbausteinaufruf mit vernünftiger Fehlerbehandlung, bevor Du um Hilfe rufst.
Im übrigen kannst Du auch den Parameter DIALOG_MODE auf '2' setzen. Dann läuft die ganze Infotyppflege sichtbar im Vordergrund ab, und Du kannst sehen, ob beim Füllen der Maske Probleme auftreten.
Ansonsten ist noch anzumerken, dass der HR_INFOTYPE_OPERATION zur Pflege des IT 2001 zwar geeignet ist
(habe ich selber schon oft dafür genutzt). Gleichwohl gibt es aber speziell für diesen Infotyp einen speziellen Baustein, der genau auf die Pflege von An- und Abwesenheiten ausgelegt ist und insofern tendenziell als bessere Wahl anzusehen ist. Und zwar kannst Du die Funktionsbausteine
- BAPI_PTMGRATTABS_MNGCREATION (Anlegen)
- BAPI_PTMGRATTABS_MNGCHANGE (Ändern)
- BAPI_PTMGRATTABS_MNGDELETE (Löschen)
nutzen, um IT 2001-Sätze zu pflegen. Macht sich besser, weil das Interface dieser Fubas genau für An/Abwesenheiten gestrickt ist.