Question of maintaining EBOM with csap_mat_bom_open.

Question

Hi,
when maintained  EBOM items using FM group :csap_mat_bom_open,CSAP_BOM_ITEM_MAINTAIN
,csap_mat_bom_close, EBOM items were returned from O_STKO exporting csap_mat_bom_open,is differ  with cs02 transaction code, what reason? example,the valid_to of one of items is before valid_from of importing csap_mat_bom_open,but it was returned in O_STKO,however cs02,this item was not displayed.
whether should it be same  that  EBOM items was in o_stko exporting from calling csap_mat_bom_open and displayed with cs02 t_code.
best regards.
vera pang.

Answer 1

Hi Richard,
in fm CSAP_MAT_BOM_OPEN there is a single call of form convert_matnr_to_intern_format:
   perform convert_matnr_to_intern_format using material
                                          changing csin-matnr
                                                   hlp_subrc.
where material is defined in the fm interface:
function csap_mat_bom_open.
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(MATERIAL) LIKE  CSAP_MBOM-MATNR
In the form interface I_MATNR in include LCSAPFC1 is defined identically:
form convert_matnr_to_intern_format
                             using value(i_matnr) like csap_mbom-matnr
                             changing o_matnr like csin-matnr
                                      value(subrc) like sy-subrc.
So importing parameter of type CSAP_MBOM-MATNR is passed to field I_MATNR of type CSAP_MBOM-MATNR and there can't be any type conflict, if
there is no modiffication in your system
fm CSAP_MAT_BOM_OPEN and include LCSAPFC1 are active
no parts of function group CSAP have been overwitten by importing a transport request into your system
Please check this code snippets against those in your system.
What can you do, if all is looking okay:
Check the version history (fm and include) for suspicious transport requests.
If no transport requests found, try to regenerate the fm, th include and the whole function group.
Regards,
Klaus