Skip to Content

Anatomy of Finding an Hitherto Unknown Solution


In thread deactivate ‘APPROVE’   button  in the ALV  in RCATS_APPROVE_ACTIVITIES. it has been asked how to inactivate an ALV toolbar function within a CATS approval transaction. Having done little work on CATS and none on CATS approval I nevertheless was able to provide the specific solution.

In the following sections I describe my strategy how I found this solution based on my experience and combined with some Learning-By-Doing. Perhaps these insights may be useful for others to improve their solution finding strategies as well. 



About three years ago I developed a report for a customer where CATS data needed to be collected, evaluated and aggregated and then used to update cost objects in assessment cycles (transaction KSU2). During this development I became acquainted quite well with class CL_DBSEL_CATS and its BAdI enhancement (see CONSTRUCTOR method):



Following this customer report development I worked for about six months in a localization project for an Add-On of RE-FX (which was one of the best ABAP-OO training I ever had experienced; see Understanding ABAP Objects). In this project I came across an ALV based approval report for rental contracts which I assumed should be somehow similar to the CATS approval report. (see below).

Finally, about half a year ago I answered a question related to BAdI CATS_REPORTING (see Select-options in CATS_DA using BAdI).


The Problem

Below you see the ALV list with the approval toolbar function that should be inactivated (report RCATS_APPROVE_ACTIVITIES).

ALV list for CATS approval

Thus, the problem can be split into two parts:

  • Trivial aspect: Inactivate toolbar function of ALV grid
  • Non-trivial aspect: How to achieve this in the context of CATS approval?



My Suspicion

My first idea was that the non-trivial aspect of this problem might be solved by using BAdI CATS_REPORTING (interface IF_EX_CATS_REPORTING).

The solution for the trivial aspect has been described in detail already many times, e.g.:



The Solution

I created an implementation for BAdI CATS_REPORTING with the implementing class ZCL_IM_US_SDN_CATS_REPORTING. In order to manipulate the ALV toolbar I added the event handler method HANDLE_TOOLBAR which handles event TOOLBAR of CL_GUI_ALV_GRID.



(1) Searching for a Suitable Interface Method
Looking at the interface IF_EX_CATS_REPORTING its method IF_EX_CATS_REPORTING~BEFORE_DISPLAY_APPR immediately caught my attention. Based on its description (Arbeitszeit & Reise Genehmigung vor der Anzeige am Schirm = Working Times & Trip Approval before display on screen) I was convinced having found the right method. The IMPORTING parameter IM_ALV_GRID granted me access to the grid instance used for the approval list.


(2.a) Method Implementation: 1st Try

The first try-out was based on the assumption that I was responsible for both making the toolbar interactive and setting an event handler.

Below you see the first implementation I tried…

…which resulted in a short-dump when I executed the report. Apparently the ALV toolbar instance had not been instantiated yet when I called method SET_TOOLBAR_INTERACTIVE of the grid instance.


 (2.b) Method Implementation: 2nd Try

In a silly attempt I tried to catch the exception which – of course – failed because CL_GUI_ALV_GRID does not raise class-based exceptions at its public interface.

 (I also tried to replace method BEFORE_DISPLAY_APPR with BEFORE_DISPLAY yet the report never stopped at the break-point meaning that this method was not called during report execution.)

Thus, my assumption on which this coding was based on appeared to be wrong and needed to be refined.


 (2.c) Method Implementation: 3rd Try

I modified my assumption that perhaps the standard report would take care of making the toolbar interactive. In this case I would only need to set the event handler method.

Below you see the third implementation I tried… 

…and it worked!

The report execution stopped at the break-point in the event handler method. Looking through the entries in E_OBJECT->MT_TOOLBAR it was obvious that function ‘CX_APPROVE’ was the one that should be deactivated.


A quick look at the data definitions of report RCATS_APPROVE_ACTIVITIES showed that the grid instance was based on class CL_GRID_APPROVAL_ACTEXP which contains the function codes as public constants. The final version of the HANDLE_TOOLBAR implementation is shown below.


 And that is how the final result looks like.



