Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

ECM BADI Problem

0 Likes
904

Can anyone supply some custom code that they use in the HRECM00_ACTIVATION-ACTIVATE_PROCESS method to update infotypes? I've been getting the following errors when trying to create an infotype 0000 record in the badi:

The exception 'CX_HRPA_VIOLATED_PRECONDITION' was raised but was not caught at any stage in the call hierarchy.

1 ACCEPTED SOLUTION
Read only

uwe_schieferstein
Active Contributor
0 Likes
791

Hello Steve

Since you did not show the coding of the class implementing the BAdI interface I cannot tell you the exact error cause.

However, the exception class CX_HRPA_VIOLATED_PRECONDITION is used (on our ECC 5.0 IDES system) in two classes only:

- CL_HRPA_INFTY_NNNN (method ASSERT_CORRECT_INFTY)

- CL_HRPA_RETROCALC (=> most likely not relevant)

Looking at the coding of method ASSERT_CORRECT_INFTY ...

METHOD assert_correct_infty.

  IF container->a_tclas       <> a_tclas OR
     container->a_pskey-infty <> a_infty.

    RAISE EXCEPTION TYPE cx_hrpa_violated_precondition.
  ENDIF.
ENDMETHOD.                    "assert_correct_infty

... I assume that the exception is raised here.

This method is called in method IF_HRPA_INFTY_BL~INSERT ...

METHOD if_hrpa_infty_bl~insert.

  FIELD-SYMBOLS <pnnnn>  TYPE ANY.
  FIELD-SYMBOLS <pshdr>  TYPE pshdr.
  FIELD-SYMBOLS <pnnnn2> TYPE ANY.
  FIELD-SYMBOLS <pshdr2> TYPE pshdr.

  DATA infotype_container TYPE REF TO if_hrpa_infotype_container.

  DATA pnnnn_ref    TYPE REF TO data.
  DATA pnnnn2_ref   TYPE REF TO data.
  DATA pref         TYPE pref.
  DATA aux_data_ref TYPE REF TO data.

  DATA has_secondary_infty TYPE boole_d.
  DATA secondary_infty     TYPE infty.
  DATA has_error           TYPE boole_d.


* Ensure that the framework did not mess up infty
  CALL METHOD assert_correct_infty
    EXPORTING
      container = container.
...

ENDMETHOD.

... where the exception class is defined in the method interface. Thus, the exception is propagated to the caller of this method.

Searching the <i>Where-Used-list</i> for method IF_HRPA_INFTY_BL~INSERT I can find only class CL_HRPA_INFOTYPE_0008.

Looking at the coding of method IF_HRPA_INFTY_BL~INSERT (in class CL_HRPA_INFOTYPE_0008) you will see the following coding:

***-----------------***
* standard processing *
***-----------------***
 CALL METHOD SUPER->IF_HRPA_INFTY_BL~INSERT
   EXPORTING
     UPDATE_MODE                = UPDATE_MODE
     MASSN                      = MASSN
     MASSG                      = MASSG
     NO_AUTH_CHECK              = NO_AUTH_CHECK
     MESSAGE_HANDLER            = MESSAGE_HANDLER
   IMPORTING
     IS_OK                      = IS_OK
   CHANGING
     CONTAINER                  = CONTAINER
     .

Thus, I assume that in your BAdI implementing class you call method IF_HRPA_INFTY_BL~INSERT of class CL_HRPA_INFOTYPE_NNNN (= superclass of CL_HRPA_INFOTYPE_0008).

If you surround this method call by a TRY-ENDTRY block then you should not get the dump but catch the exception:

TRY.
  CALL METHOD go_infty_nnnn->IF_HRPA_INFTY_BL~INSERT( ...).

CATCH cx_hrpa_violated_precondition INTO lo_error.
" ... send error message
ENDTRY.

<b>Conclusion</b>: It looks like that using method go_infty_nnnn->IF_HRPA_INFTY_BL~INSERT you can only create infotype 0008.

Regards

Uwe

5 REPLIES 5
Read only

uwe_schieferstein
Active Contributor
0 Likes
792

Hello Steve

Since you did not show the coding of the class implementing the BAdI interface I cannot tell you the exact error cause.

However, the exception class CX_HRPA_VIOLATED_PRECONDITION is used (on our ECC 5.0 IDES system) in two classes only:

