I've seen on SCN plenty of question about copying BOM from one plant to other, or from one material to other. Most of them were closed by using LSMW or direct input methods, but there is a really nice way to do it using CEWB function modules. I've been playing with CEWB modules for a long time so I'm not afraid to debug CEWB in case I cannot make it work by myself but when you look on the logic of the sample program to copy BOM then you'll see it's reasonable.
At the beginning let's clear Function Group memory using FM 'CP_CC_S_REFRESH_DATA'. Just for the safety reasons :-)
Then let's load BOM header data to FG memory. If you want to do mass transaction then you would probably want to fill selection table i_cpsc_bom_selwith more than one BOM number, it will be then faster than calling FM 'CP_CC_S_LOAD_COMPLEX_BY_BOM' separately many times.
But header data is not enough, we should do same thing for BOM items using FM 'CP_CC_S_LOAD_COMPLEX_BY_ITM', as Items belongs to different work area in CEWB.
Once we loaded data to memory we can start copying, firstly we need to call 'CP_CC_S_BOM_PROVIDE_BY_MBM' to get source header data and then use its export parameters in FM 'CS_CL_S_MAT_BOM_CREATE_BY_COPY', which is doing copy of a header data.
Once it's done we have to get source items from memory using 'CS_CL_P_ITM_PROVIDE', and then use it for copying items to our target BOM in 'CS_CL_S_ITM_CREATE_BY_COPY'.
At the end, when everything is fine, use FM'CP_CC_S_SAVE' to save your changes and commit your work.
Bellow and in the NUGG attachment you can find sample program which is using this technique for single BOM copy. It does not have error handling or built-in change number usage but you can do it yourself in your programs if this will be necessary.
When you use QM01/QM02/QM03/IQS1/IQS2/IQS3 transactions then you've noticed that when you have some task defined then you cannot directly go to attachments of notification. Following popup always appears:
But there is a way of getting rid of it. We can add new action box action to call directly attachments of notification.
So go to SPRO and find Define Action Box in QM node.
In my article about cl_progress_indicator I've mentioned that sometimes progress showing is more time consuming than the action which is described by it, so you must be careful when using progress indicator in ABAP. I've said also that it's better to cl_progress_indicator instead of FM SAPGUI_PROGRESS_INDICATOR because of built-in function to show progress only once per 10 seconds. But sometimes when using standard SAP FM we can see that progress showing is taking too much time (like SAP_CONVERT_TO_CSV_FORMAT for example), and as we should not do any modification of the system code then we need to use a small trick to get rid of such progress indicators.
If you look into code of SAPGUI_PROGRESS_INDICATOR then you'll notice that showing of progress depends on parameter called SIN :-)
Today I've got a question from Custodio de Oliveira (hope you don't mind mentioning) about Dark Eclipse settings which I'm using. As I know that settings colors in Eclipse for ADT is a pain, then I want to share with you my settings and the steps to achieve the same look like I have on my installation. Of course you can update it by your own, but at least you have a starting point.
Probably this is how your Eclipse looks like, or if not then the default settings for ADT. White and eye-killing.
When you're used to create buttons in ALV Grid dynamically then you think why SAP doesn't allow create dynamically buttons on GUI STATUS. You can change icon or text if you defined that function has dynamic text but you cannot create buttons at runtime and you always have to create GUI STATUS and GUI TITLE in SE41, which personally I don't like, as in most small reports you have to create usually one to five buttons.
So what I want to present to you today is a way to create buttons dynamically at program runtime without a need to create GUI STATUS and GUI TITLE for each program. In fact whole trick is to create firstly a GUI STATUS in empty program which will contain only functions with dynamic texts, and then to fill properly static class attribute.
So let's begin with creating our program to keep GUI STATUS and GUI TITLE. I will call it ZAB_DYNAMIC_GUI_STATUS. In the source code you do not need to put anything beside report keyword.
"! Dummy program for keeping GUI STATUS and TITLE "! Used by ZCA_AB_DYNAMIC_GUI "! Do not delete it!!! report zab_dynamic_gui_status.
Yes, that's all from the code point of view in this program. As said it's only to keep GUI STATUS and GUI TITLE.
Lets create GUI STATUS firstly and call it DYNAMIC_STATUS. Items on application toolbar will have the same naming pattern Fxx, so F01, F02 etc. Each of this function code should have dynamic function text with pattern ZCA_AB_DYNAMIC_GUI=>BUTTONS-Fxx where Fxx you have to replace by current function code.
Additionally to application toolbar, fill also function keys for save, up, back, exit, print... etc so you can also use it in your programs.
Many people still asks how to create field catalog for CL_GUI_ALV_GRID or REUSE_ALV_GRID_DISPLAY on a base of internal table. This is very easy since we have SALV classes, you could see it in my article Create XLSX/MHTML file from internal table in background and probably also somewhere in the net. To make it easier here are ready methods to create LVC and SLIS field catalogs from internal table using CL_SALV_CONTROLLER_METADATA and CL_SALV_TABLE. Both methods are created with new ABAP 7.40 SP05 syntax.
LVC Field catalog definition
class-methods lvc_fcat_from_internal_table importing
it_table type any table returningvalue(rt_fcat) type lvc_t_fcat.
LVC field catalog implementation
method lvc_fcat_from_internal_table. data: table type ref to data. create data table like it_table. assign table->* to field-symbol(<table>). try.
r_salv_table = data(salv_table) changing
t_table = <table> ).
rt_fcat = cl_salv_controller_metadata=>get_lvc_fieldcatalog(
r_columns = salv_table->get_columns( ) " ALV Filter
r_aggregations = salv_table->get_aggregations( ) " ALV Aggregations ). catch cx_root. endtry. endmethod.
I know that many times showing any progress information isn't something that developer likes to have in his program, especially when it's so fast that progress indicator only slows it down horribly, but often we're putting it into code, when program runtime is quite long ( more than 1 minute) and we want to show the users that program is running and we're currently at step m of n. Since I remember I was always using SAPGUI_PROGRESS_INDICATOR FM to display such messages on the screen. When used inside loops I often was manually dividing current tabix by selected variable (for example 1000) and if there was no rest from such division then I was running this FM, just to avoid calling this FM to often. The problem of this FM is that when used in background it hasn't show any info in job log. So if you wanted to have also entries in job log, then additional lines with checks if this is foreground or background mode were needed, and if we were in bg mode then messages instead of progress indicator had to be used.
I was playing a bit with CL_GUI_TIMER some time ago and I thought that this would be good to use it somewhere to have idea how it works. So I've created then a small game Battleships, which you for sure know from analog version.
Game is very simple, firstly you have to build your own map with ships. Just to remind you, there are 2 submarines, 2 destroyers, 1 cruiser, 1 battleship and 1 aircraft carrier. Map is created with CL_GUI_ALV_GRID. Once you click on status button to add one of the ships, map will show you in which place you can start ship. When you'll select position of the start it will show you possible fields for end.
After you build your map hit Join Game button and wait for second player to join you.
If you imported NUGG file from previous article you could be surprised that there is one additional FM available called Z_AB_POPUP_GRID_MULTI_SEL. This FM can be used to call a popup with ALV grid which allows multiple row selects.
1) In order to prepare such popup you'll need to firstly define some global variables in FG which you can find bellow:
constants: c_ccname_grid_popup type scrfname value 'CC_GRID_POPUP'. data: go_popup_custom_cont type ref to cl_gui_custom_container. data: go_popup_grid type ref to cl_gui_alv_grid. data: gs_popup_layout type lvc_s_layo. data: gs_popup_variant type disvariant. data: gt_popup_fcat type lvc_t_fcat. data: g_popup_question type char70. field-symbols: <gt_popup_outtab> type standard table.
2) Then you need to create GUI status with Cancel and Enter Buttons
When using editable ALV mass replace function is needed very often, but when it comes to creating it you have to choose which from the not so perfect possibilities you should use. You can create a screen or selection-screen with all possible fields which can be used in the function (not good when you have a lot of editable fields), you can create dynamic program and submit it (not good as then you switch to the screen of generated) or you can create a FM to call selection-screen in separate task (disadvantage is that user can click on original window and hide your popup). I've used all of these possibilities but when you'd like to reuse them then third one (FM to call dynamic selection-screen in separate task) seems the best.
First of all the question is why do we need separate task to call it? Well, when you call dynamic selection-screen (with parameters like (variable) ) for the first time the output is ok, but the second time you do it in the same runtime of transaction or program then the length, type and F4 help are just like for the field generated for the firs time. This is because the generated selection screen is kept in memory an called each time with same parameters, nevertheless the change of "variable". The way to omit it is to call this selection-screen in new task. This will force SAP to regenerate selection-screen each time.