Cash Management: in SAP S/Hana [PDF]

Zitiervorschau

Fº

ESPRESSO

| | | TUTORIALs ==

Cash Management in SAP S/HANA - Principle areas of Cash Management powered by SºHANA

- Deployment options and

- Comparison between ECC and SAP S/4HANA functionality, including an

- SAP Cash Management implementation tips and tricks

overview of release 1.8Lº

implementation steps

Mary Loughran Praveen Gupta

Cash Management in SAP® S/4HANA

Mary Loughran, Praveen Gupta Cash Management in SAP® S/4HANA

ISBN: 978-3-96012-264-7 (EPUB) Editor: Karen Schoch Cover Design: Philip Esch Cover Photo: istockphoto.com | PeteDraper, # 93456124 Interior Book Design: Johann-Christian Hanke

All rights reserved. 1st Edition 2019, Gleichen © 2019 by Espresso Tutorials GmbH URL: www.espresso-tutorials.com

All rights reserved. Neither this publication nor any part of it may be copied or reproduced in any form or by any means or translated into another language without the prior consent of Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Germany. Espresso Tutorials makes no warranties or representations with respect to the content hereof and expressly disclaims any implied warranties of merchantability or fitness for any particular purpose. Espresso Tutorials assumes no responsibility for any errors that may appear in this publication. Feedback We greatly appreciate any feedback you may have concerning this book. Please send your feedback via email to: [email protected].

Table of Contents Cover Title Copyright / Imprint Preface 1 Introduction to S/4HANA 1.1 What is SAP S/4HANA? 1.2 The SAP HANA database 1.3 SAP Fiori 1.4 Universal Journal 1.5 Key advantages of S/4HANA 1.6 Deployment options 2 An overview of Cash Management and Liquidity Planning 2.1 Bank Account Management 2.2 Cash Operations 2.3 Liquidity Management 3 Getting started 3.1 Defining banks 3.2 Defining house banks 3.3 Defining house bank accounts 3.4 Defining G/L accounts 3.5 Summary 4 Bank account management 4.1 Bank account management workflow approval processes 4.2 Payment signatories 4.3 Foreign bank account reporting 4.4 Importing and exporting house bank accounts 5 Bank Communication Management and Multi-Bank Connectivity 5.1 BCM Overview 5.2 BCM Connector 5.3 Multi-Bank Connectivity 5.4 Summary 6 Cash operations 6.1 Cash Operations overview 6.2 Cash balances 6.3 Cash operations configuration 6.4 Summary 7 One Exposure 7.1 One Exposure overview 7.2 Certainty level

7.3 Aggregating flows 7.4 Setting up One Exposure 7.5 Summary 8 Liquidity Management 8.1 Actual Cash Flow Analysis 8.2 Liquidity forecasting 8.3 Liquidity planning 8.4 Liquidity Management configuration 8.5 Summary 9 Overview of Release 1809 9.1 Architecture overview 9.2 Machine Learning Cash Application 9.3 Bank Account Management 9.4 Cash operations 10 Tips, tricks, and other information 10.1 Underlying BAM tables 10.2 Security roles 10.3 SAP Fiori apps library 10.4 Navigating the Fiori launchpad 10.5 Creating your own “favorites” group 10.6 SAP NetWeaver Business Client 10.7 Definition of terms 10.8 Useful SAP notes A The Authors B Disclaimer Endnoten

Thank you for purchasing this book from Espresso Tutorials! Like a cup of espresso coffee, Espresso Tutorials SAP books are concise and effective. We know that your time is valuable and we deliver information in a succinct and straightforward manner. It only takes our readers a short amount of time to consume SAP concepts. Our books are well recognized in the industry for leveraging tutorial-style instruction and videos to show you step by step how to successfully work with SAP. Check out our YouTube channel to watch https://www.youtube.com/user/EspressoTutorials.

our

videos

at

If you are interested in SAP Finance and Controlling, join us at http://www.fico-forum.com/forum2/ to get your SAP questions answered and contribute to discussions. Related titles from Espresso Tutorials: Lennart B. Ullmann & Claus Wild: Electronic Bank Statement and Lockbox in SAP® ERP Ashish Sampat: First Steps in SAP® Controlling (CO) Janet Salmon & Ulrich Schlüter: SAP® Ann Cacciottolli: HANA for ERP Financials, 2nd edition

First Steps in SAP® Financial Accounting (FI) Janet Salmon & Claus Wild: First Steps in SAP®S/4HANA Finance Mary Loughran, Lennart Ullmann: Guide to SAP® In-House Cash (ICH)

LEARN SAP ANYTIME, ANYWHERE, AND ON ANY DEVICE

Provide effective SAP training for your team without travel costs and external trainers

150+ eBooks and Video tutorials

Try affee 7-day no obligation trial http://free.espresso-tutorials.com

* Regularly updated with nEW COſilent

• Access via web browser or app (OSAndroid) * Pricing based on number of users

Gela quote for your team today. http://company.espresso-tutorials.com

Preface This book is intended to give business users, SAP support staff, and SAP consultants an introduction to the functionality included in SAP’s Cash Management powered by S/4HANA, and we outline the many benefits of implementing it. Throughout this book, we have focused on release 1709 of S/4HANA, but we have included an introduction to the functionality new to release 1809 in a later chapter. Chapter 1 provides a brief introduction to S/4HANA and the great transformation SAP has made. Although deployment options are covered in this initial chapter, the main functionality we discuss is based on SAP’s on premise solution. In An overview of Cash Management and Liquidity Planning, we then introduce the three principal areas of Cash Management powered by S/4HANA. There are many changes for users moving from SAP ERP Central Component (ECC) to S/4HANA, so we have written Getting started as a gradual introduction to the world of S/4HANA Cash Management. In subsequent chapters, each of the areas of Cash Management powered by S/4HANA are detailed separately. Each of these chapters starts with the business functionality, followed by the associated configuration. We cover the areas of Bank Communication Management and Multi-Bank Connectivity, Cash operations, One Exposure, Liquidity Management, Overview of Release 1809, and Tips, tricks, and other information; all of which help users to better understand the full scope of functionality that SAP offers. A special thank you goes to everyone at Espresso Tutorials who made this book possible. We sincerely hope you find this book useful. We have added a few icons to highlight important information. These include:

Tip

Tips highlight information concerning more details about the subject being described and/or additional background information.

Example Examples help illustrate a topic better by relating it to real world scenarios.

Warning Warnings draw attention to information that you should be aware of when you go through the examples from this book on your own.

Finally, a note concerning the copyright: All screenshots printed in this book are the copyright of SAP SE. All rights are reserved by SAP SE. Copyright pertains to all SAP images in this publication. For simplification, we will not mention this specifically underneath every screenshot.

1 Introduction to S/4HANA There are many aspects of the SAP landscape that change when moving from an ECC environment to an S/4HANA environment. Before we move forward to look at the new HANA Cash Management functionality, let’s take a step back and discuss exactly what S/4HANA is. In this chapter, we introduce S/4HANA and its key components. We also cover the key advantages of S/4HANA and its deployment options. The changes in landscape are relevant to the Cash Management functionality. In the next chapter, we move into the specific changes in the Cash Management functionality. 1.1 What is SAP S/4HANA? SAP S/4HANA is SAP’s next generation business suite designed to help its customers “Run Simple” in a digital and connected world. This new suite is built on an in-memory data platform, SAP HANA, and offers a personalized user experience with SAP Fiori. The SAP S/4HANA business suite is built natively and optimally to run only on an SAP HANA platform. A brand-new user experience, SAP Fiori has been delivered to improve the productivity and satisfaction of business users and it brings the interface up to a current generation experience optimized for any device (e.g. laptop, smartphone and tablet). It is truly monumental that a forty-year-old software company, with a customer base the size of SAP’s, can make the significant generational changes to its product that SAP is making at this time. SAP S/4HANA is SAP’s take on leveraging the advancement in technologies, such as powerful multicore processors, huge memories, optimized cache, and cloud computing etc., in order to re-write and design their business application software, and bring it to the next generation of technology, thereby making it mobile. In addition, with these changes, SAP can offer several different deployment options to its current and future customer base. The diagram in Figure 1.1 shows the progression of SAP’s different platforms throughout the years.

Figure 1.1: Progression of SAP platforms

Table 1.1 outlines the progression and advancements of SAP software. Product

of Year

Description

rollout SAP R/2

1979

Standard business software based on mainframe technology. R stood for real time.

SAP R/3

1992

SAP ERP

2004

Based on client server architecture/three-tier approach (database, application and user interface) A new integration application platform called SAP NetWeaver to better integrate business applications and web. Architectural changes were made to support transition from an enterprise service architecture to a service-oriented architecture.

S/4HANA 2015 SAP

A new business suite built on in-memory data platform, SAP HANA, offering a personalized user experience with SAP Fiori and various on-premise, private/public cloud deployment options.

Table 1.1: Progression of SAP software

1.2 The SAP HANA database SAP HANA is a relational database management system (RDBMS). Its primary function as a database server is to store and retrieve data as requested by the applications. In addition, it performs advanced analytics and includes Extract, Transform, and Load (ETL) capabilities, as well as an application server. Traditional business applications were built on a hierarchical data model where transactions were aggregated to a higher level and then extracted from a transactional system to a reporting system. This was primarily because a database model was either built for OLTP (online transaction processing) optimization or OLAP (online analytical processing) optimization, but not both. SAP HANA can handle both transactional processing and analytical processing. It combines OLAP and OLTP processing into a single in memory database, eliminating bottlenecks and offering significantly improved performance. SAP HANA has the power to calculate on the fly, which means transactional and analytical applications run off the same tables; data is therefore available in real-time at every level of detail. 1.3 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, are browser based and are able to run on any device (laptop, tablet and smartphone). This is a key improvement for SAP. The Fiori apps are clean, easy to use, and user friendly. Fiori offers a user-definable dashboard, referred to as the launchpad, to role-based functionality. With S/4HANA, the functionality is delivered via applications or apps (also known as tiles), as opposed to by

programs or transaction codes. There are three types of Fiori apps: 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). The SAP Fiori launchpad is a single-entry point for users to access the system. It is user-specific, role-based and customizable. End users have the ability to customize what they would like to see on their home screen. They also have access to a search function where they can look up applications, provided they have access. Using the SAP Fiori launchpad designer, a system administrator can design custom themes (branding) for the launchpad. Figure 1.2 shows a sample SAP Fiori launchpad.

Figure 1.2: Sample SAP Fiori launchpad

1.4 Universal Journal When you hear ACDOCA, think Universal Journal in S/4HANA. ACDOCA is the name of the finance module’s important new S/4HANA table, which is based on the Universal Journal line items. It contains all of the financial fields, as well as considerable information from other modules. In addition, controlling data is stored in the same ACDOCA table. Due to its raw power, SAP HANA can aggregate on the fly. Therefore, aggregate tables are no longer required. Indexes are not required either because SAP HANA is a column database (i.e. data is stored in columns instead of rows). In order to simplify the overall data structure and make use of available capacity, index tables such as BSIS, BSAS, BSID, BSAD, BSIK, BSAK, BSIM, FAGLBSIS and FAGLBSAS, as well as aggregate tables such as GLT0, GLT3, FAGLFLEXT, KNC1, LFC1, KNC3, LFC3, COSS, and

COSP are no longer required and have been removed. FAGLFLEXA and some other New GL tables are now obsolete and there are also new customizing tables. Keep in mind that customers who have developed custom ABAP reports that query the tables listed above, can continue to run on S/4HANA because there are compatibility views with the same names as the tables; they recalculate the same values as the tables do, allowing any bespoke programs reading that information to continue to function. With SAP HANA, SAP has developed a new data modelling infrastructure called Core Data Services (CDS). CDS is an extension of the ABAP dictionary that allows you to define semantically rich data models in the database and use them in your ABAP programs. With CDS, data models are defined and consumed on the database layer instead of on the application server. 1.5 Key advantages of S/4HANA To summarize, some of the key advantages of S/4HANA are: ability to run analytics and reports directly from an SAP transactional system reduced data footprint due to simplified SAP HANA database improved user experience with SAP Fiori ability to access SAP from a mobile device (smartphones/tablets) cloud-based solutions with multiple and flexible deployment options new business functionality The diagram in Figure 1.3 shows the key advantages of S/4HANA.

Figure 1.3: Key advantages of S/4HANA

1.6 Deployment options SAP has introduced numerous deployment options with SAP S/4HANA. For example, SAP has on-premise, public cloud, private cloud, and hybrid landscapes. With the ability to combine landscapes, SAP customers can tailor their landscapes to their specific business needs. Companies that do not want to support their SAP infrastructure can go with publicly or privately hosted options. The infrastructure can be hosted by SAP or by a third party. Gone are the days when SAP was a product only for larger, multinational companies. SAP S/4HANA provides a wide choice of landscapes, making it an option for companies of all sizes. Originally introduced in 2015, by 2025 all SAP customers globally are expected to be on S/4HANA. SAP S/4HANA Cloud runs on SAP-managed and SAP-operated infrastructure. SAP provides functional and non-functional innovations, inclusive of software corrections, which are applied quarterly. The cloud edition is available in two offerings: private cloud and public cloud. A significant difference between the public and private clouds is how much flexibility the customer has in making configuration changes and in implementing custom functionality. Basically, with the public cloud, SAP standard functionality must be used (no user exits or custom programs), there is a limit to what configuration tables are able to be updated, and Fiori apps must be used for all processing, as opposed to using the SAP GUI interface for some processing. On-premise editions provide the maximum control and flexibility. The

reasons most customers give for deciding to use the cloud solution is that they want to get rid of all the customization and maximize efficiency during implementation and upgrades. It is important for customers to understand that they do not have access to the Implementation Guide (IMG) in the public cloud edition. Below are different deployment options and aspects of each option. The following are the benefits of on-premise options: This option is most similar to traditional ECC implementations. traditional licensing customer’s choice for hosting infrastructure, e.g. customer’s own infrastructure or hosted by third party are two possibilities complete control of deployment and maintenance flexibility and control of configuration and enhancements can accommodate highly customized solution higher ongoing maintenance costs Cloud options These options offer Software As A Service (SAAS) and are new with S/4HANA. The benefits of a private cloud (typically single-tenant) are: resources dedicated to one customer accessed through a Virtual Private Network (VPN) owned, managed and operated by the customer, a third party, or both customer-specific functionality is possible Hybrid cloud

resources a mix of two or more distinct clouds integrated by standardized or proprietary technology enabling data and application portability Public cloud (aka multi-tenant)

resources shared by multiple customers accessed via the Internet self-service access and tools

on the premises of the third-party cloud provider (not customer) less flexible for customer-specific functionality Figure 1.4 shows the different deployment options.

Figure 1.4: SAP deployment options

The SAP Public Cloud, currently referred to as multitenant, enables SAP customers to access the newest functionality on a quarterly basis. Because SAP maintains the system, SAP does quarterly updates. SAP customers no longer need to go through the upgrade process. This is a big advantage. An aspect of the public cloud that may not work for larger organizations is the lack of flexibility in customizing the system to their needs. The SAP Public Cloud is referred to as ‘fit-to-standard’, meaning SAP standard functionality must be used, with very little possibility to tailor the solution to a company’s specific needs. An important aspect to note about the SAP Public Cloud is that customers do not have access to the IMG in the cloud edition. The personalization of an SAP S/4HANA cloud solution is done with a self-service configuration SAP Fiori Uniform Resource Identifier (URI) which can be found in the Manage Your Cloud User Interface in the SAP S/4HANA solution. That means that the flexibility of the SAP Public Cloud solution is defined by self-configuration SAP Fiori URIs. The access is only to specific configuration nodes that are made available by SAP through self-service configuration. 1.6.1 Hybrid cash management landscape example

An example of a hybrid landscape is one where most of a company is on the SAP public cloud, but the cash management and treasury functionality is on the on-premise S/4HANA system running SAP Cash Management solution on HANA, as a treasury work station (TWS). The landscape could work as follows: The TWS has the full chart of accounts, accounting exchange rate data, and roughly the same Finance and Controlling (FICO) configuration as in the cloud. The on-premise treasury system has development, Quality Assurance (QA) and production systems. There is no “starter system” for treasury, like there is for the cloud. The cloud is the general ledger system of record, and the TWS is the system of record for house bank account information (bank account management information). There are interfaces, also called Application Programing Interfaces (APIs), between the SAP public cloud and the treasury system to keep certain data in-sync. The cloud to TWS on-premise interfaces are as follows: operate cash flows from the cloud (One Exposure data) replicate exchange rates API (CO_FNDEI_EXCHANGERATE_RL) Accounts payable (AP) payment file sent to on-premise for approval and centralized reporting (manual placement of an AP file to on premise BCM_IN directory) G/L master data changes (e.g. new G/L accounts). On-premise to cloud interfaces are as follows: on-premise postings using API (Post Journal Entry Requests API) house bank account details (Manage Bank Accounts connectivity path —for the link to the house bank ID, account ID and G/L account), and signatories should be in-sync between the two systems. This is very static data. The house bank account system of record is on-premise. As the controlling data for Treasury is typically limited and static, the profit centers and cost centers related to treasury postings could be created manually in the TWS on-premise instance. For treasury in the cloud, the process is: AP payment processing (ACH, checks and wires) creation of AP XML files for ACH, checks and wires

lockbox processing prior day bank statement processing (with postings) importing of daily cashed check files operations processing (sales orders, purchase orders, etc.) For on-premise treasury, the process is: cash positioning cash forecasting intraday bank statements treasury payments

1.6.2 Side-by-side cash management scenarios Other common hybrid deployment options used with SAP Cash Management powered by SAP HANA are the side-by-side (sidecar) options, shown in Figure 1.5. One of these landscapes is 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 or Treasury functionality are moved to SAP HANA.

Figure 1.5: Side-by-side scenarios

When using 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 Cash Management. When using this, SAP Cash Management is activated in ECC, and the SAP system collects data from the relevant (configured) modules (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 IDocs (Intermediate Document). 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 corresponding tables on SAP Cash Management powered by SAP HANA (One Exposure). Factors that should be considered during a side-by-side implementation include: if and how to integrate AP and treasury payments—for example, AP payments are to be made from ECC. If treasury payments are made from SAP Cash Management powered by SAP HANA, a decision needs to be made whether payments should be merged before they are sent to the bank, or 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 whether the electronic bank statements should be imported into the SAP Cash Management powered by SAP HANA system for balance information or the balance information should transfer from the ECC system When designing deployment landscapes, companies also need to consider when they plan to move to the all-in S/4HANA system. If the second side-by side approach is selected, In-House Cash, SAP Bank Communication Management, and SAP Treasury and Risk Management do not need to be migrated into the S/4HANA system (because they are already on S/4HANA).

2 An overview of Cash Management and Liquidity Planning With the many changes involved in an SAP S/4HANA implementation, it is critical to understand the new functionality and the different options customers have in using it. In this chapter, we provide an overview of the three components of SAP Cash Management on S/4HANA. We introduce the reader to what has changed and what has stayed the same. Subsequent chapters describe the functionality in more detail. SAP’s Cash Management powered by SAP HANA (also known as Cash Management on HANA and Advanced Cash Management and CM on HANA) is a suite of programs including Cash Operations, Bank Account Management (BAM), and Liquidity Management that upgrade the cash and liquidity management functionality in ECC. The Cash Operations and Liquidity Management components enhance existing ECC functionality with improvements in functionality and the introduction of Fiori tiles. The Bank Account Management component is completely new with S/4HANA. Figure 2.1 shows where the components of SAP Cash Management powered by SAP HANA fit within the end-to-end Treasury and Risk Management solution map.

Figure 2.1: SAP Treasury and Risk Management solution map

With the move to SAP Cash Management powered by SAP HANA, SAP has

significantly changed the user interface, and has upgraded the functionality in certain areas. Another change we notice in the area of Cash Management is a move from configuration to application-side processing. This is seen with the move from house bank accounts being an IT configuration step in ECC to master data in S/4HANA. There are other examples of this, which we cover throughout the book. Next, we take a cursory view at each of the components of SAP Cash Management powered by SAP HANA. Subsequent chapters are devoted to exploring the functionality of each of the components in detail. 2.1 Bank Account Management The Bank Account Management suite of applications is the third component in SAP Cash Management powered by SAP HANA. It is all new functionality relating to bank account management processes. Bank Account Management is a structured process to implement governance structures in order 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 SAP. Prior to the release of Cash Management on HANA, this was a gap in the functionality provided by SAP. The most visible change in this area is that managing bank accounts is now part of master data, managed by business users, instead of a configuration activity as in a classic SAP ECC system, where it is an IT task. The process of creating bank accounts and the types of data tracked with those bank accounts is new. Now, all relevant information about the bank account can be captured, such as: the status of the bank account, the company code, the owner’s 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). Another welcome improvement is the ability to upload and download bank account data from/to Excel. In addition to bank account management, the solution includes an optional workflow-based governance on opening, changing, and closing accounts. It also includes a bank hierarchy view and bank account group view, a signatory process, overdraft limits and a bank account review process. Figure 2.2 shows the Bank Account Management features.

Figure 2.2: Features of SAP’s Bank Account Management

For bank account management processes, SAP has given customers two options. The first is comprehensive Bank Account Management, which is part of the separate license of SAP S/4HANA Finance for cash management. The second option is Bank Account Management Lite, which comes preinstalled with SAP S/4HANA Finance (i.e. no separate license is required). 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 can follow how the cash is consolidated or concentrated. For SAP customers who go with the comprehensive Bank Account Management option, companies can have an annual review process to

