HR_INFOTYPE_OPERATION - Commit

Hello,
I am using FM- HR_INFOTYPE_OPERATION to update the infotype but i dont want to commit the changes till i do the explicit commit to handle logical unit of work. Though i am passing the NOCOMMIT = 'X', still it commiting on its own. Could anyone help on this same.
Thanks & Regards,
Raja

Hi raja,
1. HR_INFOTYPE_OPERATION
   won't work on the logical unit of work concept.
2. So its better to use this FM,
   AT THE LAST.
3. When u are sure everything has gone allright,
   and u want to finally do explicit COMMIT   WORK,
   just before that,
   use this FM,
   (without nocommit)
regards,
amit m.

Similar Messages

FM 'HR_INFOTYPE_OPERATION' & BADI 'HRPAD00INFTY'

Hello fellow Abapers. I am experiencing problems trying to implement the following.
We have a custom infotype (9127) that has 8 intervals of dates. We want to created an absence if any of these intervals are filled. So, after some research i have found this BADI 'HRPAD00INFTY' and specially the method 'IN_UPDATE'. This method is triggered after pushing the save button, so it's just what i needed. I have already the information i need (after converting prelp structure to pnnnn) and then i try to create a record in INFTY 2001 with FM 'HR_INFOTYPE_OPERATION'.
I have made a small report with this FM and it works just fine, i can create a record i PA2001 just fine, but in the implementation of the BADI it isn't working. I guess it might be something to do with 'locks', not really sure, so if anyone has a suggestion i'd appreciatiate it.
BTW, here is the code i am using :
        CALL FUNCTION 'HR_INFOTYPE_OPERATION'
        EXPORTING
          INFTY                  = '2001'
          NUMBER                 = wa_9127-pernr
          SUBTYPE                = 'L145'
    OBJECTID               =
    LOCKINDICATOR          =
          VALIDITYEND            = <fs2>
          VALIDITYBEGIN          = <fs1>
    RECORDNUMBER           = 0
          RECORD                 = rec2001
          OPERATION              = 'INS'
    TCLAS                  = 'A'
    DIALOG_MODE            = '0'
    NOCOMMIT               =
    VIEW_IDENTIFIER        =
    SECONDARY_RECORD       =
        IMPORTING
          RETURN                 = codret
    KEY                    =
Thanks in advance, Pedro Guarita.

In FM 'HR_INFOTYPE_OPERATION', commit work is executed after infortype was updated. Infortype 9127 and corresponding BAdi belong to the same SAP LUW. So it leads to commit work has no effect in BAdi.
A common solution is to call u2018HR_INFOTYPE_OPERATION' by a submit program, this will trigger another LUW in a new work process to commit your data. The pain point for this solution is that you have to pass the data to your new program (always use memory). Also guaranteeing the success is a little bit difficult .
Another solution is to call FM like this: CALL FUNCTION 'HR_INFOTYPE_OPERATION' DESTINATION 'NONE' in BAdi 'HRPAD00INFTY'. Help this will help u.
Regards,
Kevin

About to use HR_INFOTYPE_OPERATION to create customer infotype issue:

hi
i want to create infotype use function(HR_INFOTYPE_OPERATION).
this infotype is customer infotype.
the first scenario is:
i'm be sure no data about one employee in this infotype(9004).
to call with data upload function and put data into internal table IT_PA9004.
and the table data as follow:
one line: it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080201' , it_pa9004-endda = '20080930'
          it_pa9004-zzvalue = 50 (customer field).
two line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080201' , it_pa9004-endda = '20080930'
          it_pa9004-zzvalue = 60 (customer field).
three line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 70 (customer field).
four line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 80 (customer field).
i run the programme and get information is:
11022887 insert ok.
11022887 insert ok.
11022887 insert ok.
11022887 insert ok.
but i use the transation PA30 to view all data:
in database just exist one row:
four line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 80 (customer field).
the second scenario is:
in database the infotype have exist one row:
           pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ02',
           pa9004-begda = '20080318' , pa9004-endda = '20080318'
           pa9004-zzvalue = X (customer field).
and i create another row:
line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ02',
          it_pa9004-begda = '20080318' , it_pa9004-endda = '99991231'
          it_pa9004-zzvalue = 80 (customer field)
i run the programme and get information is:
11022887 insert ok.
the three scenario is:
    set HR_INFOTYPE_OPERATION of import parameter operation = 'MOD'
    in any scenario will get error :not exist subtype .
what heppend about HR_INFOTYPE_OPERATION working,i had to use this function to
   create other infotype of SAP owner.
   and will create successfully.
so i thank it may be config Constraints about customer infotype.
is time Constraints effect?
so i want to how to check it?
and if i want to create one infotype for customer using PM01 what some thing
must be taken into account.
think you advance.
partial source code as follow:
FORM ACTION_INSERT .
DATA: P_FLAG TYPE C.
DATA: WA_LOG LIKE LINE OF DATA_LOG.
DATA: PP_ACTION TYPE PSPAR-ACTIO.
LOOP AT IT_PA9004.
    CLEAR P_FLAG.
    CALL FUNCTION 'HR_PSBUFFER_INITIALIZE'.
    PERFORM lock_employee USING IT_PA9004-pernr CHANGING P_FLAG.
    PP_ACTION = IT_PA9004-ACTION.
    PERFORM HR_INFOTYPE_OPERATION USING IT_PA9004 PP_ACTION CHANGING P_FLAG.
    IF P_FLAG IS INITIAL.
      if test_run = space.
        COMMIT WORK.
      else.
        ROLLBACK WORK.
      endif.
      write:/ it_pa9004-pernr,'insert ok'.
    ELSE.
      ROLLBACK WORK.
      write:/ it_pa9004-pernr,'error'.
    ENDIF.
    PERFORM unlock_employee USING IT_PA9004-pernr .
