In a perfect world, a bank payment that is received from customer Acme, Inc., for $100 would be automatically matched to a single $100 open receivables invoice in your ERP system, and your receivables accountant could lean back and relax. In the real world, a payment for $100 from Acme has to be matched against 17 invoices ranging from $1 to $19, and it is unclear which invoices should be cleared—and whether early payment discount terms should be applied. SAP developed the Clear Incoming Payments app after extensive end-user interviews. In this use case, I explain how the Clear Incoming Payments app supports an accountant in her attempts to clarify the payment, to match it to the correct open invoices or credit memos, and clear the payment manually. Consider this scenario. An accountant wants to view a worklist of payments she is responsible for matching. To view these payments, she logs on to S/4HANA and clicks a tile in the Fiori Launchpad called Clear Incoming Payments. These payments can be sorted by customer, date, and amount or status. After a single payment is selected for clearing, the main Clear Incoming Payments screen displays the open items for the customer account (Figure 1). One or more can be selected, and the payment is posted, clearing the open items. The accountant has direct access to the accounts payable contact information for the customer in case she needs to call the customer to discuss the situation. She can also change the discount settings of the transaction, or view the simulated journal entries that a posting would create. Finally, if the clearing of open items is not possible, she can post the payment to a general ledger (G/L) account or on the customer account, without clearing open items. For this scenario, the top of the screen in Figure 1 shows the accountant an incoming payment amount of €11,662. In the main table area, the Open Items for the customer account are presented on the left. The accountant chose the second item by clicking the Clear >> button, which brings that amount to the right side of the table. The Balance at the top right shows a difference of €238 between the payment and the open amount. The default sorting of the apps is by role. To find the documentation related to Clear Incoming Payments, access the Fiori apps library via the link referenced in the note above, scroll down to the Accounts Receivable Accountant role, and click the box next to Clear Incoming Payments. This action opens the screen shown on the right of Figure 2. Alternatively, you could enter Clear Incoming Payments in the main search bar. Fiori transactional apps in finance require your transactional business processes to be running in very recent versions of SAP ERP (such as SAP Simple Finance, on-premise edition 1503 Support Package Stack [SPS] 1511), on SAP HANA directly. Other areas of SAP (such as Sales and Distribution [SD]) offer Fiori apps that can be used in a suite on SAP HANA or an SAP HANA sidecar setup, but this is not possible for finance transactional apps. The lowest back-end release level is SAP ERP Central Component (ECC) 6 – enhancement package 7, with the Simple Finance add-on. The components that have to be installed in your SAP HANA landscape vary based on the company’s release level. For example, for companies using classic logistics with the new SAP S/4HANA Finance solution, the setup would be as shown in Table 1. Fiori apps always require SAP Gateway, and they need to be deployed in and launched from a Gateway system. SAP Gateway allows mobile devices and also other platforms to be connected with SAP software using simplified and standardized interfaces, without the mobile or front-end developers having to have deep SAP ERP process knowledge. SAP Gateway also provide other required components (such as the activate and maintain service transaction [IWFND/MAINT_SERVICE], where you would activate, test, and manage related front-end services for Fiori apps). This means that the Fiori front-end application, which is programmed in SAPUI5, can be consumed on multiple devices. For details on navigating from one Fiori app to another, read the sidebar “How Does a User Move from App to App?”

Implementation Steps

The implementation steps vary widely depending on which version of the Fiori app and back-end software you are using. Therefore, the online documentation first asks you to choose your software release as well as the release date of your app.

General Setup and Installation Tasks

The idea of reusing technical coding is an important aspect of the Fiori approach. When you look at the bottom part of the main Clear Incoming Payments screen, it looks the same as the screen in Post Incoming Payments, and in fact, the coding is reused. Both IT departments and accounting end users benefit from having repeated patterns of activities, with standardized processes for all clearing or posting transactions. When there are different transactions and processes where certain actions are triggered, the same coding is used. However, these coding blocks are not intended to be used by customer-specific implementations or partner-specific implementations; they have been designed for the SAP-delivered Fiori apps only. That is why many of the Fiori apps are linked together and may be prerequisites of another app. In order for the app to work correctly, the app, prerequisite apps, shared coding blocks, and reuse libraries must all be installed correctly. You should confirm that the front-end component (UIAPFI70 200) is in place on the front-end server and implement the SAP Notes listed in Table 2. The Clear Incoming Payments app specifically requires the prerequisite Manage Journal Entries and Post General Journal Entries Fiori apps. These apps enable the simulation of the clearing postings, which is an integral part of the Fiori app Clear Incoming Payments. If they are not implemented correctly, clicking the Simulate button results in an error.

Activate OData Services and the SAPUI5 Application Services in the Front-End Server

The OData Services that manage the exchange of information between the UI and the underlying database have to be activated. In my example case of the Fiori app for Clear Incoming Payments, the following OData Services have to be activated:

• FAR_MANUAL_CLEARING_SRV (001)
• FAC_FINANCIALS_POSTING_SRV (001)
• FAC_FINANCIAL_DOCUMENT_SRV_01 (001)

The delivered Internet Communication Framework (ICF) services that SAP delivers are initially inactive for security reasons. Therefore, you have to activate the ICF services manually:

• FIN_ARMANCLEAR

To save time, SAP delivers an SAP Fiori app that helps administrators activate the OData services and ICF nodes at the same time. This app is called App Activation. You can activate OData services and ICF nodes at once (if the app-specific documentation mentions specific OData services), by using an SAP Fiori app found here: https://help.sap.com/saphelp_fiori_sfin_200/helpdata/en/b8/8eeb54a8056368e10000000a4450e5/content.htm. In this case, since the number of OData Services and ICF services is smaller, it is probably not a critical time-saver in the overall implementation project.

