Based on the above information, it was difficult to decide on the approach. Now I take you through our subsequent reasoning process. After a few discussions with Concur we learned that Concur defines the expense types such as a relocation expense in a three-level structure as shown in Figure 1.

Figure 1

Expense structure in Concur

That is unlike the SAP system that follows a two-level hierarchy as shown in Figure 2.

Figure 2

Expense structure in the SAP system

Further discussions with Concur revealed that it would not provide the sub-expense types (relocation expense for on-site) in the inbound standard accounting extract to the SAP system. That is one of the most important fields for creating a claim or trip in an SAP system. It only provides the main expense type (relocation expense), which is not of any use in creating trips in an SAP system. In our old system we mapped general ledger (G/L) accounts to sub-expense types, and there was no concept of a main expense type. Therefore, we thought we had no choice but to go with the option to create claims in Concur and not replicate them in the SAP system, which would only be used for accounting purposes. Note that SAP considers this option to be an ideal approach and it has been implemented in most organizations.

However, our system is highly customized, so we followed the other options (replicating the claim in the ECC system). The implementation was almost started when we realized that there were a lot of SAP Business Warehouse (SAP BW) reports that needed to be modified as a part of this option. This issue was the client's main concern, as almost all the reports used standard extractors to fetch the data, and changing standard extractors is risky as well as quite complex. There were other minor issues pertaining to taxes that were blocking our way to proceed with this option.

(Note: Determining the taxes or the tax code is in ECC is done according to the G/L account and sub-expense type. As mentioned, we were not getting the sub-expense type, so we were not able to derive the tax code for value-added tax (VAT) calculations.)

We created a mapping table in the SAP system as shown in Table 3.

After the discussion, Concur agreed to send the description for both main expense and sub-expense types, with which we would be able to derive the sub-expense type code (such as RE01 and RE02) that can be used to create a trip or claim in the SAP system.

(Note: Concur has its own set of G/L accounts. We ignored this field in the SAE. Based on the mapping table (Table 3) in the SAP system, we derived the accounts for posting the accounting document.)

Option Decided

Now, both options were open for us: create a claim in Concur and replicate the same in the SAP system or create the claim in Concur and create only the accounting document in the SAP system.

However, because of issues with the earlier selected option (claim in Concur and only accounting document in the SAP system) such as the change in all SAP BW reports and taxes, we finally went ahead with the option to integrate Concur with the SAP system by creating claims in Concur and replicating them in the SAP system. The standard process of trip posting and accounting document creation follows.

Implementation Approach

As noted, the design approach chosen was to recreate the expenses created in the Concur application in the SAP system to minimize the impacts on both ECC and SAP BW reporting.

We created six interfaces between Concur and the SAP system as part of this project:

• Organizational hierarchy export. Organization master data such as line of service and cost center is sent to Concur.
• Employee export. This interface is used to export employee information to the Concur system from the SAP system, including personal, organization, and communication details.
• Work Breakdown Structure (WBS) export. WBS details are sent to Concur from the SAP system through this interface.
• SAE trip import. This has all the details regarding the claim created in Concur, such as trip, accounting, tax, and mileage data. These details are needed to replicate the trips in the SAP system.
• Payment export. Payment details are sent to Concur from the SAP system through this interface to mark the claim in Concur as paid once payment is made in the SAP system.
• One-time data transfer during cut-over: employee data, WBS data, and organizational hierarchy data.

In addition to creating the above six interfaces, we also completed design changes in the customized front-end portal to retire the create/change expenses functionality for users who are rolled out to Concur. Figure 3 is a high-level integration diagram that explains how the ECC-Concur integration actually happens. List data (WBS) and SAE are real-time interfaces, and payment confirmation, organization hierarchy, and employee data are file-to-file based interfaces.

Figure 3

High-level integration

Here are some salient features of the integration architecture:

Process details of the WBS interface as shown in Figure 3:

• WBS delta data is sent from ECC to Concur
• The ECC system initiates a request to send WBS changes to the Concur system through SAP Process Integration (SAP PI) and through the proxy communication method
• SAP PI makes a call back to Concur to get the WBS element that is needed for either amendment or deletion. The amendment or deletion is handled in the mapping logic in SAP PI.
• Then the required data is created, updated, or deleted in Concur using the interface
• SAP PI invokes a Concur API using the OAuth2.0 authentication method and uses the Advancto Representational State Transfer (REST) adapter to consume the Concur RESTful API.

Process details of the SAE interface as shown in Figure 3:

• Invoices or claims posted in the Concur system are sent to ECC to create claims or trips
• To extract the SAE file from Concur, different APIs need to be executed. The ECC system initiates the request to start the process in SAP NetWeaver Business Process Management (BPM).
• In the final BPM step, an extract file is returned as a response and the file is placed in a temporary folder, completing the BPM process.
• Next you create one more interface, which is a file to RFC, in SAP Process Orchestration (SAP PO). The SAP PO file sender adapter picks up the extract (text file with pipe delimited, a format of text in which the fields of a record are separated by a pipe symbol [|]). It performs the content conversion (converting to XML format) and triggers the RFC structure that was created in the ECC system using an RFC receiver communication channel.
• The ECC system through SAP PI and RFC communication method consumes the Concur web service API for expense accounting data.
• Consumption of Concur’s RESTful API is achieved via Advantco’s REST Adapter using the OAuth 2.0 authentication method.