ENDLOOP.
ENDFORM.                    " ACTION_INSERT
FORM LOCK_EMPLOYEE USING    P_PERNR
                    CHANGING PP_FLAG.
CHECK PP_FLAG IS INITIAL.
CLEAR P_RETURN.
CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
    EXPORTING
      number = P_PERNR
    IMPORTING
      return = P_RETURN
    EXCEPTIONS
      OTHERS = 01.
CALL FUNCTION 'HR_INITIALIZE_BUFFER'
    EXPORTING
      pernr = P_PERNR.
IF P_RETURN IS NOT INITIAL.
    PP_FLAG = '1'.
ENDIF.
ENDFORM.                    " LOCK_EMPLOYEE
FORM HR_INFOTYPE_OPERATION USING    P_PA9004 LIKE IT_PA9004
                                     P_ACTION type PSPAR-ACTIO
                            CHANGING PP_FLAG.
CHECK PP_FLAG IS INITIAL.
DATA: bapipakey type bapipakey,
        P_SUBTY TYPE P9004-SUBTY,
        PP_9004 TYPE TABLE OF P9004 WITH HEADER LINE.
CLEAR P_RETURN.
REFRESH PP_9004.
MOVE-CORRESPONDING P_PA9004 TO PP_9004.
IF P_ACTION = 'INS'.
    PP_9004-AEDTM = SY-DATUM.
    PP_9004-UNAME = SY-UNAME.
ENDIF.
IF P_ACTION = 'MOD'.
    PP_9004-AEDTM = SY-DATUM.
    PP_9004-UNAME = SY-UNAME.
ENDIF.
APPEND PP_9004.
P_SUBTY = P_LGART.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
    EXPORTING
      infty         = '9004'
     subtype       = 'FQ03'
      subtype       = P_SUBTY
      number        = PP_9004-pernr
      validityend   = PP_9004-ENDDA
      validitybegin = PP_9004-begda
     RECORDNUMBER = pp_9004-seqnr
      record        = PP_9004
       operation     = 'INS'
     operation     = P_ACTION
      nocommit      = 'X'
    IMPORTING
      return        = P_RETURN
      key           = bapipakey
    EXCEPTIONS
      OTHERS        = 0.
IF P_RETURN IS NOT INITIAL.
    PP_FLAG = '9'.
ENDIF.
ENDFORM.                    " HR_INFOTYPE_OPERATION
FORM UNLOCK_EMPLOYEE USING    P_PERNR.
CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
    EXPORTING
      number = p_pernr
    IMPORTING
      return = P_RETURN
    EXCEPTIONS
      OTHERS = 01.
ENDFORM.                    " UNLOCK_EMPLOYEE

hi
i want to create infotype use function(HR_INFOTYPE_OPERATION).
this infotype is customer infotype.
the first scenario is:
i'm be sure no data about one employee in this infotype(9004).
to call with data upload function and put data into internal table IT_PA9004.
and the table data as follow:
one line: it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080201' , it_pa9004-endda = '20080930'
          it_pa9004-zzvalue = 50 (customer field).
two line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080201' , it_pa9004-endda = '20080930'
          it_pa9004-zzvalue = 60 (customer field).
three line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 70 (customer field).
four line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 80 (customer field).
i run the programme and get information is:
11022887 insert ok.
11022887 insert ok.
11022887 insert ok.
11022887 insert ok.
but i use the transation PA30 to view all data:
in database just exist one row:
four line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ03',
          it_pa9004-begda = '20080101' , it_pa9004-endda = '20081031'
          it_pa9004-zzvalue = 80 (customer field).
the second scenario is:
in database the infotype have exist one row:
           pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ02',
           pa9004-begda = '20080318' , pa9004-endda = '20080318'
           pa9004-zzvalue = X (customer field).
and i create another row:
line:it_pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ02',
          it_pa9004-begda = '20080318' , it_pa9004-endda = '99991231'
          it_pa9004-zzvalue = 80 (customer field)
i run the programme and get information is:
11022887 insert ok.
but in database just exist the first data
           pa9004-pernr = '11022887' ,it_pa9004-subty = 'FQ02',
           pa9004-begda = '20080318' , pa9004-endda = '20080318'
           pa9004-zzvalue = X (customer field).
the three scenario is:
    set HR_INFOTYPE_OPERATION of import parameter operation = 'MOD'
    in any scenario will get error :not exist subtype .
what heppend about HR_INFOTYPE_OPERATION working,i had to use this function to
   create other infotype of SAP owner.
   and will create successfully.
so i thank it may be config Constraints about customer infotype.
is time Constraints effect?
so i want to how to check it?
and if i want to create one infotype for customer using PM01 what some thing
must be taken into account.
think you advance.
partial source code as follow:
FORM ACTION_INSERT .
DATA: P_FLAG TYPE C.
DATA: WA_LOG LIKE LINE OF DATA_LOG.
DATA: PP_ACTION TYPE PSPAR-ACTIO.
LOOP AT IT_PA9004.
    CLEAR P_FLAG.
    CALL FUNCTION 'HR_PSBUFFER_INITIALIZE'.
    PERFORM lock_employee USING IT_PA9004-pernr CHANGING P_FLAG.
    PP_ACTION = IT_PA9004-ACTION.
    PERFORM HR_INFOTYPE_OPERATION USING IT_PA9004 PP_ACTION CHANGING P_FLAG.
    IF P_FLAG IS INITIAL.
      if test_run = space.
        COMMIT WORK.
      else.
        ROLLBACK WORK.
      endif.
      write:/ it_pa9004-pernr,'insert ok'.
    ELSE.
      ROLLBACK WORK.
      write:/ it_pa9004-pernr,'error'.
    ENDIF.
    PERFORM unlock_employee USING IT_PA9004-pernr .
