lessons learned: the first customer implementation of sap...

1

Lessons Learned: The First Customer Implementation of SAP Cash Management Powered by SAP HANAby Mary Loughran, Senior Consultant, Hanse Orga Jochen Stiebe, Managing Director, SymQ July 20, 2016

With the numerous aspects involved in an SAP HANA implementation a detailed explanation is the best approach to have a good understanding of the considerations required versus undertaking an implementation strictly in SAP ERP Central Component (ECC).

Ensuring a detailed knowledge of the different components and various deployment options for running SAP Cash Management on SAP HANA is the key to success.

This article includes details related to the first rollout to production of this functionality in North America.

To date, there is only one SAP customer in North America running SAP Cash Management powered by SAP HANA in production. With the rollout of SAP Cash Management powered by SAP HANA, there are a number of changes to the SAP landscape. Following are highlights and lessons learned from that first customer implementation of this functionality.

There are three components included in SAP Cash Management powered by SAP HANA: Cash Operations, Liquidity Management, and Bank Account Management. SAP Cash Management powered by SAP HANA integrates not only with accounting in SAP S/4HANA Finance but also with the solutions for SAP Treasury and Risk Management, SAP Bank Communication Management, and SAP In-House Cash.

Key ConceptThere are three components included in SAP Cash Management powered by SAP HANA:

• Cash Operations

• Liquidity Management

• Bank Account Management.

The Cash Operations and Liquidity Management components enhance existing SAP ERP Central Component (ECC) functionality with improvements both in functionality and the user interface (UI). The Bank Account Management component functionality is a newly built technology for SAP HANA.

2This article was originally published by Financials Expert in 2016

sapexperts.wispubs.com/financials

Lessons Learned from the First Customer Implementation of SAP Cash Management Powered by SAP HANA

The new SAP Cash Management on SAP HANA suite (SAP Cash Management powered by SAP HANA) is web based using Fiori technology running on the latest database and web technology. Therefore, the web browser replaces SAP GUI. A Launchpad (see Figure A in the “Key Terms” sidebar) serves as a starting point for the different apps or tiles. Each tile covers a business task. SAP delivers Fiori applications with all three components in SAP Cash Management powered by SAP HANA.

The SAP licensing described in this article is the following:

• SAP NetWeaver 7.40 or later

• SAP HANA licensing

• SAP S/4HANA Finance, On-Premise Edition 1503

• SAP Cash Management for Finance

• SAP Integrated Business Planning for finance

• Fiori Framework

To provide a little background on SAP terminology, SAP differentiates different time segments of managing cash – short-term, mid-term, and long-term planning. In terms of short-term planning, the solution that SAP provides differentiates between the cash position dimension and the short-term outlook dimension, which is called cash positioning. The next time horizon focuses on mid- and long-term planning. The Cash Operations component covers the cash positioning and short-term planning, and the Liquidity Management component covers the mid- to long-term planning. Historical cash postings are referred to as actuals. The terms mentioned here are shown with the associated time horizons in Figure 1.

History (actuals)

1-3 days Up to four weeks 1 year Time horizon

Cash Flow Analysis

Cash Position

Liquidity Forecast

Liquidity Planning/Rolling Forecast

Data source for SAP Cash Management

One Exposure from operations

Table FQM_FLOW

Data from distributed systems

Local tables

Clas

sic

cash

(ID

oc)

Bank

bal

ance

uplo

ads

Actu

als

from

SAP

Liqu

idity

Plan

ner

SAP

Trea

sury

and

Risk

Man

agem

ent

Loan

s

Post

ings

Bank

stat

emen

ts

reco

rds

Mem

o

Cont

ract

Acc

ount

sRe

ceiv

able

and

Paya

ble

(FI-C

A)

Global cash management or treasury

Start new planning cycle for the period

Check for missing subsidiary data

Treasury reviews aggregated plan data; make adjustments, if necessary

Review plan-to-actual and plan-to-plan comparison reports


Enter or upload plan data for period

When plan is complete, submit plan

Subsidiaries

Figure 1: SAP Cash Management terminology




Before going through the article, we recommend that you review the definitions in the “Key Terms” sidebar.

Note!The time horizon for the Cash Position and Liquidity Forecast varies for different customers based on their specific business and implementation. For example, for some customers the Cash Position may be one to three days, but for other customers, it may be one to five days. The same applies to the Liquidity Forecast time horizon.

