Standard SAP Travel Management includes two main approval statuses: Request approved and trip approved. An organization uses the request approved status when the accounting clerk verifies the receipts against the trip claim from an employee. An organization uses the trip approved status when the manager verifies and approves the trips. The SAP system does not differentiate between these two statuses during settlement in transaction PREC.

You can use SAP Travel Management for settlement of employees’ traveling expenses in the standard SAP ERP processes. By settling the trip, you can then post it to finance. The payment can then be made to the employee for the expenses incurred.

Figure 1 is a snapshot of the basic standard process for travel expense handling.

Figure 1

The standard process for handling a travel expense in SAP Travel Management

The different standard statuses available in a standard SAP Travel Management system for the flow of travel expense are shown in Table 1. 

Table 1

Various trips statuses in SAP Travel Management flows

During the process flow for travel expense (Figure 1), the trip is assigned various statuses based on the action performed. Table 2 lists some examples.

Table 2

Example statuses for various steps in SAP Travel Management flows

For doing the Accounts Payable (AP) verification approval, when you execute transaction PRAP or follow SAP Easy Access menu > Accounting > Financial Accounting > Travel Management > Travel Expenses > Periodic Processing > PRAP - Approve Trip, you notice that there are options available to select the trips to be approved by an AP clerk based on the various trip statuses in the Status tab (Figure 2).

Figure 2

Transaction PRAP selection screen showing selection based on trip statuses

In Figure 2, note that the SAP system automatically populates the approval status values with 3 (trip completed) and 1 (request entered), and settlement status values with 0 (open) and 1 (to be settled). These values are hard-coded as defaults in the standard SAP program. These default values ensure that trips that are already approved and settled are not selected in transaction PRAP for AP clerk approval.

Similar options are not available during settlement of trips in transaction PREC so that only trips with a relevant status are settled. To complete trip settlement use transaction code PREC or follow SAP Easy Access menu > Accounting > Financial Accounting > Travel Management > Travel Expenses > Periodic Processing > PREC - Settle Trips. In the screen that appears (Figure 3), click the Further selections button. Note that the pop-up box that lists the selection fields does not include a field to select trips based on the trip status. 

Figure 3

Transaction PREC selection screen

This causes an issue in automatic differentiating between two statuses: 1 (request approved) and 3 (trip approved). The SAP system considers all the trips having these two approval statuses for trip settlement under transaction PREC, unless specific trip numbers are entered on the selection screen to select the already identified trips. Users consider this process cumbersome and an inefficient way to handle the trip settlement.

However, business organizations may have a different meaning for these two statuses in their travel policy definitions. For example, when an AP clerk approves the trip, the status in the system then needs to be set as 1 (request approved). When a manager (approver) approves the trip , the status in the system is only 3 (trip approved). Therefore, the organization may need only trips with status 3 to be settled in transaction PREC.

To avoid manually identifying relevant trips with status 3, I show you two options that organizations can select based on their environment and corporate policy:

• Option 1: Use authorization objects to control settlement access
• Option 2: Use user exits to control trip selection based on trip statuses for settlement

Option 1: Use Authorization Objects to Control Settlement Access

A standard SAP system provides the authorization object P_TRAVL for travel expenses. Refer to the SAP Help Site for the detailed standard documentation of this authorization object. In P_TRAVL the authorization field AUTHF (HR-TRIP: Operation and Status old) is three characters long. The various values for each character are shown in Table 3.

Table 3

Meaning for authorization field AUTHF in authorization object P_TRAVL

In authorization object P_TRAVL, the first character (operation) is the activity being performed on the trips in the process. Therefore, approving the trip in transaction code PRAP involves operation W (write trip data [create, change, copy]), and trip settlement in transaction PREC involves operation X (settle trip data).

The second character is for the existing approval status. The third character is for the existing settlement status just before performing the operation on the trip. Any combination of the values for these three characters is possible during definition for authorization object P_TRAVL.

Now, before I explain how to use this authorization object in my example, a prerequisite is that the person in your organization doing trip settlement in transaction PREC needs to be different from the AP clerk who performs the approval in transaction PRAP. Only then can you segregate the roles for these two persons based on authorization object; otherwise, you need to use option 2.

If the above prerequisite is met, you can differentiate the roles for the users as described in the next section.

Role for Trip Settlement in Transaction PREC

For the authorization object P_TRAVL, ensure that the second character in the authorization field AUTHF (HR-TRIP: Operation and Status old) has a value of 4 (trip approved) only. For example, use the following values for authorization field AUTHF:

• *4* = All operations on trip approved; approval status and all settlement status
• X4* = Settle trip data on trip approved; approval status and all settlement status
• X41 = Settle trip data on trip approved; approval status and to be settled settlement status

For the authorization object P_TRAVL, ensure that the second character in the authorization field AUTHF (HR-TRIP: Operation and Status old) does not have a value of 4 (trip approved).  For example, use the following values for authorization field AUTHF:

• *1* = All operations on request (request entered) approval status and all settlement status
• *3* = All operations on trip data (trip completed) approval status and all settlement status
• *5* = All operations on request on hold (request awaiting documents) approval status and all settlement status
• *6* = All operations on trip on hold (trip awaiting documents) approval status and all settlement status