ENDLOOP.
ENDFORM.                    " ACTION_INSERT
FORM LOCK_EMPLOYEE USING    P_PERNR
                    CHANGING PP_FLAG.
CHECK PP_FLAG IS INITIAL.
CLEAR P_RETURN.
CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
    EXPORTING
      number = P_PERNR
    IMPORTING
      return = P_RETURN
    EXCEPTIONS
      OTHERS = 01.
CALL FUNCTION 'HR_INITIALIZE_BUFFER'
    EXPORTING
      pernr = P_PERNR.
IF P_RETURN IS NOT INITIAL.
    PP_FLAG = '1'.
ENDIF.
ENDFORM.                    " LOCK_EMPLOYEE
FORM HR_INFOTYPE_OPERATION USING    P_PA9004 LIKE IT_PA9004
                                     P_ACTION type PSPAR-ACTIO
                            CHANGING PP_FLAG.
CHECK PP_FLAG IS INITIAL.
DATA: bapipakey type bapipakey,
        P_SUBTY TYPE P9004-SUBTY,
        PP_9004 TYPE TABLE OF P9004 WITH HEADER LINE.
CLEAR P_RETURN.
REFRESH PP_9004.
MOVE-CORRESPONDING P_PA9004 TO PP_9004.
IF P_ACTION = 'INS'.
    PP_9004-AEDTM = SY-DATUM.
    PP_9004-UNAME = SY-UNAME.
ENDIF.
IF P_ACTION = 'MOD'.
    PP_9004-AEDTM = SY-DATUM.
    PP_9004-UNAME = SY-UNAME.
ENDIF.
APPEND PP_9004.
P_SUBTY = P_LGART.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
    EXPORTING
      infty         = '9004'
     subtype       = 'FQ03'
      subtype       = P_SUBTY
      number        = PP_9004-pernr
      validityend   = PP_9004-ENDDA
      validitybegin = PP_9004-begda
     RECORDNUMBER = pp_9004-seqnr
      record        = PP_9004
       operation     = 'INS'
     operation     = P_ACTION
      nocommit      = 'X'
    IMPORTING
      return        = P_RETURN
      key           = bapipakey
    EXCEPTIONS
      OTHERS        = 0.
IF P_RETURN IS NOT INITIAL.
    PP_FLAG = '9'.
ENDIF.
ENDFORM.                    " HR_INFOTYPE_OPERATION
FORM UNLOCK_EMPLOYEE USING    P_PERNR.
CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
    EXPORTING
      number = p_pernr
    IMPORTING
      return = P_RETURN
    EXCEPTIONS
      OTHERS = 01.
ENDFORM.                    " UNLOCK_EMPLOYEE

Problem with multiple calls to hr_infotype_operation in a loop

Hi,
Im using infotyp 2003 with the following situation. For a date, e.g. 2011/07/20 and a person_nr I have several time entries, like 08:00-09:00, 10:00-12:00, 15:00-17:00. Now I read the entries with HR_READ_INFOTYPE and store them back unmodified with hr_infotype_operation in a loop in the same report.
data: i_p2003 type standard table of p2003.
CALL FUNCTION 'HR_READ_INFOTYPE'
         EXPORTING
*          TCLAS                 = 'A'
           pernr                 = person_nr
           infty                 = '2003'
         BEGDA                 = '20110720'
          ENDDA                 = '20110720'
*          BYPASS_BUFFER         = ' '
*          LEGACY_MODE           = ' '
*        IMPORTING
*          SUBRC                 =
         tables
           infty_tab             = i_p2003
        EXCEPTIONS
          INFTY_NOT_FOUND       = 1
          OTHERS                = 2.
loop at i_p2003 assigning <p>.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
        EXPORTING
          infty         = '2003'
          number       = person_nr
          validityend   = '20110720'
          validitybegin = '20110720'
          record        = <p>
          operation     = 'MOD'
          dialog_mode   = '0'
        IMPORTING
          return        = return_struct
          key           = personaldatakey
        EXCEPTIONS
          OTHERS        = 0.
endloop.
the first call to hr_infotype_operation succeeds but the following operations fail because of collision. This example is stupid, I know, but it shows the core of a problem I have in a more complex report.
I face the problem that several calls to HR_INFOTYPE_OPERATION cause a collision error even if there cannot be a collision because the data are unchanged.
Any hints on this.
Regards,
JOP

Hi, you must execute a 'BAPI_EMPLOYEE_ENQUEUE' before 'HR_INFOTYPE_OPERATION' and a 'HR_EMPLOYEE_DEQUEUE' after.
See next example:
Bloqueo del empleado
CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
EXPORTING
    NUMBER = PERNR.
IF SY-SUBRC IS INITIAL.
Si se pudo bloquear el empleado intenta
insertar el infotipo
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
    INFTY         = '2001'
    NUMBER        = P0001-PERNR
    SUBTYPE       = i_p2001-subty
    VALIDITYEND   = acdate
    VALIDITYBEGIN = acdate
    RECORD        = i_p2001
    RECORDNUMBER = '000'
    OPERATION     = 'INS'
    TCLAS         = 'A'
    DIALOG_MODE   = '0'
    NOCOMMIT      = ' '