- CL_HRPA_INFTY_NNNN (method ASSERT_CORRECT_INFTY)

- CL_HRPA_RETROCALC (=> most likely not relevant)

Looking at the coding of method ASSERT_CORRECT_INFTY ...

METHOD assert_correct_infty.

  IF container->a_tclas       <> a_tclas OR
     container->a_pskey-infty <> a_infty.

    RAISE EXCEPTION TYPE cx_hrpa_violated_precondition.
  ENDIF.
ENDMETHOD.                    "assert_correct_infty

... I assume that the exception is raised here.

This method is called in method IF_HRPA_INFTY_BL~INSERT ...

METHOD if_hrpa_infty_bl~insert.

  FIELD-SYMBOLS <pnnnn>  TYPE ANY.
  FIELD-SYMBOLS <pshdr>  TYPE pshdr.
  FIELD-SYMBOLS <pnnnn2> TYPE ANY.
  FIELD-SYMBOLS <pshdr2> TYPE pshdr.

  DATA infotype_container TYPE REF TO if_hrpa_infotype_container.

  DATA pnnnn_ref    TYPE REF TO data.
  DATA pnnnn2_ref   TYPE REF TO data.
  DATA pref         TYPE pref.
  DATA aux_data_ref TYPE REF TO data.

  DATA has_secondary_infty TYPE boole_d.
  DATA secondary_infty     TYPE infty.
  DATA has_error           TYPE boole_d.


* Ensure that the framework did not mess up infty
  CALL METHOD assert_correct_infty
    EXPORTING
      container = container.
...

ENDMETHOD.

... where the exception class is defined in the method interface. Thus, the exception is propagated to the caller of this method.

Searching the <i>Where-Used-list</i> for method IF_HRPA_INFTY_BL~INSERT I can find only class CL_HRPA_INFOTYPE_0008.

Looking at the coding of method IF_HRPA_INFTY_BL~INSERT (in class CL_HRPA_INFOTYPE_0008) you will see the following coding:

***-----------------***
* standard processing *
***-----------------***
 CALL METHOD SUPER->IF_HRPA_INFTY_BL~INSERT
   EXPORTING
     UPDATE_MODE                = UPDATE_MODE
     MASSN                      = MASSN
     MASSG                      = MASSG
     NO_AUTH_CHECK              = NO_AUTH_CHECK
     MESSAGE_HANDLER            = MESSAGE_HANDLER
   IMPORTING
     IS_OK                      = IS_OK
   CHANGING
     CONTAINER                  = CONTAINER
     .

Thus, I assume that in your BAdI implementing class you call method IF_HRPA_INFTY_BL~INSERT of class CL_HRPA_INFOTYPE_NNNN (= superclass of CL_HRPA_INFOTYPE_0008).

If you surround this method call by a TRY-ENDTRY block then you should not get the dump but catch the exception:

TRY.
  CALL METHOD go_infty_nnnn->IF_HRPA_INFTY_BL~INSERT( ...).

CATCH cx_hrpa_violated_precondition INTO lo_error.
" ... send error message
ENDTRY.

<b>Conclusion</b>: It looks like that using method go_infty_nnnn->IF_HRPA_INFTY_BL~INSERT you can only create infotype 0008.

Regards

Uwe

Read only

0 Likes
791

Hello UWE,

Here is the code in my ACTIVATE_PROCESS method. There is no error checking yet as I was just beginning with an attempt to create a new infotype 0000 Action record and was getting those exceptions. Any help would be appreciated.

method if_ex_hrecm00_activation~activate_process .

constants:

c_abkrs_u1 type abkrs value 'U1',

c_abkrs_u2 type abkrs value 'U2',

c_abkrs_u3 type abkrs value 'U3',

c_abkrs_u4 type abkrs value 'U4',

c_massn_z4 type massn value 'Z4', "Change in Pay

c_massg_10 type massg value '10', "Merit/Equity

c_endda_1231 type datum value '99991231',

c_actio_ins type actio value 'INS', "Create

c_citem_us(2) type c value 'US',

c_citem_uq(2) type c value 'UQ',

c_infotype_0000(4) type c value '0000',

c_is_ok type boole_d value 'X',

c_is_not_ok type boole_d value ' '.

data: p0000 type standard table of p0000.

data:

w_rec_it0000 type p0000,