After setting these roles, the person doing trip settlement in transaction PREC needs to be able to settle only the trips that have the status trip approved.  Therefore, the trip selection based on trip statuses in transaction PREC is controlled via authorization object P_TRAVL.

In a case in which the same person has authorization to do AP clerk approval (PRAP) and trip settlement (PREC), option 1 does not work as in that case the user has the access for various trips statuses, thereby mixing the roles for transactions PRAP and PREC.

In this case you can use the Business Add-In (BAdI) TRIP_IMP_EXP to control the trips based on the trip status. In the next section, I explain the process for implementing this BAdI with sample code that an organization can use and that can be further enhanced if needed to meet a more specific business requirement.

Step 1. Copy the Standard BAdI into the Custom  Implementation

Execute transaction SE18 or follow SAP Easy Access Menu > Tools > ABAP Workbench > Utilities > Business Add-Ins > SE18 – Definition. Define the name as TRIP_IMP_EXP and click the Display button (Figure 4).

Figure 4

Display standard BAdI TRIP_IMP_EXP in transaction SE18

On the next screen (not shown), select the option Implementation and Create from the menu bar. Now enter the custom implementation name starting with customer-specific names such as those starting with Y or Z (Figure 5). 

Figure 5

Enter the name for the custom implementation for the BAdI in transaction SE18

After you press Enter, you end up at the screen shown in Figure 6.

Figure 6

Save the custom implementation for BAdI in transaction SE18

Enter the short text for the custom implementation (e.g., Implementation to settle the trips based on tripstatus). Click the save icon.

Step 2. Define the Logic in the Custom Implementation of a BAdI 

Execute transaction SE19 or follow SAP Easy Access Menu > Tools > ABAP Workbench > Utilities > Business Add-Ins > SE19 – Implementation to go to Figure 7. Enter the custom definition name (Z_TRIP_IMP_EXP in my example). Click the Change button.

Figure 7

Change the custom implementation for the BAdI in transaction SE19

On the next screen (Figure 8) select the Interface tab and double-click the Method RESTRICT_TRAVEL_RANGE.

Figure 8

Change the method of custom implementation in transaction SE19

Enter the logic for the delimiting date as shown in Figure 9. Only the trips created after this date are selected for analysis in the custom implementation of the BAdI. This behavior can be useful to improve the performance of the BAdI as only recent trips can be selected. You can define the code logic to define a date dynamically as the current date less one year or less one month. For simplicity, I use the delimiting date as 1900/01/01 to ensure that all trips are considered for this logic. After defining the logic, click the save icon and then the activate icon.

Figure 9

Define logic in method RESTRICT_TRAVEL_RANGE in transaction SE19

The code to define the logic with a 1900/01/01 delimiting date is as follows:

You can paste this code in the screen shown in Figure 9.

Now return to the custom implementation Interface tab by pressing the back icon. Double-click the method RESTRICT_TRIPS_IN_RANGE as shown in Figure 10.

Figure 10

Change the method of custom implementation in transaction SE19

On the next screen (Figure 11) enter the code logic for excluding the trips not having a status of 4 (trip approved). After defining the logic, click the save icon and then the activate icon.

Figure 11

Define logic in method RESTRICT_TRIP_IN_RANGE in transaction SE19

The code for this logic is written as follows:

You can paste this code in the screen shown in Figure 11.

In these steps I restrict this new logic only for standard program RPRTEC00 (of transaction PREC) so that this logic does not affect other travel management functions because this BAdI is called in other SAP Travel Management functions.

I have excluded only the trips in which trip approval status (field ANTRG) is not equal to 4 (trip approved) so that during settlement only relevant trips with a status of 4 (trip approved) are settled.

Step 3. Activate the Implementation of the BAdI 

Execute transaction SE19 or follow SAP Easy Access Menu > Tools > ABAP Workbench > Utilities > Business Add-Ins > SE19 – Implementation. Enter the custom definition name as created earlier (Z_TRIP_IMP_EXP in my example) and click the activate icon. The following message appears in the next screen (Figure 12): BAdI implementation Z_TRIP_IMP_EXP has been activated! 

Figure 12

Activate the implementation of the BAdI in transaction SE19

After you activate the custom implementation, when you execute trips settlement in transaction PREC, it considers only the trips with a status of 4 (trip approved). All other trips are excluded from settlement processing.

The logic in this article has been explained considering the particular need during the trip settlement process to settle trips based on trip status. However, this standard BAdI TRIP_IMP_EXP can be used for various others scenarios including the following.

To restrict the reprocessing of approved trips in transaction PRAP, you can define the following code logic in method RESTRICT_TRIP_IN_RANGE for this BAdI:

Here I restrict this new logic only for standard program RPR_APPROVE_TRAVEL_EXPENSES (of transaction PRAP) and exclude only the trips where trip approval status (field ANTRG) is equal to 4 (trip approved). During transaction PRAP the AP clerk can’t change the trips that are already approved by a manager.

To restrict any operation on trips already posted to finance, you can define the following code logic in method RESTRICT_TRIP_IN_RANGE for this BAdI:

Here I restrict this new logic to exclude only the trips in which trip FI transfer status (field UEBRF) is 1 (posted to Financial Accounting) or 3 (cancellation posted to Financial Accounting). This ensures that after the trips have been posted to Financial Accounting (Accounts Payable), nobody can change the trips.