IMPORTING
    RETURN        = I_RETURN
    KEY           = I_KEY.
IF SY-SUBRC IS INITIAL.
VARGT = 'Y'.
ELSE.
VARGT = 'N'.
ENDIF.
No se hace COMMIT debido que el estandar lo realiza
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
Desbloqueo del empleado
CALL FUNCTION 'HR_EMPLOYEE_DEQUEUE'
EXPORTING
NUMBER = PERNR.
Regards,
Diego.

HR_INFOTYPE_OPERATION not working when called from Dynamic action

Hi ,
       Senario : I would like to execute a form from dynamic action which
creates a record in 0015 (Additional payment IT) .
       I have writen the code as shown below am using FM HR_INFOTYPE_OPERATION
. When i execute the program from se38 it is creating a record, however it is
not created when it is called from dynamic action..when i debugged the code in
inside the FM HR_INFOTYPE_OPERATION there is a FM HR_MAINTAIN_MASTERDATA where
they are using call dialog (statement) and
sy-oncom = 'N'   when called from Dynamic action and
sy-oncom = 'S'   when called executed directly.
I tried to change the sy-oncom to S while run from Dynamic action it created
the record.
So Can anyone explain me abt sy-oncom and how can i resolve the issue..
code..
REPORT ZHRPYENH01 .
perFORM TERMIATION_9000.
INCLUDE DBPNPMAC.
      FORM Termiation_9000                                          *
FORM TERMIATION_9000.
INFOTYPES : 0015.
*data : i .
*i ='c'.
*break-point.
*message i000(000) with i.
TABLES : PRELP.
DATA : P9000 TYPE PA9000." with header line.
DATA : P0000 TYPE STANDARD TABLE OF P0000 WITH HEADER LINE.
DATA : P0015 TYPE STANDARD TABLE OF P0015 WITH HEADER LINE.
DATA : HIRE_DATE LIKE SY-DATUM,
         TERM_DATE LIKE SY-DATUM.
DATA : MOLGA LIKE T500L-MOLGA VALUE '25',
         SEQNR LIKE PC261-SEQNR.
DATA : RGDIR TYPE STANDARD TABLE OF PC261 WITH HEADER LINE.
DATA : ACTUAL_PERIOD LIKE PA9000-RETENTION.
DATA : PNP-SW-FOUND TYPE SY-SUBRC ,
         PNP-SY-TABIX TYPE SY-TABIX.
DATA : TER_PERNR LIKE PA0001-PERNR.
DATA : REF_PERNR LIKE PA0001-PERNR.
data : key type BAPIPAKEY.
data : payed_amount type p0015-BETRG.
data : future_payment_amount type p0015-BETRG.
data : p0002 like pa0002.
types : begin of t_deduction ,
          deducation_date like p0015-begda,
          future_payment_amount type p0015-BETRG.
types : end of t_deduction.
data : future_deduction type standard table of t_deduction with
*header line.
data : future_deduction type t_deduction .
data : RETURN type BAPIRETURN1.
*data : deduction_p0015 like standard table of p0015 with header line.
data : deduction_p0015 like p0015 .
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
****Prepare 0015 data for deduction
*deduction for payed amount
clear deduction_p0015.
*refresh deduction_p0015.
deduction_p0015-pernr = REF_PERNR.
*deduction_p0015-pernr = TER_PERNR.
deduction_p0015-lgart = 'M120'.
deduction_p0015-begda = sy-datum + 1 .
deduction_p0015-endda = sy-datum + 1 .
deduction_p0015-BETRG = payed_amount.
deduction_p0015-WAERS = 'SGD'.
deduction_p0015-ZUORD = TER_PERNR.
*append deduction_p0015.
**deduction for future payment amount
*loop at future_deduction.
*clear deduction_p0015.
*deduction_p0015-pernr = REF_PERNR.
**deduction_p0015-pernr = TER_PERNR.
*deduction_p0015-lgart = 'M120'.
*deduction_p0015-begda = FUTURE_DEDUCTION-DEDUCATION_DATE.
*deduction_p0015-endda = FUTURE_DEDUCTION-DEDUCATION_DATE.
*deduction_p0015-BETRG = future_deduction-future_payment_amount.
*deduction_p0015-WAERS = 'SGD'.
*deduction_p0015-ZUORD = TER_PERNR.
*append deduction_p0015.
*endloop.
Create a deduction wage type in 0015 for the employee
break-point.
CLEAR RETURN.
CALL FUNCTION 'BAPI_EMPLOYEET_ENQUEUE'
EXPORTING
    NUMBER              = REF_PERNR
    VALIDITYBEGIN       = '18000101'
IMPORTING
   RETURN              = return
if not return is initial.
message E000(000) with
'Referred Employee could not be locked for referal payment deducation,
please try after some time'.
endif.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
    INFTY                  = '0015'
    NUMBER                 = REF_PERNR
   SUBTYPE                = 'M120'
OBJECTID               =
LOCKINDICATOR          =
   VALIDITYEND            = SY-DATUM
   VALIDITYBEGIN          = SY-DATUM
RECORDNUMBER           =
    RECORD                 = deduction_p0015
    OPERATION              = 'COPY'
TCLAS                  = 'A'
   DIALOG_MODE            = '2'
NOCOMMIT               =
VIEW_IDENTIFIER        =
SECONDARY_RECORD       =
IMPORTING
   RETURN                 = return
   KEY                    = key