Key Terms!In this section we define a few key terms that would be helpful to understand while reading this article.

SAP HANA. SAP HANA is a database that uses in-memory technology. An SAP HANA database is faster, thereby reducing data redundancies in non-SAP HANA database landscapes. SAP HANA has become possible because of the technological advancements that have been made in database management.

SAP Fiori. SAP Fiori is a new user interface to SAP functionality. The key to Fiori apps is they have a more attractive user interface and are able to run on multiple devices. Fiori offers a user-definable dashboard, referred to as the Launchpad, to role-based functionality. Figure A shows a Fiori Launchpad for a treasury team member.

Fiori apps are also called tiles and can be developed by any third-party software provider. There are three types of Fiori apps. They are transactional (task-based access), analytical (monitoring and tracking data usually with graphics), and fact sheets (a listing of essential information in a report format with drill-down capabilities).

SAP HANA Enterprise Cloud (SAP HEC). SAP HEC consists of SAP infrastructure and application management services with an SAP HANA database provided by SAP or a third party. They are not on the SAP customer’s premises, but are instead on the premises of the SAP HEC provider. SAP HEC infrastructure can be either custom or standardized. The standardized setup would run only SAP standard functionality, and would have simplified SAP licensing. The custom setup would be customer-specific functionality, and would have customer-specific SAP licensing.

On-premise. SAP installation in a customer’s system landscape. The customer purchases a license from SAP.

The terms S/4HANA, SAP Simple Finance, and sFIN are synonymous. As of release 1602, SAP S/4HANA Finance will be the only official product name for both the 1503 and 1602 releases. SAP S/4HANA Finance stands for SAP Business Suite 4 SAP HANA and is SAP’s next-generation financials solution, which runs on an SAP HANA database.

The term Cash Management add-on is sometimes used to refer to SAP Cash Management powered by SAP HANA, and is part of SAP S/4HANA Finance.




Deployment OptionsBefore reviewing the components in SAP Cash Management powered by SAP HANA in detail, we first describe the different deployment options for SAP Cash Management powered by SAP HANA. Figure 2 shows the different landscape options. The first two are the side-by-side (aka sidecar) landscapes. One of these landscapes should be selected if the operating modules (Financial Accounting [FI], materials management [MM], sales and distribution [SD], and Project System [PS]) remain on ECC, and only the SAP Cash Management and SAP Treasury and Risk Management functionalities are moved to SAP HANA. The integrated scenario is an SAP system with all modules running on an SAP HANA database.

When you use a side-by-side approach, the cash flow information collected in ECC must be transferred to the SAP Cash Management powered by SAP HANA box to be reflected in the Cash Operations reporting. This is done by activating standard SAP distributed

Key Terms! (continued)

One Exposure is the data source that feeds the cash management and liquidity forecast reports when using Cash Operations and Liquidity Management in SAP Cash Management powered by SAP HANA. One Exposure stores both actual (historical) and forecasted (future) cash flows. One Exposure is discussed further when we cover the Cash Operations component. (Note: You may also see the term Exposure Hub used. Exposure Hub and One Exposure are synonymous. One exposure is the newer term used by SAP.)

Figure A: A Fiori Launchpad




cash management. When using SAP distributed cash management, SAP Cash Management is activated in ECC, and the SAP system is collecting data from the relevant (configured) applications (FI, SD, MM) in real time in ECC. The operational data is then passed from the ECC system to the SAP Cash Management powered by SAP HANA box via an IDoc. This IDoc-based interface can be triggered either periodically in the background or manually by a user. When the interface is triggered, it transfers the cash flow information from the ECC SAP Cash Management database tables into the One Exposure feature of SAP Cash Management powered by SAP HANA. The SAP distributed cash management functionality is not new. It has been available from SAP for at least 15 years.

If a side-by-side deployment option is used, the bank master data (transaction code FI01) also needs to be in sync between the ECC and SAP Cash Management powered by SAP HANA systems. Either ECC or SAP Cash Management powered by SAP HANA is designated as the master system, and the other should be updated periodically to ensure the two systems are in line. SAP provides a standard (IDoc-based) interface to distribute bank master data among systems. Using the SAP Distribution of bank master data (transaction code FI08) with the IDoc BANK_SAVE_REPLICA type, bank master data is sent from ECC to the SAP Cash Management powered by SAP HANA. It adds or updates the bank master data there, assuming ECC is the master system for bank master data.

