To continue previous two posts about re-exploding and deleting subcontracting BOM of purchase requisition item, let me describe you how to do the same thing with subcontracting BOM of purchase order line.
The main part is again to use FM ME_COMPONENTS_MAINTAIN and ME_COMPONENTS_UPDATE_PREPARE , but this time there is no easy way to fill MDPA and MDLB structures which are needed here.
So I had to use CL_PO_HEADER_HANDLE_MM and IF_PURCHASE_ORDER_MM to fetch all data from purchase order and to move them to MDPA and MDLB structures. Once it was ready the rest was peanuts and I could get rid of using this two buttons :-)
In previous post I've shown how to re-explode subcontracting components of purchase requisition using FM ME_COMPONENTS_MAINTAIN and ME_COMPONENTS_UPDATE_PREPARE . Using very similar code you can delete completly it's BOM.
You may wonder why would need to delete subcontracting BOM? This is not possible in standard transaction ME52N and in most cases it makes no sense to have the subcontracting item without BOM. But in the case that you don't want that components are taken into consideration by MRP until you really need this then it could be helpful.
The code is 99% same like during the re-exploding the BOM, the difference is that FM ME_COMPONENTS_MAINTAIN is called with parameter i_vorga = 'D' and message check at the end is bit different.
I faced lately a small issue in one of the process in our company, I needed to re-explode the BOM of subcontracting item in purchase requisition. Normally users goes to ME52N and press "Explode BOM" button, but I needed to do this from ABAP side.
I started with IF_PURCHASE_REQUISITION but although there is a method "explode_bom" for item, then it was calling the screen with the results instead of selecting and updating components in the database. IF_BOM_MM didn't helped as well.
I started to dig in the standard transactions and local classes of ME52N and finally I have figure out how to do this in backgroud. The solution was to run FM ME_COMPONENTS_MAINTAIN and ME_COMPONENTS_UPDATE_PREPARE in correct way together with message handler to not interrupt whole process.
If you follow my blog, then you probably noticed that I'm not keen of SALV class, as it's not editable and you cannot handle all events that you can in cl_gui_alv_grid class. With a small trick you can make your SALV editable and you can handle all the events you want from underlying cl_gui_alv_grid object.
What you need to do, is to set handler for event after_refresh for all instances of cl_gui_alv_grid and to force refreshing of SALV just after creation of the object. Then inside the handler for after_refresh event you can set up handlers for other events just for current instance and you can modify layout or field catalog settings to make it editable.
Please be aware that accessing private or protected data may have unpredictible consequences! Use it at your own risk.
From time to time, it happens that you want to access private data or methods from CL_GUI_ALV_GRID, which is normally not possible.
When you look into the class definition you'll notice that there is only one global friend - interface IF_ALV_RM_GRID_FRIEND which has no attributes or methods declared. Quite strange, isn't it?
When you'll search were this interface is used then you'll notice that it's helping to get access to private grid data. So why not to use it the same way?
Everybody sends mails from SAP, some are still using old FM SO_NEW_DOCUMENT_ATT_SEND_API1 but some CL_BCS class. This class is really powerful but it has one disadvantage - it does commit work, and not only when sending emails but also during adding of attachments. In this case it's really not safe to use this class in BADIs or User-Exits, but there is one replacement for CL_BCS -> CL_BCS_MESSAGE. This class only collects the data, and when send method is run then calling a FM SBCS_SEND with destination NONE, or SBCS_SEND_UPDATE in update task, depending what attributes are passed to the class. It means you can use it also in BADIs or User-Exits where commits are not welcomed.
I was lately trying to find an HTML WYSIWYG editor for ABAP, but I failed. I though or this was not needed so far, or the solution was not posted anywhere. So I've tried several times and thanks to NICEdit and this tread on SCN I found the way to make HTML WYSIWYG editor for ABAP.
My editor use CL_GUI_HTML_VIEWER to display NICEdit in container, and then thanks to POST method I put changes back to SAP. ZCL_HTML_EDITOR class, which is attached to this post, raises an event whenever someone click on save button in the editor, so you can easily handle it and then use new HTML for your purposes. Video bellow shows the demo of usage.
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 :-)