‎2007 Aug 10 9:06 PM
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.
‎2007 Aug 10 9:52 PM
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
‎2007 Aug 10 9:52 PM
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
‎2007 Aug 11 3:21 PM
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
‎2007 Aug 11 10:23 PM
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
‎2007 Aug 12 4:48 PM
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
‎2007 Aug 14 11:02 PM
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