The process details of payment confirmation, organization hierarchy, and employee data interfaces as shown in Figure 3:

• Employee master data, payment export data, and organizational hierarchy data are sent from ECC to Concur
• The comma-delimited file (CSV) file containing the data is placed in ECC for SAP PI to pick up
• SAP PI File adapter (Network File System [NFS] protocol) keeps polling for the file at regular intervals or at a scheduled time on a daily basis
• Once the file is available from ECC, SAP PI picks up the file and the file is then placed on the file share (folder path) available in Secure Transport, which defines a profile of RTP (Real-Time Transport Protocol), intended to provide encryption, ensure message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications.
• The client Secure Transport tool keeps polling the folder location where the files will be placed by SAP PI. Once the files are available, Secure Transport encrypts the file using PGP (Pretty Good Privacy) encryption.

The Process

Here is an outline of the end-to-end process starting from creating claims in Concur through the settlement of the claim:

• Employees submit expense claims from Concur. They are approved by the designated approver in Concur. Approvers are based on grade or designation. For instance, a Job Level 4 submitter has an approver at Job Level 5 and above. All expenses approved and processed in Concur are included in SAE from Concur. The pre-SAE validation happens in Concur through web service calls from SAP (such as WBS or cost center blocked for posting). A cost center can be locked for primary postings and WBS can be blocked for expense postings, and in these cases, the employee would not be able to create a claim on either of these two cost objects. The SAP system receives an SAE file from Concur. This file contains the details of the claims submitted and approved in Concur that are eligible for payment.
• The details from SAE are used to create trips in the SAP system. Processes subsequent to trip creation, trip posting, and accounting document posting happen in the SAP system.
• In the SAP system the report/claim ID is stored in the reference key at the header level in the accounting document for tracking and reconciliation purposes, and also to differentiate the Concur claims from existing claims when the need arises.
• The entire detail in SAE is stored in a customized table in the SAP system for reporting and future enhancements, if any. An option is provided to keep the data permanently or to delete the data after the claim is posted in the SAP system.
• Payment details are sent to Concur from the SAP system to mark the claim in Concur as paid once payment is made in the SAP system
• The standard accounting extract data is sent from Concur to the SAP system via SAP PI as the middleware

  Best Practices

The analysis and implementation of the project derived the following best practices:

• For us this was one of the first SaaS solutions to be implemented in the firm, so analysis was carried out in this area as part of the requirement analysis (RA) phase to better understand the options that I explained earlier to complete the implementation
• In the event that the Concur solution is unavailable for extended periods of time, I advise that the incumbent technical solution (e.g., the conventional travel management solution) be readily available so that it can be switched on in a controlled and timely manner. It is rare for the Concur solution to be unavailable for a lengthy period of time, but just after go-live we have seen few instances in which Concur was not able to send the extract or data to ECC. For this reason we came out with a back-up plan that actually proved to be a success and that was appreciated by the client.
• Develop a reprocess transaction or program for failed claims in the SAP system that helps to reprocess any claims if there is a failure in the first run due to issues either at Concur or in the SAP system
• Single Sign-On to access to the Concur solution should be enabled
• The project members and testing team should have a good understanding of the functionalities of the Concur application (ask for a few training sessions to understand what Concur has to offer). Understanding the Concur application means there is less dependency on the back-office team, which saves time and reduces resource dependency.
• If possible follow a phased go-live strategy with migrating 10 percent of the users to Concur first, with the rest using the conventional application. After two to three months roll out all the users.

Things to Remember

The project should be implemented and supported using the following technology stack:

• SAP ERP – customized ECC 6.0
• Integration layer – SAP PI 7.31 and SAP PO 7.4 Web and application server platform SAP NetWeaver
• Security: SiteMinder R12.5 is used for end-user authentication
• Client mobile device: Apple iPhone or iPad with iOS minimum version 6.x.x (recommended iOS 7.x.x or greater)
• SAP PO 7.4 (PI plus SAP NetWeaver BPM software is available to implement the integration solution. Although REST support is currently not available as standard, it is achievable with SAP-certified Advantco REST Adapter (version 1.0.22).
• Authentication via the standard SiteMinder log-in page is used to access the website
• If the system has nightly BATCH running, then the testing of it should be covered in the regression testing to ensure nothing is affected.

  Recommendation

Both options have their individual benefits to offer. However, it is important to keep the long-term roadmap in mind while making the decision.

Option 1 (claim replicated in SAP) may allow you to retain and use a larger portion of SAP functionality and reporting that has been developed, tried, and tested over the years. Since the bulk of the data will be replicated, this option could offer the benefit of being less dependent on external systems.

Option 2 (claim in Concur and only accounting in the SAP system) may allow you to create a single source of truth for the expense and accounting information and take better advantage of the external SaaS system’s capabilities in functionality and reporting. However, the change management in this option will be relatively higher.

Go with option 1 if:

• The system is highly customized.
• Standard extractors are used for most of the SAP BW reports.
• The business is apprehensive of a higher level of change management.

Go with option 2 if:

• Most of the processes/functionalities are in standard SAP with very few customizations.
• You have SAP S/4HANA implemented as this does not need a separate SAP BW instance for reporting. All the analytics and business intelligence are embedded in the SAP system so there is no major effect in reporting apart from minor changes.
• The business is ready to accept and comfortable with the change management involved.