break-point.
COMMIT WORK.
if not return is initial.
*return-TYPE
*ID
*NUMBER
*MESSAGE
message I000(000) with return-MESSAGE.
endif.
CALL FUNCTION 'BAPI_EMPLOYEET_DEQUEUE'
EXPORTING
    NUMBER              = REF_PERNR
    VALIDITYBEGIN       = '18000101'
IMPORTING
   RETURN              = return
xxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxx
Thanks and regards
-Senthil Bala
Message was edited by: senthil bala

Hi Senthil
Why at all U want a subroutine to create a record in IT0015 through Dynamic action.There are some standard codes available to update infotypes.
Let me give U an example
14     9CON     BETRG     4     2     I     INS,0015 This will create a record in IT0015 when IT0014 is updated with Wagetype 9CON
14     9CON     BETRG     4     3     W     P0015-LGART='5400' Set wagetype for IT0015(Here U can use a subroutine call to set the wagetype)
14     9CON     BETRG     4     4     W     P0015-BETRG=P0014-BETRG set amount for IT0015(Here U can use a subroutine call to get the amount)
14     9CON     BETRG     4     5     W     P0015-BEGDA=P0014-ENDDA set the dates(Here U can use a subroutine call to set the dates)
Hope this will help U.
Please award points if helpful

HR ABAP: Issue with using 'nocommit' parameter on FM HR_INFOTYPE_OPERATION

Issue with using nocommit parameter on FM HR_INFOTYPE_OPERATION:
My client has a requirement to create the following 4 infotypes in sequence in a LUW, i.e either all are created or none is created.
9045 (custom infotype)
0045
0078
0015
I tried to use the nocommit parameter on FM HR_INFOTYPE_OPERATION to insert the 4 infotypes
in a nocoomit mode and then at the end I have issued
'Commit Work', but to my surprise only I/T 0015 is created in the database and the first three (9045, 0045 and 0078) did not make it to database.
I searched many threads on SDN but could not find a solution.
Please let me know if there could be any solution to implement the LUW.
YOur inputs will be appreciated.

Hi ,
i think u can also try with this FM HR_MAINTAIN_MASTERDATA , see its documentations.
no commit works like a simulation mode , what u can do is ,
call FM for all Infotypes and collect all error msgs if any , then finally call FM for all infotypes again without passing nocommit work ( i.e space).
regards
prabhu

Re: perform on commit

Hello Friends,
I want to write perform on commit.
but can anyone tell me what is the syntax whils writing it as perform?
and while writing form and endform.
it's urgent , plz.

