A service-based company provides service to its customers by visiting the customer site on a daily, weekly, or monthly basis. Every day, service representatives carry relevant service documents (service orders, contracts, and confirmations) to the customer site with them. Therefore, every day managers must use the SAP Smart Form tool to generate PDFs of the service documents and send them to each representative. The process can be automated using the action job monitor (transaction CRMC_ACTION_JOB), which executes each action that a manager schedules; in this case, the generation of PDFs.

Once the action job monitor successfully executes a scheduled action, however, it does not determine or schedule actions again for further execution. If actions that have been executed successfully have to be scheduled again, a manager has to open each document individually and schedule it manually. Rescheduling each action on each document is a tedious, time-consuming process.

By customizing a Business Add-In (BAdI), managers can reschedule these actions automatically, saving themselves the trouble of rescheduling each individual printing and sending every day. This frees up time for more important activities.

I first explain the standard process for scheduling actions in the job monitor, and then demonstrate how to enhance the process using the custom BAdI. I use a service order as my example throughout, but the process can be used to run actions on any existing service document, as well as other actions that are not rescheduled automatically after being executed.

Executing Scheduled Actions: Standard Process

In a normal scenario, a service manager would use transaction CRMC_ACTION_JOB to display the action job monitor screen in Figure 1. There are several fields to populate:

• The Application field, in which you specify the application that you are using to run the action (for example, for a CRM order, the application would be CRM_ORDER).
• The Action Profile field, which contains all the actions defined for a particular transaction. In this case, it contains the action profile that stores all actions associated with a service order.
• The Action Definition field, which defines the actions assigned to the Action Profile
• The Application Key field, which defines the transaction number (in this case the service order number)
• The Promotion Status field, which represents the status of the actions taken on a given order (scheduled, executed, or contains errors). In this case, it should have a value of zero, meaning that the actions are scheduled and ready for execution.

Click the execute icon in the top left corner of the screen.

Figure 1

Input fields that are used to filter orders with a given action definition

The screen shown in Figure 2 appears. Execute the actions by selecting the required service documents and click the execute icon to process the action (Figure 2). The order highlighted in green and the status change (a green square) indicate that the action has been executed (Figure 3).

Figure 2

Filtered orders with actions scheduled based on the input fields

Figure 3

Actions on orders are successfully executed

If you repeat the process for the same service document, the system sends a warning message that 0 actions have been selected (Figure 4). This is because this action has already been successfully executed, and is therefore not scheduled.

Figure 4

No actions are scheduled once the actions are successfully executed

At this point, to execute this action again, you would have to manually reschedule the action using the following procedure. Open the order using transaction crmd_order (Figure 5).

Figure 5

Open the transaction by entering the transaction number

Edit the order as desired. In this case, the action to be scheduled is a certificate of destruction, rendered at the time of service. Click the Actions tab, followed by the icon highlighted in Figure 6. A dropdown menu will appear. Select the action description Certificate of Destruction at time of Se. The action is scheduled.

Figure 6

Manually schedule the action

This results in another row with a yellow triangle appearing in the Action column, which indicates that the action with the description Certificate of Destruction at time of Service (Print) has been scheduled (Figure 7).

Figure 7

Action Certificate of Destruction at time of Service (Print) is scheduled

Enhance the Standard Process

As you can see from Figures 4, 5, and 6, once an action is executed successfully using the action job monitor, you have to reschedule the action manually to execute it again. This section explains how you can enhance the standard process to reschedule actions automatically after they are successfully executed from the action job monitor.

The BAdI TRIGGER_EXECUTED is called whenever actions are executed from the action job monitor. The code in the BAdI below checks if the action is successfully executed, and whether the action should be rescheduled. If the action must be rescheduled, the BAdI re-determines the action and resaves the order.

Enter transaction SE19. Enter TRIGGER_EXECUTED in the BAdI Name field. Click the Create Impl. icon, and in the window that pops up enter a name for the implementation (Figure 8). In this case, I use ZREPEAT_COD_PRINT. Click the check icon. This creates a custom implementation of the BAdI TRIGGER_EXECUTED. Whenever you execute actions using the action job monitor, this BAdI is called and it reschedules the action for further execution.

Figure 8

Create a BAdI implementation

This BAdI is filter-dependent. In this case, you specify the filter CRM_ORDER as the BAdI, so that only actions performed on orders are automatically rescheduled, as opposed to other applications (Figure 9). That way, the BAdI is called during runtime only when the value in the Application field of the action job monitor (first seen in Figure 1) and the filter are the same; CRM_ORDER in my example.

Figure 9

Specify CRM_ORDER as the filter for the BAdI

You then enhance the method TRIGGER_EXECUTED_IN_REPORT and implement the appropriate code, as demonstrated below.

Copy the standard code from the method trigger_executed_in_report in the definition TRIGGER_EXECUTED, found in the Standard Implemented BAdI CRM_ORDER. In this way you are not changing the standard implemented BAdI. You are implementing your own BAdI. In this line of the standard code add one more condition to specify the action definition for which the enhanced process should work (Figure 10).

Figure 10

Check if the action that is executed is equal to the one specified in the condition

Figure 11

Get the guids of orders that are to be saved

Figure 12

Get the guid of the order and insert it into the internal table lt_guid

Figure 13

Redetermine the action for the order

If none of the attributes related to the order were changed while executing the action, you need to get the unique identifier of the order (its 16-digit guid) and insert it into the lt_guid internal table to reschedule the action for the order (Figure 12). By calling the function, the module of the action is redetermined and rescheduled (Figure 13). You then copy the code from the standard BAdI CRM_ORDER (Figure 14).

Figure 14

Save the order and collect error messages (if any) into the error log

Test the Enhanced Process

To test the enhanced BAdI you created above, use the same process for executing actions in the job action monitor described in the first section of this article. In transaction CRMC_ACTION_JOB, populate the necessary fields (also described in the first section), enter the appropriate service order number in the Application Key field, and click the execute icon (Figure 15). In this case, I am testing with one service order, but you can use the action job monitor to process actions for all of the required service documents at one time. As before, the screen in Figure 16 appears.

Figure 15

Input fields that are used to filter the orders with a given action definition

Figure 16

Filtered orders with actions scheduled based on the input fields

Now if you run the action again for the same service order that has been executed successfully, it does not show any warning message. It processes the action for the service order, because the action has been redetermined and rescheduled through the enhanced BAdI TRIGGER_EXECUTED (Figure 17).

Figure 17

Action on the order is successfully executed

Having implemented the BAdI, you can process (execute) successfully executed actions on service documents any number of times, without manually rescheduling the actions by opening each service document.

This process is normally carried out by a service manager in the back end SAP GUI. While there is no process defined to do this in the SAP CRM Web Client UI, it can be accessed via the Transaction Launcher tool.