analyze the current bank accounts, which is supported by the Bank Account Management component. There is typically a person or group in the company who is/are responsible for each bank account. This information is stored in Bank Account Management and is included in the annual review process. A very useful feature of this new functionality is the integration of the bank account data definition with the cash pooling or cash concentration for the accounts. When 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. There are other differences between the lite version and comprehensive version that are detailed in SAP Note 2165520—“Feature Scope Differences Between Bank Account Management and Bank Account Management Lite”. Figure 2.3 shows an overview of the different components of Cash Management on HANA.

Figure 2.3: Overview of SAP Cash Management Powered by SAP HANA

2.2 Cash Operations The Cash Operations component contains a number of Fiori apps to be used in day-to-day cash management processing. The Cash Operations component covers bank statement monitoring, the review of bank account balances in the cash position report, bank transfers, and approval of payments. The apps have a completely new look and feel. Figure 2.4 shows the new Cash Position app tile.

Figure 2.4: Cash Position app tile

Cash Position tile KPI warning The Cash Position KPI tile can be misleading because it pulls information from One Exposure that contains cash position as well as liquidity management data.

As mentioned in the previous chapter, there are three types of Fioritiles, one being the key performance indicator (KPI) Fiori apps. There are two KPI tiles delivered with the Cash Operations component: the Bank Statement Monitor, which shows the bank statement import status, and the Cash Position app, which gives a high-level view of account balances. The tiles provide cash managers with KPI information. An example is shown in Figure 2.5; with a simple glance, users can see the percentage of bank statements that require processing.

Figure 2.5: Example of a KPI tile

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 a bank-to-bank transfer (transaction code FRFT_B) on ECC. With the Make Bank Transfer app, cash managers can quickly enter a bank

transfer. Because SAP is an integrated system, when the payment is saved, it is immediately reflected in the Cash Position report. With SAP Cash Management powered by SAP HANA, SAP gives its customers the option of using the older version of the cash position report driven by Cash Management Groupings, planning levels, and planning groups. Why would customers use the older functionality? There could be two possible reasons. First, the CM groupings, which group bank accounts into views, are no longer used as they were being used in ECC. To view a specific set of bank accounts at a time, SAP Cash Management powered by SAP HANA uses field filters. For companies with multiple bank accounts, viewing the cash position across all bank accounts may not be convenient. Another difference is the Cash Management Account name is no longer part of SAP Cash Management powered by SAP HANA. It would be unusual for customers to not go with the upgraded cash position report; however, this is possible, which is why it is pointed out here. SAP customers can implement the basic SAP S/4HANA Finance for cash management functionalities in order to continue using the cash management features offered by the classic ECC system without requiring any additional license for SAP S/4HANA Finance for cash management. Refer to SAP Note 2376432—“How to Implement Basic Cash Management in SAP S/4HANA On-premise Edition 1610”. 2.3 Liquidity Management The next suite of applications in Cash Management powered by SAP HANA is Liquidity Management, which brings together mid-term to long-term planning and actuals determination, to provide actual-to-plan, plan-to forecast, and plan-to-plan variance analysis reporting. SAP differentiates cash flow management into short-term, mid-term, and long-term time segments. In terms of short-term planning, SAP uses the term “cash positioning”, which can be one to five days out. This reporting is done in Cash Operations. The ECC Liquidity Planner module, which calculates the uses and sources of cash, has been repackaged as the Cash Flow Analysis report in Liquidity Management. The Liquidity Management component also covers mid-term to long-term forecasting and planning. The above-mentioned terms are displayed in Figure 2.6.

Figure 2.6: Cash Management planning horizons

Plan data versus forecast data The difference between plan data 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.

Below are a few of the reporting apps available in Liquidity Management: Liquidity Forecast Liquidity Forecast Detail Actual Cash Flow Cash Flow Detail Analysis A significant improvement in this area is the way in which SAP stores the cash flow-related data. SAP has redesigned how data is stored and has created One Exposure, which is the central storage of all actual and forecast operational business transactions. Because forecast data and actual data is

all stored consistently in One Exposure, the different data has the same granularity, which is required when doing forecast-to-actual and year-over year (YoY) comparison reporting. This is a key improvement over ECC where data to be compared was not at the same level of granularity.

3 Getting started Before moving on to the details of the different areas of Cash Management on HANA, let’s take a step back and look at some of the basic changes SAP made with the move to S/4HANA that impact multiple areas of Cash Management on HANA, and that will impact all SAP ECC users moving to S/4HANA. In this chapter, we cover the initial steps required for basic management of banks, house banks, and house bank accounts in S/4HANA. The more complex features such as workflow and integration with Bank Communication Management (BCM) are covered in later chapters. 3.1 Defining banks There are two Fiori apps that can be used to define bank master data, as illustrated in Figure 3.1.

Figure 3.1: The Manage Banks apps

The Manage Banks—Basic app contains the same fields available in the ECC FI01/FI02 transaction code. The Manage Banks app has all the fields available in ECC FI01/FI02, as well as new, additional fields. We recommend using the Manage Banks app. In S/4HANA, as in ECC, bank data is initially loaded with an external bank data file. The bank data load file can come from a number of different sources such as SWIFT, Accuity, the U.S. Federal Reserve, etc. The SAP Country-Specific Transfer of Bank Data (transaction code BAUP) can be used to import the file into SAP. Keep in mind that the SAP GUI programs Create Bank (transaction code FI01) and Change Bank (transaction code FI02) can continue to be used to maintain banks in SAP, and the existing process can continue to be followed to create bank data in SAP. This functionality is typically limited to specific

users because the data entered in the bank data is included in payment files generated from SAP. The screenshot in Figure 3.2 shows the house bank information that is displayed in the Fiori Manage Banks app. Note that there are two new pieces of information that were not available in ECC: a link to the business partner and bank risk information.

Figure 3.2: Display Bank screen

3.2 Defining house banks 3.2.1 Defining house banks through Fiori SAP has added new functionality and several new features to the house bank definition, which are outlined in this section. Banks and house banks can now be created using the Manage Banks app, which is different to the corresponding process in ECC. In ECC, the programs are Create Bank (transaction code FI01), Change Bank (transaction code FI02) and Change House Banks/Bank Accounts (transaction code FI12) to maintain house banks. First, the transaction code used to create house banks in configuration has moved from transaction code FI12 to FI12_HBANK. FI12_HBANK can still be used to create house banks, but house bank accounts now need to be created through the Manage Bank Accounts Fiori app. Transaction code

FI12 is obsolete in S/4HANA and Display House Banks (transaction code FI13) is now FI13_HBANK. Figure 3.3 shows the definition of a house bank via the SAP GUI.

Figure 3.3: Definition of a house bank using FI12_HBANK

Figure 3.4 shows the definition of a house bank via the Fiori Manage Banks app.

Figure 3.4: Definition of a house bank via the Fiori Manage Banks app

When executing FI12 through the SAP GUI in S/4HANA, users see the message shown in Figure 3.5.

Figure 3.5: Message when executing FI12

FI12

You may want to implement SAP Note 2646577—“Re enabling of Transaction Code FI12 for maintaining House Banks”—to re-activate transaction code FI12.

The screenshot in Figure 3.6 shows a defined bank that does not (yet) have a corresponding house bank. Note that the bank Wells Fargo has been created but there are zero corresponding house banks.

Figure 3.6: Display Bank screen

To create a house bank for the example bank above, press the EDIT button in the lower right corner of the screen (not shown here). The screen then on changes the toicon. EDIT BANK, as shown in Figure 3.7. To create a house bank, click

Figure 3.7: Create house bank

As in ECC, a five-character house bank ID is used to define a house bank. Users can also enter optional information such as the company number and customer number. The company number is an ID that is assigned to the payment-initiating entity by the banks for non-urgent payments in the U.S. The customer number can be used to identify the initiating party in payment files. These fields are displayed in Figure 3.8.

Figure 3.8: Create house bank screen

Pressing the icon in the upper left corner of the screen takes you back to the DISPLAY BANK screen where the HOUSE BANKS tab now shows the house bank account you just defined (see Figure 3.9).

Figure 3.9: Display house banks tab

One key improvement in the design of house banks is that a house bank can now be linked to a business partner. This allows customers to group house banks. For example, with this new feature, Citi Group can now be represented as a group of all Citibank branches globally where a company has bank accounts. This facilitates the viewing of cash balances across banks.

Link to Business Partner

By selecting LINK TO BUSINESS PARTNER in change mode, the system automatically creates a business partner for the bank with the roles shown in Figure 3.11.

It is possible to drilldown to the business partner representing the bank from the Manage Banks app, as shown in Figure 3.10.

Figure 3.10: House bank Business Partner display

The business partner is created with three roles assigned: BANK, BUSINESS PARTNER (GEN.), and FINANCIAL SERVICES BP (see Figure 3.11).

Figure 3.11: House bank Business Partner roles

It is now possible to easily link house banks to each other using the RELATED BRANCHES tab, which is shown in Figure 3.12.

Figure 3.12: Linking house banks to each other

A particularly useful feature is the additional information available by pressing F1 help. All Fiori apps have a help screen display like the one shown in Figure 3.13.

Figure 3.13: F1 help available with Fiori

As discussed previously, house banks can be defined using the Change House Banks program (transaction code FI12_HBANK) in SAP GUI, which moves the house banks between SAP systems in a transport. However, to utilize all the additional capabilities provided by SAP, we recommend updating house banks using the Manage Banks Fiori app where users can assign business partners and risk ratings. 3.3 Defining house bank accounts With the move to S/4HANA, SAP changed house bank accounts from being a configuration step to being master data. With this change, the transaction code FI12 is no longer used. Users can still use FI01 to create banks and FI12_HBANK to create house banks. Users must define house bank accounts on the Connectivity Path tab of the Manage House Bank Accounts app.

Before moving forward, let’s review the definitions of a house bank and a house bank account. A house bank is a bank where the SAP customer has bank accounts. This is typically an external bank, but in the case of In-House Cash, could also be an internal bank. A house bank ID (up to five characters) is created to represent the bank; for example, JPMC1, BONY1, or BANK1. The house bank ID is assigned to a company code. A house bank account is a bank account at the house bank. A house bank account ID (up to five characters) is created to represent each bank account; for example, 39403, USD01, ACCT1. Both the house bank ID and house account ID are free-form alphanumeric IDs. In ECC, the house bank account is defined first in configuration, and moves through the system landscape in a transport, along with the other customization for the new house bank ID; for example, payment program and electronic bank statement customization. House bank accounts are created through the Manage Bank Accounts tile (see Figure 3.14).

Figure 3.14: Manage Bank Accounts tile

Once in the app, click on the “…” (more) button, then select the CREATE OBJECT button (see Figure 3.15).

Figure 3.15: Create house bank account button

You are then taken to the screen shown in Figure 3.16, where the most basic details of a bank account are entered.

Figure 3.16: Bank account header information

The account holder fields allow you to set a different company code name to the bank account name. In ECC, the bank account name is driven from the company code name, which is set in configuration. Under the GENERAL DATA tab, there are new fields that can be tracked with the house bank account (see Figure 3.17).

Figure 3.17: Bank account General Data information

The bank relationship tab is shown in Figure 3.18.

Figure 3.18: Bank Relationship screen

Under G/L ACCOUNT the CONNECTIVITY are assigned PATH (see tab, Figure the HOUSE 3.19). The BANKdefinition ACCOUNTofand a G/L associated account is described in Section 3.4. The ID CATEGORY and REMOTE SYSTEM fields in the CONNECTIVITY PATH tab contain the type of ERP system and the logical ID of the system in which the bank account is operational. These fields are used in the case of a multiple system landscape, and CM on HANA is the centralized Cash Management system.

Figure 3.19: Connectivity Path data

A signatory can be used to approve bank account management and to approve payment. However, this may not be consistent with the business requirements; in most organizations, it is not the same person who performs both these tasks. The signatory group and signatory (user) are assigned together with the maximum approval amounts for payments and batches, and the validity date range for approval processing (see Figure 3.20).

Figure 3.20: Screen to assign payment signatory

Additional approvers are assigned by pressing the Figure 3.21.

icon, as shown in

Figure 3.21: Add an additional approver

When complete, press SAVE in the lower right corner of the screen, as shown in Figure 3.22.

Figure 3.22: Save house bank account definition

If the DRAFT SAVED button is selected instead of SAVE, the bank account is created in an inactive status. After saving, press the EDIT button, shown in the top right corner of Figure 3.23, to enter additional details such as the IBAN.

Figure 3.23: Bank Account View

After entering the account number and bank information, press the IBAN button and the system populates the IBAN field, as shown in Figure 3.24.

Figure 3.24: Calculating the IBAN number

3.3.1 The Bank Group field The BANK GROUP field is a new field in the bank master data that can be used to group banks together using the Manage Banks app. The BANK GROUP field is a two-character, free-form identifier, as shown in Figure 3.25.

Figure 3.25: Bank Group field

The bank group can be used as filter in the reports to list banks that belong to the same group. To add the BANK GROUP field as a filter in the Manage Banks app, press the button, as shown in Figure 3.26.

Figure 3.26: Adapt filter option

The screen shown in Figure 3.27 then appears. Select the BANK GROUP option to add the bank group as a filter.

Figure 3.27: Add bank group as filter

In our example, we have used US as the bank group to group all US banks together. Figure 3.28 shows the banks that belong to the US BANK GROUP.

Figure 3.28: Bank Group US listing

3.3.2 House bank and account reporting The Manage Banks app has additional, built-in house bank account reporting, which is very useful. As shown in Figure 3.29, users are able to view the banks that are also defined as house banks, as well as the number of bank accounts associated with each.

Figure 3.29: House bank and account reporting

Users can click on the text written in blue, which are links, to easily display the specific bank accounts (see Figure 3.30). This type of reporting and the ease of use is not available in ECC.

Figure 3.30: Bank account listing

3.3.3 House bank account creation process flow With the creation of house bank accounts now being a master data element, as opposed to an IT configuration step, the process flow of creating house bank accounts has changed, as shown in Figure 3.31.

Figure 3.31: House bank account creation process flow

The last step in the process is to set the bank account to ACTIVE status. The bank account should be set to ACTIVE status only after the house bank account ID has been defined and the configuration needed to process the

bank account is in the production system. 3.3.4 Bank account statuses With S/4HANA, three statuses have been defined to track house bank accounts in SAP: INACTIVE, ACTIVE, and CLOSED. We recommended setting bank accounts to INACTIVE status during the creation process. Once all the configuration and testing has been completed and moved to production, the bank account can be set to ACTIVE and can then be used in processing. Additional functionality introduced in S/4HANA is the ability to close a house bank account using the Manage Bank Accounts app (see Figure 3.32). Note that before a bank account can be closed, the balance in the account must be zero.

Figure 3.32: Manage Bank Accounts app tile

After selecting the app, press the GO button to view a listing of the bank accounts in SAP. From the list of bank accounts, select the account to be closed (see Figure 3.33).

Figure 3.33: Active account to be closed

In the bank account screen, select the CLOSE option from the dropdown menu in the upper right corner of the display, as shown in Figure 3.34.

Figure 3.34: Select Close from the dropdown menu

A popup window appears, in which the close date and time can be entered, as shown in Figure 3.35. Note that the time is optional. Next, click on the CLOSE button.

Figure 3.35: Set date of account closing

You then see a message, like the one shown in Figure 3.36, indicating that the account has been closed.

Figure 3.36: Account closed message

At this point, the bank account is displayed in the Manage Bank Accounts app with a status of CLOSED, as shown in Figure 3.37.

Figure 3.37: Account shown with closed status

Once a bank account is closed, it should not appear in the cash position. 3.4 Defining G/L accounts With the definition of house bank accounts, a main G/L account is assigned to the house bank account definition. The G/L account can be created in S/4HANA using the SAP GUI, assuming the SAP GUI is in-scope for the project, or it can be created using the Manage G/L Account Master Data tile (see Figure 3.38).

Figure 3.38: Manage G/L Account Master Data tile

The definition of the G/L account in S/4HANA is the same as in ECC, and the cash management and house bank account settings on the CREATE/BANK/INTEREST tab of the G/L master record in S/4HANA are also the same as in ECC. There are useful information displays that are new to the Fiori interface; for example, users can see the list of company codes where the G/L exists, as well as the settings in each of those company codes (see Figure 3.39). This display is not possible in ECC. The Fiori apps provide a much more user friendly interface.

Figure 3.39: G/L company code data

In S/4HANA, as in ECC, it is easy to copy from an existing G/L account to create a new G/L account using the Manage G/L Account Master Data tile (see Figure 3.40).

Figure 3.40: Copy from G/L account functionality

3.5 Summary The information that is available within the bank, house bank and house bank account definitions has changed considerably with the move from ECC to S/4HANA. Banks and house banks can still be created using the SAP GUI but the creation of house bank accounts has moved from an IT configuration task to a business user master data task. However, be aware that the creation of bank accounts directly in production does not mean they can be used for processing. They can only be used for processing after the electronic bank statement and payment-related configuration have also moved to the production system.

Below is a summary of the key changes relating to bank, house bank and bank accounts: Banks can be grouped using a two-character free-form identifier that can be used for reporting. A risk rating can be assigned to a bank and is used for the Bank Risk app. Banks can now be linked to a business partner. Banks can also be linked to another bank using the Related Branches functionality. There are three statuses to track house bank accounts: INACTIVE, ACTIVE and CLOSED. Payment signatory information can be stored at the house bank account level, which can be used for payment approval, and is integrated with BCM. A bank account now has a new ACCOUNT HOLDER field that allows a bank account holder name to be different to the company code name. Reporting features have been enhanced.

A new risk Now that the creation of bank accounts has become a master data task, a new risk has been introduced— successful testing in the DEV (Development) and QA (Quality Assurance) environments does not guarantee successful payments in production because incorrect house bank account data may have been entered in production.

4 Bank account management In the previous chapter, we discussed the basics of managing banks, house banks, and bank accounts in S/4HANA. In this chapter, we dive deeper into the more complex bank account management functionality. As mentioned in Section 2.1, the Bank Account Management (BAM) component provides new functionality relating to bank account management processes. Bank Account Management includes a central repository of bank accounts and related processes that can be monitored within SAP. All relevant information about a 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 IBAN, a description, bank key and SWIFT code, overdraft limits, profit center, and contact person (both internal and external). The functionality included in the Bank Account Management component and which are covered in this chapter are: bank account management workflow approval process payment signatories and relevant payment processes foreign bank account reporting creation of bank accounts using an import process from Excel In this chapter, we review the above processes and discuss any associated configuration in detail. 4.1 Bank account management workflow approval processes Bank Account Management is delivered with an optional workflow approval process for opening, changing and closing bank accounts, and a periodic review process. The workflow for bank accounts is based on SAP standard workflow. SAP has delivered several predefined workflow templates. Users can use these templates or adapt them to their own needs. Keep in mind that only fields that are defined as “sensitive” fields in the bank account master data can trigger the workflow process. Sensitive fields are fields such as bank account number or IBAN that, when updated, require an approval. In the predefined workflow, the process for opening a new bank account is as follows:

Initiate—a business user decides that the company needs a new bank account. The subsidiary cash manager then completes a new bank account request and submits it to the group cash manager. Approve—the group cash manager sees the request in the bank account worklist, compares the request with existing bank accounts in the company code, and decides whether to accept or reject the request. Confirm—the bank relationship manager works with the bank regarding the new bank account. After everything is finalized and the bank account is officially opened at the bank, the bank relationship manager enters the detailed information for the bank account in the Manage Bank Accounts app and confirm the workflow request. IT configuration—IT staff make the necessary configuration for the new bank account. They then enable the bank account with the payment and bank statement processes so that the bank account can be used for daily processing. A sample process flow using the Bank Account Management workflow is shown in Table 4.1.

Table 4.1: Bank account review process

Let’s now walk through these steps in more detail. 4.1.1 Open new bank account with Workflow A business user selects the Manage Bank Accounts app to create the new bank account (refer to Chapter 3 on how to do this). If BAM workflow is not enabled, the account will be created in an ACTIVE status. If BAM workflow is enabled, after pressing the SAVE button, users are presented with a message similar to that in Figure 4.1. Note that the CHANGE REQUEST number is 182 (SAP tracks activities such as opening an account or making changes to bank accounts with change request numbers).

Figure 4.1: Change request message

If BAM workflow is enabled, the account is created in an INACTIVE status, as shown in Figure 4.2.

Figure 4.2: Account created in inactive status

Users can view the Change Request for the newly created bank account in the Manage Bank Accounts app, by selecting the account and pressing the VIEW HISTORY link, as shown in Figure 4.3.

Figure 4.3: Manage bank account View History link

A popup screen is then displayed, indicating that the bank account is currently going through the workflow process (see Figure 4.4). Be aware that users are not able to make any changes to the bank account when the account is going through the workflow approval process.

Figure 4.4: Bank account in “To Be Approved” status

Requests for new bank accounts can be approved or rejected using the My Bank Account Worklist app, as shown in Figure 4.5.

Figure 4.5: Approve or request new bank account

Figure 4.6 shows the popup window that appears after approving the workflow request. Here, the approver can enter relevant information regarding the request.

Figure 4.6: Approve request message