If a company decides to go with a side-by-side approach, and uses or plans to use In-House Cash, SAP Bank Communication Management, or SAP Treasury and Risk Management,

Figure 2: The initial screen to define settings for the Journal Entry Ledger

Note!In Figure 2, BCM stands for SAP Bank Communication Management, IHC stands for SAP In-House Cash, and TRM stands for SAP Treasury and Risk Management.




the company needs to decide which of the side-by–side scenarios it makes sense to select. Factors that need to be evaluated in detail during the implementation include:

• If and how to integrate AP and treasury payments. For example, AP payments will be made from ECC. If treasury payments are made from the SAP Cash Management powered by SAP HANA, a decision needs to be made if payments should be merged before they are sent to the bank, or if AP and treasury payments should go to the bank in separate files.

• Whether it makes sense for treasury users to log in to different systems (ECC or SAP Cash Management powered by SAP HANA) based on the functionality with which they are working.

• If the electronic bank statement should be imported into the SAP Cash Management powered by SAP HANA system for balance information or if the balance information should transfer from the ECC system

• When the company plans to move to the integrated scenario also is a factor to consider when designing the deployment landscape

• The migration effort of moving from a side-by-side approach to the integration scenario. For example, if the second side-by-side approach is selected, In-House Cash, SAP Bank Communication Management, or SAP Treasury and Risk Management, if used, would not need to be migrated.

Advantages of the Side Car Deployment

Here are a few advantages of going with one of the side-by-side approaches:

• Treasury is able to take advantage of the latest SAP technology, and the other modules or departments can follow at their own pace. It is natural that a move to SAP HANA for FI would take longer due to the many changes with the transfer to the Universal Journal.

• If you assume a company is ready for an SAP HANA landscape, it is difficult to make an argument to go with older technology.

• SAP Treasury and Risk Management and SAP In-House Cash are capable of working with S/4HANA. There is no new functionality in these modules, but in the future, SAP may make changes to the SAP Treasury and Risk Management and SAP In-House Cash modules. Companies that have gone with the side-by-side approach with SAP Treasury and Risk Management and SAP In-House Cash on the SAP HANA platform can incorporate the new functionality from SAP in these two modules. Companies that have gone with the first side-by-side approach cannot incorporate new changes from SAP and third-party vendors.

• Treasury users will have one consistent interface when working in the SAP system.




• When using the second side-by-side approach, drilldown to trades and treasury payments are possible on the SAP Cash Management powered by SAP HANA system, which is a nice feature for treasury users.

• Another advantage of the second side-by-side approach is the treasury functionality does not need to be migrated to SAP HANA when the other modules or departments are ready to move to the integrated scenario.

Components of SAP Cash Management on SAP HANAIn this section, we discuss the three components of SAP Cash Management on SAP HANA. For each component, we describe the functionality supported, and then add further information about what has changed with respect to the comparable functionality in ECC.

Cash Operations

The Cash Operations component contains a number of Fiori apps to be used in the day-to-day cash management processing. The Cash Operations component covers the monitoring of bank statements, the reviewing of bank account balances in the cash position report, bank transfers, and approval of payments. None of the underlying functionality is new, but it has been changed to a certain extent, and the Fiori user interface is completely new.

The functionality included in the Cash Operations component is:

• Monitor bank statements imported (similar to SAP Bank Communication Management’s Bank statement monitor [transaction code FTE_BSM] in ECC)

• An overview of a Cash Position report with drilldown to detail (similar to the Cash Position report [transaction code FF7A] in ECC)

• Overview of bank risk (There is not a comparable standard report in ECC. This is a counterparty risk report.)

• Initiation of bank transfers and manual payments (functionality to make bank transfer or track bank transfers)

• Approve bank payments (similar functionality to the payment approval in SAP Bank Communication Management)

The Cash Operations component contains a Cash Position report app. This report is similar in some ways to the Cash Position report in ECC (transaction code FF7A), but there also are a number of improvements.

The Cash Position report app displays data from bank accounts (bank statements), cash in transit (payments), and treasury deals. The source of data is taken from general ledger (G/L) accounts, payment data (AP and treasury payment runs), treasury deals, memo records, and bank statements.




