Knowledge Management

Question:
Hi...
I've developed a custom infotype,say 9000 which has a table control on the single screen(2000). but when i save after entering the data the program goes into an infinite PBO-PAI loop....I've coded my own update process using the standard Function module "HR_INFOTYPE_OPERATION"..please note that my infotype can be considered similar to the "absence quotas infotype 2006"...and my update process is also similar to the one that can be seen in 2006...
If anybody can advice a solution...I'd be most greatful...
Thanks in advance
Regards
Shankar
Answer:
You should not use HR_INFOTYPE_OPERATION inside IT dialog, as it calls the same dialog module and this leads to infinite recursion. All you need to do is to fill all the neccessary fields of your Pnnnn (say P9000) structure properly before calling module POST_INPUT_CHECKS in the screen PAI.
_________________
Best regards, Sergey Korolev
Answer:
Hi Sergei...
Thanks a lot for the reply....In any normal infotype development the update is taken care by the post_input_checks module called in the PAI as you'd pointed out very correctly..
in the normal scenario the data from the screen fields goes into the PSnnnn and the pnnnn structures first and then into the PA/PB table...so the post_input_check module itself can handle the update...
but in the case of my infotype 9000 there are multiple records for the same set of fields as i'm having a table-control on the single screen....(let's assume that the user populates 10 lines of the table.....these 10 lines together with the infotype key fields has to go to the table Pa9000....)
So I cannot update the PAnnnn table directly from the Pnnnn structure as I'm using another internal table for storing multiple records....
That's the reason why I'd opted for a seperate update using HR_INFOTYPE_OPERATION....is there a more convenient way of updating multiple records into an infotype?????
Kindly advice a suitable solution.....
Thanks in advance
With best Regards
Shankar
Answer:
Hi Sergi...
I'm also posting my PBO & PAI code for your reference. Please go through the same as you'll get a much better picture of what I'm trying to accomplish....
******************************************************
PROCESS BEFORE OUTPUT.
***********************
***---Standard Module
MODULE before_output.
***---For "describing" the table control internal table
MODULE desc_tcntrl.
CALL SUBSCREEN subscreen_empl INCLUDING empl_prog empl_dynnr.
CALL SUBSCREEN subscreen_header INCLUDING header_prog header_dynnr.
LOOP AT it_9005 WITH CONTROL tc_9005 CURSOR tc_9005-current_line.
***---For setting the table control attributes
MODULE init_tc9005.
***---data transfers + modifications....
MODULE modify_tc_9005.
ENDLOOP.
PROCESS AFTER INPUT.
********************
***---at exit command....not working?????
MODULE exit AT EXIT-COMMAND.
* MODULE pre_input_checks.
LOOP.
CHAIN.
FIELD: p9005-regno, p9005-passdat,
p9005-tdetail.
***---data fetching
MODULE get_data_tc_9005.
***---cursor controls....
MODULE get_cursor.
***---user actions!!!----update problems here!!!
MODULE user_cmd_2200.
ENDCHAIN.
ENDLOOP.
**************************************************
MODULE user_cmd_2200 INPUT.
CLEAR ok_code.
ok_code = sy-ucomm.
CASE ok_code.
WHEN 'UPD'.
BREAK-POINT.
PERFORM update_data TABLES it_9005
USING pspar-pernr
pspar-infty
pspar-tclas.
BREAK-POINT.
PERFORM end_of_screen.
ENDCASE.
ENDMODULE. " user_cmd_2200 INPUT
******************************************************
FORM update_data TABLES p_it_9005 STRUCTURE it_9005
USING p_pspar_pernr
p_pspar_infty
p_pspar_tclas.
DATA: update_record LIKE prelp OCCURS 0 WITH HEADER LINE,
message_buffer LIKE bapireturn1,
prelkey LIKE bapipakey.
DATA: save_pspar_askey LIKE pspar-askey.
* IF sy-uname = 'PRASANTH'.
* BREAK-POINT.
* ENDIF.
**----§Filling the update table and the update buffer....
LOOP AT it_9005.
MOVE it_9005-regno TO it_updatetab-regno.
MOVE it_9005-passdat TO it_updatetab-passdat.
MOVE it_9005-tdetail TO it_updatetab-tdetail.
MOVE-CORRESPONDING p9005 TO it_updatetab.
APPEND it_updatetab.
ENDLOOP.
CALL METHOD cl_pt_container_util=>move_table_to_table
EXPORTING
im_tab = it_updatetab[]
IMPORTING
ex_tab = update_record[].
LOOP AT update_record.
CALL FUNCTION 'HR_INFOTYPE_OPERATION'
EXPORTING
infty = p9005-infty
number = p9005-pernr
subtype = update_record-subty
lockindicator = update_record-sprps
validityend = update_record-endda
validitybegin = update_record-begda
record = update_record
operation = 'INS'
tclas = 'A'
dialog_mode = '1' "screen on error
nocommit = 'X' "one commit for all records
IMPORTING
return = message_buffer
key = prelkey.
IF sy-subrc <> 0 OR
NOT message_buffer IS INITIAL.
MESSAGE ID message_buffer-id
TYPE message_buffer-type
NUMBER message_buffer-number
WITH message_buffer-message_v1
message_buffer-message_v2
message_buffer-message_v3
message_buffer-message_v4.
ENDIF.
ENDLOOP.
* check whether within a measure (update at the and of the inft. group)
IF pspar-massn IS INITIAL.
PERFORM put_infotyp_buffer(sapfp50p).
ENDIF.
* set switch for leave screen
psyst-inpst = input_stored.
* clear suppress dialog flag after BAPI Call
CLEAR pspar-supdg.
pspar-askey = save_pspar_askey. " note 497219
ENDFORM. " update_data
**********************************************************
MODULE exit INPUT.
PERFORM exit(sapfp50m).
ENDMODULE.
**********************************************************
My requirement is that the internal table data that gets populated from the table control needs to be updated into the PAnnnn table with the respective key fields for the employee....the standard module POST_INPUT_CHECKS will not serve the purpose as I'm having multiple records for a set of PSnnnn fields....
as u rightly pointed out the FM HR_INFOTYPE_OPERATION uses the infotype's dialog module for the infotype updation...so it can be infered that I get an infinite loop as i'm calling the FM in the PAI....then is there a way to exit and return to the statemtnt after the function call in the main program after the execution of the dialog module??? or is there a better way to handle the updates in these kind os scenarios....
Kindly advice
with the very best regards...
PI
Answer:
Hi Shankar,
I don't remember exactly if there are table infotypes in PA (as in OM), in that case it would be an option. Another option is to emulate several records via repetitive field group just like in 0008 infotype (main payments), thoudh the solution is sufficient only for small number of records - it depends on maximal length of infotype record buffer.
As you know there are special aided ABAP construct to manipulate repetitive field groups (DO ... VARYING, WHILE ... VARY...).
If you still intend to create several infotype records you definetely cannot do it via HR_INFOTYPE_OPERATION as I mentioned in my previous post, and the only option is writing directly into internal infotype buffer. There are some subroutines in SAPFP50P subroutine pool: INSERT_INFOTYP, DELETE_INFOTYP, MODIFY_INFOTYP. Note that they all are internal undocumented subroutines and you can use it at your own risk only. Also note that even after successfull database update the system will treat all those records like separate infotype records and would not display then in a single bunch.
Hope this helps somehow.
_________________
Best regards, Sergey Korolev
Answer:
Hi Sergi...
Thanks for the advice...I'd explore the possibilities of using repetitive structures or the subroutines in sapfp50p....but in the meanwhile I'd like to point out that the infotype 2006 - Absence Quotas uses a seperate call to the FM HR_INFOTYPE_OPERATION and this seemed the easiest option available to me when developing the infotype..can you please suggest some pinters in this regard(2006) ????
Thanks for the advice
With Best Regards
Shankar
Answer:
Hi Sergi..
One more thing that I forgot to mention in my previous post is that the basic pay infotype uses seperate fields for storing the multiple values...for eg. the wage type lgart goes into lga01,lga02....etc....I've already tried updating my infotype in a similar fashion and it works...post_input_checks itself is enough for the matter....but I'm a bit reluctant to use multiple fields for the same entity as I'd worked extensively in other SAP modules where a mass database update is more flexible.Hence I was trying for other options to update multiple values for one internal table itself...I guess I don't have much options now as you'd explained all the possibilities.....
Thanks a lot for the timely advice...
With the very best regards
Shankar