I recently had a client who was having issues during the execution of one of the custom reports their employees regularly ran. The custom report was designed to allow them to update a number of different positions quickly by using a simple load file. The process, however, was still taking a long time to complete because the employees were being prompted to update infotype 19 (Monitoring of Tasks) several times during execution. The client asked me if I could modify the report so that these screens would no longer be displayed.
Upon debugging the report, I found that the screens were actually being generated by a dynamic action associated with one of the infotypes the report updated. I relayed my findings to the client, who posed the following question:
“Is there any way to bypass the dynamic action when this report is executed?”
I had never encountered a situation like this one. So, I informed the client that I would need to do some research to find a solution. I turned to my usual well of SAP knowledge—a combination of SCN (SAP Community Network) and Google. To my surprise, though, it seemed no one else had posed this question or faced this issue before. A number of days passed, and I realized if I wanted to provide a solution to the client I was going to have to put on my problem solver hat and figure it out for them.
There is no inbuilt way to pass information back and forth between reports and dynamic actions, so I had to find a way for the two to communicate, and perform differently, depending on those communications. This reminded me of a time in which I had to export data from a user exit to a memory location so that it could be retrieved and used separately in an email program that was called in that user exit. I wondered if I could use a similar tactic for this problem.
I began looking at the KENNZ (see figure 1) field of the dynamic actions table (V_T588Z) which determines what type of action should be taken at each step in a dynamic action. There are six different type of action indicators available.
- P – Check Condition
- I – Maintain infotype record
- W – Set default values when creating a new record
- V – Reference to another step
- F – Call Routine
- M – Send mail
I realized that in order to enable this dynamic action to be bypassed during the execution of the report, but behave normally otherwise, I was going to have to add 3 of the 6 step indicators while rewriting the action. I would need to set a flag to a memory location before the infotype update occurred in the report, then I would need the dynamic action to use F (call routine) to retrieve the flag from the memory location, then in the next step the dynamic action would need to P (check condition) to determine if the flag was set or not, then V reference step P to determine if it should continue processing the dynamic action or cease processing. Then in the report I would need to clear the memory location after the infotype update was completed.
The client was very pleased that I was able to come up with a solution to this problem on such short notice. Thinking through this problem and working out a solution was a challenge, but it’s the type of support we provide customers on a consistent basis. So don’t hesitate to reach out with questions. Even if we don’t have an answer today, we will find it for you.
Click the button below to gain weekly access to useful SAP HCM and SuccessFactors blogs written by Whitaker-Taylor expert consultants.