Create Roles and Manage Access to the Fiori Launchpad

Authorization settings have to be made in both the front- and back-end servers to have users be able to access Fiori apps filled with information from the database. Ultimately, you want to authorize business users to access (database) data via the OData services. The OData service authorizations are grouped and assigned to a business role, and all related technical default values related to the authorization are automatically added to a role. This is analogous to the system behavior when an administrator adds classic SAPGUI transactions to a PFCG role. SAP delivers a sample front-end business role SAP_SFIN_BCR_RECEIVABLES_CLERK. This delivered role can be copied and adjusted as needed. Again, this process is the same as when administrators set up roles for the classic SAPGUI transactions. The role can be restricted based on in which instance the role is activated—for example, a common restriction would limit the role’s access to one company code only. This is the same behavior as in the case of SAPGUI transactions. Note that in cloud editions, the authorization concept is different than in the on-premise editions, and the settings for determining which user can see data from which company code are handled in a simplified way through a configuration app. In addition, the PFCG role has to include back-end authorizations to allow your users to simulate and display the G/L document according to the relevant OData services. This is delivered in the example role SAP_FIN_GLDOCMANAGE_APP, which was not intended for direct use, but rather to serve as a template to copy and modify.

Set Up the App within the Fiori Launchpad

To make sure that the role can be viewed in the Fiori Launchpad (Figure 3), it has to be assigned to a catalog. End-user launchpads are based on settings made by an administrator. Since a user could have dozens of transactional and analytical app tiles, the Fiori app tiles are grouped into areas of responsibility or process. The structure of the Fiori app content is shown in Figure 4. There are Business Catalogs according to business role—in my example, Account Receivables Accountant. Homepage Groups are subsets of one catalog. End-user launchpads are then structured based on the groups and catalogs made available to them. To make the Clear Incoming Payments app available in the Fiori Launchpad,  follow several steps described in the documentation. First, the administrator must ensure that users have access to the Fiori Launchpad with its personalization and navigation options. Therefore, a front-end server PFCG role must be set up containing references to:

• Fiori Catalog – The list of apps from which the user can choose
• Fiori Groups – A subset of apps that automatically appears in the Launchpad
• Corresponding R3TR IWSG objects for those OData services that are created during service activation

For the Clear Incoming Payments app in my example, the roles, catalogs, and groups listed in Table 3 are important.

Configuring Your Process

Note that in Finance, through the end of 2015 (at the time of publishing), none of the transactional apps that post data into the database are available for extension according to the UI Extensibility concept of SAP Fiori. There are no extensibility points delivered in the coding; and no customer-specific UI adjustments are possible (e.g., adding new data fields). In the current versions of the Fiori app-specific documentation, this point is not very clearly described. Companies still have some flexibility in terms of process customizing, however. Receivables teams want to have as much automation support as possible to avoid having to process manually a large number of worklist items. The ERP system can help you search for matching open items based on payment reference information contained in the electronic bank statement, such as invoice number or reason for payment. You can define rules for payment allocation in customizing in the SAPGUI menu by following menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Settings for the Data Import > Define Posting Parameters. Here you can define the posting parameters, with settings for each company code. It is also possible to have rules on a more detailed level, such as by house banks and account IDs. You also have to indicate which number ranges are relevant for searches for document numbers or reference document numbers. One additional new capability of Clear Incoming Payments (compared with the SAPGUI transaction) that accountants should investigate using is being able to copy and paste data into a search field. The system uses this information to attempt to match using the matching algorithms. This functionality is a reuse of coding from the Post Incoming Payments Fiori app where accountants manage incoming bank statement items. Note that there is no impact on customizing if you are using the Fiori app or the traditional SAPGUI. Using the Fiori app for Clear Incoming Payments offers accountants these additional benefits over their SAPGUI process:

• Simplified worklist-based process with direct access to customer contact information, notes, and discount settings
• Flexibility in terms of drag-and-dropping notes into a text box that the system can then use to make matching suggestions

For IT teams, the result is more mixed:

• Customizing the app remains the same, via settings in the SAPGUI
• Additional complexity around authorizations and Launchpad management

However, the authorization and Launchpad complexities are not app-specific—after an initial concept has been set up, the authorization process for hundreds of Fiori apps is managed in the same way. There is certainly a learning curve involved, but this mitigates the negative aspects for IT. In cloud deployments, the authorization and Launchpad complexity has been resolved.

How Does a User Move from App to App? In the traditional SAPGUI, professional users have a number of transaction codes memorized that they enter into a field at the top of the screen, or they use an SAP Easy Access menu. In the Fiori world, the analogous navigation pattern is to return to the Launchpad and open the next transaction by clicking a tile. However, there is improved navigation between the apps themselves based on the business context and semantic objects. For example, in the Manage Customer Line Items Fiori app, I can view line items by customer grouped by company code. The customer number is shown in Figure A as a hyperlink. By hovering over the customer number field, you are offered the name of the customer, as well as navigation options that are available for the semantic object of a customer (the pop-up screen in Figure A). In this case, you can jump to five different Fiori apps: Clear Incoming Payments, Display Customer Balances, Manage Customer Master Data, Post Incoming Payments, or Process Receivables. The options presented to you are of course limited by your authorizations. When you navigate via these links, the data presented to you in the next Fiori app is preselected to the particular customer. In the Fiori implementation project, companies can decide which roles have which semantic navigation options.

Q&Ahere