Figure 3 shows a sample of the Fiori web Cash Position app delivered with SAP Cash Management powered by SAP HANA. Notice that the interface has been improved in that the amounts are displayed in the transaction currencies, and when drilling into an account, the user is not taken to a new screen. Instead the screen expands to show the detail of the clicked-on account, leaving the other account information intact.

Two new key performance indicator (KPI) Fiori apps are delivered with the Cash Operations component. They are the Bank Statement Monitor, which shows at a high level the bank statement import status, and the Cash Position app, which gives a high-level view of account balances. The Bank Statement Monitor (Figure 4) lets the cash manager know at a glance the status of processing of the prior-day bank statements in the SAP system.

It lets the cash manager know if the bank statement was received from each bank and where the bank statements were successfully imported into the SAP system. If there are

Figure 3: The Cash Position report on SAP Cash Management powered by SAP HANA

Figure 4: The Bank Statement Monitor KPI




any missing bank statements, the cash manager can quickly see that. These are things the cash manager needs to know before he or she starts looking at the account balances in the SAP system. The cash manager then looks at the Cash Position app, which shows a high-level view of the current bank account balances. Both these apps have drill-down capability to allow the cash manager to get more information.

There is also a Make Bank Transfer app, which is a fast way to make a transfer payment from one bank account to another. This is similar to running Bank-to-Bank Transfer (transaction code FRFT_B) on ECC. With the Make Bank Transfer app, shown in Figure 5, you enter an amount, value date, payment method, and reference text at the top of the screen. Select the source and target bank accounts by clicking the bank accounts and then clicking the Make Bank Transfers button at the bottom of the screen. Because SAP is an integrated system, when the payment is saved, it is immediately reflected in the Cash Position report.

You are then prompted with a pop-up, similar to the one shown in Figure 6, to confirm the bank transfer. Click the Submit button on the bottom of the pop-up, and the bank transfer payment request is created. The user interface (UI) is very easy to use.

The next app in the process flow would be the Approve Bank Payment app, which allows a manager to approve a payment workflow, assuming the configuration is set up for approving payments (not shown). This uses functionality within the SAP Bank Communication Management module.

Figure 5: The Make Bank Transfer Fiori app




The planning levels and planning groups in Cash Management in ECC continue to be the means to categorize the type of cash flows with SAP Cash Management powered by SAP HANA. The Cash Position report is now displayed by Liquidity Items, which is the term used to tag cash flows in SAP’s Liquidity Planner module. The Cash Management Account name is no longer part of SAP Cash Management powered by SAP HANA. The Cash Management Grouping in Classic Cash Management has been replaced by Bank Account Group in SAP Cash Management powered by SAP HANA.

One Exposure provides data storage for cash management reports. One Exposure is a central data structure of all transaction data that has an impact on financial exposure. Data is stored within One Exposure with a certainty level. A certainty level is a way to capture the likelihood of the cash flow on the corresponding date. In other words, it is a probability of the cash flow happening on the corresponding date. A number of programs build the

Figure 6: Confirm the bank transfer

Note!At the end of the article, there is a complete list of the Fiori apps delivered with SAP Cash Management powered by SAP HANA.




data in One Exposure including balance records and cash flows from operations. All external data is stored in a database table with a time stamp and an identifier. The cash management reports access the data from this storage by analyzing the time stamp and providing the most recent information to the cash management applications. One Exposure holds all transactional data, and also all plan data.

The technical name of One Exposure is Financial Quantity Management (FQM). (The underlying table for One Exposure is FQM_FLOW.)

One Exposure integrates data from different applications and modules even in a distributed system landscape. Figure 7 shows the source of data for cash management reports on SAP Cash Management powered by SAP HANA.

SAP Cash Management powered by SAP HANA requires operational cash flows that are held with the operations modules, whether on the ECC system in the case of a side-by-side SAP Cash Management powered by SAP HANA approach or on the SAP HANA platform in the case of an integrated system approach. To get the operational cash flows to the SAP Cash Management powered by SAP HANA box to be reflected in the Cash Management in the case of a sidecar setup, distributed cash management needs to be configured. The IDocs used to transfer the operation cash flows from the ECC box to One

Note!Where you see transaction codes or programs with FQM, this is most likely part of One Exposure.

History (actuals)

1-3 days Up to four weeks 1 year Time horizon

Cash Flow Analysis

Cash Position

Liquidity Forecast

Liquidity Planning/Rolling Forecast

Data source for SAP Cash Management

One Exposure from operations

Table FQM_FLOW