w_rec_it0001 type p0001, "Infotype 0001 (Org. Assignment)

w_rec_t549a type t549a, "Payroll areas

w_rec_t549q type t549q, "Payroll Periods

w_is_ok type boole_d,

w_return type bapireturn1,

w_infty_key type bapipakey,

w_message_handler type ref to cl_hrpa_message_list.

  • set is_ok export parameter to true to start with

is_ok = c_is_ok.

      • For each IT0759 record with a value of USnn or UQnn (where 'nn' =

      • last two digits of the current plan year) in field IT0759-CITEM

if p0759-citem(2) eq c_citem_us or

p0759-citem(2) eq c_citem_uq.

      • Look up the employees current Payroll Area from IT0001-ABKRS

call function 'HR_ECM_GET_IT0001'

exporting

pernr = p0759-pernr

key_date = sy-datum

message_handler = message_handler

importing

p0001 = w_rec_it0001

is_ok = w_is_ok.

      • If the payroll area is equal to U1, U2, U3 or U4 then:

if ( w_rec_it0001-abkrs eq c_abkrs_u1 or

w_rec_it0001-abkrs eq c_abkrs_u2 or

w_rec_it0001-abkrs eq c_abkrs_u3 or

w_rec_it0001-abkrs eq c_abkrs_u4 ).

      • Use the payroll area to look up the Period Parameter from V_T549A field PERMO

clear w_rec_t549a.

select single permo from t549a

into w_rec_t549a-permo

where abkrs eq w_rec_it0001-abkrs.

      • Select the Payroll Period whose start date (BEGDA) is immediately

      • after the effective date on IT0759-EFFDT

clear w_rec_t549q.

select single * from t549q

into w_rec_t549q

where permo eq w_rec_t549a-permo

and pabrj eq p0759-begda(4)

and begda ge p0759-begda.

CALL FUNCTION 'HR_READ_INFOTYPE'

EXPORTING

pernr = p0759-pernr

infty = c_infotype_0000

endda = c_endda_1231

TABLES

infty_tab = p0000

EXCEPTIONS

infty_not_found = 1

OTHERS = 2.

  • sort descending to put the latest record first

sort p0000 descending.

  • read the first record into the IT0000 record structure

read table p0000 into w_rec_it0000 index 1.

      • Initial Field - the system will populate

clear: w_rec_it0000-aedtm,

w_rec_it0000-uname.

w_rec_it0000-begda = w_rec_t549q-begda.

w_rec_it0000-massn = c_massn_z4.

w_rec_it0000-massg = c_massg_10.

      • This will lock employee for update

CALL FUNCTION 'BAPI_EMPLOYEE_ENQUEUE'

EXPORTING

number = p0759-pernr

IMPORTING

return = w_return.

call function 'HR_INFOTYPE_OPERATION'

exporting

infty = c_infotype_0000

number = p0759-pernr

validityend = c_endda_1231

validitybegin = w_rec_t549q-begda

record = w_rec_it0000

operation = c_actio_ins

importing

return = w_return

key = w_infty_key.

      • This will unlock employee record

call function 'BAPI_EMPLOYEE_DEQUEUE'

exporting

number = p0759-pernr

importing

return = w_return.

endif.

endif.

endmethod.

Steve

Read only

0 Likes
791

Hello Steve

I do not have a straightforward solution at hand. Yet I assume that the error occurs within function module <b>HR_INFOTYPE_OPERATION</b>. In order to get closer to the problem I would recommend to call this function module with <b>DIALOG_MODE = '1'.</b> This enables display of the screens while creating the infotype.

Regards

Uwe

Read only

0 Likes
791

Hi Again UWE,

Thank you for all your help. I tried your advice by setting the Dialog_Mode parameter and it did show me the infotype 0000 screen and the screen looked good. However it abended shortly after clicking save. In research I have found that the problem potentially lies with the maintenance of a tabled called T77S0. I have emailed our ECM consultant asking him if he knows anything about this table and will wait to hear back from him. Thanks again for all your help. I'll let you know how things go.

Steve

Read only

0 Likes
791

Hi UWE,

If I place my code in a separate program and call that program from the BADI then I am able to successfully create infotype records. I was unable to create infotype records from within the BADI using HR_INFOTYPE_OPERATION. Thanks for your time on this.

Steve