Summary
This document provides an introductory and practical overview of FI / AR, as well as, HANA Reporting – via an illustrative “End-to-end HANA Modelling: From SAP FI business process to SAP Report presentation” scenario.
Please download the PDF version, here: Practitioner Perspective, ERP on HANA and FI Analytics
Content
Objective
----Introduction
----The HANA Advantage
----HANA Reporting Options
SAP Finance Overview
----Overview of SAP FI
----Details of FI Business Process
SAP Techno-functional Analysis
----The Payment Business Process
----The Payment SAP Transaction
Technology Architecture
----HANA Reporting Landscape
----Building a HANA Model
----Interpreting the Report
Conclusion
Reference
=====================================================================================================
Objective
Introduction
SAP ERP is an OLTP system optimized for writing business transactions. It supports
real-time operational reporting – albeit having little efficacy. While SAP BW
is a reporting and analytics environment, it is positioned to be at the
strategic-level reporting. The operational level reporting gap is never
properly addressed. Hence, the natural evolution of HANA Live arises.
SAP AG defines HANA Live as “Real-Time operational reporting directly on your Suite
on HANA system [e.g. ERP on HANA, CRM on HANA] without any redundancy or
latency. Alternatively in a sidecar scenario next to your existing SAP Business
Suite deployment”.
The objective of this paper will be to provide a hands-on illustration for “End-to-end HANA Modelling: From SAP FI
business process to SAP Report presentation”. We will utilized SAP HANA
Modelling techniques and present the data with SAP ALV Grid (ABAP) and SAP Lumira
technologies.
We will navigate this paper in the following 4 steps:
- Getting to know HANA Reporting
- Gaining SAP ERP techno-functional understanding (from double-entry
to transactions to tables) - Getting to know the architecture of HANA landscape (from data
model to processing logic to presentation layer) - Integrating the above information and Building a HANA Report
Due to the limitation of scn portal. I am unable to display image as needed.
Please download the PDF version Practitioner Perspective, ERP on HANA and FI Analytics
=====================================================================================================
The HANA Advantage
HANA Reporting has many advantages. We noted two prominent ones:
- Performance– Data is accessed directly from base tables
in-memory. To maximize performance further, HANA introduces the Code-Pushdown
paradigm. ABAP programs, traditionally, query the database and perform iterative
manipulation of data at the application level. However, modelling done in HANA
are performed at the database level. Hence, it is recommended to ‘push-down’
data manipulation (where possible) to the database level – this will reduce the
data transfer volume and optimized codes execution. - Scalability– Mapping can simply be done with HANA
Studio Graphical Interface or HANA ubiquitous SQL Scripting. This is actually
one up from SAP BW standard contents which keeps its business logic cryptically
embedded into its transformation mapping (one after another).
HANA Reporting Options
- HANA Modelling – this allows developer to perform Modelling directly on the base ERP tables (such BSEG, MSEG, VBRP, etcs).
Traditionally in BW/ABAP, we build once and seldom perform massive changes as
re-engineering takes up considerable effort and checking. Canned reports are
acceptable then. HANA means speed, timely and flexible – to take harness this
advantage, we have to possess sufficient techno-functional knowledge for agile
business requirements. HANA - Live Content - HANA Live comes with pre-defined model which we can use
on-the-fly. There are many packages that we can import for use.
SAP Finance Overview
Overview of SAP FI
SAP Finance (SAP FI) follows the accounting principles closely especially the bookkeeping principles
which includes double-entry, control account, sub-ledgers concepts.
The end result of financial processes are financial statements.
These statements provide an overview of an organization’s profitability and financial position.
The SAP FI processes are broken down into:
- General Ledger
- Account Payable
- Account Receivable
- Asset Accounting
Business transactions can be updated directing into the FI modules or derived from the Logistics modules (SD, MM).
The relationship of General Ledger (GL) and sub-ledgers (AP, AR, AA) are based on accounting concept of “control account”.
The GL module provides the total amountowed to creditors, owed by debtors, dollar value of fixed asset classes and the overall Balance Sheet statement. The sub-ledgers provide detail information of which specific vendor we owe what amount, and how many actual machinery we have. If an account is set as reconciliation level, no posting is possible at that account. We have to post it into the sub-ledgers which will rollup back to the total reconciliation account.
Each customer (or vendor) has their reconciliation account setup in their Company Code MasterData view – this
ensure all postings (except for special GL items) to the customers are reconcilable at the reconciliation level.
Additionally, in bookkeeping, we use Debit to add and Credit to minus. SAP uses the debit/credit indicator for this (Debit = S, Credit = H).
Details of FI Business Process
For our purpose, we will choose the Account Receivable (AR) process to analyze.
What is Account Receivable?
The term receivables refer to accrual transactions. Accounts Receivables occur when customer have bill outstanding with us (just as Accounts Payables are from the vendor side). In real business world, many transactions are on accrual basis (instead of cash payment). And there are also agreed payment terms, due baseline dates and prompt discounts.
How does Account Receivable works?
A typical cash sales transaction will increase bank balance and update sales revenue. (Dr Bank, Cr Sales Revenue). In accounting, all transactions have at least two legs (one debit, one credit) and the net amount of both side will tally.
An accrual sales transaction will update sales revenue
but instead of increase bank, it increase the debt of the customer –
as cash has not yet been received (Dr Customer, Cr Sales Revenue). Only when
the customer has done cash payment, we will offset the debt of the customer and
increase bank (Cr Customer, Dr Bank). When the two transactions are completed,
the customer account will be net zero, resulting in entries similar to those of
cash sales (Dr Bank, Cr Sales Revenue). Why go thru such effort if the end
result is the same as cash sales? This is to keep the books as updated as per
period, for thousands of transactions that are dragged across months and years!
AR transaction typically starts from a Sales Order in the Sales Cycle (if SAP SD is
implemented). However, we can also post direct customer invoice (and credit
memo) with FB70 - this creates customer invoice while crediting a revenue
account.
F-28 is able to pay and clear invoices. Pay means customer outstanding amount is reduced; clear
means the paid amount will be matched back to specific invoices. For credit
memo, it is an offset figure, there is no money flow. Hence, we need to clear
the credit amount to match a specific invoice with F-32.
SAP Techno-functional Analysis
We shall now move into techno-functional analysis – Mapping Double-entry to SAP Transaction to Database Table.
We should know at what stage what transactions are used. And how those transactions are recorded
into the database tables. This intricate knowledge will have a direct impact on
how we present the data in charts later on.
The Payment Business Process
- SAP uses document type to control the nature of the document posted. For Customer invoice, by default “DR” (other types include D1, D2, RM, etcs). When a customer is over-invoiced, we post a reduction document known as a Credit Memo, which use “DG” as document type. Payment uses “DZ” document type.
- When invoice is posted against a customer, there will be a debit entry (SHKZG = ‘S’) in the BSID table.
- When a payment is posted, the entry will be removed from BSID.
- However, an invoice can be paid partially, in this case, a credit entry (SHKZG = ‘H’) will be inserted into BSID to offset the original invoiced amount.
- After an invoice is fully paid, the entries are removed from BSID and inserted into BSAD.
Technology Architecture
HANA Reporting Landscape
When architecturing HANA Modelling Landscape, there are multiple path of options to choose from. We can segregate HANA into 3 sections: Data Model, Processing Logic, and Presentation Layer.
Data Model – refers to the base tables of the business process and their functional
relationships
- Processing
Logic – refers to modelling technique applied. It can be done using HANA Modelling
or HANA Stored Procedures- SAP ABAP uses Dictionary View to connect to HANA Views.
Dictionary Views are exported meta-data of HANA models to ABAP AS. It can be generated using ABAP in Eclipse IDE (AIE) or HANA Studio.
- SAP ABAP
uses either Core Data Services (CDS) Views or ABAP managed Database procedures
(AMDPs) for direct HANA connections. These two methods are known as “top-down”
approach (as oppose the earlier HANA “bottom-up” approach). The approach allows
all ABAP changes to be done at the ABAP Application Server level; related
HANA-intermediate objects will be generated upon activation. Transport is done
in CTS level only; HANA objects will automatically be included. - Presentation Layer – refers to tools that interface HANA as DataSource
- SAP BOBJ (inc Lumira and Design Studio) can connect to HANA models directly.
- SAP ALV Grid or SAP UI5/Fiori are used to present HANA data retrieved into ABAP AS.
Building a HANA Model
Up till now, we have gained sufficient knowledge of the FI process and the HANA landscape. We
shall apply this knowledge into building a “Customer
Days Outstanding Report”.
- Data will be taken from base tables BSID / BSAD.
- The tables will be join using HANA Analytical View.
- The presentation layer will be in SAP ALV Grid and SAP Lumira.
Reference
1 Practitioner Perspective, Modelling HANA vs BW7
https://www.scribd.com/doc/248694989/Practitioner-Perspective-HANA-vs-BW7-Modelling
2 SAP HANA Live Overview and Installation
3 “SAP HANA Live for SAP ERP” Add-On
http://help.sap.com/saphelp_hba/helpdata/en/8d/60d3289497430c86bc1465662559c8/content.htm
4 “SAP Simple Finance” Add-On
http://help.sap.com/saphelp_sfin100/helpdata/en/cb/f6d652b072ff25e10000000a4450e5/content.htm
5 SAP Smart Business for the SAP Simple Finance Add-On
http://help.sap.com/saphelp_ssb_sfin_100/helpdata/en/60/671753bf213047e10000000a44538d/frameset.htm
6 SAP End-to-End Development (ABAP) Example in SAP NetWeaver 7.4 & SAP HANA
7 SAP ABAP CDS - Language Elements
http://help.sap.com/abapdocu_740/en/index.htm?file=abencds_annotations.htm
Author Bio
Benedict Yong is an SAP practitioner, experienced in Business Intelligence Consultation and ERP Support. Due to his variedworking exposure in the SAP space, he is able to integrate ERP business processes with cutting-edge reporting technologies. He holds a Masters in ERP (Finance focus), Bachelor of Management (Australia) and a Diploma in Business InfoTech (Singapore). He is familiar with the Consulting and Support environments, with his various Project Lead & Consultant roles. He is situated in Singapore and is bilingual in English and Mandarin. He can be contacted at benytx@gmail.com.