08-18-2009 10:08 AM
Hi Friends.
Badi ME_PROCESS_PO_CUST is used for standard user exits for transaction ME21N,ME22n and ME23n
I am using the method PROCESS_ITEM to check a condtion on an item level and then update a fieald in the condtion (KWERT) and then i want to update the condtion.
This is the code in method process_item :
data: ls_mepoitem type mepoitem
,ls_condition TYPE komv
,lt_conditions type MMPUR_TKOMV.
ls_mepoitem = im_item->get_data( ).
im_item->get_conditions( IMPORTING EX_CONDITIONS = lt_conditions ).
LOOP AT lt_conditions INTO ls_condition WHERE kschl = 'PB00'.
ls_condition-kwert = '88.8'
MODIFY lt_conditions FROM ls_condition.
ENDIF.
ENDLOOP.
im_item->set_conditions( lt_conditions ).
.
The code compiles and can be executed, but the result is that the standard SAP framework starts in an endless loop and exits after severals loops.
If I remove the im_item->set_conditions statement, then there is no endless loop, so the fault is in the set_conditions method. (Which is a standard method). I also get this error message from the system and there it seems that it is just impossible to update the KWERT field.
Can anyone confirm to me that this is the case or can anyone help me to make this work ( change the KWERT field in conditions when the PO is processing the items). ?
Here is the error messages from the system.
Data from Business Add-In ME_PROCESS_PO_CUST not adopted
Message no. MEPO151
Diagnosis
An endless loop occurred during the processing of the Business Add-In ME_PROCESS_PO_CUST. The system terminated the processing.
Procedure
Contact your system administrator.
Procedure for System Administration
Check whether standard fields are changed in the implementation of the Business Add-In ME_PROCESS_PO_CUST.
Changes to standard fields that are part of the Include structure MEPOITEM_TECH and/or MEPOSCHEDULE_TECH are generally not allowed. In addition, no field values that are not changeable through the field settings in the Enjoy transactions can be changed in the BAdI. Correct the implementation accordingly.
08-18-2009 10:27 AM
Hi
Answer is pure assumption
Pls refer to OSS note
Note 803749 - ME_PROCESS_PO_CUST Business Add-In: Endless loop
Pls take opinion from Basis / SAP, before implementing the OSS note
Regards
Madhan D
08-18-2009 10:37 AM
HI ,
It goes to an endless loop because of infinite line item u have to just two lines it may solve ur problem
DATA: lv_bnfpoTYPE banfpo.
IMPORT lv_bnfpo TO lv_bnfpo FROM MEMORY ID 'ZHDR'.
**>If the line item changes (track line item changes)
IF lv_bnfpo <> lv_items-bnfpo
your code of set conditions.
FREE MEMORY ID 'ZHDR'.
lv_bnfpo = lv_items-bnfpo. "lv_items is a table which is populating from get_data method
EXPORT lv_bnfpo FROM lv_bnfpo TO MEMORY ID 'ZHDR'.
endif.
Thanks ,
Ruchi
11-27-2009 6:58 AM
Hello,
I'm getting the same error and also want to use the set_conditions. Do you have a solution yet? Could you share with me. Thanks.
Sanny
10-16-2012 8:06 AM
Hello ,
Use following code
DATA: LV_PO_HEAD_REF type ref to IF_PURCHASE_ORDER_MM,
CL_PO type ref to CL_PO_HEADER_HANDLE_MM.
LV_PO_HEAD_REF = IM_ITEM->GET_HEADER( ).
* Initialize header check
CL_PO ?= LV_PO_HEAD_REF.
if not CL_PO->MY_RECHECK_QUEUE is initial.
clear CL_PO->MY_RECHECK_QUEUE.
endif.
05-07-2014 5:24 AM
Dear Experts,
I have also same problem @ ME_PROCESS_PO_CUST~Check method want to PO Account information like Sales Order No and Its line Item No. which available @ ME_PROCESS_PO_CUST~Account Process.
How can we get the Sales Order and its line item information (Account Assessment) @ Check method.
Please suggest me also.
Regards,
Kamal Rathore
05-09-2014 5:13 AM
Dear Experts,
I have done the above mentioned problem by following logic.
I have declare the work area @ class level (Public) and fill this work area at Process Account Method and use this area work area @ Check Method.
Please guid to me ,Is it ok or Not.
Regards,
Kamal Rathore
12-18-2015 3:54 PM
Add following code at the end of the method. Originally referenced from ABAPblog.com - Endless loop in BADI ME_PROCESS_PO_CUST
DATA: f_item TYPE REF TO if_purchase_order_item_mm.
FIELD-SYMBOLS: <ekko> TYPE ekko.
DATA: f_mepoitem TYPE mepoitem.
DATA: fo_header TYPE REF TO if_purchase_order_mm.
DATA: f_checkheader TYPE mepoheader.
DATA: f_checkheader_curr TYPE mepoheader.
DATA: f_ekkotxt TYPE string.
DATA: BEGIN OF fs_condcheck,
set TYPE c,
ebelp TYPE ekpo-ebelp,
END OF fs_condcheck.
DATA: ft_condcheck LIKE STANDARD TABLE OF fs_condcheck.
CHECK f_item IS NOT INITIAL.
f_mepoitem = f_item->get_data( ).
f_ekkotxt = '(SAPLMEPO)EKKO'. "we'll use ekko from me21n
ASSIGN (f_ekkotxt) TO <ekko>. "do not do changes on that FS !!!
IF sy-subrc EQ 0.
"we only do changes for new purchase order and requisitioner 'TESTONE'
"of course you should put your own codding here
IF <ekko>-ebeln+0(2) NE '45' AND f_mepoitem-afnam EQ 'TESTONE'.
"we're importing data from memory
IMPORT ft_condcheck = ft_condcheck
f_checkheader = f_checkheader
FROM MEMORY ID 'CONDADJUST'.
"get header object
fo_header = f_item->get_header( ).
fo_header = f_item->get_header( ).
"get current header data
f_checkheader_curr = fo_header->get_data( ).
"compare current header with the one from memmory
IF f_checkheader_curr <> f_checkheader.
"if different then we've got new PO
REFRESH ft_condcheck[].
f_checkheader = f_checkheader_curr.
"clear cond wa and set ebelp
CLEAR fs_condcheck.
fs_condcheck-ebelp = f_mepoitem-ebelp.
ELSE.
"we're in same PO like befor so let's check if we already have
"data for current position in our check table
READ TABLE ft_condcheck WITH KEY ebelp = f_mepoitem-ebelp INTO fs_condcheck.
IF sy-subrc NE 0.
"if not then we clear check wa and set ebelp
CLEAR fs_condcheck.
fs_condcheck-ebelp = f_mepoitem-ebelp.
ENDIF.
ENDIF.
"if the condition was set before then we do nothing
IF fs_condcheck-set IS INITIAL.
DATA: ft_conditions TYPE mmpur_tkomv.
DATA: f_cond_changed TYPE c.
FIELD-SYMBOLS: <komv> TYPE komv.
"clear cond change flag
CLEAR f_cond_changed.
"get condition for item
f_item->get_conditions( IMPORTING ex_conditions = ft_conditions[] ).
"our manipulation of conditions (do your coding here)
LOOP AT ft_conditions ASSIGNING <komv>.
IF <komv>-kschl NE 'PB00' AND
<komv>-kschl NE 'PBXX' AND
<komv>-kbetr IS NOT INITIAL.
CLEAR <komv>-kbetr.
<komv>-kmprs = 'X'.
"set that we've done change
f_cond_changed = 'X'.
ENDIF.
ENDLOOP.
"check if we changed something
IF f_cond_changed IS NOT INITIAL.
"if yes then we set conditions
f_item->set_conditions( EXPORTING im_conditions = ft_conditions[] ).
"fill check data and set that for this ebelp the conditions were
"already saved
fs_condcheck-set = 'X'.
"export data to memory so we can read it in the next call of process_item
APPEND fs_condcheck TO ft_condcheck[].
EXPORT ft_condcheck = ft_condcheck
f_checkheader = f_checkheader
TO MEMORY ID 'CONDADJUST'.
ENDIF.
ELSE.
DATA: fo_order TYPE REF TO cl_po_header_handle_mm.
DATA: fo_model TYPE REF TO if_model_mm.
"cast header
fo_order ?= fo_header.
"cast item to model
fo_model ?= f_item.
"check if item is still in the queue to check again
READ TABLE fo_order->my_recheck_queue WITH KEY model = fo_model TRANSPORTING NO FIELDS.
IF sy-subrc NE 0.
"if not then we can delete entries from table to be able to run check
"in the next change of item
DELETE ft_condcheck WHERE ebelp = f_mepoitem-ebelp.
"export data to memory without line that was changed already
EXPORT ft_condcheck = ft_condcheck
f_checkheader = f_checkheader
TO MEMORY ID 'CONDADJUST'.
ENDIF.
ENDIF.
ENDIF.
ENDIF.