As previously mentioned, the process steps are: approve, confirm, and then open the bank account at the bank. The approvers of the workflow messages are driven by the agent settings in the workflow configuration. 4.1.2 Changing and closing bank accounts with Workflow The workflow process for changing an account is the same as opening a bank account. For the change process, the trigger is a change made to a field that is marked as a “sensitive” field, such as the account number, IBAN or signatory. The sensitive fields are defined in configuration under Define Settings for bank account master data. This configuration is shown in Figure 4.7.

Figure 4.7: Define sensitive fields for bank accounts

Once workflow for revisions has been configured, a workflow message is automatically triggered when a bank account is closed. When a business user initiates the closing of a bank account, the system creates a change request and initiates the workflow, as shown in Figure 4.8. Until the workflow triggered at the closing of the account is complete, the account remains in ACTIVE status.

Figure 4.8: Initiate closing of bank account with workflow

4.1.3 Initiate periodic review with Workflow Most corporates perform a periodic review of bank accounts to ensure that the bank account data is accurate and up-to-date. In addition, in the review process, bank accounts that can be closed can be identified. The steps to initiate a periodic bank account review process are similar to the steps for opening a bank account, except that the initial step can be triggered by any user with the authorization to select the INITIATE REVIEW PROCESS button in the Initiate Review Process app. Note that if you want to use the bank account review process, ensure that there is an internal contact person populated in the CONTACT PERSON field on the GENERAL DATA tab, because only those who have been defined as internal general contacts receive the review reports triggered by this process. This field is shown in Figure 4.9. To do so, on the GENERAL DATA tab, under INTERNAL CONTACT PERSONS, specify the contact person in the CONTACT PERSON field.

Figure 4.9: Contact person in General Data of Manage Bank Accounts app

At this point, business users with authorization to access the Initiate Review Process app (see Figure 4.10) can trigger the bank account review process and monitor the status of the bank account review

Figure 4.10: Initiate Review Process app tile

After selecting the Initiate Review Process app, users enter the account filters to display the bank accounts that should be reviewed. Users click on the relevant checkboxes to the left of the accounts, or select all, then select the INITIATE REVIEW button, as shown in Figure 4.11.

Figure 4.11: Initiate review process account listing

A popup window then appears, similar to the one shown in Figure 4.12, where a message can be written for the contact person(s).

Figure 4.12: Initiate review process for bank accounts

After pressing OK on the popup screen (in Figure 4.12), the system displays the change request numbers that have been created, as shown in Figure 4.13

Figure 4.13: Review process change requests

The review request is only sent to the contact person's inbox, as shown in Figure 4.14. Only the reviewer can change the status of accounts using the My Bank Account Worklist app. The app only lists the requests belonging to the current user.

Figure 4.14: Review process request message

The Monitor Review Status app is used to monitor the bank account review process. From this app, users can check and remind reviewers to review bank accounts. The Monitor Review Status app tile is shown in Figure 4.15.

Figure 4.15: Monitor Review Status app

From this app, changes to the request status cannot be made directly; the REVIEWED checkbox is always read-only in this app. Figure 4.16 shows the output of the Monitor Review Status app.

Figure 4.16: Monitor review status report output

With the My Bank Account Worklist app users see any workflow requests

that they have queued up to be reviewed (see Figure 4.17).

Figure 4.17: My Sent Requests app tile

Figure 4.18 shows a message in the My Sent Requests app.

Figure 4.18: My Sent Requests app

As seen above, the initiation of bank account reviews is triggered using the Initiate Review Process app. Approvers, who are contact persons at the bank account level, use the Bank Account Worklist to approve the account. The Monitor Review Status app is a report that shows the progress of the review process. During this process, the initiator can review the request using the My Sent Requests app. 4.1.4 Troubleshooting Workflow To view the agents assigned to a workflow task, or for other types of workflow troubleshooting, the Selection Report for Work Items (transaction code SWI1) can be used. From this report, after selecting the workflow request, users are able to view the workflow log, which shows the agents assigned to approve the workflow message. Figure 4.19 shows the workflow approval history available via Selection Report for Work Items (transaction code SWI1).

Figure 4.19: SWI1 workflow Approval History

To check for triggered workflow messages, the Workload Analysis program (transaction code SWI5) can be used. The APPLICATION COMPONENT should be set to FIN-FSCM-CLM-BAM, as shown in Figure 4.20.

Figure 4.20: Input screen—Workload Analysis program

Figure 4.21 shows the workflow log for a triggered BAM workflow message. Note that an audit trail for the message is available.

Figure 4.21: Workflow Log in the Workload Analysis program

Troubleshooting BAM Workflow issues See SAP Note 2351803 "Troubleshooting for workflow issues in BAM Apps” for tips on resolving issues with BAM workflow.

4.2 Payment signatories With S/4HANA, SAP has introduced additional functionality that enables business users to assign payment signatories in master data. Payment signatories are people who have the authorization to approve payments. With Bank Account Management, you can define different approval processes for different bank accounts by configuring signatory groups and approval patterns. Note that this function is integrated with the BCM approval processes. The signatories can approve payments using the Approve Bank Payments app. For each bank account, different signatories and signatory amount limits are defined in the bank account master data so that only eligible signatories receive the approval requests. Multiple signatories can be assigned to one signatory group. The benefit here is that if one signatory is on leave, someone else can still perform the approval process. In addition, you can assign signatories to different business groups; for example, one group for the Treasury Department and one group for the Accounting Department. For different bank account types, different payment approval patterns can be assigned so that different bank account types can have different approval

logic. Validity dates for signatories are defined by maintaining the VALID FROM and VALID TO attributes for signatories. With Bank Account Management, it is still possible to use the automatic payment approval logic defined in BCM, so that payments that satisfy certain rules can bypass the approval. Figure 4.22 shows the PAYMENT SIGNATORIES tab in the Manage Bank Accounts app, where the payment signatories are defined.

Figure 4.22: Definition of payment signatories

Clicking on the icon on the Payment Signatories tab brings up the detailed definition of a payment signatory, as shown in Figure 4.23.

Figure 4.23: Detailed definition of a payment signatory

It is possible to define a single signature scenario (one signatory) and a joint signature scenario (more than one signatory) for one bank account. Signatories can be grouped into different business groups and assigned different conditions for making payment approvals. For example, payments made from a payroll account need to be approved by at least one person from HR and one person from Treasury. Payments made from an operating account need to be approved by at least one person from Accounting and one person from Treasury.

For different signatory groups involved in an approval process, you can define the sequence of each group or define it as non-sequential approval process. In one signatory group there can be more than one signatory to approve payment from the same bank account. The payment signatories defined in Bank Account Management can be used for payment approval. They replace the more elaborate release strategy in BCM. After certain Business Transaction Events (BTEs) are activated, the payment signatories’ logic, defined in BAM, is activated with BCM payment approval. For automatic approval processes for small payments, the rules defined in BCM are still used. If a payment exceeds the defined maximum limits of all available signatories, the BCM exception handling process is used. 4.2.1 Payment process flow Before stepping through the payment process flow, let’s look at the process steps, which are shown in Table 4.2.

Table 4.2: Payment process flow

From the process point of view, payments with approval using either BAM or BCM follow the same path. These are detailed in the next section where we outline an example payment process. 4.2.2 Payment process example

Let’s now walk through the payment process steps in SAP. Payments can be triggered a number of different ways, such as through bank-to-bank transfers, treasury trade payments, accounts payable payments, etc. In our example, we use the Make Bank Transfers app to easily and quickly make a bank-to-bank transfer payment, as shown in Figure 4.24. Using this app, cash managers select the sending and receiving accounts in the lower left and right panels respectively, then enter the amount, transfer date, payment method and reference information in the fields at the top. Clicking on MAKE BANK TRANSFER, at the bottom right of the screen, initiates the payment.

Figure 4.24: Make Bank Transfers screen

After clicking on MAKE BANK TRANSFER, a confirmation popup window is displayed, as shown in Figure 4.25. The cash manager is able to verify the payment information and add additional information before pressing the SUBMIT button to initiate the payment process.

Figure 4.25: Make Bank Transfer popup window

As you can see in the screenshot in Figure 4.26, a payment request is then created, and the Treasury payment program can be triggered automatically based on a configuration setting.

Figure 4.26: Make Bank Transfer message

At this point, users can click on TRACK BANK TRANSFERS in the lower right of the MAKE BANK TRANSFER screen. Alternatively, to view the treasury payments, users can select the Track Bank Transfers tile (see Figure 4.27).

Figure 4.27: Track Bank Transfers tile

Figure 4.28 shows the output of the Track Bank Transfers report.

Figure 4.28: Track Bank Transfers output

In our case, the Creation of Cross-Payment Run Payment Media (transaction code FBPM1) is run on a scheduled basis. At this point, the payments show as awaiting approval in the Batch and Payment Monitor (transaction code BNK_MONI), as shown in Figure 4.29.

Figure 4.29: Batch and Payment Monitor output

Users can alternatively use the Monitor Payment app (see Figure 4.30).

Figure 4.30: Monitor Payments app tile

By clicking on the approvers list icon , the Batch and Payment Monitor shows the list of approvers (see Figure 4.31); in our case, this is driven by the BAM signatories assigned to the paying account.

Figure 4.31: List of approvers

The next app in the process flow is the Approve Bank Payments app, which allows managers to approve payment workflows (see Figure 4.32).

Figure 4.32: Approve Bank Payments app tile

Once the Approve Bank Payments app has been selected, users see the

payments for review, and are able to drill down to view details on the individual payments included in the batch, as shown in Figure 4.33.

Figure 4.33: Approve Bank Payments screen

One option is to use the signatories in BAM. In most cases, this is a simpler setup driven by master data changes made by business users. For SAP customers wanting a more sophisticated payment approval design, they can use the BAM signatories only for opening new bank accounts, changing specific fields on an account, and closing accounts, and use the BCM payment approval configuration for payment approvals. 4.2.3 Changing signatories When a signatory leaves a company, it is not uncommon that bank signatory details need to be updated for multiple bank accounts. You also need to consider that when a new payment signatory is authorized, you must assign that signatory to a certain number of bank accounts. To help you with these scenarios, the mass signatory change function can help you maintain signatories in multiple bank accounts with a single action. With this function, you can add a new signatory to the chosen bank accounts or replace existing signatories with a new one. You can also revoke one signatory in multiple bank accounts by editing the validity information of the signatory. The Maintain Signatory for Multiple Accounts app tile is shown in Figure 4.34.

Figure 4.34: Maintain Signatory for Multiple Accounts app tile

After selecting the Maintain Signatory for Multiple Accounts app, the last date that an old signatory was in their position is entered as the VALID TO date, and the start date of the new signatory is set as the VALID FROM date. The approval process checks the validity periods to pick up only the eligible signatories at a certain point in time. In other words, business users can identify the bank accounts for which the person leaving is a signatory. This is shown in Figure 4.35.

Figure 4.35: Query for a signatory

Next, select the checkboxes to the left of the accounts that should be changed. Then, select the CHANGE SIGNATORY button. A CHANGE SIGNATORY popup message is then displayed, as shown in Figure 4.36. In this example, the signatory is a sensitive field; therefore, approval workflow is triggered.

Figure 4.36: Change Signatory workflow initiation

After pressing the OK button, the change requests are created, as shown in Figure 4.37.

Figure 4.37: Change signatory change requests

The accounts remain in active status while the signatory changes move through the workflow approval process. 4.3 Foreign bank account reporting If an entity has a financial interest in, or signature authority over, a foreign financial account, including a bank account, brokerage account, mutual fund, trust, or other type of foreign financial account, exceeding certain thresholds, the Bank Secrecy Act may require the entity to report that account annually to the Department of Treasury by electronically filing Financial Crimes Enforcement Network (FinCEN) 114, Report of Foreign Bank and Financial Accounts (FBAR) (source—Internal Revenue Services).

Most of our clients have to comply with FBAR requirements, which is usually handled via a custom report in SAP or in an excel file. This report is delivered out-of-the-box with SAP S/4HANA. The Foreign Bank Account Report app (see Figure 4.38) enables you to see a list of bank accounts by country and company code.

Figure 4.38: Foreign Bank Account Report app tile