Data from distributed systems

Local tables

Clas

sic

cash

(ID

oc)

Bank

bal

ance

uplo

ads

Actu

als

from

SAP

Liqu

idity

Plan

ner

SAP

Trea

sury

and

Risk

Man

agem

ent

Loan

s

Post

ings

Bank

stat

emen

ts

reco

rds

Mem

o

Cont

ract

Acc

ount

sRe

ceiv

able

and

Paya

ble

(FI-C

A)

Global cash management or treasury

Start new planning cycle for the period

Check for missing subsidiary data

Treasury reviews aggregated plan data; make adjustments, if necessary



Enter or upload plan data for period

When plan is complete, submit plan

Subsidiaries

Figure 7: The data source for cash management reports




Exposure on the SAP Cash Management powered by SAP HANA box are CMSEND and CMREQU. The transfer of data could be either or both scheduled or manually triggered by the Cash Manager. For example, if the scheduled transfer of information is hourly, and the cash manager wants a refresh of the cash flows from the ECC system a half hour after the last scheduled run, he or she can manually trigger the interface to run.

The One Exposure is the central storage of all actual and forecast operational business transactions and therefore SAP uses the phrase “single source of truth” for One Exposure. In SAP Cash Management powered by SAP HANA, One Exposure replaces the data source for the old transaction code FF7A and FF7B in ECC, both of which are in tables such as FDSB and FDSR.

Cash flows from the following sources are stored in One Exposure:

• Financial operations (Central Finance integration possible)

• Treasury and Risk Management

• Customer and mortgage loans

• Contract Accounts Receivable and Payable (FI-CA)

• Sales and distribution

• Materials management

• Bank account balances via Microsoft Excel upload

• Expected cash flows from classic SAP Cash Management via IDoc (distributed cash management)

• SAP Liquidity Planner actuals

Liquidity ManagementThe second component of SAP Cash Management powered by SAP HANA is Liquidity Management, which brings together mid- to long-term planning, and actuals determination, to provide actual-to-plan, plan-to-forecast, and plan-to-plan variance analysis reporting.

Parts of the functionality in this component are similar to the Liquidity Planner functionality for actual and planned data rolled out approximately

Note!The Project System module is not on the list, although the Cash and Liquidity Forecast in ECC does reflect Project System cash flows.

Note!The difference between plan and forecast data is that plan data is related to business planning and is not based on contracts within the SAP system. Forecast data is based on business for which contracts and invoices are in place.




10 years ago with SAP Strategic Enterprise Management (SEM). This functionality then was phased out, but is now on the SAP HANA platform with a Fiori front end. This fills a gap in mid- to long-term planning functionality that has existed for many years.

The functionality included in the Liquidity Management component supports daily forecast and reporting activities (Cash Flow Analysis). Liquidity Management also tracks plan and forecast data.

Liquidity Management supports basic planning functions, such as:

• Opening of a new planning period

• The system recommends initial amounts, such as use last year’s actual numbers

• The person entering the plan data has the ability to change the amounts

• Bump-up, bump-down plan data by percentage change

• The planning status of subsidiaries can be tracked

• High-level status tracker to check status of submitted or missing plans

SAP provides sample templates to be used with Liquidity Management to upload plan data from Microsoft Excel. The Liquidity Management functionality also supports liquidity planning by liquidity item, planning level, and cash pool. It also supports multiple currencies for use in foreign exchange (FX) forecasting and hedging purposes.

For mid-term planning, there is a short-term liquidity forecast web Fiori app. Now with SAP Cash Management powered by SAP HANA in this report, SAP has united cash position and liquidity forecast data so both cash position and liquidity forecast data can be displayed on the same report output, unlike in ECC. Another change with this component is that the layouts of Cash Position and Liquidity Forecast reports are displayed by liquidity item, as opposed to by planning level in ECC Cash Management.

Liquidity Planner, which has been delivered as part of an ECC license for at least 10 years, is now being repackaged by SAP as the Cash Flow Analysis report in the Liquidity Management component. Liquidity Planner categorizes all cash postings into SAP-configured buckets, which are the uses of cash an SAP customer wants to track for cash forecasting and planning purposes. The categorized cash postings are referred to as actuals. (Actuals describe how cash was used in the past. The actuals determination in Liquidity Planner analyzes each cash posting and categorizes it into buckets or liquidity items.) The Liquidity Item is a new key tag for cash flows in SAP Cash Management powered by SAP HANA, and it also relevant to the Cash Flows report layout. The actuals are stored in One Exposure mentioned above under the Cash Operations component.

