Die SAP bietet im Standard einen Funktionsbaustein zum Durchführen von Operationen bei Infotypen an. Dieser ist sehr nützlich, wenn zum Beispiel neue Einträge in Infotypen durch eine Kundeneigene Entwicklung hinzugefügt oder angepasst werden sollen. Dieser Baustein nennt sich „HR_INFOTYPE_OPERATION“. Leider ist die entsprechende Dokumentation dieses Funktionsbausteins nicht sehr aussagekräftig, daher bedarf es meistens etwas Forschungsarbeit, bis man versteht, wie man diesen verwenden muss.

Sperren der Personalnummer

Wenn ein Anwender eine Änderung an einer Personalnummer durchführt, zum Beispiel über die Transaktion PA30, dann wird die Personalnummer für andere Anwender gesperrt, so dass diese nur noch lesend auf die Akte zugreifen können. Dadurch wird verhindert, das gleichzeitige Änderungen sich in die Quere kommen und vielleicht sogar gegenseitig überschreiben.

Auch bei der Verwendung des Funktionsbausteins HR_INFOTYPE_OPERATION ist es notwendig, dass die Personalnummer vorher gesperrt wird. Dazu gibt es einen weiteren Funktionsbaustein, den BAPI_EMPLOYEE_ENQUEUE:

DATA: lv_pernr    TYPE pernr_d,
      ls_bapiret1 TYPE bapireturn1, 


CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
    EXPORTING
      number = lv_pernr
    IMPORTING
      return = ls_bapiret1. 

IF ls_bapiret1 IS NOT INITIAL.
    MESSAGE ID ls_bapiret1-id TYPE ls_bapiret1-type NUMBER ls_bapiret1-number.
  ENDIF. 

In diesem Funktionsbaustein wird lediglich die Personalnummer mitgegeben, anschließend sollte sie durch den ausführenden Benutzer gesperrt sein, damit die Änderungen stattfinden können. Die Inhalte des Return-Parameters geben darüber eine Information. Dort werden in einem Fehlerfalle auch die Fehlermeldung mitgegeben, so dass man entsprechend auf einige Situationen die häufiger auftreten reagieren kann.

Lesen bestehender Einträge

In einigen Fällen kann es notwendig sein, dass bereits bestehende Einträge für die Änderungen gelesen werden müssen. Dies kann zum Beispiel der Fall sein, wenn ein Eintrag abgegrenzt oder zu einem neuen Eintrag mit ergänzenden Informationen kopiert werden soll.

Dieses Vorgehen wird einfacher, durch den Funktionsbaustein HR_READ_INFOTYPE, der den entsprechenden Eintrag oder auch mehrere Einträge in einem Infotyp liefert. Die Struktur passt dann direkt auch für das spätere Schreiben in den Infotypen.

DATA: lv_pernr    TYPE pernr_d,
      lt_p0006    TYPE TABLE OF p0006. 

CALL FUNCTION 'HR_READ_INFOTYPE'
    EXPORTING
*     TCLAS           = 'A'
      pernr           = lv_pernr
      infty           = '0006'
*     BEGDA           = '18000101'
      endda           = '99991231'
*     SPRPS           = '*'
*     BYPASS_BUFFER   = ' '
*     LEGACY_MODE     = ' '
* IMPORTING
*     SUBRC           =
    TABLES
      infty_tab       = lt_p0006
    EXCEPTIONS
      infty_not_found = 1
      invalid_input   = 2
      OTHERS          = 3.

  IF lt_p0050 IS INITIAL.
*     Ggf. Fehlermeldung ausgeben
  ENDIF. 

In der Vergangenheit ist mir dabei aufgefallen, dass man immer die Struktur zu einem Infotyp für die Definition des Datentyps beim Tables Parameter nutzen sollte. Dies ist in der Regel PXXXX, wobei das XXXX durch den Nummer des Infotyps ersetzt wird. Bei der Verwendung der Transparenten Tabelle als Datentyp kann es sonst später beim Funktionsbaustein HR_INFOTYPE_OPERATION zu Fehlern kommen.

Änderung der Daten durchführen

Nachdem die Daten ausgelesen wurden, bzw. eine entsprechende Struktur angelegt wurde, können nun die Operationen am Infotypen durchgeführt werden.

Mögliche Operationen sind unter andere:

• MOD: Änderung von Einträgen
• INS: Hinzufügen von Einträgen
• DEL: Löschen von Einträgen
• LIS9: Abgrenzen von Einträgen

Im folgenden Beispiel wird ein neuer Eintrag hinzugefügt. Ein ggf. bestehender Eintrag wird je nach Infotyp abgegrenzt werden:

CALL FUNCTION 'HR_INFOTYPE_OPERATION'
    EXPORTING
      infty         = '0006'
      number        = lv_pernr
      subtype       = '0001'
      objectid      = ls_p0006-objps
      lockindicator = ls_p0006-sprps
      validityend   = '99991231'
      validitybegin = sy-datum
      recordnumber  = ls_p0006-seqnr
      record        = ls_p0006
      operation     = 'INS'
*     TCLAS         = 'A'
*     DIALOG_MODE   = '0'
*     NOCOMMIT      =
*     VIEW_IDENTIFIER        =
*     SECONDARY_RECORD       =
    IMPORTING
      return        = ls_return
      key           = ls_key. 

Die Informationen die neu geschrieben werden sollen, müssen in der Struktur für den Parameter „record“ geschrieben werden, im Beispiel oben also bei der Struktur ls_p0006. Das betrifft vor allem den Gültigkeitszeitraum mit BEGDA und ENDDA.

Die weiteren Parameter dienen der Selektion des Datensatzes an dem die Operation durchgeführt werden soll.

Hier zeigt sich auch der Vorteil, wenn man vorher bestehende Einträge ausliest. Man hat direkt die Parameter zur Identifizierung der Einträge.

Der „return“-Parameter gibt hier auch wieder Informationen darüber, ob die entsprechende Operation durchgeführt werden konnte oder ob es zu einem Fehler gekommen ist.

Entsperren der Personalnummer

Nachdem wir im ersten Schritt die Personalnummer für Änderungen durch andere Benutzer gesperrt haben, muss diese nun nach der Bearbeitung auch wieder freigegeben werden. Auch dafür gibt es einen entsprechenden Funktionsbaustein. Dieser Schritt ist wichtig und sollte nicht vergessen werden:

  CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
    EXPORTING
      number = lv_pernr
    IMPORTING
      return = ls_bapiret1.