In this weblog I have tried to explain one of the strategies that I apply to find a hitherto unknown solution to a new problem. This scientific approach consists of combining experience with formulating working hypotheses. These hypotheses are tested in a systematic manner.

My first hypothesis that BAdI CATS_REPORTING is involved in the solution proved to be correct whereas the second hypothesis (ALV event handling) required a few cycles of refinement.



The more you know about the domain of the problem the more systematic will be your approach towards the problem. At a certain level of experience this proceeding will lead you almost inevitably to the solution.

You must be Logged on to comment or reply to a post.
  • I also adopt this approach to problem solving, but it’s apparent from the forums (and working in support) that most (or many) don’t.
    We’ve all heard the conversation that goes:
    Customer: “I’ve a problem”
    Customer Support: “What’s the problem”
    C: “Well, I was just typing along, and all of a sudden the words went away.”
    CS: “Went away?”
    C: “They disappeared.”
    CS: “Hmm. So what does your screen look like now?”
    C: “Nothing.”
    CS: “Nothing?”
    C: “It’s blank; it won’t accept anything when I type.”
    CS: “Can you move the cursor around on the screen?”
    C: “There isn’t any cursor, I told you, it won’t accept anything I type.”
    CS: “Does your monitor have a power indicator?”
    C: “What’s a monitor?”
    CS: “It’s the thing with the screen on it that looks like a TV. Does it have a little light that tells you when it’s on?”
    C: “I don’t know.”
    CS: “Well, then look on the back of the monitor and find where the power cord goes into it. Can you see that?”
    C: “Yes, I think so.”
    CS: “Great. Follow the cord to the plug, and tell me if it’s plugged into the wall.”
    C: “…….Yes, it is.”
    CS: “When you were behind the monitor, did you notice that there were two cables plugged into the back of it, not just one?”
    C: “No.”
    CS: “Well, there are. I need you to look back there again and find the other cable.”
    C: “…….Okay, here it is.”
    CS: “Follow it for me, and tell me if it’s plugged securely into the back of your computer.”
    C: “I can’t reach.”
    CS: “Uh huh. Well, can you see if it is?”
    C: “No.”
    CS: “Even if you maybe put your knee on something and lean way over?”
    C: “Oh, it’s not because I don’t have the right angle – it’s because it’s dark.”
    CS: “Dark?”
    C: “Yes – the office light is off, and the only light I have is coming in from the window.”
    CS: “Well, turn on the office light then.”
    C: “I can’t.”
    CS: “No? Why not?”
    C: “Because there’s a power outage.”
    CS: “A power… A power outage? Ah, Okay, we’ve got it licked now. Do you still have the boxes and manuals and packing stuff your computer came in?”
    C: “Well, yes, I keep them in the closet.”
    CS: “Good. Go get them, and unplug your system and pack it up just like it was when you got it. Then take it back to the store you bought it from.”
    C: “Really? Is it that bad?”
    CS: “Yes, I’m afraid it is.”
    C: “Well, all right then, I suppose. What do I tell them?”
    CS: “Tell them you’re too stupid to own a computer.”
    • Hello Thomas

      Thank you for this positive feedback which will – for sure – encourage me to continue with blogging.

      Indeed I have already several ideas in the back of my mind about a tutorial for object-oriented ABAP programming. And I have already a suitable subject for this purpose:

      I have written an extended IDoc Monitor for one of our Lindt subsidiaries which not only displays the business object along with the IDoc (e.g. IDoc 324123 = invoice 90050030) but also shows the GUID of the SAP-XI message together with crucial information of the XI-message payload (e.g. ICN = Interchange Control Number of the EDI INVOIC message). All these useful data are displayed side by side in the ALV list of this extended monitor.

      As soon as the workload on my EDI projects is decreasing I will try to start with this “blogging” project.