To summarize, cash postings are assigned to Liquidity Items by the SAP Liquidity Planner. Cash Flow Analysis and Make Liquidity Plans use liquidity items as the buckets or categories of data.




Another new aspect introduced with Liquidity Management in SAP Cash Management powered by SAP HANA is the ability to create a rolling period plan, (for example, a 12-month rolling forecast with monthly granularity).

The process is as follows. Each period, a new planning cycle is started. This step would be done by someone in treasury. Next, the subsidiaries enter or submit their forecast for the next month. There are three options for how the planned data can be initially populated (auto-filled) into the layout: liquidity forecast data, previous period plan data, or last year’s actual data. The user can adjust the data after the figures are initially populated. Treasury checks that all subsidiaries have submitted their plans using the Status Tracker app (not shown). The opening balance is included as the starting point. Once all plans are submitted, treasury looks at the aggregated plan data, and can make final adjustments, if necessary. The plan for the month is then set.

The planning process is shown in Figure 8.

The forecast is entered into the SAP system using SAP Integrated Business Planning for finance. This is different from SAP BusinessObjects Planning and Consolidation (BPC). SAP Integrated Business Planning for finance is designed for planning only, not for consolidations. If a customer does not have a BPC license, using SAP Integrated Business Planning for finance is fine. Companies already using BPC for consolidations need to decide which BPC application to use for Liquidity Management. It is important to mention

Figure 8: The monthly planning process




that there is no SAP-delivered migration path from SAP Integrated Business Planning for finance to BPC.

Figure 9 shows a sample screen in which the plan data is entered. As mentioned, you can also upload the plan data from Excel.

FX forecasting is possible in that the planned data can be entered and viewed by currency. The FX forecasting can be used for hedging purposes.

Once the plan data is in the system, plan-to-actual variance reporting is available.

One Exposure, mentioned above under the Cash Operations component, ensures that planned, forecast, and actual data have the same granularity, which is key for reporting purposes. (In other words, when you are doing a plan-to-actual comparison reporting, you want to compare apples to apples.)

Bank Account ManagementThe Bank Account Management component is the third component in SAP Cash Management powered by SAP HANA. It is a completely new functionality for bank account management. Bank Account Management is a structured process to implement governance structures to manage the processes and comply with rules and regulations around bank account management. Bank Account Management includes a central repository of bank accounts and related processes that can be monitored within the SAP system.

Figure 9: Enter plan data




This component fills the gap of bank account master data that existed prior to its release. To clarify, in ECC, there is the definition of a house bank account (transaction code FI12), which is the technical definition of house bank accounts. The definition of the house bank account must be completed before transactional processing, such as payments or electronic bank statements processing, can be done. This data in the technical definition of a house bank account in ECC (listed in Table 1) was never meant by SAP to be master data. It was always meant to be the technical definition of a bank account to enable processing in the SAP system.

The functionalities included in the Bank Account Management component are:

• Centralized bank account management with relevant data stored with each bank account

• A workflow approval process for opening and closing bank accounts and a periodic review process

• The ability to mark specific fields as sensitive so that changes to those fields require an approval process

• The ability for cash managers to assign the bank accounts to a hierarchy, which in most cases would represent how the cash flows at the banks for cash pooling or concentration

• Mass signatory changes with approval process

• Integration with SAP Bank Communication Management for payment approvals

Table 1: Fields stored in ECC with a house bank account

Field Description

Company code Legal entity

Bank ID A five-character identification of the bank (for example, BANK1)

Bank account ID A five-character identification of the account (for example, CHK01)

Description An approximately 35-character description (for example, BANK1

payroll account)

Currency The type of currency used (for example, USD)

Bank account number

Alternative account number

G/L account The main G/L account for the bank account




With the release of Bank Account Management in SAP Cash Management powered by SAP HANA, bank account master data is maintained for house bank accounts. Bank accounts are defined as part of a bank account hierarchy. The bank account hierarchy definition could follow how the cash is consolidated or concentrated. Figure 10 shows the General Data screen for a bank account in SAP Cash Management powered by SAP HANA. Notice that all relevant information about the bank account can be captured, such as the status of the bank account, the company code, the beneficiary name, the account type, the account number or International Bank Account Number (IBAN), a description, bank key or Society for Worldwide Interbank Financial Telecommunication (SWIFT) code, overdraft limits, profit center, and contact person (both internal and external).