On the FOREIGN BANK ACCOUNT REPORT screen (see Figure 4.39, by populating the HOME COUNTRY field, users can display foreign bank accounts. In addition, by selecting the CONSIDER ACCOUNT VALUE dropdown menu, users can control the account values to be displayed.

Figure 4.39: Foreign Bank Account Report—input

After populating the fields, press the GO button to execute the report. If you consider account value, when the sum of the maximum amount of each bank in the company code exceeds the MINIMUM AGGREGATE VALUE specified in filter bar, then the bank accounts in the company code are shown, as in Figure 4.40. In the MAXIMUM ACCOUNT VALUE column, users can check the greatest value of currency in a particular bank account in the specified time period. It is calculated based on the FI document and bank statements.

Figure 4.40: Foreign Bank Account Report—output screen, table view

There are two kinds of views to display data using the Foreign Bank Account app. Users can switch between a table view (see Figure 4.40) and list view (see Figure 4.41) by selecting the toggle button on the top right of the accounts view screen, as shown in Figure 4.41

Figure 4.41: Foreign Bank Account Report—output screen, list view

The Foreign Bank Account app is another reporting tool that is new with S/4HANA and can be used for FBAR reporting instead of custom reports. 4.4 Importing and exporting house bank accounts As mentioned in Chapter 3, a significant change in S/4HANA is that house bank accounts are now part of master data; however, house bank IDs can still be moved in transports by using the new S/4HANA transaction code FI12_HBANK. Once the house bank IDs are imported into the respective system, users are able to create the house bank accounts. In addition, SAP provides functionality to import and export house bank accounts from Excel. In this section, we outline the steps to do this. Importing and exporting bank accounts requires an introduction, as provided here, to fully understand how it is done. Bank Account Management requires either Fiori or NetWeaver Business Client (NWBC). In other words, it is not possible to use the SAP GUI to create house bank accounts in S/4HANA. Using NWBC is helpful when house bank accounts need to be created in a client other than the client the Fiori Launchpad points to; for example, when loading or creating the house bank accounts into the golden client (client 100). Please see the SAP NetWeaver Business Client in Section 10.6 for more information on using NWBC.

Additional information on migrating bank accounts See SAP Note 2437574 “Transport of Bank Account Master Data” and SAP Note 2304752 “Examples of Importing Bank Accounts” for information about creating house bank accounts in S/4HANA.

Before getting started, make sure you have enabled the Developer tab in Excel. To do this in Excel, follow the menu path FILE • OPTIONS. A screen similar to the one in Figure 4.42 is displayed. Select the CUSTOMIZE RIBBON tab, select the DEVELOPER option, and then press the OK button. This step is required because the upload of house bank accounts is done from an XML file.

Figure 4.42: Enable Developer tab in Excel

4.4.1 Download and view template To view the SAP template used to upload and download house bank accounts, click on the Manage Bank Accounts app. Select the IMPORT AND EXPORT BANK ACCOUNTS link, as shown in Figure 4.43.

Figure 4.43: Import and Export Bank Accounts link

The IMPORT AND EXPORT BANK ACCOUNTS screen is then displayed, as shown in Figure 4.44.

Figure 4.44: Import and Export Bank Accounts screen

After selecting the DOWNLOAD XML SPREADSHEET TEMPLATE link, a popup message is shown (see Figure 4.45). From here, the is XML_SpreadSheet_Template.xml file then saved to the user’s directory.

Figure 4.45: Download template popup window

The XML file can be opened in Microsoft Excel by selecting it into an open Excel worksheet. The template file contains one example house bank account and multiple sheets, as shown in Figure 4.46. SAP provides the template with a sample bank account, so users can see how the data should be populated. The sheets in Excel hold the data on various tabs in the

Manage Bank Accounts app. Note the names for the different sheets (CONNECTIVITY PATH, PAYMENT SIGNATORIES, etc.). These correspond to the tabs shown in the Manage Bank Accounts app.

Figure 4.46: XML template spreadsheet

4.4.2 Populating the template spreadsheet After populating Excel with the bank account information, and before you import data from Excel, check the data and ensure that: all the bank account entries you want to import are inside the blue frame, there are no empty rows between bank account entries, and empty rows show as errors upon upload to SAP. The screenshot in Figure 4.47 shows the blue frame that is in the downloaded template file.

Figure 4.47: The blue frame

After adding the bank account data to an Excel file, save the file as an XML file, as shown in Figure 4.48.

Figure 4.48: Saving the excel spreadsheet as XML

4.4.3 Importing house bank accounts Importing house bank accounts involves two steps: 1. First, import the bank accounts on the GENERAL AND ADDITIONAL DATA tab, leaving the data on the other tabs blank. 2. Next, after assigning a technical ID to the bank accounts imported, upload the house bank account and additional information. Step 1 In the first step, the bank account is created in SAP. Only the first sheet of information (in the GENERAL AND ADDITIONAL DATA ab) is imported in this first step, as shown in Figure 4.49. The CONNECTIVITY PATH, PAYMENT SIGNATORIES tabs, etc., are populated in the second step, after a technical ID has been assigned to each bank account.

Figure 4.49: Excel spreadsheet for Step 1

At upload, SAP looks for a bank account with the same bank key and account number. If found, then the fields in the spreadsheet are used to update the existing record. If not found, a new bank account is created. There is an IMPORT WITH TEST RUN button to check for errors before importing. Figure 4.50 shows the BANK ACCOUNTS IMPORT screen after a file of bank

accounts has been imported in non-test-run mode. Note the TARGET ACCOUNT ID field now shows a value of 28. This is the technical ID that has been assigned to this bank account. This value is used in the second step.

Figure 4.50: Import bank accounts—Step 1

If the OVERWRITE checkbox is selected, the system updates all the fields based on the input file. If the OVERWRITE checkbox is not selected, only blank, non-populated fields are updated from the input file. Step 2 Now that the technical IDs are known for each bank account created in SAP, the house bank accounts can be created. Update Excel with the technical IDs from the output from Step 1 for each bank account, as shown in Figure 4.51.

Figure 4.51: Update Excel with technical IDs

Next, import the file in test-run mode by pressing the IMPORT button, as shown in Figure 4.52.

WITH

TEST RUN

Figure 4.52: Import bank accounts—Step 2, test run

After running in test-run mode, press the IMPORT button to create the house bank accounts, as shown in Figure 4.53.

Figure 4.53: Import bank accounts—Step 2

Once a user has completed the above steps, it is relatively easy to create the house bank account using export/import processes. In addition, the S/4HANA migration cockpit can create house bank accounts in S/4HANA from ECC house bank accounts. Companies might also want to add additional fields, stored by bank account. This can be done by appending structure CI_AMD_EXT to database table FCLM_BAM_AMD. To enhance the template for importing and exporting bank accounts and assign checks for custom fields, proceed as follows: To enhance the XML schema for validation, choose Download XML Schema File for Import Validation. Edit the downloaded file XML_Schema_Import.xml using Notepad or other XML editing tools. The XML file already contains the custom fields you have defined. For each custom field, add an attribute type as appropriate. The value of the type attribute can be one of the simple types defined. If the simple types are not sufficient, you can add your own type definitions. Download the XML template by choosing Download XML Spreadsheet Template. Open the template file XML_SpreadSheet_Template.xml.

On the DEVELOPER tab, choose SOURCE, and the predefined validation structure is displayed. Choose the XML MAPS Button, and then delete the default mapping dataroot_Map. To add the new validation schema that contains a check for customer specific fields, choose the ADD button to import the changed schema file XML_Schema_Import.xml, and select DATAROOT. Map the new validation file to the corresponding cell of each sheet by using drag and drop. To activate the validation, on the DEVELOPER tab, choose MAP PROPERTIES and select the VALIDATE DATA checkbox against schema for import and export. Save the file as your new template. 4.4.4 Bank Account Management configuration So far in this chapter, we have outlined the processes related to Bank Account Management. We now outline the associated Bank Account Management configuration. Business function activation In order to use S/4HANA Cash Management, the business function FIN_FSCM_CLM must first be activated. This is done using transaction code SFW5, as shown in Figure 4.54. The business function FIN_FSCM_CLM is not activated for Basic Cash Management (Cash Management Lite/Bank Account Management Lite). This business function is reversible.

Figure 4.54: Activate S/4HANA Cash Management

Define basic settings In the next step we determine whether to use Basic Cash Management or S/4HANA Cash Management. This is found in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • GENERAL SETTINGS • DEFINE BASIC SETTINGS (see Figure 4.55). The options for Cash Management Scope are: BASIC SCOPE (Basic Cash Management)

FULL SCOPE (Cash Management Powered by S/4HANA)

Figure 4.55: Specify version of Cash Management functionality

When using the FULL SCOPE option, specify how change requests for maintaining payment signatories should be grouped for multiple bank accounts in bank account management. SAP offers group change requests for mass changes to Bank Account Management fields when workflow is enabled. This allows for one approval message, as opposed to an approval message for each change. With the customization activity, you can split a mass change request into a grouping by company code, account type, or a combination of both that trigger separated workflows. Keep in mind that only fields that are defined as sensitive fields in the bank account master data can trigger the workflow process. The grouping options are as follows: GROUP INTO A SINGLE CHANGE REQUEST—the change requests are sent individually to users who have been configured to process mass change requests. GROUP BY COMPANY CODE—the change requests are grouped by company code and sent to the users assigned to the specific company codes. GROUP BY ACCOUNT TYPE—the change requests are grouped by account type and sent to the users assigned to the specific account types. GROUP BY COMPANY CODE AND ACCOUNT TYPE—the change requests are grouped by company code and account type. The groupings are shown in Figure 4.56.

Figure 4.56: Specify how to group payment signatory changes

In addition, when using the FULL SCOPE option, specify how bank account changes should be handled. The BANK ACCOUNT REVISION options (see Figure 4.57) are as follows: ACTIVATE DIRECTLY—changes to bank accounts are saved automatically. ACTIVATE VIA DUAL CONTROL—changes go into effect after a second person, with proper authorization, approves the changes. ACTIVATE VIA WORKFLOW—SAP standard workflow.

Figure 4.57: Activation of bank account changes

Because this book covers the BAM workflow process, we have activated the third option ACTIVATE VIA WORKFLOW.

Workflow error resolution

If you get the message WORKFLOW IS TURNED OFF, when triggering the Initiate Review process, check the setting (see Figure 4.57).

Define and assign number ranges When a bank account is defined in S/4HANA, a technical ID is automatically assigned by the system. The number range for the bank account technical ID is found in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • DEFINE BASIC SETTINGS • DEFINE NUMBER RANGES FOR BANK ACCOUNT TECHNICAL IDS (see Figure 4.58).

Figure 4.58: Define technical ID number ranges

When activities are performed in Bank Account Management, such as opening or closing a bank account, a change request is created, and a number range must be defined for the change requests. The number range for change requests is defined in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • BASIC SETTINGS • DEFINE NUMBER RANGES FOR CHANGE REQUESTS (see Figure 4.59).

Figure 4.59: Define change request number ranges

The final step regarding number ranges is to assign the bank account technical ID and change request number ranges, which is done in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • BASIC SETTINGS • ASSIGN NUMBER RANGES (see Figure 4.60).

Figure 4.60: Assign number ranges

Define settings for bank account master data The bulk of the Bank Account Management configuration settings are made using the configuration node under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • BASIC SETTINGS • DEFINE SETTINGS FOR BANK ACCOUNT MASTER DATA. Let’s now walk through the seven configuration folders. Account type definition In the ACCOUNT TYPE DEFINITION folder, the different account types are defined. The account types defined can be operating, payroll, disbursements, etc. The account types are tied to the workflow processes and reporting, and they are assigned to bank accounts in the Manage Bank Accounts app. When defining an account type, a description is given, as shown in Figure 4.61. The DIRECTION column specifies whether cash flows are incoming, outgoing, or in both directions. The ATTRIBUTE column specifies whether the account is an operating account or a functional account.

Figure 4.61: Definition of account types

Sensitive fields for modification When using Bank Account Management workflow to track field changes, fields in the bank account definition (assigned through the Manage Bank Accounts app) can be marked as sensitive. Any changes made to these fields then trigger the workflow change request process. When specifying the sensitive fields, the object type is first specified. The

object type groups the fields. Next, the fields are specified. The different object types and the different fields within each of those object types are outlined below.

What are sensitive fields? It may help to glance back at Figure 3.17 and Figure 3.19 while reading this section.

Bank Account

This object contains fields on the GENERAL DATA tab; for example, bank, country, company code, account number, IBAN, etc. Figure 4.62 shows the different fields in the OBJECT type BANK ACCOUNT.

Figure 4.62: Marking sensitive fields for bank account management Currency

This object contains the ACCOUNT CURRENCY field on the GENERAL DATA tab. Overdraft Limit

This object contains fields on the OVERDRAFT LIMITS tab. Signature

This House object Bank contains Account fields on the PAYMENT SIGNATORIES PATH tab.

This object contains fields on the CONNECTIVITY

tab.

Figure 4.63 shows sensitive fields assigned across multiple objects.

Figure 4.63: Sensitive field assignments

Define import methods for bank statements Different import method for bank statements can be defined on the DEFINE IMPORT METHODS FOR BANK STATEMENTS tab, as shown in Figure 4.64. This is free-form text and is used for reporting purposes only. It could also be used to document the bank statement format being used. The import methods can be assigned in the Manage Bank Accounts app on the BANK RELATIONSHIP tab.

Figure 4.64: Defining import methods for bank statements

Define signatory groups Groups of authorized signatories can be defined based on the business requirements. For example, there may be a group of authorized signatories for payments up to a certain dollar amount, and another group for payments over a certain dollar amount. An example of defined signatory groups is shown in Figure 4.65.

Figure 4.65: Defining signatory groups

Define approval patterns In this step, approval patterns are defined. Approval patterns can be sequential or non-sequential. Up to four signatory groups can be assigned in the sequential patterns. This means the approvals must be given in an order. An example is shown in Figure 4.66.

Figure 4.66: Defining approval patterns

Maintain non-sequential approval patterns For non-sequential patterns, approvals do not need to be received in a specific order, and there must be at least two signatory groups (see Figure 4.67).

Figure 4.67: Defining non-sequential approval pattern

Assign approval patterns The assignment of approval patterns works as follows (see Figure 4.68): If an approval pattern is assigned to a company code but not to any account type, then the approval pattern is applicable to all account

types under that company code. If an approval pattern is assigned to an account type but not to any company code, then the pattern is applicable to the account type for all the company codes. If multiple approval patterns are assigned to an individual account type or company code, approval pattern priority can be defined to determine the sequence of approval patterns. A lower number means higher priority. Priority 0 is the highest priority.

Figure 4.68: Assign approval patterns

Activate BAM workflow The next configuration node relates to activation of the BAM workflow process. This configuration node is located under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • MAINTAIN THE EVENT TYPE LINKAGE FOR TRIGGERING WORKFLOW PROCESSES. The SAP standard workflow template WS74300043 includes the following processes: Workflow for opening bank accounts (creating new bank account master records) Workflow for changing bank accounts (changing existing bank account master records) Workflow for closing bank accounts (marking the bank account records as closed) Workflow for changing a signatory in multiple bank accounts Workflow for reviewing bank accounts The linkage defined in this step is used to assign the predefined CREATED

event (initialize a workflow process) in Business Object Repository (BOR) object FCLM_CR (predefined BOR object for Bank Account Management; the CR stands for Change Request) to a receiver (it can be the SAP predefined workflow template WS74300043 or the customer-defined workflow template), so that the system triggers workflow processes in Bank Account Management (see Figure 4.69).

Figure 4.69: Maintain event type trigger for BAM workflow

Double clicking on the line in Figure 4.69 brings up the screen shown in Figure 4.70. The LINKAGE ACTIVATED checkbox must be selected for the BAM workflow to be activated.

Figure 4.70: Activate bank account management workflow

Assign workflow approvers

The next step in configuring BAM workflow is to assign users to the rules listed above, which is done under: FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • DEFINE RESPONSIBILITIES FOR RULES USED IN WORKFLOW STEPS. Table 4.3 shows the BAM SAP-delivered workflow templates, the associated user assigned to each role, and a description of the workflow rule. Rule

Role

74300006 Cash Manager

Description Users assigned to this workflow rule can approve or reject change requests for opening, changing, or closing bank accounts.

74300007 Bank Accountant Users assigned to the Bank Accountant role are responsible for opening, changing, or closing bank accounts (and works under the Cash Manager). 74300008 Key User

Key Users are responsible for making configuration changes for bank accounts and house bank accounts.

74300013 Reviewer

This is a standard SAP-delivered workflow for the bank account review process.

Table 4.3: SAP standard BAM workflow rules

Let’s now look at the process of assigning users for rule number 74300006 (Cash Manager). Note that the steps to assign users are the same for all rules. First, enter the rule in the RULE NUMBER field, as shown in Figure 4.71, then press the Enter key.

Figure 4.71: Enter workflow rule number

Press the create icon . ,(object and aabbreviation) CREATE RESPONSIBILITY and NAMEpopup window appears, as shown in Figure 4.72. Enter a validity date range for the workflow. The OBJECT ABBR fields can be changed, if desired.

Figure 4.72: Popup window—Create responsibility

Click on the CONTINUE button and a screen appears showing the ACCOUNT TYPE and COMPANY CODE (see Figure 4.73). If you do not want to restrict the workflow by company code or account type, enter the wildcard character * (asterisk) to apply to all.

Figure 4.73: Set responsibility values

After entering these details, click the SAVE button. The NO DEFINED message (see Figure 4.73) changes to RESPONSIBILITY shown in Figure 4.74.

RESPONSIBILITY COMPLETE,

as

Figure 4.74: Rule with “Responsibility complete” setting

Press the back arrow.

Next, press the insert agent assignment icon to assign the users. As with all SAP standard workflow, the assignments can be made by organizational hierarchy level, specific users, etc. From the popup window (see validity Figure period. 4.75), Press you thecan CONTINUE specify button. the ORGANIZATIONAL UNIT, USER, etc. and

Figure 4.75: Agent selection popup window

Enter a selection, e.g. organizational unit, user, etc., then press the key. The screen shown in Figure 4.76 is then displayed.

Enter

Figure 4.76: Assign user

Press the CREATE button at the bottom of the popup window. The agent (approvers) are now assigned, as shown in Figure 4.77.

Figure 4.77: Agents/approvers added to the cash manager workflow

Back out once and do the above steps for rule numbers 74300007 (Bank Accountant) and 74300008 (Key User). We do not show the screenshots for Bank Accountant and Key User here because the steps are the same as for Cash Manager (just with different users). Enable signatory control To activate signatory control in BAM, follow the menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • ENABLE SIGNATORY CONTROL, as shown in Figure 4.78. Enter the two BTE’s displayed.

Figure 4.78: Enable workflow

When signatory control is enabled, users defined as signatories are able to approve or reject payments in Bank Account Management. The signatory information maintained in the bank account master data does not take effect until the signatory control is enabled here. If the signatory control is not enabled, payment approvals are handled using the logic in the Bank Communication Management component. Manage field status groups The next configuration step is to define field status rules for Bank Account Management. In this activity, you can define field status groups and special rules to control the appearance and status of fields on Bank Account Management screens; for example, if a field is mandatory, hidden, editable, or read-only. The different field status rules are captured under DEFINE FIELD STATUS GROUPS, as shown in Figure 4.79. This configuration node is in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • MANAGE FIELD STATUS GROUPS.

Figure 4.79: Definition of field status groups

After the field status groups are defined, use the settings in the DEFINE UI FIELD STATUS folder to specify the desired field status for that field status group, as shown in Figure 4.80.

Figure 4.80: Specify field status rules

A good example of the use of field status groups is setting the IBAN for bank accounts in the European Union. In this case, you may also want to keep the bank account number field in your bank account master data for German bank accounts, because bank account numbers are used in various reports as the bank account identifiers. To configure these requirements: Define field status groups and assign them accordingly to different screens. In the field status group settings, define the field account number and IBAN as mandatory. With the above settings, when a new bank account in Germany is created, both the IBAN and the account number are required fields. After you fill out the ACCOUNT NUMBER Field, the IBAN can be automatically populated by pressing the IBAN button. For most companies, the standard SAP-delivered settings should suffice. To create custom field status groups with customized checks on fields, there is BAdI FCLM_BAM_FIELDS_CTRL. If using the BAdI, keep in mind that the SAP standard field status groups take precedence over the default BAdI implementation FCLM_BAM_FIELDS_CTRL. 4.4.5 Bank Communication Management (BCM) configuration As mentioned above, if you want to use the BCM payment approvals, as opposed to the BAM payment approvals, do not enable signatory control in the following IMG task: FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • ENABLE SIGNATORY CONTROL. Regardless of whether BCM or BAM approval logic is used,

configuration in the BCM module is required, which is covered here. If an automatic approval process has been defined for small dollar amount payments in the BCM, small dollar amount payments will be approved automatically regardless of the signatory settings you defined in BCM. Define cross-payment run payment media settings Set up cross-payment-run identifiers. The identifiers entered refer to how the identification field is populated when running the AP and/or Treasury payment programs. When running the SAP payment programs, each payment run is uniquely identified by a run date and an identification field that is manually entered by the user. In this configuration, you specify the AP/AR (F110), Treasury (F111), and HR payment runs that should be directed to SAP BCM for batching of payments and approvals. To complete this step, use transaction code OBPM5 or follow the menu path FINANCIAL ACCOUNTING • ACCOUNTS RECEIVABLE AND ACCOUNTS PAYABLE • BUSINESS TRANSACTIONS • OUTGOING PAYMENTS • AUTOMATIC OUTGOING PAYMENTS • PAYMENT MEDIA • DEFINE IDENTIFICATION FOR CROSS-PAYMENT RUN PAYMENT MEDIA. In the initial screen, select the FI AP/AR PAYMENT PROGRAM FOR CUSTOMERS AND VENDORS option. The RUN INDICATOR field is set based on the button clicked. Enter payment-run identifiers in the fields in the IDENTIFIER column and select the BRM (BCM) checkbox. Figure 4.81 shows this step for the Treasury payment program (also known as the Payment Program for Payment Requests). If an asterisk * is entered, all payments are routed for approvals.

Figure 4.81: Identify payment runs to route through BCM

Basic settings for approval Configure basic settings for approval. To complete this step, follow the configuration menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • BANK COMMUNICATION MANAGEMENT • BASIC SETTINGS • BASIC SETTINGS FOR APPROVAL, as

shown in Figure 4.82. In this configuration, you specify the default currency for the total batch amount, the resubmission days from the current date, and whether a digital signature is needed for payment. The value entered in the EXCHANGE RATE TYPE field (M in our example) is the exchange rate type used to convert payments into the RULE CURRENCY entered. In the DAYS RESUBMISSION field, enter the default number of days to be used when batches are resubmitted. During the approval process, if a payment or batch is resubmitted, the system adds this number of days to the current date to compute the proposed resubmission date. In our example, the DAYS RESUBMISSION is set to 1, so the default resubmission date is the next day.

Figure 4.82: BCM Basic Settings

Rule maintenance Next, configure BCM rule maintenance. BCM rule maintenance is required for group payments as per the SAP customer’s specific needs. In other words, this configuration defines the rules for batching payments. Priorities can be given to the rules for instances when a payment can fall into more than one rule, in which case the payment is included in the rule with the highest priority (the highest priority has the lowest number, so priority 0 is higher than priority 1). As an example, if you require approvals for all payments of $1 million or more, you define one batch containing all payments of $1 million and more, and a second batch of all payments less than $1 million. These batches also need to be defined by bank, because, as previously mentioned, the batching is how the payments are grouped when sent to the bank, and you would not send JPM Chase payments to Citibank, for example. You can define the rules for the kind of grouping you require for payments. Basically, most of

the attributes of the payment are available to be used in the batching rule definition (e.g. amount, currency, postal code, payee's bank account number, etc.). To complete this step, follow the configuration menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • BANK COMMUNICATION MANAGEMENT • PAYMENT GROUPING • RULE MAINTENANCE. The first step is to create the rules, which are shown in Figure 4.83.

Figure 4.83: Rule maintenance

To enter the actual criteria for the rule, click the detail view icon (see red arrow). The rules are then defined, as shown in Figure 4.84. In this example, we are grouping payments by company code, payment method, and amount (over $1,000,000).

Figure 4.84: Rule definition

When defining the rules, make sure that they do not overlap. It's best to keep it simple. You can further specify additional criteria for grouping payments in the ADDITIONAL CRITERIA FOR PAYMENT GROUPING configuration node. For example, the additional criteria for Payment Grouping, under GRPNG. FIELD1, can be entered as HKTID for the house bank account. You can choose one more criteria under GRPNG. FIELD2 for payment groupings, if desired. For example, in the grouping of payments above, the payments can be grouped by amount. In the ADDITIONAL CRITERIA FOR PAYMENT GROUPING node. We show this in Figure 4.85. HKTID is the technical name for bank account ID.

Figure 4.85: Additional criteria for payment grouping

Mark rules for automatic payments (no approval) To complete BANK COMMUNICATION this step,MANAGEMENT follow menu •path RELEASE FINANCIAL STRATEGY SUPPLY •CHAIN MARK MANAGEMENT RULES FOR• AUTOMATIC PAYMENTS (NO APPROVAL) (see Figure 4.86).

Figure 4.86: Mark rules for automatic payments (no approval)

In this configuration, you mark any batching rules that do not require approval. For our example, the rules have been set so that payments of less than $1 million do not require approval. Figure 4.86 shows that for the batching rules for payments under $1 million, the auto-approval indicator is set. If the AUTO (Automatic) checkbox is selected, the approval step will be skipped for the payments falling into that rule. If the AUTO (Automatic) checkbox is not selected, the batches will require approval. Rules should be prioritized, so that when there is more than one rule satisfying the criteria for grouping, your priorities determine the batching rule. Assign role to release steps If using the BCM payment approvals, as opposed to the BAM payment approvals,1 the approvers need to be specified in BCM. This is done in configuration, by following the menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • BANK COMMUNICATION MANAGEMENT • RELEASE STRATEGY • CHANGE AND RELEASE • ASSIGN ROLE TO RELEASE STEPS. SAP BCM uses two workflow objects: BNK_INI (verifier) and BNK_COM

(approver). The verifier, also known as the “first releaser”, has the ability to change batches by rejecting payments. The approver (after the first release) only has the ability to approve or reject at the batch level. In this step, you assign a standard role to the release step that applies to the verifier release object, as shown in Figure 4.87. (The verifier is able to approve, reject, or partially approve batches.)

Figure 4.87: Assign the BNK_INI rule

After saving your entry, or to display an existing entry, select the checkbox to the left of the entry and click the CREATE RULE or DISPLAY RULE button to assign users to the approver role (see Figure 4.88).

Figure 4.88: Assign users as approvers

If more than one approval is required, then the same setup must also be completed for release object BNK_COM. Because the steps are the same as for BNK_INI, we do not show them here. In the case of first approval, the approvals are assigned in the CHANGE AND RELEASE node. For additional approvals, the approvers are assigned in the ADDITIONAL RELEASE STEPS node. 4.4.6 Summary With the move from ECC to S/4HANA, SAP has taken functionality that was previously defined in configuration and moved it to master data. This is a key point because:

it gives business users more control over how the system functions (thereby removing responsibility from IT), and it reduces the amount of configuration needed to get the system up and running, thus potentially reducing implementation time. With the introduction of workflow and payment signatories, SAP has filled a major gap by now providing Bank Account Management software. Prior to S/4HANA, SAP did not offer this type of software. There are still various functionalities missing when compared to a matured eBAM software, but with every release, SAP is moving further into Bank Account Management software space. The key changes with respect to bank account management are: bank account approval workflow process, workflow process support in opening, changing and closing a bank account, periodic bank account review process, introduction of payment signatories in BAM, integration with BCM, and foreign bank account report.

5 Bank Communication Management and Multi-Bank Connectivity Although there is no new functionality specific to S/4HANA in SAP Bank Communications Management (BCM), because BCM is so relevant to this book, we cover some aspects of it here. As discussed in previous chapters, SAP/4 HANA has introduced approval functionality within Bank Account Management (BAM). However, this is applicable to relatively simple approval requirements. If a company has complex approval requirements (e.g., different approvers for different payment types), they still need to use BCM. We cover some basic aspects of BCM in this chapter. We also cover some basic aspects of Multi-Bank Connectivity (MBC) which helps corporations connect with financial institutions. 5.1 BCM Overview SAP BCM can be used to efficiently manage inbound (current day reports, prior day reports, payment file, and transaction-level acknowledgments) and outbound (AP, HR, and Treasury payments) communications with banking partners. In addition, SAP BCM provides additional capabilities such as payment batching, approval capabilities using SAP standard workflow, digital signature, and payment status tracking. Prior to the release of the BCM module, SAP did not provide the ability to merge payments from various payment runs using pre-configured rules and route them for approval to appropriate users. SAP users could also not process and track file and transaction-level acknowledgments that were provided by the banks. With the addition of BCM, SAP has provided these additional capabilities along with payment and bank statement status monitoring tools. The key advantages of using BCM are: Users are able to merge payments from various runs using predefined rules and create batches that can be routed for approvals. There are many payment attributes (such as amount, payment origin, company code, payment methods, currency, house bank, and value date) that can be used to batch payments together. However, note that payments

from the SAP HCM (Human Capital Management) module cannot be merged with payments from AP and Treasury. Users have an optional ability to approve payments before they are delivered to the bank. A payment batch can still be sent to the bank without approval if approvals after the payment runs are not necessary. SAP BCM provides functionality to have as many approvals as required, using standard SAP workflow. Users can import both file-level and transaction-level acknowledgments into the SAP system. Upon successful import of acknowledgments, the payment batch status is updated in the SAP system. The Batch and Payment Monitor (transaction code BNK_MONI) and the Monitor Payments Fiori app in SAP Bank Communication Management show all payments and their associated statuses. Users have the ability to set up custom alerts if a batch status is not updated as per the agreed timeframe. For example, if the file-level acknowledgment is not received from the bank within 15 minutes of sending the file to the bank, an alert is triggered. SAP Bank Communication Management’s bank statement monitor gives Treasury and bank reconciliation users a quick view of the status of bank statements imported for the day. The report also notifies users of any bank statements missing for the day. There is increased efficiency and automation of payment processing and payment reconciliation.

5.2 BCM Connector The BCM Connector is a tool within the BCM module that enables customers to centralize their payment approvals and payment reporting with a hybrid landscape. The BCM Connector can be used to route the payment files from an external source system through an on-premise instance before the payments are sent to the bank. Another advantage of using the BCM Connector is that all payment files are sent from a company following the same path (through an on-premise instance). Treasury users might like to have a centralized payment hub through which all payments from an organization are sent. For example, to do this, the AP, payroll, and Concur T&E payment files are created in their respective systems, then placed in an incoming BCM connector directory in the on premise system. The on-premise SAP system reads the AP and Concur payment files, requires no approvals, and then sends the payments to the bank using the same transmission as the Treasury payment files. Again, this

enables Treasury to have centralized reporting across all these payments. One limitation of the BCM connector is that approval is only at file level. If a payment from an external system file is rejected, the entire file must be rejected, even if the file format is in a standard format such as XML ISO pain.001. This is because no mechanism or process exists to support transaction-level rejections. Figure 5.1 shows how payment files can be sent to banks based on our example hybrid landscape.

Figure 5.1: BCM Connector

The batches that are created using BCM Connector have a different status to batches that are created within the native system when viewed in the Batch and Payment Monitor (transaction code BNK_MONI) or the Monitor Payments Fiori app. Users see the batch status, as shown in Figure 5.2, upon creation of approvals and payment medium.

Figure 5.2: Status upon creation of approvals and payment medium

In addition, users are also able to see the difference in the rule description field (see Figure 5.3).

Figure 5.3: Payments sent through BCM Connector

5.3 Multi-Bank Connectivity With Multi-Bank Connectivity, SAP provides customers with an end-to-end payment solution. Multi-Bank Connectivity is a digital channel enabling corporates to connect with banks via their SAP systems. It provides a channel that can be used for incoming and outgoing traffic. Multi-Bank Connectivity is delivered through a private cloud managed by SAP. Customers are able to connect with their banking partner via the following SAP-supported mechanisms: direct bank integration (host-to-host) ebics SWIFT Alliance Lite 2 Figure 5.4 shows an overview of how Multi-Bank Connectivity fits into the SAP landscape.

Figure 5.4: Multi-Bank Connectivity overview

Even with Multi-Bank Connectivity, companies need membership to SWIFT (which comes with a unique Business Entity Identifier (BEI) and SWIFT Alliance Lite 2). In this connectivity model, customers are charged by both SWIFT and SAP for their services. 5.4 Summary With the introduction of BCM, SAP has eliminated the need for final approval in the banking portal and customers can now perform this step in SAP itself. BCM Connector allows customers to have a centralized dashboard where

they can approve and monitor all their payments, regardless of origin. This was a missing piece in SAP’s payment solution. To take payment processing even further, SAP also offers connectivity services, using Multi-Bank Connectivity, which facilitates the onboarding of a new banking partner, and provides a truly complete payment solution.

6 Cash operations In this chapter, we take a detailed look at the area of cash operations. With S/4HANA Cash Management, SAP has re-designed the Cash Operations functionality, which is the focus of this chapter. Included in day-to-day cash operations processing are: bank statement processing cash positioning payment creation payment approval and processing reporting SAP S/4HANA offers the following options for Cash Management functionality: Basic Cash Management (formerly known as Cash Management Lite) S/4HANA Cash Management (also known as Cash Management on HANA and Advanced Cash Management) Although we primarily focus on the new and improved S/4HANA Cash Management, it is important to look briefly at Basic Cash Management and what it offers. 6.1 Cash Operations overview Basic Cash Management is essentially the cash management functionality that has been available in ECC for many years. The Cash Position and Liquidity Forecast reports (transaction code FF7A and FF7B) are now available through the DISPLAY CASH POSITION and DISPLAY LIQUIDITY FORECAST tiles shown in Figure 6.1. The cash concentration process is executed through the CASH CONCENTRATION VIA PAYMENT ADVICE tile (not shown). SAP customers that do not purchase S/4HANA Cash Management can use the Basic Cash Management functionality with the standard S/4HANA license.

Figure 6.1: Basic Cash Operations tiles

House bank account creation Whether using Basic Cash Management or the S/4HANA Cash Management, since S/4HANA release 1503, the creation of house bank accounts has moved from IT configuration to business master data.

If SAP customers are currently using the Cash Management functionality on ECC, they can migrate over to S/4HANA with the existing Basic Cash Management functionality. One aspect of the Cash Position report that has changed with S/4HANA Cash Management is that Cash Management Account Name and Cash Management Groupings are no longer required configuration steps. With S/4HANA Cash Management, bank accounts are displayed by bank account number, by currency, and by a number of other fields. For customers wanting to give a textual name to the bank accounts in the Cash Position, the master data Bank Account Group may be useful. 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. Liquidity items, which is the term used to categorize cash, are now an integrated part of Cash and Liquidity Management. An example of a typical process flow for Cash Operations is shown in Table 6.1.

Table 6.1: Day-to-day operations process flow

Figure 6.2 provides a pictorial view of the day-to-day process flow.

Figure 6.2: Pictorial view of day-to-day cash operations

SAP has provided a catalog of apps that can be used for day-to-day cash operations. The Cash Operations catalog is displayed in Figure 6.3.

Figure 6.3: Cash Operation catalog

Two new KPI Fiori apps have been delivered with the Cash Operations component: the Bank Statement Monitor, which provides a high-level view of the bank statement import status, and the Cash Position app, which gives a high-level view of bank account balances. The Bank Statement Monitor informs cash managers if bank statements were received from each bank and whether the bank statements were successfully imported into the SAP system. They can quickly see whether there are any missing bank statements. These are things that cash managers might need to know before they start looking at the account balances in SAP. They then look 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 cash managers to get more detailed information. Let’s now walk through the various steps involved in the day-to-day cash operations process. 6.1.1 Monitor bank statements Typically, previous bank statements are imported on a scheduled basis before a cash manager’s day starts. The Bank Statement Monitor app is a new KPI app to view the status of bank statements in a graphical display. Note that the app’s tile (see Figure 6.4) shows the current status of the bank statement processing.

Figure 6.4: Bank Statement Monitor app tile

Clicking on the tile brings up a graphical display of the import and reconciliation status of the previous bank statements. Figure 6.5 shows the graphical display before the bank statements are imported. Note that because the bank statements have not been imported into SAP for the day the app was run, the graph shows errors. SAP has chosen green-colored bars to indicate error status, as defined in the legend.

Figure 6.5: Bank Statement Monitor initial graphical display

You only see the accounts that are configured for Bank Statement Monitor display, which is described further in the Cash Operations Configuration section. Figure 6.6 shows the Bank Statement Monitor display after some bank account statements have been uploaded.

Figure 6.6: Bank Statement Monitor initial graphical display after upload

Figure 6.7 shows the Bank Statement Monitor app when the statements for all configured bank accounts have been imported into SAP.

Figure 6.7: Bank Statement Monitor after all statements imported

Users are able to go from the Bank Statement Monitor graphical display to the Manage Bank Statements app by selecting the OPEN IN button and then selecting the MANAGE BANK STATEMENTS option, as shown in Figure 6.8.

Figure 6.8: Going from the Bank Statement Monitor app to the Manage Bank Statements app

Figure 6.9 shows the Manage Bank Statements report, which is the Fiori version of the Bank Statement Monitor report, showing the statements imported on a single business day or range of dates. See the BANK STATEMENT DATE field.

Figure 6.9: Manage Bank Statements report

In the SAP GUI version, the Bank Statement Monitor (transaction code FTE_BSM) can be used to run the report for a given STATEMENT DATE or IMPORT DATE, as shown in Figure 6.10. Note that this functions differently to the Fiori version of the same program.

Figure 6.10: Bank Statement Monitor through SAP GUI

6.1.2 Cash position With S/4HANA, SAP provides the Cash Position app, which is a KPI Fiori tile showing the current account balances (see Figure 6.11).

Figure 6.11: Cash Position app tile

When clicking on the Cash Position tile, a graphical view of the bank account balances is shown (see Figure 6.12).

Figure 6.12: Cash Position graphical display

From the Cash Position balance display, users can press the OPEN IN button (not shown here) to view the Cash Flow Analyzer app, which shows the detailed cash position view. Alternatively, users can go directly to the Cash Flow Analyzer app (see Figure 6.13).

Figure 6.13: Cash Flow Analyzer app tile

Clicking on the Cash Flow Analyzer app brings up the new Cash Position report, as shown in Figure 6.14. Note the improvements to the interface—the amounts are displayed in the transaction currencies, and when drilling into an account, users are not taken to a new screen. Instead, the screen expands to show details of the account that was clicked-on, leaving the other account information intact. This is an improved user experience compared to the ECC cash position report.

Figure 6.14: The new Cash Position report

As mentioned previously, when using the new Cash Flow Analyzer app, configuration is no longer required for the CM Groupings. There are many ways to filter and/or view data in the Cash Flow Analyzer app. Some of the filters can be seen in Figure 6.15. In addition, release 1709 enables users to filter the Cash Position data by Public Sector elements, such as the fund and grant (not shown here).

Figure 6.15: Main filters for cash position

Additional filters are shown in Figure 6.16, but this is not an exhaustive list.

Figure 6.16: Additional filters for cash position

SAP has added an OVERDUE column, to reflect past due items. If this column is not required, follow these steps to hide it:

Click on the settings icon

.

On the popup window that appears (see Figure 6.17), deselect the OVERDUE checkbox. Click OK at the bottom of the popup window.

Figure 6.17 : Cash position settings

Follow the same steps to change the layout in a number of other ways. There are over fifty fields displayed on the above settings popup window; we have shown only a small selection here. As with ECC, it is possible to save report variants in order to save predefined selection criteria for reports. After entering the inputs, click on the select view icon and then click on SAVE AS (see Figure 6.18).

Figure 6.18: Create variants

Bank hierarchies and bank groups We now move onto bank hierarchies and bank account groups, which are similar yet different, but which can both be used to view cash position. Bank hierarchies and bank account groups are available to help users group, organize, and display banks, bank accounts, and bank account information. Table 6.2 outlines the differences and similarities between bank account groups and hierarchies. Bank account groups

Bank hierarchies

Can be created as user specific or shared across all users

Shared across all users

It is possible to name bank account groups and nodes

Naming the bank hierarchy is not possible.

There is no system-forced structure for bank account groups.

The bank hierarchy is driven by bank key and bank country

can There beiscreated. no limit to the number of bank account groups that

A single bank hierarchy exists for all house banks in BAM.

Used to view bank accounts in the cash position

Used to view bank accounts in the cash position

In release 1809, there Not used in cash pooling is Used newinfunctionality cash pools,for as creating of release cash 1709. pools.

Table 6.2: Differences between bank account groups and bank hierarchies

Cash position by bank hierarchy When displaying bank accounts using the bank hierarchy, the bank accounts under each bank are displayed automatically in the bank hierarchy. From this view, users can see a complete list of all the banks and bank accounts within the company. To view bank accounts by bank hierarchy or bank account group, click on DISPLAY HIERARCHY, as shown in Figure 6.19.

Figure 6.19: Select bank hierarchy display

A popup window is then displayed, as shown in Figure 6.20.

Figure 6.20: Select hierarchy popup window

To display the cash position by bank hierarchy or bank account group, select the BANK ACCOUNT GROUP radio button. After pressing the OK button, another popup window is displayed (see Figure 6.21). In this window, the first item displayed is always the BANK HIERARCHY.

Figure 6.21: Select Bank Account Group popup window—Bank Hierarchy

Selecting the bank hierarchy displays the cash position by bank hierarchy, as shown in Figure 6.22.

Figure 6.22: Display accounts by bank hierarchy

It is best practice to include all banks where a company has accounts in the bank hierarchy; this ensures that all accounts are included when reporting

on the bank accounts using a bank hierarchy. Defining bank hierarchies Both bank hierarchies and bank account groups are defined using the Manage Bank Accounts app (see Figure 6.23). In the following section, we cover the process to define bank hierarchies.

Figure 6.23: Manage Bank Accounts apps

Manage Bank Accounts apps The two apps shown in Figure 6.23 show the same data. The difference between them is that the Manage Bank Accounts app is a native SAP Fiori app, whereas the Manage Bank Accounts—Bank Hierarchy View app is a Web Dynpro app.

Clicking on the Manage Bank Accounts tile opens the screen displayed in Figure 6.24. To define or change either bank hierarchies or bank account groups, select the MAINTAIN HIERARCHY AND GROUPS button.

Figure 6.24: Maintain bank hierarchy and groups

A bank hierarchy represents the hierarchical relationship of banks and branches within a banking group. As previously mentioned, only one bank hierarchy exists for all house banks in BAM. Pressing the MAINTAIN HIERARCHY

AND

GROUPS button brings up a screen

similar to the one shown in Figure 6.25. Click the hierarchy.

icon to edit the bank

Figure 6.25: Bank Hierarchy: Active Accounts screen

Once in edit mode, the screen is separated into two panels. To add a bank to the bank hierarchy, select it in the left panel, and select the target bank on the right, as shown in Figure 6.26. Then click on the ADD BANK button.

Figure 6.26: Add to bank hierarchy

The checkboxes under IN HIERARCHY signify whether banks are already assigned to the bank hierarchy. Each bank can be assigned just once to the bank hierarchy. If a user tries to add a bank that is already defined in the bank hierarchy, an error message will appear. After pressing the ADD BANK button, the bank appears as a node in the bank hierarchy on the right (see Figure 6.27), and the banks assigned as related branches inherit the business partner from the parent.

Figure 6.27: Banks added to bank hierarchy WITHlatter The difference between ADD BANK and ADD BANK WITH BP is BANK that the enables users to build a structured bank hierarchy where banks are assigned to multiple/different node levels. To use the ADD BP option, you must have business partners assigned to the bank, and banks must be added one by one.

When complete, press the SAVE button in the lower right corner of the screen (not shown here). The changes are then saved, and a message is displayed (see Figure 6.28).

Figure 6.28: Bank hierarchy saved message

Bank account groups Business users can define bank account groups according to their individual requirements. Users can set whether a group is for public or personal use (i.e. whether other users can use the Bank Account Group). Cash pools are created by bank account groups and it makes the work of creating and maintaining cash pools much easier. In order to create a bank account group, users click on the CREATE button, as shown in Figure 6.29.

Figure 6.29: Create bank account group button

Enter a name for the bank account group node, as shown in Figure 6.30.

Figure 6.30: Create new bank account group node

After creating the bank account group node, select the checkbox to the left of each bank account that should be included in this group (see Figure 6.31). These accounts are then transferred to the bank account group by clicking on the ADD TO BANK ACCOUNT GROUP button.

Figure 6.31: Transfer accounts to bank account group node

The accounts are then shown under the corresponding node in the right panel, as shown in Figure 6.32.

Figure 6.32: Accounts transferred to bank account group

When complete, press the SAVE button and a message is then displayed (see Figure 6.33).

Figure 6.33: Change to bank group saved message

To display the cash position by the new bank account group, follow the steps under Cash position by bank hierarchy. At the step displayed in Figure 6.20, make the selection shown in Figure 6.34.

Figure 6.34: Select bank account group—US Accounts

After pressing the OK button (not shown), the cash position is displayed by the new bank account group, shown in Figure 6.35.

Figure 6.35: Cash position by bank account group

6.1.3 Payments So far, we have discussed bank statement processing and cash positioning. Based on the information in the cash position, the next logical step for a

business user is to manage cash; for example, bank transfer payment processing. Payments can be created in various ways, such as cash pooling, bank transfers, treasury trades, etc. We covered bank account transfers and approvals in Payment process example), and in this section we give a brief overview of cash pooling. Be aware that in release 1809 SAP has changed the cash pooling functionality. We cover the new functionality in Chapter 9 (Section 9.4.1), but the older cash pool functionality is briefly covered here. Cash pools With Bank Account Management, you can create cash pools based on a bank account group structure and use cash concentration to centrally manage your cash. The steps to cash pooling are: 1. Create a bank account group 2. Create a cash pool 3. Run cash concentration With S/4HANA, unlike ECC, the setup of the cash pools is all application side processing. There is no configuration required specifically for cash pooling. In release 1709, the cash pool functionality is accessed via the Manage Bank Accounts app. First, users select the bank account group to be used for cash pooling, then access the CASH POOL dropdown menu, as shown in Figure 6.36.

Figure 6.36: Cash Pool menu options

For bank account groups to be used for cash pooling, ensure the following: Define only one first-level node for the bank account group.

For bank accounts placed under a sub-node, all accounts under this sub-node must be from the same company code. In the MANAGE BANK ACCOUNTS window, select a bank account group that has been defined for cash pooling, then from the CASH POOL dropdown list, choose the CREATE CASH POOL option. After selecting the CREATE CASH POOL menu option, the pooling structure is then defined. Note that there are three parts to defining the pooling structure: CASH POOL DATA, TARGET ACCOUNT information, and SOURCE ACCOUNTS (see Figure 6.37).

Figure 6.37: Create Cash Pool window

Under CASH POOL DATA, specify the cash pool ID, name, and usage. In the TARGET ACCOUNT section, specify the account information for the leading bank account to which money should be concentrated. Under SOURCE ACCOUNTS, specify the accounts from which the money is transferred to the leading account. The next step is to create a concentration run by selecting CONCENTRATION from the CASH POOL dropdown menu. This is where payment requests are created. After that, the payments follow the same process flow as covered in Section 4.2.2. 6.1.4 Reporting

SAP has provided a number of different apps that can be used to track the payment life cycle. These reports enable users to find the latest status of payments, as well as statistical data such as the number of payments by a payment type in a specified time period. SAP has also provided apps that can be used for periodic reporting. Three of these apps are covered in the following sections. Track Bank Transfers app After you have made a bank transfer, you can check the bank transfer status by checking the Track Bank Transfers app (see Figure 6.38). For example, users can check all the bank-to-bank transfer information that has been collected in the system for a given time period.

Figure 6.38: Track Bank Transfers app tile

In the Track Bank Transfers app, bank transfers are categorized into different sections according to their status; for example, if a bank transfer encounters exception issues, you can find them in the exceptions category. In the app, under DETAILED STATUS, users can see what stage of the lifecycle a payment is at; for example, new, in approval, approved, sent to bank, failed, or completed (see Figure 6.39).

Figure 6.39: Track bank transfers output screen

Payment Statistics app The Payment Statistics app provides reporting on payments made (see Figure 6.40).

Figure 6.40: Payment Statistics app tile

Cash managers can display the KPI of payments using the Payment Statistics app. They can check recent payments made through Bank Communication Manager and the total amount of payments, according to different filter criteria. Some of these are shown in Figure 6.41.

Figure 6.41: Filters for payment statistics

Some key features and capabilities of this app are: View the total amount of payments by status View the total amount of payments by company View the total amount of payments by house bank View the total amount of payments by processing days View the total amount of payments by payment method View the total amount of payments by currencies When the app is executed, it displays a graphical image of the payment statistics. From there, users are able to go to the Check Cash Flow Items app to view the details of each payment by selecting the CHECK CASH FLOW ITEMS—OPEN IN… option shown in Figure 6.42.

Figure 6.42: Payment Statistics app output

Bank Risk app With S/4HANA, SAP has introduced the Bank Risk app, which enables a company to view bank risk exposure, along with a predefined risk rating (see Figure 6.43).

Figure 6.43: Bank Risk app tile

After clicking on the tile, users see a graphical display of the company’s bank risk exposure, shown in Figure 6.44.

Figure 6.44: Bank Risk app output

The rating is assigned to each bank using the Manage Banks app. This is done by users (see Figure 6.45).

Figure 6.45: Assign bank rating

Keep in mind that the rating must be defined in configuration before it can be used. Ratings are defined by following the menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • GENERAL SETTINGS • MARKET DATA • DEFINE RATING (see Figure 6.46).

Figure 6.46: Define bank ratings

Be aware that this app is not replacing Credit RiskAnalyzer in any way and there is no integration with the Credit RiskAnalyzer functionality. 6.2 Cash balances In a new implementation, one of the cutover tasks could be to adjust the initial bank account balances. SAP customers might also have bank accounts defined in remote systems whose balances need to be set in the new Cash Management system. In this section, we discuss the topic of setting cash balances. We also discuss how the calculation of the beginning balance has changed with the move to S/4HANA. 6.2.1 Importing initial cash balances

The Import Initial Bank Account Balances program (transaction code FQM_INIT_BALANCES) uploads initial balances across bank accounts in SAP. The bank account balances are imported from Microsoft Excel format into One Exposure at the initial go-live stage, before setting the balances by G/L postings. This is a specifically formatted Excel file and the layout is shown in Figure 6.47. The Excel data includes: value date, G/L account number, technical account ID, IBAN, balance amount, and balance currency.

Figure 6.47: Upload initial bank account balances

Uploading the balances via the Excel file sets the initial bank account balance in One Exposure to the amount specified in the input file. 6.2.2 Importing cash balances for remote accounts In the case of centralized cash management, if the balance in the SAP S/4HANA system cannot be updated by importing bank statements, the Import Bank Cash Balances program (transaction code FQM21) can be used to import bank account balances on a daily basis. This is a specifically formatted Excel file and the layout is shown in Figure 6.48. The data in the Excel file includes: value date, technical account ID, IBAN, balance amount, and balance currency.

Figure 6.48: Upload bank account balances file format

As mentioned above, the bank account is specified by the technical account ID in column B, which is defined in the S/4HANA system for each bank account. As an alternative, the bank account’s IBAN can be used to identify the bank account. When using the Import Bank Cash Balances program (transaction code FQM21), you must specify exactly how the existing balances are to be updated. The following options are available: UPDATE BALANCES—only the balance for the relevant value date is adjusted. Any later balances that already exist remain as they are. UPDATE BALANCES AND INVALIDATE LATER BALANCES—the balance for the relevant value date is adjusted and any later balances that already exist are invalidated. This means that the value date balance applies to later dates as well. UPDATE BALANCES AND ADJUST LATER BALANCES—the balance for the relevant value date is adjusted and any later balances that already exist are adjusted considering the input balance for the value date. Figure 6.49 shows the Import Bank Cash Balances program inputs outlined above.

Figure 6.49: Input options to import bank cash balances

We now use the file shown above and import it for the account ending in 89765 (see Figure 6.50). Before importing the file, the cash position is displayed.

Figure 6.50: Cash Position Before Importing Balance

After importing the cash balance, the final balance is the balance in the input file, as shown in Figure 6.51.

Figure 6.51: Cash position after importing balance

6.2.3 Calculation of the opening balance Whether using Basic Cash Management or Cash Management powered by S/4HANA, the way SAP determines the opening balance in the cash position report is different to how it is calculated in ECC. In the simplest terms, the opening balance is the aggregated amount of all actual cash flows (i.e. 1900.01.01 to the first day minus 1), in One Exposure. Moving forward, all opening balances are determined by the closing balance of the previous day. The opening balance is the previous day’s closing balance plus any forecasted cash flows with a value date of that day. Put another way, SAP does not store a balance number for each bank account. Instead, when the cash position report is run, the balances are calculated in real-time from data in One Exposure. In S/4HANA, when a bank statement is imported into SAP, whether the bank statements are posted to the ledger or not, they are still reflected in the balance displayed. This is different to ECC. The cash position report continues to be a value-date-driven report and cash flows continue to be shown by planning level. CM groupings are no longer used to drive the bank accounts pulled into the report as they were used in ECC. Instead, the bank hierarchies and bank groups are used. 6.3 Cash operations configuration In this section, we cover the configuration related to cash operations.

6.3.1 Define planning levels Planning levels are a basic element used in SAP’s Cash Management solution used to categorize cash flows in the cash position. Planning levels are then assigned to planning types, planning groups, and flow types in later configuration steps. It is important for customers to define planning levels specific to their needs because they are visible to business users in the cash position. Planning levels are defined in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • PLANNING LEVELS AND PLANNING GROUPS • DEFINE PLANNING LEVELS. By following this path, the user is taken to the CHANGE VIEW “PLANNING LEVELS” OVERVIEW window shown in Figure 6.52.

Figure 6.52: Define planning levels

6.3.2 Define planning groups Operating cash flows, such as invoices, purchase orders, and sales orders are reflected in the liquidity forecast report by planning group. Planning groups are entered in the customer and vendor master records and are used to categorize the type of customer or vendor. All planning groups are mapped to a planning level. Planning groups are defined in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • PLANNING LEVELS AND PLANNING GROUPS • DEFINE PLANNING GROUPS. By following this path, the user is taken to the CHANGE VIEW “PLANNING GROUPS” OVERVIEW window, as shown in Figure 6.53.

Figure 6.53: Defining planning groups

6.3.3 Define flow types With Cash Management on S/4HANA, SAP has introduced flow types, which classify information from different source components or different steps in the cash flow lifecycle. Flow types describe how a cash flow moves through the system. For example, flow types follow the document chain from a cash flow generated by a source application, such as sales and distribution, materials management, or SAP Treasury and Risk Management, to a payment generated and executed, to the actual cash flow received in a bank statement. Flow types are not visible to users but are tracked by SAP at the document level. The flow type is a type of tag SAP attaches to the flows from different source applications, such as FI, MM, SD, TRM, etc., so the cash management reports know what type of cash flow they are. Only data assigned with flow type information can be consumed and used in Cash Management applications. To use the new SAP Cash Management, it is important to understand the new flow type concept. SAP provides a default logic; however, customers can influence the default logic through configuration. Configuration is only necessary if customers require flow types that are different to what is delivered in standard SAP. This is done in the IMG under

FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • FLOW TYPES • DEFINE FLOW TYPES (see Figure 6.54).

Figure 6.54: Define flow types

More on flow types With Cash Management on S/4HANA, SAP has also introduced the Flow Builder that derives cash flows and stores the flow types and liquidity items in One Exposure for analytical purposes. The Flow Builder is discussed further in Section 8.1.3. In general, the integration of Financial Operations into One Exposure covers information on invoices, payments, and bank statements. SAP classifies accounting document line items into the following categories: Receivables/payables Cash-in-transit Cash The SAP standard flow type categories and how they are determined are listed in Table 6.3.

Table 6.3: SAP standard flow type categories

For the accounting document line items mentioned above, SAP standard functionality derives the flow categories shown in Table 6.4. There are over one hundred SAP-delivered flow categories. The flow categories are not changeable in configuration, but are assigned to flow types, which are configurable. We have listed a few of the basic flow categories here. Users should reference their SAP system to see the full list of flow categories.

Table 6.4: Examples of receivables and payables flow categories

During processing in SAP, as a transaction moves through its lifecycle, flow types are automatically assigned to the associated data in One Exposure. The flow type is stored in the One Exposure table in the FQM_FLOW FLOW_TYPE field, and in the BSEG accounting document table in the BSEG-FQFTYPE field. 6.3.4 Assign planning levels to flow types Planning levels are assigned to flow types in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • FLOW TYPES • ASSIGN PLANNING LEVELS TO FLOW TYPES (see Figure 6.55).

Figure 6.55: Assign planning levels to flow types

6.3.5 Assign flow types to G/L accounts If a customer requires different accounting document flow types to what is delivered in standard SAP, they must define the flow types and assign them to G/L accounts in configuration. By following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • FLOW TYPES • ASSIGN FLOW TYPES TO G/L ACCOUNTS, the user is taken to the customizing window shown in Figure 6.56, where flow types are assigned to G/L accounts.

Figure 6.56: Assign flow types to G/L accounts

Note that there are two flow type fields. The first is used for debit entries and the second is used for credit entries.

Reconciliation accounts Do not assign flow types to a G/L account that is characterized as a reconciliation account with account type V (contract accounts receivable).

6.4 Summary We have seen in this chapter that there are quite a few changes when moving from ECC’s cash management to Cash Management powered by S/4HANA. One key change is that SAP has moved configuration tasks to application-side processing which can be done by business users in production. This means a reduction in the amount of configuration required, and faster overall implementation. The other key difference with S/4HANA is the dramatically improved user experience with the new Cash Operations Fiori tiles. Within the cash management process, SAP has introduced various KPI tiles, which were not available in ECC. In upcoming releases, SAP is introducing even more.

7 One Exposure One Exposure, as previously discussed, is a data storage structure for the data that feeds the cash management reports. One Exposure ensures that forecast and actual data have the same level of granularity. This is key for reporting and analytical purposes, because it enables “apples to apples” comparisons. In this chapter, we cover One Exposure in more detail. In literature provided by SAP, One Exposure is typically called One Exposure from Operations or One Exposure from Operations Hub. For simplicity purposes, we use the term One Exposure. 7.1 One Exposure overview One Exposure is a central data storage structure for all transactional data that impacts on financial exposure. It is the underlying source of cash position data, whether using Classic Cash Management (Cash Management Lite) or SAP Cash Management powered by SAP HANA. Cash flows from the following sources are stored in One Exposure: Financial operations Treasury and risk management Customer and mortgage loans Contract accounts receivable and payable 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 Note that planning data is missing from the above list. SAP’s solution for liquidity planning continues to change. It is in a state of transition from the previous solution to a new solution. A number of programs build data in One Exposure, including balance records and cash flows from operations. All 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. As of S/4HANA release 1709, the only data that is not stored in One Exposure is the memo records and planning data. The FDES table in SAP is where memo records are stored. Release 1809 has done away with this table, and the memo record data is stored in One Exposure. The technical name of One Exposure is Financial Quantity Management (FQM) and the underlying table for One Exposure is FQM_FLOW. Figure 7.1 shows a sample table entry from the One Exposure table.

Figure 7.1: One Exposure sample table entry

One Exposure transaction codes and programs Where you see transaction codes or programs with FQM, this is most likely part of One Exposure. If you see the term “Exposure Hub”, this is an older term used for One Exposure. Exposure Hub and One Exposure are synonymous.

7.2 Certainty level Data is stored in One Exposure with a certainty level. A certainty level is a way to capture the likelihood of the cash flow occurring on the corresponding

date. In other words, it is a probability of the forecasted cash flow becoming an actual cash flow. For example, all previous day bank statement postings have a certainty level of ACTUAL because the transaction has already happened. The possible values for certainty level are displayed in Table 7.1.

Table 7.1: SAP-delivered certainty levels

7.3 Aggregating flows The items flagged as ACTUAL in One Exposure, which determine the opening balance of bank accounts, accumulate over time. To address this, the ACTUAL items in One Exposure are replaced with “aggregated” flows when FQM_AGGREGATE_FLOWS is run. (FQM_AGGREGATE_FLOWS is both the transaction code and the program name.) The Aggregate Flows program provides a feature for aggregating historical data to reduce the data volume to the quantity and granularity required for business applications such as SAP Cash Management. In addition, this program aggregates flows in One Exposure to delete any personal data. The Aggregate Flows program deletes flows with certainty level ACTUAL in One Exposure and substitutes them with aggregated flows.

The program creates aggregated flows for existing ACTUAL flows with a transaction date up to the date on the selection screen (see Figure 7.2).

Figure 7.2: Aggregate Flows—input screen

The aggregated flows created do not contain any personal data. This is to comply with data protection laws applicable in specific countries. Therefore, the following fields are blank: PARTNER CUSTOMER VENDOR MATERIAL PROJECT PROFIT CENTER Finally, you use the Aggregate Flows transaction to physically delete all flows that are marked as deleted (this means FQM_FLOW-DELETED = 'X'). As a result, the volume of data in One Exposure is further reduced. 7.4 Setting up One Exposure You can set up, or migrate to, One Exposure in the IMG. Follow the menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • DATA SETUP. The steps are outlined in Table 7.2.

Table 7.2: Setup steps for One Exposure

7.4.1 Activate source applications The first step in migrating to One Exposure is activating the source applications, which is done in the IMG under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • DATA SETUP

• ACTIVATE INDIVIDUAL SOURCE APPLICATIONS APPLICATIONS (see Figure 7.3).

OR

ACTIVATE MULTIPLE SOURCE

Figure 7.3: Activating source applications for One Exposure

SAP provides two configuration nodes to activate source applications. The ACTIVATE INDIVIDUAL SOURCE APPLICATIONS node allows you to activate combinations of source applications and company codes individually. The ACTIVATE MULTIPLE SOURCE APPLICATIONS node allows you to activate or deactivate multiple company codes for several source applications simultaneously. Activating a source application means that One Exposure accepts data from that source. It is also necessary to activate this source application even if data from remote systems is being transferred into One Exposure. The source applications are shown in Table 7.3. Source Key Source Description BKPF

Financial Operations

CMDSR

Manual Entry of Cash Position w/o Bank Account

CML

Customer and Mortgage Loans

CMSND

Manual Entry of Cash Position on Bank Account

MEBAC

Manual Entry of Cash Balances

MM

Materials Management

SDCM

Sales and Distribution (CM)

TRM

Treasury and Risk Management

Table 7.3: One Exposure source applications

The Financial Operations source application comprises accounting documents such as invoices, payments, and bank statements. Without this

configuration, the bank balance import program or transaction cannot function, and the system encounters a hard error. 7.4.2 Delete entries from One Exposure If required, execute FQM_DELETE with the option Persist Log [X] marked. In addition, this transaction does not delete data physically from FQM_FLOW table but marks the field 'DELETED' = X so that the associated entries do not appear in any cash position reporting. You need to run transaction code FQM_DELETE, and in the SOURCE APPLICATION field enter the source application to be deleted. (See Figure 7.4.) Then, press EXECUTE. For the final run, you need to deselect the TEST RUN checkbox and select PERSIST LOG.

Figure 7.4: Delete data from One Exposure

For FI and MM application data, you use transaction code FCLM_FB_UTIL to physically delete the data from the FQM_FLOW table (see Figure 7.5).

Figure 7.5: Delete flow builder flows

When encountering errors displaying data Because One Exposure holds the data reflected in the Cash Flow Analyzer report, if there are issues with the data displayed, a first place to look is in the One Exposure table (FQM_FLOW).

7.4.3 Distributed cash management When using a sidecar deployment approach (see Section 1.6.2), the cash flow information collected in ECC must be transferred to SAP Cash Management powered by SAP HANA in order to be reflected in the Cash Operations reporting. This is done by activating standard SAP distributed cash management. When using SAP distributed cash management, SAP Cash Management is activated in ECC, and the SAP system collects 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 to S/4HANA. It has been available from SAP for at least 15 years. The IDocs used to transfer the operations cash flows from the ECC box to One Exposure on the SAP Cash Management S/4HANA box are CMSEND and CMREQU. The transfer of data could be either scheduled or manually triggered, as mentioned previously. For example, if the scheduled transfer of information is hourly, and a cash manager wants a refresh of the cash flows from the ECC system a half hour after the last scheduled run, he/she can manually trigger the interface to run. If Distributed Cash Management is used, the company codes, planning groups, planning levels, and business areas of the sender’s system are mapped to company codes, planning groups, planning levels, and business areas in the centralized Cash Management Powered by HANA system using the IMG path FINANCE SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • DATA SETUP • INBOUND MAPPING FOR INTEGRATION OF REMOTE DATA INTO ONE EXPOSURE (see Figure 7.6).

Figure 7.6: Distributed cash management configuration

7.5 Summary One Exposure is a real-time collection point and storage location for operational data that is relevant for managing cash and liquidity. One key aspect of One Exposure’s design is that data feeding the cash management reports (both forecast and actual) is stored in one table. This ensures that planned, forecast, and actual data have the same level of granularity, which is key for comparison/analytical reporting and also facilitates forecast-to actual comparison reporting. We consider this a huge win over ECC.

8 Liquidity Management Liquidity Management brings together analysis of actuals cash flows, mid-term liquidity forecasting, and liquidity planning. With Liquidity Management, cash managers can analyze how cash was spent, forecast mid-term liquidity trends, and perform a rolling plan in order to understand their obligations and determine whether they need to make investment or borrowing decisions. To provide a little background on SAP terminology, SAP differentiates between various cash management timeframes: short-term, mid-term, and long-term planning. The Cash Operations component covers cash positioning and short-term planning, and the Liquidity Management component covers mid to long-term planning. Historical cash postings are referred to as actuals, which are displayed in Cash Flow Analysis. The terms mentioned here are shown with the associated time horizons in Figure 8.1.

Figure 8.1: SAP Cash and Liquidity Management terminology

In this chapter, we cover Actual Cash Flow Analysis, forecasting, and liquidity planning.

8.1 Actual Cash Flow Analysis In this section, we give a basic overview of what Actuals Cash Flow Analysis is and provide detailed information on how it works. 8.1.1 Basic overview Readers familiar with the Liquidity Planner module in ECC, will be happy to know that SAP has incorporated much of the Liquidity Planner functionality into the Actual Cash Flow Analysis process. The functionality is similar in many ways but has been simplified with the move to S/4HANA. Cash Flow Analysis for actuals answers questions such as “How much cash came in as customer receipts this week?”, or “How much did we spend on payroll this month?”, etc. Having quick and up-to-date access to this type data is important for all organizations. The key component to Cash Flow Analysis is the liquidity item. Liquidity items represent the use and purpose of the cash flow. With liquidity items, cash flows can be classified into different categories and sub-categories in a hierarchical view; for example, cash flows for operations, cash flows for financing, and cash flows for investment. A liquidity item is the term used in Cash Flow Analysis to define the buckets or categories that cash flows are tracked under for actuals determination. The liquidity items are used in the cash and liquidity related reports and used for displaying the actual cash transactions. Liquidity Items are defined as part of the implementation configuration. How a company defines the liquidity items depends on the company’s business, such as: payroll overhead customer receipts prepaid expenses purchases of property and equipment proceeds from sales of investments purchases of investments bond payments In addition to defining liquidity items, liquidity hierarchies are also defined, which are structured layouts to display the uses of cash. A common hierarchy to display actual liquidity items is shown in Figure 8.2, and has a

layout similar to a cash flow statement.

Figure 8.2: Definition of a liquidity hierarchy

Because Actuals Cash Flow Analysis starts at the cash accounts and traverses through the clearing documents until a liquidity item is determined, there is no risk of pulling in a non-cash item. There are no accruals that need to be backed out. This is an inherent benefit of using Cash Flow Analysis over using other ways of determining the sources and uses of cash. The liquidity hierarchy is used in liquidity planning and in actuals reporting. It is important that the plan data is captured at the same level of granularity as the actuals data so that an actuals-to-plan data comparison is possible. There is no restriction on the number of liquidity item hierarchies that can be defined. However, when using Liquidity Planning, at least one liquidity hierarchy is required. Both the accounting document table BSEG and One Exposure track the liquidity item with cash flow transactions. In addition, users can enter a liquidity item when creating memo records. 8.1.2 Actuals determination rules Actuals determination is the process of assigning liquidity items to cash transactions. SAP provides three methods for determining actuals: Queries G/L account assignment User exit (FCLM_LQF_DERIVE_LQITEM_SAMPLE)

Queries and G/L account assignment can be used together, but if a user exit is used to define custom logic for deriving and assigning liquidity items, SAP only uses the logic defined in the user exit. Using queries Cash Flow Analysis for actuals determination has different levels at which the query related assignment rules can be defined (see Table 8.1). The assignment rules drive how the liquidity items (the predefined categories) are assigned to cash transactions. For each level, it is important to understand the criteria that can be used to classify the transactions. Origin Description C

Origin C applies to line items with account type D (customer) or K (supplier). Typical assignments made at this level are by customers and vendors.

D

Origin D applies to line items with account types other than D or K. Assignments can be made by controlling objects, such as cost centers and profit centers. For data integrated into One Exposure from source applications in the central system, such as TRM, CML (Loans Management module), or FI-CA (Contract Accounts Payable and Receivable) data, there is no default derivation rules for liquidity items. You need to define query and query sequences for this purpose. In this case, you should always specify the Origin as X.

X

Table 8.1: Cash Flow Analysis origins

C-level queries By using C-level queries, users can easily assign cash postings related to specific customer and vendor criteria to a liquidity item. This can be used, if, for example, there is a vendor or group of vendors that are all assigned to a specific category, such as tax payments, or intercompany payments. The assignment can easily be made for the vendor or group of vendors by defining query IDs and assigning them to a query sequence.

Liquidity item derivation sequence It is important to keep in mind that when deriving liquidity items, SAP first tries to apply the query sequences. If unsuccessful, it then moves to the default liquidity items by G/L accounts. SAP attempts to assign a liquidity item until it finds one. Once it finds a liquidity item for a cash transaction, it moves to the next transaction.

At the customer and vendor level, cash postings related to certain customers or vendors can be tagged to a liquidity item. For example, if a company uses

a specific range of customers and vendors for tax payments, any cash postings to customers and vendors in this range can be assigned to the LP_APTAX liquidity item, as shown in Figure 8.3.

Figure 8.3: C-level query assignment

D-level queries There are many fields that can be used for D-level assignments; for example, controlling objects such as cost center, profit center, etc. (see Figure 8.4).

Figure 8.4: D-level query assignment

X-level queries X-level queries can use Transaction Manager, CML, or FI-CA fields such as PRODUCT TYPE, SECURITIES ACCOUNT, PORTFOLIO, etc. to support liquidity item assignments, as shown in Figure 8.5.

Figure 8.5: X-level query assignments

In addition to creating queries, a few additional steps are required: Create a query sequence (FLQC15) Create queries (FLQQA1) Assign the queries to query sequences (FLQQA5) Assign the liquidity item derivation to company codes (FLQC0) Before the query IDs can be used, they need to be assigned to a query sequence. The query sequence holds the query IDs that should be used and the order in which they are used. There is a number (NO.) column to the left of the QUERY ID, as shown in Figure 8.6. This number is used to drive the order in which the query IDs are run.

Figure 8.6: Assign queries to query sequence

Again, remember that SAP processes each cash flow posting and executes the rules that have been set up until it finds a rule that applies to the cash posting. Once an assignment is made, SAP moves onto the next cash posting. Keep in mind this logic when assigning the numbers on the left of the query IDs.

Leaving space between Query IDsL When entering a number in the NO. column, leave enough spacing between the numbers so additional queries can be added, if necessary, without having to reorder the queries.

Assignment by G/L account Configuration “by G/L account assignment” takes the place of the ECC Liquidity Planner Assign Info Accounts (transaction code FLQINFACC) step, which maps the G/L account to a liquidity item. Figure 8.7 shows a simplified example of how this actuals determination works by traversing the document chain. In this example, the liquidity item assignments are made via “By G/L Account Assignment”. The cash postings for the example are on the left. The arrows indicate how the Flow Builder traverses the FI documents from the cash postings on the right. After the actuals determination program is run, the cash postings have $100 assigned to liquidity item LI_RENT and $200 to LI_OVERHEAD.

Figure 8.7: Example of assignment by G/L account

8.1.3 Flow Builder Flow Builder has been introduced with the new cash management functionality to integrate FI and MM data into the new cash management reports. Flow Builder is a program that runs in the background and populates fields, such as the liquidity item, in One Exposure. It makes the actuals determination programs FLQAC, FLQAD, and FLQAF in ECC’s Liquidity Planner obsolete. Flow Builder is typically scheduled to run periodically in the background. For each document posted, Flow Builder attempts to determine the liquidity item that should be assigned. When Flow Builder is run, it first uses the C, D, and X origin queries and then traverses the document chain to assign the liquidity item based on the liquidity item to G/L account settings. Once the actuals liquidity items are determined, they can be used to create reports such as planned versus actual reporting, as well as month-over month and year-over-year reporting on cash expenditures and receipts. These custom reports can be created in S/4HANA or in BW. There are two apps that fall under Actual Cash Flow analysis: the Actual

Cash Flow app, which is a KPI (graphical) tile (see Figure 8.8), and the Cash Flow Detailed Analysis app.

Figure 8.8: Actual Cash Flow Tile

Clicking on the Actual Cash Flow tile brings up a graphical display, such as the one shown in Figure 8.9.

Figure 8.9: Actual Cash Flows app output

From the Actual Cash Flows app, users are able to easily view the data in the Cash Flow Detailed Analysis app (see Figure 8.10).

Figure 8.10: Cash Flow Detailed Analysis app tile

Figure 8.11 shows an example of the Actuals Cash Flow reporting that is possible with this new functionality.

Figure 8.11: Example of Actuals Cash Flow reporting

8.2 Liquidity forecasting In SAP terminology, forecasted cash flows are those flows that have already been recorded in SAP but have not yet happened. These forecasted cash flows can also be analyzed within the same analytical reporting structure, making the actual and the forecasted cash flows immediately comparable. Forecast data is data based on business for which contracts and invoices are in place in SAP. Treasury needs to see forecast data for AR (Accounts Receivable) and AP (Accounts Payable) invoices, purchase orders, and sales orders entered into SAP. In addition, data from Treasury trades, FI-CA, and loans from CML also need to be forecasted. Treasury departments use this information for short-term forecasting. Operating cash flows (invoices, purchase orders, sales orders) are reflected in the liquidity forecast report by planning group. A planning group is defined

in configuration, stored in the vendor and customer master records, and then transferred to the One Exposure structure with transactional data. As mentioned previously, One Exposure is the structure where SAP stores the forecasting and actual cash flows, which feed the cash position and liquidity forecast apps. All planning groups are mapped to planning levels. There is typically one planning level for vendor data and one planning level for customer data. By doing this, from a higher-level perspective regarding liquidity forecast, all vendor and customer invoices are in separate lines items. The PLANNING GROUP field should be set as a required field in all customer and vendor master records. The Treasury consultant should assist AP and AR in classifying vendors and customers by planning group. The two main apps that fall under Liquidity Forecast are the Liquidity Forecast app and the Liquidity Forecast Details app (see Figure 8.12 and Figure 8.16).

Figure 8.12: Liquidity Forecast app tile

With the Liquidity Forecast app, you can forecast the liquidity trend approximately 90 days out in various dimensions and using different filter conditions. Figure 8.13 shows the different data display options available through the report.

Figure 8.13: Liquidity Forecast app dimensions

The Liquidity Forecast is calculated based on the transaction data from One Exposure and memo records. Figure 8.14 shows one display option available through this KPI app.

Figure 8.14: Liquidity Forecast app output screen

As shown in Figure 8.15, there are a number of different chart types that can be used to display the data.

Figure 8.15: Liquidity Forecast app chart types

Users can go directly from the Liquidity Forecast app to the Check Cash Flow Items app or the Liquidity Forecast Details app (see Figure 8.16).

Figure 8.16: Liquidity Forecast Details app tile

Figure 8.17 shows the output screen of the Liquidity Forecast Details app.

Figure 8.17: Liquidity Forecast Details app output

In the actual-to-forecast comparison report, there is no variance column. Typically, in actual to forecast reporting, there is either a variance amount or a percentage. To add the variance column, customers need to do an enhancement. 8.3 Liquidity planning Liquidity planning seems to be an area of SAP that is forever changing. SAP’s current S/4HANA planning solution uses Integrated Business Planning for Finance, which requires a separate license. SAP is moving from Integrated Business Planning for Finance to SAP Analytics Cloud (SAC) for liquidity planning starting with release 1902.2 Although we anticipate that the liquidity planning functionality to be offered in SAC will be similar to that available in Business Planning and Consolidation (BPC), because the offered functionality is changing, we provide a high-level overview here.

Change in direction for liquidity planning Because SAP’s solution for liquidity planning is changing with release 1902, we do not spend a significant amount of time on this subject in this book.

The Liquidity Planning apps help users to create liquidity plans, which are projections for future cash flows. The liquidity plans are created using the

same analytical structure used by the Liquidity Analysis and Liquidity Forecast apps. The actual and forecasted cash flow data can be used as the reference data in the Liquidity Planning models. As a result, the actual, forecasted, and planned cash flows can be compared in the same reporting structure. The plan data should be at the same level of granularity as the actual data, or at least rolled up to the same level. This is necessary to facilitate the plan versus actual comparison reporting. We would like to mention that planned data is not stored in One Exposure. 8.3.1 Planning process The planning process is as follows: Each period, a new planning cycle is started. This step is done by someone in Treasury. Next, the subsidiaries enter or submit their forecast for the next period. There are three options for initially populating (auto-fill) the planned data into the layout: Liquidity forecast data Previous period plan data Last year’s actual data Users can adjust the data after the figures are initially populated. Treasury can check whether all subsidiaries have submitted their plans using the Status Tracker app. Once all plans are submitted, Treasury looks at the aggregated plan data, and can make final adjustments, if necessary. The plan for the period is then set. The above steps are illustrated in Figure 8.18.

Figure 8.18: SAP planning process flow

The plan data is entered into the SAP system using SAP Integrated Business Planning for Finance. This is different to SAP BPC. SAP Integrated Business Planning for Finance is designed for planning only, and not for consolidations. Figure 8.19 shows a sample screen in which the plan data is entered. Users can also upload the plan data from Excel.

Figure 8.19: Example planning template

8.3.2 Planning Business Intelligence content SAP is delivered with standard Business Intelligence (BI) content that can be activated and used for reporting of planned, actual, and forecasted data. A description and activation of the BI content is beyond the scope of this book. 8.4 Liquidity Management configuration In this section, we cover the Liquidity Management configuration settings. A prerequisite to Liquidity Forecast is configuration of SAP Cash Management. A prerequisite to Cash Flow Analysis or actuals determination and Liquidity Forecast is configuration of One Exposure. 8.4.1 Actuals Cash Flow Analyzer configuration In this section, we cover the configuration needed for actual cash flow analysis. Define liquidity items Liquidity items serve as an important dimension for financial planning and reporting in SAP Cash Management. Liquidity items are defined in configuration by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • EDIT LIQUIDITY ITEMS (see Figure 8.20). Users of ECC’s Liquidity Planner functionality will notice the second column, CASH FLOW DIRECTION, indicating the direction of the liquidity item. This is a new field with S/4HANA, which is currently not used, but may be used in future releases.

Figure 8.20: Define liquidity items

Table 8.2 shows liquidity items that are hard-coded and must be defined if the desired functionality is to be used. Liquidity item Description

LP_CASHOP

When the cash position and bank balance data should be integrated/mapped

LP_DPOP

When an opening balance for Treasury and Risk Management trades is desired

LP_EXF

Cash planned to be converted from another currency Cash planned to be converted to another currency

LP_EXI

Table 8.2: Hard-coded liquidity items

Define liquidity hierarchy Liquidity hierarchies are defined in configuration by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • DEFINE LIQUIDITY ITEM HIERARCHIES. This takes you to the LIQUIDITY ITEM HIERARCHY LIST screen (see Figure 8.21).

Figure 8.21: Define liquidity hierarchy

Define queries for liquidity item derivation All types of queries for liquidity item derivation can be created by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • DERIVATION RULES FOR

LIQUIDITY ITEMS • DEFINE QUERIES FOR LIQUIDITY ITEM DERIVATION. In the EDIT QUERY and screen, LIQUIDITY populate ITEM the fields, QUERY as shown COCD Figure (query 8.22. company code), NAME, DESCRIPTION

Figure 8.22: Define C-level query

Next, press the CONDITIONS button to specify the condition the assignment applies to. There are many fields available for assignment. Open the ACCOUNTING DOCUMENT SEGMENT folder on the left side of the popup window, and double click on the ACCOUNT TYPE and VENDOR fields. These fields then appear on the right side of the popup window and can be used in the condition. Enter K in the ACCOUNT TYPE field (to indicate vendors) and enter the vendor number or vendor number range in the VENDOR field, as shown in Figure 8.23.

Figure 8.23: Define vendor query

When complete, press the SAVE button to save the query. The query is now complete (see Figure 8.24). There is no restriction on the number of queries that can be created.

Figure 8.24: Completed vendor query

Define query sequences Before queries can be used, they need to be assigned to a query sequence. The query sequence holds the queries that are used in the actuals determination run. Query sequences are defined by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • DERIVATION RULES FOR LIQUIDITY ITEMS • DEFINE QUERY SEQUENCES (see Figure 8.25).

Figure 8.25: Define query sequence

The query sequence is entered, along with a name and description. A company code can be assigned or left blank to apply to any company code. Assign queries to query sequences Queries are assigned to query sequences by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • DERIVATION RULES FOR LIQUIDITY ITEMS • ASSIGN

QUERIES TOscreen OVERVIEW QUERY(see SEQUENCES, Figure 8.26). which takes you to the CHANGE VIEW “QUERIES”

Figure 8.26: Assign query to query sequence

There is a NO. (number) column to the left of the QUERY ID. This number is used to drive the order in which the query IDs are executed. Again, remember that the Flow Builder processes each cash posting and executes the rules that have been set up until it finds a rule that applies to the cash posting. Once an assignment is made, SAP moves on to the next cash posting. Keep this logic in mind when assigning the numbers in this column. Define liquidity item derivation settings for company codes In this activity, you assign the default derivation logic for liquidity items to company codes. Each entry assigns a query sequence and a derivation function to a company code, which the system uses to derive liquidity items for that company code. To assign the query sequence to all company codes, leave the company code field blank. This step is done by following the IMG path FINANCIAL CASH MANAGEMENT SUPPLY • LIQUIDITY CHAIN MANAGEMENT ITEMS • DERIVATION • CASH RULES AND LIQUIDITY FOR LIQUIDITY MANAGEMENT ITEMS • DEFINE LIQUIDITY ITEM DERIVATION SETTINGS FOR COMPANY CODES (see Figure 8.27). In this configuration step, if a user exit is used, it is specified under DERIVATION FUNCTION.

Figure 8.27: Assign derivation parameters to company code

Define default liquidity items for G/L accounts

Liquidity items are derived according to the customer-configured query sequences. If the query sequence fails to determine a liquidity item, a default liquidity item defined here is used and recorded in an accounting document line item table. A default liquidity item for each G/L account is assigned by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • LIQUIDITY ITEMS • DERIVATION RULES FOR LIQUIDITY ITEMS • DEFINE DEFAULT LIQUIDITY ITEMS FOR G/L ACCOUNTS (see Figure 8.28). The G/L accounts entered into this table are the G/L accounts that are relevant to cash postings.

Figure 8.28: Define default liquidity items for G/L accounts

If the checkbox in the FURTHER column is selected, the Flow Builder will not stop on that liquidity item but will try to derive a liquidity item for the cash posting by continuing to traverse the document chain. Scheduling the Flow Builder The Flow Builder program (see Figure 8.29) can be accessed by using transaction code FCLM_FLOW_BUILDER.

Figure 8.29: Flow Builder program

Flow Builder has two RUNNING TYPE options: MASS RUN and DELTA RUN. The delta run processes the newly posted or modified accounting documents. The Flow Builder program has a JOB DELAY field. Once a new accounting document is posted, the delay kicks in, after which the Flow Builder is triggered as a background job to perform the delta run. This populates One Exposure with the liquidity item for the newly posted document(s). 8.4.2 Changing derivations in production Liquidity items can be created in configuration, but it is also possible to create or change liquidity items in application-side processing by using transaction code FLQC1. The reason for this is to enable liquidity items to be initially created for a project in configuration, which facilitates the liquidity items to be initially moved between systems with a transport; these are then modifiable by business users in production. A similar logic applies when defining queries and assigning the queries to query sequences. However, the following two steps are not moved between systems with a transport and must be defined manually in each system:

Define queries for liquidity item derivation (transaction code FLQQA1) Assign queries to query sequences (transaction code FLQQA5)

8.4.3 Liquidity planning configuration As mentioned previously, with release 1902, SAP is moving from BPC to SAC for liquidity planning. Because the offered functionality is changing, we only provide a high-level overview of the liquidity planning configuration here. Liquidity planning configuration can be found in configuration, under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING (see Figure 8.30).

Figure 8.30: Liquidity planning configuration

Maintain planning unit settings Planning units are organizational units that need to enter liquidity plan data. Each planning unit typically corresponds to a company code. Planning Units and their corresponding settings are defined under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING • MAINTAIN PLANNING UNIT SETTINGS (see Figure 8.31).

Figure 8.31: Maintain planning unit settings

Activate planning unit hierarchy In this step, the planning unit hierarchy to be used is activated, which makes the planning unit hierarchy available for use in the liquidity planning process. Planning unit hierarchies are activated under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING • ACTIVATE PLANNING UNIT HIERARCHY (see Figure 8.32).

Figure 8.32: Activate planning unit hierarchy

Define reference data sources Reference sources are used to categorize different sources or types of data, such as actuals, forecast, plan, etc. SAP predefines standard reference sources, and SAP customers can also define their own reference data sources if needed. Reference data sources are defined in configuration under FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING • DEFINE REFERENCE DATA SOURCES (see Figure 8.33).

Figure 8.33: Define reference sources

Exclude liquidity items representing balance values Liquidity items can be defined to represent cash flows or balance amounts. In liquidity planning, only the liquidity items that represent cash flows should be taken into consideration. To exclude liquidity items that represent balance amounts from the liquidity planning calculation, you must specify the liquidity items defined in the system that represent balance amounts. This is done by following the configuration path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING • EXCLUDE LIQUIDITY ITEMS REPRESENTING BALANCE VALUES. Using this configuration, users should press the NEW ENTRIES button then enter the balance amount liquidity items that should be excluded from the liquidity planning calculation, as shown in Figure 8.34.

Figure 8.34: Exclude liquidity items from liquidity planning

Define Planning Types Customers can define their own planning types, which can be done in configuration by following the menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • LIQUIDITY PLANNING • DEFINE LIQUIDITY PLANNING TYPES (see Figure 8.35). In this step, the user presses the NEW ENTRIES button and enters a planning type identifier, a description, and a longer text field.

Figure 8.35: Define planning types

8.5 Summary With the Liquidity Management design in S/4HANA, there is a big change in the underlying structure of the data. Actual and forecasted data are stored at the same level of granularity, thereby facilitating comparison and analytical reporting. A somewhat undesirable aspect of Liquidity Management is that liquidity planning continues to be a changing design. SAP customers who have implemented Integrated Business Planning for Finance will need to move to SAC in the coming years. In addition, as previously mentioned, planning data is not stored in One Exposure with the actual and forecast data, which makes comparison and analytical reporting more difficult. In moving ECC’s Liquidity Planner functionality to S/4HANA with the Actuals Cash Flow Analysis, many more SAP customers are now able to take advantage of the user-friendly functionality and rich reporting that it provides.

9 Overview of Release 1809 SAP continues to push forward with new functionality and improvements to existing functionality. In this chapter, we describe some of the new functionality delivered with SAP Cash Management powered by SAP HANA in release 1809. 9.1 Architecture overview Figure 9.1 shows the architecture for release 1809. Note that the plan data is stored outside of One Exposure (FQM_FLOW). See the lower level of the screen that is in orange.

Figure 9.1: SAP S/4HANA release 1809

9.2 Machine Learning Cash Application SAP is moving into machine learning in multiple areas. One such area is in lockbox cash application. There is a downgraded SAP note regarding release 1709 covering the machine learning lockbox cash application functionality. Companies need to be on cash application for a number of months in order for SAP to have the history to apply to machine learning functionality. SAP Cash Application intelligently learns the matching criteria from historical cash applications, reads and processes payment advice documents, and automatically clears payments with minimal intervention. See Figure 9.2 for a pictorial view of the machine learning lockbox cash application process.

Figure 9.2: Machine learning cash application process

9.3 Bank Account Management In release 1809, SAP made significant strides in the area of Bank Account Management (BAM), with bank fee analysis software and bank correspondence, which we cover in the following sections. 9.3.1 Bank fee analysis Bank fee analysis is new functionality in release 1809. With this functionality, SAP continues to close the gap on traditional Bank Account Management software, which was often an add-on software that SAP customers would need to purchase from a third party. There are three tiles included in the bank fee analysis functionality. First, the bank Manage Bank Fee Conditions app (see Figure 9.3), allows SAP customers to create, edit, and delete bank fee conditions. A condition defines how bank fees should be charged for a certain bank service and is considered master data on SAP.

Figure 9.3: Manage Bank Fee Conditions app tile

Figure 9.4 shows the definition of a bank fee condition.

Figure 9.4: Definition of bank fee condition

The system uses the conditions to validate the imported bank fee data to see if there are any mistakes or improper charges. Next, we have the Monitor Bank Fees app (see Figure 9.5). After conditions have been defined, this app is used to assign the conditions to bank services.

Figure 9.5: Monitor Bank Fees app tile

Using the Monitor Bank Fees app, users can perform validations on the imported bank fees to identify if there are any mistakes in bank service charges. In addition, users are able to keep track of their company’s bank service charges using various data displays. It is possible to analyze bank fees using different drill-downs and combinations of drill-downs, such as comparison of money spent in different companies, regions, and banks, monitoring service charges over time, by bank, etc. (see Figure 9.6).

Figure 9.6: Monitor bank fees reporting

With the initial rollout of bank fee analysis, the CAMT086 ISO 20022 format is supported; this is an ISO standard format. Using the third app, Import Bank Services Billing Files app (see Figure 9.7), a bank fees file, with the above format, is imported into SAP.

Figure 9.7: Import Bank Services Billing Files app tiles

After clicking on the Import Bank Services Billing Files tile, a screen similar to that shown in Figure 9.8 is displayed.

Figure 9.8: Import Bank Fees File program

Using this functionality, it is possible to set up alerts for certain situations

such as the following: Alerts when a type of service increases or decreases for a specific bank account Alerts when the unit price of a certain service type changes for a specific bank account Alerts when volumes of a certain service type for a bank account exceeds a predefined threshold Because in most cases the transactions generating the bank fees are initiated in SAP (e.g. the payments are generated in SAP), tools are also provided to help companies validate the fees; for example, the number of wire transfers executed with a bank in a quarter. One such tool is the Payment Statistics app. 9.3.2 Bank Correspondence Bank Correspondence (an Adobe form) can now be generated by SAP for the following two scenarios: Close bank account(s) Change signatory for bank account(s) To facilitate the communication between a company and a bank, the PDF form can be emailed from SAP to the contacts at the bank, informing the bank of the change (bank account closure or change to bank account signatory). Once sent, the email generated is available for display through the Manage Bank Accounts app, by clicking on the BANK CORRESPONDENCE tab (see Figure 9.9).

Figure 9.9: Bank Correspondence tab

The form is customizable, so companies can change the wording of the form, add a company logo, etc. 9.3.3 Review bank account process

With this new feature, SAP customers can initiate a review process and monitor the status of requests without using the workflow process. This simplified process is handled by the Manage Bank Accounts, Review Bank Accounts, and Manage Review Process apps. In the Manage Bank Accounts app, you start a review process by choosing the INITIATE REVIEW PROCESS button, as shown in Figure 9.10.

Figure 9.10: Initiate Review Process button in the Manage Bank Accounts app

In the Review Bank Accounts app (see Figure 9.11), you can: search for and display review tasks, navigate to a bank account, and complete the reviews, add review notes to bank accounts, display review notes in the bank account history in the Manage Bank Accounts app, search for and display the review requests that have been created and monitor the review status by checking review tasks that are not yet completed, and keep track of all the review requests that are in-progress or completed.

Figure 9.11: Review Bank Accounts app tile

To clarify, the following apps are not used for the non-workflow related process described above. Initiate Review Process app Monitor Review Status app

9.4 Cash operations 9.4.1 New cash pool Starting with release 1809, cash pools are no longer created based on bank account groups in the Manage Bank Accounts—Bank Hierarchy View app. Instead, there are a number of new apps for the end-to-end cash pooling process. The first step is to create the cash pool master data, using the Manage Cash Pools app (see Figure 9.12).

Figure 9.12: Manage Cash Pools app tile

The cash pool names are created in this app, as shown in Figure 9.13.

Figure 9.13: Manage cash pool—definition step

After creating the cash pool identifiers in the Manage Cash Pools app, move to the Manage Bank Accounts app. There is now a CASH POOL tab where the bank accounts can be assigned to cash pools as leading or participant accounts. In the latter case, cash concentration parameters such as TARGET BALANCE and MINIMUM TRANSFER AMOUNT can also be defined on the account, as shown in Figure 9.14.

Figure 9.14: Define cash pools

There are two apps for initiating cash concentration runs. The first is the Manage Cash Concentration app (see Figure 9.15), that is used to manually trigger a concentration run.

Figure 9.15: Manage Cash Concentration app tile

The second is the Schedule Jobs for Cash Concentration app, which is used to schedule cash concentration runs (see Figure 9.16).

Figure 9.16: Schedule Jobs for Cash Concentration app tile

With the Manage Cash Concentration app, users can initiate an immediate cash concentration with an automatic simulation process of cash movement from the assigned subaccounts to the header accounts. This feature allows your company to centrally manage cash balances, thus improving the efficiency of cash management, as was the case with the ECC cash concentration program (transaction code FF74). Figure 9.17 shows a just executed cash concentration screen. The cash concentration can be run across company codes.

Figure 9.17: Cash concentration run—output screen

Configuration is required to define cash concentration profiles and assign planning levels to those profiles. This is found by following the customizing menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • BANK ACCOUNT BALANCE CALCULATION • ASSIGN PLANNING LEVELS TO PROFILES. This tool is used to move the funds (physical cash movement). Notional cash pooling is not yet on the SAP roadmap. In addition, the Manage Cash Pools functionality comes with an app that lists the Cash Pool transfers that have been made (see Figure 9.18).

Figure 9.18: Cash Pool Transfer Report app tile

9.4.2 Snapshot of cash position report SAP’s Cash Position report is a real-time report. The ability to save a snapshot is extremely useful; for example, after setting the cash position or at the end of each day. It is now possible to save a “snapshot” of the cash position report, which can be viewed at a later point to understand what had been forecasted at an earlier timeframe. Both the Cash Flow Analyzer app and the Check Cash Flow Items app allow users to view the “snapshots”, as shown in Figure 9.19 and Figure 9.20. All other reporting apps show the real-time view of cash flows from One Exposure.

Figure 9.19: Cash Flow Analyzer with snapshot field

Figure 9.20: Check Cash Flow Items with snapshot field

In the Cash Flow Comparison app, which compares actual to forecast data, the forecast data can be from a snapshot but does not need to be taken from a snapshot. With this enhancement, historical changes are recorded and stored in One Exposure. You can use this feature to enable the automatic capture of cash position and cash flow data, allowing you to view historical figures as they were at the time of any snapshot date. This new feature is now available in the cash management apps, such as the Cash Flow Analyzer app and the Check Cash Flow Items app. To activate the snapshot functionality, follow the customizing menu path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • GENERAL SETTINGS • DEFINE BASIC SETTINGS, and select the ENABLE SNAPSHOT checkbox, as shown in Figure 9.21.

Figure 9.21: Enable the Snapshot functionality

9.4.3 Intraday bank statement reconciliation program

As intraday bank statements are imported into SAP, memo records are created for each bank statement transaction, after which a reconciliation of intraday bank statement memo records and forecasted cash flows must take place. If this reconciliation does not happen, there will be duplicate cash flows reflected in the cash position report. The necessary process is illustrated in Figure 9.22.

Figure 9.22: Intraday bank statement reconciliation process flow

With the Reconcile Cash Flows app (see Figure 9.23), users can manually reconcile intraday memo records that were generated automatically when the intraday bank statements were imported.

Figure 9.23 : Reconcile Cash Flows for Intraday Memo Records app tile

Forecasted cash flows are reconciled with memo records created from intraday bank statement transactions. This feature enables users to compare intraday bank statement transactions with forecasts throughout the business day. This way, you can easily identify the unknown payments or payments

not yet settled. It is important to exclude duplicate items in forecasts to gain a more accurate view of the cash positions. The output screen of the Reconcile Cash Flows app is shown in Figure 9.24.

Figure 9.24: Reconcile Cash Flows app

By clicking on the CASH FORECAST FLOWS tab, users are able to see the non reconciled forecast items, as shown in Figure 9.25.

Figure 9.25: Reconciled Items display

It is possible to set non-zero tolerance amounts for reconciliations in configuration by following the IMG path FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • CASH MANAGEMENT • CASH FLOW RECONCILIATION DEFINE • TOLERANCE GROUPS FOR CASH FLOW RECONCILIATION. This configuration allows slight differences in the amounts of the items being reconciled. The tolerances can be specified in terms of amount and percentage. SAP customers can run the FCLM_CR_TRIGGER program to trigger auto

reconciliation, which can be run before executing the manual reconciliation process. In doing this, all one-to-one matches reconcile automatically, thus reducing any manual work. 9.4.4 Cash Flow—Create, Update, Delete To support stand-alone, hybrid Cash Management and Treasury workstations, SAP has delivered a new cash management API (see Figure 9.26).

Figure 9.26: New Cash Flow API

The Cash Flow—Create, Update, Delete service enables create, update, and delete cash flow data received S/4HANA systems or third-party systems. It is based on Access Protocol (SOAP). This API enables you to deployment of Cash and Liquidity Management.

SAP customers to from other SAP the Simple Object implement hybrid

This service contains cash flow information, such as keys for cash flows, value date, amount, currency, company code, certainty level, bank account, and account assignment information, such as G/L account and liquidity item. After data validation and business data mapping are performed in SAP Application Interface Framework, the information is then saved in the cash management system. If there are any issues during validation and business data mapping, the system displays error messages. The API is delivered with a Release Cash Flows app (see Figure 9.27), which allows cash flows from the external system to be reviewed and released before they are saved to the One Exposure structure in the centralized S/4HANA Cash Management system.

Figure 9.27: Release Cash Flows app tile

After clicking on the app tile, users are able to see any cash flows to be released, as shown in Figure 9.28.

Figure 9.28: Release Cash Flows program

All listed cash flows are then released into the cash position by the user. 9.4.5 New Manage Memo Records app Memo records are a cash management element that allow cash flows to be displayed in SAP without having an associated SAP transaction. There is a new Manage Memo Records app in release 1809 (see Figure 9.29). A fundamental change introduced with this app is that the underlying table where the memo records are stored is now One Exposure (table FQM_FLOW), rather than the FDES table. From a user’s perspective, this is not a significant change.

Figure 9.29: Manage Memo Records app tile

The user interface to enter a memo record has also changed with this app. A PLANNING LEVEL is entered as opposed to a PLANNING TYPE, and a LIQUIDITY ITEM is now added with the memo record (see Figure 9.30).

Figure 9.30: Create Memo Record app

After pressing the SAVE button (in the lower left of the screen, not shown here), a message is displayed, similar to the one shown in Figure 9.31.

Figure 9.31: Create Memo Record message

The listing of memo records is included in the same app, as shown in Figure 9.32. The display is much cleaner and more user-friendly than the previous

version.

Figure 9.32: Manage Memo Records display

To migrate the memo record data from the FDES table to the One Exposure table, SAP customers can execute the FCLM_MIGR_FDES2FQM program.

10 Tips, tricks, and other information In this chapter, we cover tips and tricks that are useful in implementing SAP Cash Management powered by SAP HANA. 10.1 Underlying BAM tables With the new functionality in Bank Account Management, there are new underlying tables to store the information. In ECC, all information related to banking and house bank accounts are included in the following tables: BNKA—Bank Master Data TI12—House Banks T012K—House Bank Accounts With SAP Cash Management powered by SAP HANA, the above tables remain, but a number of new tables have been introduced. All tables starting with FCLM relate to Cash and Liquidity Management (i.e. CM on HANA). The FCLM_BAM_AC_LINK table links the T012K table with the new FCLM tables. Tables T012 and T012K are still used to store the house bank and house bank account information, as with ECC, but the way to populate them has changed. The primary tables for Bank Account Management start with FCLM_BAM*. See Table 10.1 for an overview of some of the underlying tables.

Primary tables for Bank Account Management The table that links the new FLCM_BAM* tables and the house bank account table T012K is the FCLM_BAM_AC_LINK table.

Table

Table description

FCLM_BAM_AMD

Main bank account table

FCLM_BAM_AMD_T

Bank account text table

FCLM_BAM_AMD_CUR Bank account currency table FCLM_BAM_AMD_LIM

Bank account overdraft limit

FCLM_BAM_AMD_SIG Bank account signatory FCLM_BAM_AC_LINK

Link between house bank accounts and bank accounts

FCLM_BAM_ACLINK2

Link between bank accounts and house bank accounts

FCLM_BAM_BNKA_BP Stores the business partners tied to a bank.

Table 10.1: New underlying tables in Bank Account Management

10.2 Security roles In the current standard SAP-delivered solution, catalogs (collections of Fiori apps) and roles are one-for-one. Table 10.2 shows the SAP-delivered roles for the new Cash Management functionality. The front-end roles cover the functionality visible to business users. The back-end roles drive the authorizations on the back-end server. Role description

Role

Front-end business role for cash managers SAP_BR_CASH_MANAGER Back-end Front-end roles business for cash role for managers cash specialists SAP_SFIN_CASH_MANAGER SAP_BR_CASH_SPECIALIST

Back-end role for liquidity plans (analysis)

SAP_FIN_ANALIQUIDYPLAN_APP

Back-end role for liquidity plans (develop)

SAP_FIN_DEVLIQUIDYPLAN_APP

Back-end role for to launch liquidity actual liquidity cash forecast flows plans

SAP_FIN_LF90DAYS_SMB_APP SAP_FIN_ACF90DAYS_SMB_APP FCLM_LP

Table 10.2: SAP Cash Management roles

10.3 SAP Fiori apps library There are many uses of the SAP Fiori apps reference library, but for us, the two most common uses are: to check the Fiori apps available in an SAP release, and to map an ECC transaction code to the Fiori app name, which is critical when getting started on S/4HANA. It also provides a comprehensive listing of the Fiori apps by category, and then by role. The SAP Fiori apps reference library can be found by selecting the link below: https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/index.html#/ First, go to the link then select the ALL in Figure 10.1.

APPS FORS/4HANA

option, as shown

Figure 10.1: Fiori apps library

The next screen enables users to search for Fiori apps in a number of different ways. For example, it is possible to search for apps by industry or role. Let’s use the BY PRODUCT VERSION button as an example, as shown Figure 10.2.

Figure 10.2: Search Fiori apps by SAP version

Next, the screen shown in Figure 10.3 is displayed, which shows the number of apps for a given release. In S/4HANA release 1610, there are 7,546 S/4HANA Fiori apps, and for release 1709, there are 9,183 Fiori apps. We’ll click on release 1709 to see the different apps in that release.

Figure 10.3: Fiori apps by S/4HANA release

The screen then shows the Fiori apps in 1709, by application component, as shown in Figure 10.4.

Figure 10.4: Fiori Apps in 1709 by application component

From here, we are able to search for the number of Cash and Liquidity Management apps, by typing FIN-FIO-CLM in the search field, as shown in Figure 10.5. The page then indicates that there are twenty Cash and Liquidity Management apps, and it lists them.

Figure 10.5: Search for Cash and Liquidity Management apps

Users can select any app on the list by clicking the checkbox on the left, and the details related to that app are displayed on the right. For example, in the screenshot in Figure 10.6, we select the MAKE BANK TRANSFERS app, and the right panel shows the details about the Cash and Liquidity Management (S/4 OP) solution, etc.

Figure 10.6: Make Bank Transfers app details

By scrolling down, users can find additional information on the Make Bank Transfers app, as well as links to further details, as shown in Figure 10.7.

Figure 10.7: Detailed information about apps

The last tip related to the SAP Fiori library is how to search for related apps by ECC transaction code. For example, in the search field, users can enter the ECC transaction code, and the associated Fiori app is displayed. In the screenshot in Figure 10.8, we enter the transaction code FBL3N in the search screen, and the associated apps are displayed.

Figure 10.8: Show apps related to transaction code

There is a multitude of information available in the Fiori library. It is definitely worth checking out. 10.4 Navigating the Fiori launchpad In this section, we discuss some basic navigation tools for the Fiori launchpad. The screenshot in Figure 10.9 shows a Fiori launchpad.

Figure 10.9: Fiori launchpad

The Fiori app groups that users have access to are displayed across the top panel, which is outlined in red in Figure 10.10.

Figure 10.10: Fiori app groups

By pressing the more groups icon , as shown in Figure 10.11, users are able to see the list of different Fiori app groups they have access to.

Figure 10.11: The More Groups icon

By pressing the HOME button at the top of the screen (see Figure 10.12), users can see all of their groups, and the tiles that are included in each of the groups. The screenshot in Figure 10.12 shows the apps included in the CASH MANAGEMENT—CASH OPERATIONS group.

Figure 10.12: The Home button

The search option in the upper right section of the screen allows users to search for apps by name. For example, by searching on bank, as shown in Figure 10.13, the apps with “bank” in their name appear. From here, users can double-click on the app to run it.

Figure 10.13: The search feature

To get to the profile settings, press the profile icon . After clicking on it, the profile setting options are displayed on the left of the screen, as well as a list of the most recently used apps (see Figure 10.14).

Figure 10.14: Profile Settings button

When users are assigned many roles, such as an SAP_ALL type setting, the system can become slow because all the apps are being read into the Fiori launchpad. From the homepage settings screen, users can choose to show all groups on a single page or show one group at a time. For users who have many groups assigned to their login ID, it may be better to select the SHOW ONE GROUP AT A TIME option so that only the apps in one group are displayed. The screenshot in Figure 10.15 shows this option.

Figure 10.15: Option for single-group display

10.5 Creating your own “favorites” group It is often helpful to create a group of apps, similar to the Favorites menu in ECC. To create your own home page, follow these steps: First, go to your profile settings by pressing the profile icon

.

After clicking on it, the profile settings options are displayed on the left of the screen, as well as a list of the most recently used apps, as shown in Figure 10.16. Click on EDIT HOME PAGE icon.

Figure 10.16: Edit Home Page

Press the icon to add apps to your home page (see Figure 10.17). Alternatively, press the + ADD GROUP button to create a custom group.

Figure 10.17: Buttons to add app and add group

Enter the new group name. Our group name is CASH MANAGEMENT APPS, as shown in Figure 10.18.

Figure 10.18: Personalized group

Next, click on the open app finder button , as shown in Figure 10.19, to find the apps to be included in the new group.

Figure 10.19: Open app finder

The screen changes to the one shown in Figure 10.20. Select a catalog from the left panel to see the apps on the right side of the screen. Alternatively, use the search field to search for specific apps; for example, apps with the word manage, as shown at the top of Figure 10.20.

Figure 10.20: App Finder example

Click on the pins in order to add apps to the new group. You then see a message indicating the app has been added to either your home page or to the custom group you created (see Figure 10.21).

Figure 10.21: Message that app has been added to group

Continue to do this until you have added all the apps you want in the custom group, then press the home page icon. The home page then looks similar to the screenshot in Figure 10.22. Press the home button, then the CLOSE button in the lower right-hand corner.

Figure 10.22: Review new group

Users are then taken to the home page and can start using the custom app group, as shown in Figure 10.23.

Figure 10.23: Custom launchpad

10.6 SAP NetWeaver Business Client SAP NetWeaver Business Client (NWBC) is a user interface to access all the applications from a single platform. From NWBC, users can access native Fiori apps and SAP GUI, all from a single point of access. Figure 10.24 shows the initial NWBC screen.

Figure 10.24: Initial Screen for SAP NetWeaver Business Client

From the initial screen, users can select any of the roles listed. After clicking on the SAP_SFIN_CASH_MANAGER role, for example, users are taken to the screen shown in Figure 10.25, where they can access any of the SAP functionality available through the role, using a web browser. (Text written in blue indicates links that take users to the corresponding SAP functionality.)

Figure 10.25: Cash Manager role through NWBC

If you receive the error shown in Figure 10.26, the NWBC access is not activated.

Figure 10.26: NWBC not-activated error message

SAP transaction code SICF is used to maintain services for HTTP communication in the SAP System, using the Internet Communication Manager (ICM) and the Internet Communication Framework (ICF). When you first install your new S/4HANA system, the standard SAP services you want to use may not be active so SICF is used to activate them. This is a Basis task, so it is not discussed further here. 10.7 Definition of terms Table 10.3 contains definitions of key terms used in this book. Term

Description

Actuals Actuals are the uses and sources of cash. They include both revenue and expenditure actual cash posting data and are in the form of liquidity items that map to the general ledger (G/L) categories. BAM

Bank Account Management

BCM

Bank Communication Management

ECC

SAP ERP Central Component

HEC

SAP HANA Enterprise Cloud A house bank is a bank where an SAP customer has bank accounts. This is typically an external bank, but in the case of In-House Cash, could also be an internal bank. A house

bank House

bank ID, with up to five characters, is created to represent the bank (e.g. JPMC1, BONY1, or BANK1). The house bank ID is assigned to a company code. House A house bank account is a bank account at the house bank. A house bank account ID, bank with up to five characters, is created to represent each bank account (e.g. 39403, account USD01, ACCT1). Both the house bank ID and house account ID are free-form alphanumeric IDs. Liquidity Liquidity items define the buckets or categories in which the cash flows are tracked for items reporting purposes. NWBC

Using NetWeaver Business Client (transaction code NWBC), users can access the functionality they have authorization to.

SOAP

Simple Object Access Protocol

TWS

Treasury Work Station

Table 10.3: Definition of terms

10.8 Useful SAP notes Table 10.4 lists useful SAP notes. note SAP

Description

2165520 Feature Scope Differences Between Bank Account Management and Bank Account Management Lite 2342101 Trouble Shooting for Common Issues in BAM Apps 2376432 How to Implement Basic Cash Management in SAP S/4HANA On-premise Edition 1610 2437574 Transport of Bank Account Master Data in S/4HANA 1577912 FAQ: BCM 1041016 Workflow setup in new installations for BRM 1861019 BNK_MONI: Check for active linkage BUSISB001/tasks 2111290 Bank Account Management: Import and Export Bank Accounts 2305593 Replication of Bank Accounts, House Banks and House Bank Accounts to Remote Systems 2273656 FI Flow Builder: Bug Fixes 2354048 Information Note for MM Flow Builder: Available Fields in Query Sequence 2580031 FAQ: Liquidity item assignment into one Exposure (FQM_FLOW)

Table 10.4: Useful SAP notes

You have finished the book.

Sign up for our newsletter! Stay up to date! Sign up for our newsletter for updates on new SAP book releases and exclusive discounts. Please visit us at newsletter.espresso-tutorials.com to find out more.

A The Authors 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. Mary’s expertise is in SAP’s Treasury and Risk Management, In-House Cash, Liquidity Planning, Accounts Payable, payments from SAP in general, Cash Management, and Electronic Banking.

Praveen Gupta has been specializing in the SAP Financials area since 2005 and has worked on numerous projects in the areas of finance, treasury, banking and product management. Praveen’s expertise is in SAP’s Treasury and Risk Management, Accounts Payable, Electronic Banking, Cash Management, In-House Cash, Payments, Bank Communication Management, and SWIFT.

B Disclaimer This publication contains references to the products of SAP SE. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase, Inc. Sybase is an SAP company. SAP SE is neither the author nor the publisher of this publication and is not responsible for its content. SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Endnoten 1 To clarify, this means that the following configuration for BAM signatory

control has not been entered FINANCIAL SUPPLY CHAIN MANAGEMENT • CASH AND LIQUIDITY MANAGEMENT • BANK ACCOUNT MANAGEMENT • ENABLE SIGNATORY CONTROL. 2 At the time of writing this book, this release is scheduled for February

2019.

More Espresso Tutorials eBooks Lennart B. Ullmann & Claus Wild: Electronic Bank Statement and Lockbox in SAP® ERP Processing the Electronic Bank Statement in SAP Integrating Payment Advices as of SAP EhP 5 New Functionality for Post-Processing as of SAP EhP 6 Detailed Message Monitoring and Reprocessing Examples

Ashish Sampat: First Steps in SAP® Controlling (CO) Cost center and product cost planning and actual cost flow Best practices for cost absorption using Product Cost Controlling Month-end closing activities in SAP Controlling Examples and screenshots based on a case study approach

Janet Salmon & Ulrich Schlüter: SAP® HANA for ERP Financials, 2nd edition Basic principles of SAP HANA The idea behind SAP Accounting powered by SAP HANA HANA applications in ERP Financials Implications on business processes

Ann Cacciottolli: First Steps in SAP® Financial Accounting (FI) Overview of key SAP Financials functionality and SAP ERP integration Step-by-step guide to entering transactions SAP Financials reporting capabilities Hands-on instruction based on examples and screenshots

Janet Salmon & Claus Wild: First Steps in SAP® S/4HANA Finance Understand the basics of SAP S/4HANA Finance Explore the new architecture, configuration options, and SAP Fiori Examine SAP S/4HANA Finance migration steps Assess the impact on business processes

Mary Loughran und Lennart Ullman: Guide to SAP®In-House Cash (ICH) SAP payment management fundamentals and tools In-House Cash and In-House Bank functionality scenarios Useful transaction codes and reports Tips and tricks for resolving common errors

More Value

for your SAP’ſ What sets us apart is the ability to put ourselves in the situation of our clients.

The result: excellent, tailor-made solutions,

With our combination of specialized IT ex

These are our areas of

pertise and ERP know-how, Our knowledge

specialization:

of business requirements and more than 15

M. Basis

years of experience, we are ideally positioned

* ERP Accounting

to provide lifecycle management for your SAP*

* ERP Logistics

system. Due to our international presence, we

M. Business Intelligence

are able to offer our clients on-site support

* NetWeaver

around the Worki.

A HANA

Interested?

Visit us www.consolut.com or write an Email: [email protected]

*

consolut solutions + walue