In your BADI submit a function module [IN BACKGROUND TASK|https://www.sdn.sap.com/irj/scn/advancedsearch?cat=sdn_all&query=inBACKGROUNDTASK&adv=false&sortby=cm_rnd_rankvalue] to update the second infotype via FM [HR_INFOTYPE_OPERATION|https://www.sdn.sap.com/irj/scn/advancedsearch?query=hr_infotype_operation&cat=sdn_all] (create a RFC enabled Z-FM that call the standard FM)
Regards

Perform ON COMMIT doesn't work (Try it)

Has anyone tried a PERFORM ON COMMIT within a BADI? It doesn't work and i don't know why.
I am working with the HR Module, and i have a BADI, which is fired when the user hits the 'SAVE' button (PA30 Transaction).. when this happens, i execute a PERFORM ON COMMIT and the subroutine is never called...
Does anyone know anything about this?
Regards

In your BADI submit a function module [IN BACKGROUND TASK|https://www.sdn.sap.com/irj/scn/advancedsearch?cat=sdn_all&query=inBACKGROUNDTASK&adv=false&sortby=cm_rnd_rankvalue] to update the second infotype via FM [HR_INFOTYPE_OPERATION|https://www.sdn.sap.com/irj/scn/advancedsearch?query=hr_infotype_operation&cat=sdn_all] (create a RFC enabled Z-FM that call the standard FM)
Regards

Potential problems with using a report to run a commit in a separate LUW.

I am working with a classic Badi within a transaction where I wanted to commit some information to a database before the commit that occurs at the end of the transaction.
Putting a commit point directly inside the BADI caused problems with cursors that were open inside the transaction, so I researched some and discovered that Report Programs can run in a separate database Logical Unit of Work (LUW).
I coded my BADI to call a report which does some database work based on input parameters, and then commits this work to the database before returning control back to the calling BADI function.
Does anyone know of any potential problems from doing this? It seems like a good way to get around restrictions on the use of commit points inside transactions, but I'm not sure if there could be potential undesired effects from doing this.
Has anyone tried this before?

Hi Clay,
Yes I did it too. We faced some issues with commit when using fm HR_INFOTYPE_OPERATION . We had to enclose it in separate report which only then let us do physical change in DB.
What is to be noticed here as well is (according to SAP) that DB commit is triggered each time work process is released which happens when:
- system shows dialog message
- RFC call is executed
- new transaction is called
The above however didn't work for me in couple cases, but using separate SAP LUW solves the problem (as you already read). This happens each time:
- new report is called (SUBMIT ...),
- new transaction is called (CALL TRANSACTION ...)
- new asynchoronus RFC call is executed (CALL FUNCTION...STARTING NEW TASK).
This approach works fine for cases I met and had to overcome with such solution. So far we didn't face any issues with that. Works perfectly
Regards
Marcin

HR_INFOTYPE_OPERATION not working in badi HRBAS00INFTY

Hi All,
I need to create a record in IT0019 when IT0024 is updated.
For that purpose I have created an implementation of badi HRBAS00INFTY and added my code in method IN_UPDATE.
I try to create the record in IT0019 using FM HR_INFOTYPE_OPERATION.
The problem is that the record is not created but the FM doesn't return any error( return param is empty ).
I added 'commit WORK.' after the FM but this doesn't work neither.
Do you have any idea why ths FM is not working in the badi.
kr
Karim

Hi,
Try with the BADI HRPAD00INFTY, If it not working try creating dynamic action for INFTY 0024.
Dynamic actions : SPRO -> SAP Reference IMG -> Personnel Management -> Personnel Administration - >Customizing procedures -> Dynamic Actions.
~~~ Ganesh Kumar K.

HR_INFOTYPE_OPERATION

Hi,
i am using the FM HR_INFOTYPE_OPERATION to upload the data into infotypes 0000,0007 and 0008 for change of shift action and in the FM i am using NOCOMMIT = 'X' as i don't want to insert the record in 0000 and 0007 if infotype 0008 fails or either of one fails .first i am locking the pernr then using the FM HR_INFOTYPE_OPERATION three times individual for 0000,0007 and 0008 and passing the respective internal tables to the FM and atlast i am writing the COMMIT WORK statement so if all three are success data is saved in their respective tables with the new start date and then unlocking the pernr.
In my selection screen i am entering a start date which is passed to FM BEGDA , Work schedule rule(P0007-schkz) ,Time management status(P0007-zterf),working week(p0007-wweek).Either of the one should have a value . I am getting a problem when i insert a value 0 in time management staus field(p0007-zterf) and this is passed to the internal table which is then passed to FM for upload infotype 0007 . I can see the newly changed value as 0 in the internal table of FM but once program is executed when i check the PA0007 table the field value ZTERF is changed as 1 instead of 0 . I am not getting a clue why it is converting to 1 . I checked with DIALOG_MODE = '2' running in foreground even though i enter 0 value on selection screen for field p0007-ZTERF in the foreground i can see other field values are changed according to the selection date but this field ZTERF is shown as 1 . Please advise me.
Thanks,
Latha.

Hi Madhu ,
here is the code where i am uploading the infotype 0007.
if the workschedule (p0007-schkz) or TMS(p0007-zterf) or working week (p0007-wweek) is blank then it should pick the previous record values for the start date on selection screen.
p_begda = selection screen date
V_endda is 12/31/9999
rp-provide-from-last p0007 space p_begda v_endda.
check pnp-sw-found <> 0 .
refresh it_p0007.
it_p0007 = p0007.
v_wostd = p0007-wostd.
v_empct = p0007-empct.
*check if work schedule rule is not initial
IF NOT p_schkz IS INITIAL AND p_schkz <> it_p0007-schkz.
    it_p0007-schkz = p_schkz.
   ENDIF.
*check if time management status is not initial
IF NOT p_zterf IS INITIAL.
    it_p0007-zterf = p_zterf.
ENDIF.
*check if working week is not initial
IF NOT p_wweek IS INITIAL.
    it_p0007-wweek = p_wweek.
ENDIF.
it_p0007-begda = '00000000'.
it_p0007-endda = '00000000'.
append it_p0007.
Create infotype 0007 record
CLEAR v_return.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
       EXPORTING
            infty         = '0007'
            number        = it_p0007-pernr
            record        = it_p0007
            validitybegin = p_begda
            validityend   = v_endda
            operation     = 'INS'
          dialog_mode   = '0' "Use default
           nocommit      = 'X' "Use default
       IMPORTING
            return        = v_return
            key           = bapipakey_tab.
IF NOT v_return is initial.
    PERFORM std_log_error using 'F01'
                                text-e10
                                it_p0007-pernr
                                v_return-message
                                c_x
                                c_x.
    PERFORM rollback_pernr.
    EXIT.
ENDIF.
COMMIT WORK.

HR_INFOTYPE_OPERATION within Dynamic Action

Hello,
I am calling HR_INFOTYPE_OPERATION from within the Dynamic Action. I can debug through it and even have it display the screens and everything appears to work fine. The return structure is clear of any errors and the key structure indicates that the 'MOD' was done with no problem. The infty is 2012.
However once the dynamic action is complete the 2012 records have not been updated. I am passing blank for the no_commit parameter on the FM.
Does HR_INFOTYPE_OPERATION with a 'MOD' operation work from within the dynamic action?
Regards,
Jeff

Hi Jeff,
I am not sure if I get you right. But as for DB commit, it will be triggered automatically once SUBMIT statement is executed (as work process is released). What I have in my program is as follows:
- in T588Z table (dyn.actions) I have invoked subroutine from my custom program
POPUP_SELECTION_FOR_IT0015((YPLPY_PRO_RE_QUOTAGEN1).
- In this YPLPY_PRO_RE_QUOTAGEN1 program I write subroutine wherein I do some coding and submit another report (which do real update).
form POPUP_SELECTION_FOR_IT0015.
"some coding - in my case I am filling P0015 strcutre (as this infotype has to be udpdated) while dyn. action is triggered for IT2002
    P0015-PERNR = LS_PSKEY-PERNR = P2002-PERNR.
    P0015-SUBTY = LS_PSKEY-SUBTY = P0015-LGART = LGART = IT_RET-FIELDVAL.
    P0015-BEGDA = LS_PSKEY-BEGDA = DATUM.
    P0015-ENDDA = LS_PSKEY-ENDDA = DATUM.
    P0015-UNAME = UNAME.
    P0015-INFTY = LS_PSKEY-INFTY = '0015'.
   "before I am submiting another program I am passing this strcuture
    export P0015 = P0015 PSKEY = LS_PSKEY to memory id 'ZXPADU02_P0015'.
    submit YPLPY_PRO_RE_ZXPADU02_2002
           and return.
- Now the below program creates my IT0015 and the same time changes to IT2002 are written (DB commit is triggered with SUBMIT)
REPORT yplpy_pro_re_zxpadu02_2002.
data: p0015 like p0015.
data: ls_return TYPE bapireturn1,
      ls_pskey like pskey.
IMPORT p0015 = p0015 pskey = ls_pskey FROM MEMORY ID 'ZXPADU02_P0015'.
CALL FUNCTION 'HR_EMPLOYEE_ENQUEUE'
EXPORTING
    number = ls_pskey-pernr.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
    infty                  = ls_pskey-infty
    number                 = ls_pskey-pernr
    subtype                = ls_pskey-subty
    validityend            = ls_pskey-endda
    validitybegin          = ls_pskey-begda
    record                 = p0015
    operation              = 'INS'
    dialog_mode            = '2'
IMPORTING
    return                 = ls_return.
IF NOT ls_return IS INITIAL AND
   ls_return-type EQ 'E'.
MESSAGE e000(38) WITH ls_return-message.
ENDIF.
"unlock the EE
CALL FUNCTION 'HR_EMPLOYEE_DEQUEUE'
EXPORTING
    number = ls_pskey-pernr.
Works fine for me.
Regards
Marcin

HR_INFOTYPE_OPERATION from dynamic action?

hi
plz send me the sample code for calling subroutine (using the above mentioned FM) from dynamic action ..
Regds
Gunjan

It's here a little example.
FUNCTION ZHR_INFOTYPE_OPERATION.
*"*"Lokale Schnittstelle:
*" IMPORTING
*"     VALUE(ZINFTY) LIKE PRELP-INFTY
*"     VALUE(ZNUMBER) LIKE P0001-PERNR
*"     VALUE(ZSUBTYPE) LIKE P0001-SUBTY OPTIONAL
*"     VALUE(ZOBJECTID) LIKE P0001-OBJPS OPTIONAL
*"     VALUE(ZLOCKINDICATOR) LIKE P0001-SPRPS OPTIONAL
*"     VALUE(ZVALIDITYEND) LIKE P0001-ENDDA OPTIONAL
*"     VALUE(ZVALIDITYBEGIN) LIKE P0001-BEGDA OPTIONAL
*"     VALUE(ZRECORDNUMBER) LIKE P0001-SEQNR OPTIONAL
*"     VALUE(ZRECORD)   type p0014 "use the infotype number you need
*"     VALUE(ZOPERATION) LIKE PSPAR-ACTIO
*"     VALUE(ZTCLAS) LIKE PSPAR-TCLAS DEFAULT 'A'
*"     VALUE(ZDIALOG_MODE) TYPE C DEFAULT '0'
*"     VALUE(ZNOCOMMIT) LIKE BAPI_STAND-NO_COMMIT OPTIONAL
*"     VALUE(ZVIEW_IDENTIFIER) LIKE P0003-VIEKN OPTIONAL
*"     VALUE(ZSECONDARY_RECORD) OPTIONAL
*" EXPORTING
*"     VALUE(ZRETURN) LIKE BAPIRETURN1 STRUCTURE BAPIRETURN1
*"     VALUE(ZKEY) LIKE BAPIPAKEY STRUCTURE BAPIPAKEY
CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
    EXPORTING
      number = znumber.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
    EXPORTING
      infty         = zinfty
      number        = zpernr
      subtype       = zsubty
      objectid      = zobjps
      lockindicator = zsprps
      validityend   = zvalidityend
      validitybegin = zvaliditybegin
      recordnumber = zrecordnumber
      record        = zrecord
      dialog_mode   = zdialog_mode
      operation     = zmod
    IMPORTING
      return        = zreturn.
CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
    EXPORTING
      number = znumber..
COMMIT WORK AND WAIT.
endfunction.
bye
enzo

Good old HR_INFOTYPE_OPERATION to DELETE data

Hi,
I am using this FM to delete infotype data from within dynamic actions. The same piece of code works perfectly fine when I execute the program directly in online mode. But when I call the same routine through dynamic actions (even with dialog_mode   = '2' and manually pressing DELETE button on infotype screen), the program keeps processing all records one by one and then ends without giving an error but also without deleting any data. Is this a known problem???
        CALL FUNCTION 'HR_INFOTYPE_OPERATION'
             EXPORTING
                  infty         = '9007'
                  number        = lv_rec-pernr
                  subtype       = lv_rec-subty
                  validityend   = l_pa9007-endda
                  validitybegin = l_pa9007-begda
                  record        = lv_rec
                  operation     = 'DEL'
                  dialog_mode   = '2'
             IMPORTING
                  return        = lv_ret
                  key           = lv_key.
Thanks and regards
NOTE: I am on 4.6C
Message was edited by:
        Shehryar Khan

It didn't work earlier due to the COMMIT WORK conflict.. Pl refer to this <a href="https://forums.sdn.sap.com/click.jspa?searchID=243663&messageID=2551286">Thread</a> on a similar issue..
~Suresh

Problem with 'HR_INFOTYPE_OPERATION'

Good day to everyone. This is my first post and I'm looking forward to get your help.
I'm working on a project and I need to insert a record into infotype.
The problem is when the program reach HR_INFOTYPE_OPERATION the system hangs! and you cannot even close it. Even end session will not work! to kill this session I have to go to sm04 ... etc
can you help me with this!
this is a peace of my code!
        CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
          EXPORTING
            number = p9057-pernr
          IMPORTING
            return = wf_bapireturn1.
      CALL FUNCTION 'HR_INFOTYPE_OPERATION'
         EXPORTING
           infty                  = '9057'
           number                 = wa_pa9057-pernr
           subtype                = wa_pa9057-subty
          objectid               = wa_pa9057-objps
          lockindicator          = wa_pa9057-sprps
           validityend            = wa_pa9057-endda
           validitybegin          = wa_pa9057-begda
          recordnumber           = wa_pa9057-seqnr
           record                 = p9057
           operation              = 'INS'
           tclas                  = 'A'
           dialog_mode            = '0'
           nocommit               = 'X'
         VIEW_IDENTIFIER        =
         SECONDARY_RECORD       =
     IMPORTING
           return                 = wf_bapireturn1.
          key                    = wf_key.
        CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
          EXPORTING
            number = p9057-pernr
          IMPORTING
            return = wf_bapireturn1.

Hi,
Go through this piece of code.
It insert data into 0194 infotype successfully.
See if its of any help.
*&      Form INSERT_0194
*       Inserting the infotype with corresponding records
* --> p1        text
* <-- p2        text
FORM INSERT_0194.
CLEAR WA_0194.
LOOP AT I_0194 INTO WA_0194.
*Necessary FM required to lock an employee before calling FM
*HR_INFOTYPE_OPERATION
    CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'
      EXPORTING
        NUMBER = WA_0194-PERNR
      IMPORTING
        RETURN = WA_RETURN.
    IF WA_RETURN IS NOT INITIAL.
          <Error Checking>
      CONTINUE.
    ELSE.
*Populating the new structure with the old values
      CLEAR WA_0194_NEW.
      WA_0194_NEW-PERNR = WA_0194-PERNR.
      WA_0194_NEW-BEGDA = WA_0194-BEGDA.
      WA_0194_NEW-ENDDA = WA_0194-ENDDA.
      WA_0194_NEW-GCASE = WA_0194-GCASE.
      WA_0194_NEW-GSTAT = WA_0194-GSTAT.
      WA_0194_NEW-RCVDD = WA_0194-RCVDD.
      WA_0194_NEW-RLSDD = WA_0194-RLSDD.
      WA_0194_NEW-GPRIO = WA_0194-GPRIO.
      WA_0194_NEW-ORIGN = WA_0194-ORIGN.
      WA_0194_NEW-GCATE = WA_0194-GCATE.
      WA_0194_NEW-FIPSC = WA_0194-FIPSC.
      WA_0194_NEW-MEDSU = WA_0194-MEDSU.
      WA_0194_NEW-LIFNR = WA_0194-LIFNR.
      WA_0194_NEW-ORCOD = WA_0194-ORCOD.
      WA_0194_NEW-ORNAM = WA_0194-ORNAM.
      WA_0194_NEW-ORSTR = WA_0194-ORSTR.
      WA_0194_NEW-ORORT = WA_0194-ORORT.
      WA_0194_NEW-ORPLZ = WA_0194-ORPLZ.
      WA_0194_NEW-ORREG = WA_0194-ORREG.
      WA_0194_NEW-PLAIN = WA_0194-PLAIN.
      WA_0194_NEW-SCHID = WA_0194-SCHID.
      WA_0194_NEW-RULNR = WA_0194-RULNR.
      WA_0194_NEW-ANSWR = WA_0194-ANSWR.
      WA_0194_NEW-LAPDY = WA_0194-LAPDY.
      WA_0194_NEW-SCRUL = WA_0194-SCRUL.
      WA_0194_NEW-LAPDT = WA_0194-LAPDT.
*Function Module to insert 0194 data
      CALL FUNCTION 'HR_INFOTYPE_OPERATION'
        EXPORTING
          INFTY                  = '0194'
          NUMBER                 = WA_0194-PERNR
*     SUBTYPE                =
*     OBJECTID               =
*     LOCKINDICATOR          =
*     VALIDITYEND            =
*     VALIDITYBEGIN          =
*     RECORDNUMBER           =
          RECORD                 = WA_0194_NEW
          OPERATION              = 'INS'
         TCLAS                  = 'A'
         DIALOG_MODE            = '0'
*     NOCOMMIT               =
*     VIEW_IDENTIFIER        =
*     SECONDARY_RECORD       =
       IMPORTING
         RETURN                 = WA_RETURN_OP
         KEY                    = KEY_INFO
      COMMIT WORK.
*Success Error Summary
      CLEAR WA_ERROR.
      CLEAR WA_SUCCESS.
      IF WA_RETURN_OP IS NOT INITIAL.
          <Error Checking>
      ELSE.
          <Error Checking>
      ENDIF.
*FM to unlock an employee
      CALL FUNCTION 'BAPI_EMPLOYEE_DEQUEUE'
        EXPORTING
          NUMBER = WA_0194-PERNR
        IMPORTING
          RETURN = WA_RETURN.
      IF WA_RETURN-MESSAGE IS NOT INITIAL.
          <Error Checking>
      ENDIF.
ENDLOOP.
ENDFORM.                    " INSERT_0194
And WA_0194_NEW is of type P0194 structure.
Regards.
Edited by: rajan roy on Apr 28, 2009 12:29 PM

HR_INFOTYPE_OPERATION - Commit

Similar Messages

Maybe you are looking for