As you can see, the G/L account tied to the house bank account is not stored with the bank account definition. This is because the G/L account is defined with the technical definition of the bank account in ECC, using Maintain House Bank Account (transaction code FI12), as mentioned above.

The new Bank Account Management functionality contains a workflow approval process for opening, closing, and editing bank accounts. You can also define what fields are sensitive, and if edited, should or should not require approval.

For each bank account, the signatories and signatory limits are stored in Bank Account Management under the Payment Signatories panel, shown in the highlighted box

Figure 10: Configure the non-leading ledger




in Figure 10. The data entered here is integrated with the SAP Bank Communication Management module for payment approvals. In addition, users can store (attach) contract information by clicking the Attachments button, also shown in the highlighted box in Figure 10.

After entering the information for a new bank account as shown in Figure 10, and clicking the Save and Submit button, you are prompted with a message similar to the one shown in Figure 11.

Next, the workflow approval process is triggered to obtain the approvals for the new bank account, as is shown in Figure 12.

From the screen shown in Figure 12, the approver can either approve or reject the new bank account by clicking the workflow Approve or Reject button (not shown). Additionally,

Figure 11: Submit a request to create a bank account

Figure 12: The workflow approval list

19


This article was originally published by Financials Expert in 2016


you can select the Create bank account link to view the full details of the new account, as shown in Figure 13.

As with all functionality in the SAP system, there is a complete audit trail on all processing, adhering to internal compliance and regulatory guidelines. By clicking the audit trail log icon under the History column, you can see who requested the new account and when. This data is displayed in Figure 14.

Figure 13: Approve or reject new account

Figure 14: An audit trail log

20




In addition companies typically have an annual review process to review the current bank accounts, which is supported by the Bank Account Management component. There typically is a person in the company who is responsible for each bank account. This is information stored in Bank Account Management and it is included in the annual review process. Figure 15 shows the Initiate Review Process app and how after selecting the accounts to be reviewed, you click the Initiate Review button to start the review process.

The Monitor Bank Account Review Status app, shown in Figure 16, is used for treasury to monitor the status of the annual review of accounts.

Figure 15: Initiation of the review process

Figure 16: A report in the Monitor Bank Account Review Status app

21




A very useful feature of this new functionality is the integration of the definition of the bank account data with the cash pooling or cash concentration for the accounts. When the accounts are created, they are added to a bank account group. This bank account group is similar to the Cash Management Groupings in the ECC Cash Management functionality.

The Bank Account Management solution does not currently support fee analysis, which is important functionality for many companies. Fee analysis is typically a somewhat tedious monthly process. The treasury department should evaluate the bank’s monthly invoice, which is composed of the different services the company has used over the month.

Lastly, the three components of SAP Cash Management powered by SAP HANA are integrated and work together. It is important to mention that Bank Account Management needs to be activated so the bank accounts can be used in the Cash Operations and Liquidity Management components.

Information from the First Customer ImplementationThe first customer rollout of the SAP Cash Management on SAP HANA implementation was a customer in North America. This customer selected to go with the side-by-side approach with SAP Treasury and Risk Management on the SAP Cash Management powered by SAP HANA box. The SAP Cash Management powered by SAP HANA components implemented were the Cash Operations and Bank Account Management, both of which are currently live in production. The customer will move forward with the implementation of Liquidity Management this year.

The side-by-side approach selected was the second side-by-side deployment option mentioned in Deployment Options above. With the side-by-side approach, certain data needs to be passed between the two systems (ECC and SAP Cash Management powered by SAP HANA). For the two systems to have all the information needed, SAP standard IDoc interfaces were required to exchange information. Distributed Cash Management used the standard distribution feature based on IDoc technology described in the “Cash Operations” component section of this article. In order for Cash Operations to work properly, the operating information was gathered in ECC, and then periodically transferred to the SAP Cash Management powered by SAP HANA system.

The aspects of Bank Account Management that were important in the first customer implementation were the annual review process and the tracking of the bank account master data information in a central and secure location.

Prior to using SAP’s Bank Account Management, the annual review process was done by email with no built-in audit trail, and standard SAP reporting was not available. It was important

Note!Most companies have an annual or periodic review process of the active bank accounts. In the annual review, information such as signatories and internal contacts for each bank account are reviewed. In addition, companies typically validate that each active bank account needs to remain open.

22




that the process of annually reviewing the active bank accounts was incorporated into workflow, with an audit trail. Now with SAP Cash Management powered by SAP HANA, SAP workflow is used, and with SAP HANA, the workflow can go to either the business user’s company email account or the SAP workflow messages through Business Workplace (transaction code SBWP). As part of the annual review process, the person or people in charge of each account is reviewed, as well as the authorizers on each account. In addition, the active accounts are reviewed to ensure the accounts should remain in place. Fee analysis was not a high-priority factor at that point in time for this customer. (As mentioned above, the Bank Account Management does not support fee analysis.) Prior to using Bank Account Management, this customer did not have a secure system in which to store bank account information centrally.

Here we mention some lessons learned from this first customer implementation:

• Be sure to include all people or departments involved in the decision before jumping in. Some parts of the organization were keen to move forward at a rapid pace, leaving other parts of the organization lagging on getting fully on board.

• The SAP contract signing process takes time. Make sure a sufficient amount of time is included for this within the project timeline.

• This is new functionality being released by SAP, and there are many SAP notes that go along with it. SAP Cash Management powered by SAP HANA is not as easy or fast to roll out as a module in ECC, which is understandable. A buffer in the project timeline should be included because this is new functionality from SAP.

• Although the SAP Note issues were not always resolved quickly, SAP was fully dedicated to the success of the project. There was direct communication between SAP and the implementation team during the implementation of the project.

• The customer did not have an on-premise SAP HANA landscape when starting the SAP Cash Management powered by SAP HANA project. Therefore, the customer used SAP’s HEC to start the project sooner, with the expectation of moving to an on-premise system when it became available. When the on-premise SAP HANA landscape was ready to use, moving from the SAP HEC to the on-premise system was technically difficult to do, and this caused a delay in the project timeline. The difficulties, for the most part, were related to the SAP HANA database setup. Another factor was that the SAP HEC environment was set up by SAP prior to the project; therefore, the project team did not have all the expertise needed for a swift transition. Overall, using the HEC environment was a good decision. It was because of the HEC environment that the project was able to start sooner. Unfortunately, those gains were lost with the technical issues encountered when moving from the HEC to the on-premise system.

• Along the lines of the first lesson, stakeholder management cannot be underestimated.

23




Here is a list of the Fiori applications that are provided with each of the SAP Cash Management powered by SAP HANA components.

Cash Operations:

• Bank Statement Monitor

• Cash Position

• Cash Position Details

• Analyze Payment Details

• Make Bank Transfer

• Track Bank Transfers

• Approve Bank Payments

• Bank Risk

• Payment Statistics

Liquidity Management:

• Develop Liquidity Plans

• Display Liquidity Plans

• Display Liquidity Forecast

• Display Cash Flow

Bank Account Management:

• Manage Bank Accounts

• My Sent Requests

• My Bank Account Worklist

• Maintain Signatory

• Initiate Review Process

• Monitor Bank Account Review Status

• Create Bank

• Change Bank

• Manage House Banks



Title of article

• Bank

• House Bank

• House Bank Account

The link below is a listing of the Fiori apps by category and then by role.

https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/

Mary Loughran has been specializing in the SAP Financials area since 1997 and has worked with numerous clients throughout North America and Europe in the areas of finance and treasury. She was employed as a consultant with SAP America and was a designated expert within SAP America for treasury before she left SAP in 2004. Mary’s expertise is in the areas of SAP Treasury and Risk Management, SAP In-House Cash, Liquidity Planner, Accounts Payable, payments from SAP in general, Cash Management, and Electronic Banking. Mary was an independent consultant from 2004 to 2016 and has recently joined Hanse Orga Group.

Jochen (Joe) Stiebe has more than 17 years of experience in the area of Cash, Treasury, and Risk Management for industrial, trading and energy companies as well as for banks and asset management companies. His consulting focus lies both on the realization of SAP-based solutions and on designing and implementing alternative system designs in existing SAP system landscapes. As managing director he is responsible for all business segments of SymQ, which is an SAP consulting company within Hanse Orga Group.

Note!We would like to thank Marco Meyer, Hanse Orga SymQ Project Manager, for the contributions he added to this article.

https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/

lessons learned: the first customer implementation of sap...

Documents