SAP Accounting powered by SAP HANA – Moving controlling and finance closer together

Editor's Notes

1. 3 copies of data In different data models Inherent data latency Accelerate through cache In recent years, computer systems have increased number of processing cores with large integrated caches. Main memory space has become practically unlimited with the ability to hold all the business data of enterprises of every size. Falling prices have moved processing from Disk/SSD to In-Memory. Memory access is 1M – 10M times faster than disk. Disk-centric computing was also one of the major factors that forced separation of transactional and analytical workloads. Moving data to various locations was necessary for reporting to circumvent network issues. Pre-processing of data then became the necessity to optimize linear data transfers. We do not have to live with those limitations any more. Feasibility is given. Through advances in data sciences combined with relevant hardware trends, SAP is leading the real-time computing revolution… leveraging the power of in-memory computing to bringing OLAP and OLTP back together in one database. This transforms how we construct business applications and our expectations in consuming them. Adopting this new technology will sharpen your competitive edge by dramatically accelerating not only data querying speed but also business processing speed.
2. What are the capabilities of an accounting system based on SAP HANA ? There is only one single source of truth for Financial and Managerial Accounting. All General Ledger will be stored in one repository, the revenue and cost part of the P&L has all relevant detail like as to customers, products and regions. The processing and analysis is based on line items rather than pre-configured totals. Thus you have the highest granularity available, your analysis is not restricted by first setting up aggregates in order to evaluate data fast enough. The aggregates would limit the kind of analysis you can do fast. With HANA you can do all analysis fast, you have all dimensions available which you have in your line items. The solution is easy to adapt. Any number of customer specific dimensions can be added consistently in Accounting. Some industries like banking and insurance see more and more regulations, which require to add fields to accounting, sometimes 30 or even 80 fields. Reporting based on this data is fast and flexible. State of the art BI frontend tools can be used for operational reporting, thus the benefits of BI tools are inherited to the transactional system. The month end closing process is accelerated, some steps can even be run on a daily/weekly basis rather than just at period end. Thus the accounting system can give you insight on a daily/weekly basis. Finally consolidations could also be run on the original accounting data. Data replication would become obsolete, some consolidation functionality could even be run on the fly in reporting. ! Achtung Demo ! Receivables Manager
3. Throughput Boost data throughput by overcoming the lock issue and reducing data volume to be posted (Non)-Reconcialition No reconciliation because of ‚One Document‘ Flexibility One starting point to extend and adapt simply and straightforwardly Data Volume Reduce data volume dramatically by eliminating redundancies Performance Expectation: achieve identical response times as before plus optimize
4. The basis tables BKPF, BSEG/BSEG_ADD and FAGLFLEXA remain almost unchanged. Index and totals tables have been replaced with compatibility views (aka equally named views). These views have the same name as the original tables, contain the same fields and shall allow for a smooth transition to the new data model in the standard as well as in the partner and customer coding.
5. Balance Sheet Accounts are typically independent of CO whereas Profit and Loss Accounts generally include a CO account assignment. All profit and loss accounts are now linked to their equivalent postings in CO. This means that all profit and loss items are effectively one long posting string with fields from the BSEG table, fields from the COEP table and in the case of CO-PA (revenue and COGS postings) dimensions from the CE4 table. Taking the example of Payroll Accounts, two types of posting are possible – an allocation that crosses dimensions in FI (profit center, business area,…) and an allocation that has no impact in CO. Allocations that cross FI dimensions are captured via Real Time Integration. Again these documents are linked and can be reported, but there is a transformation from the CO cost element to the FI account. Other allocations are only in the COEP table. The logical document allows you to select not just those accounts with a link but also the balance sheet accounts and secondary cost elements with no link to FI.
6. All cost or revenue relevant postings in HR, MM, PP, SD like good issues, material consumption, creation of a billing document for a sales order result in a posting of a line item in Financial Accounting at the relevant profit and loss accounts. This line item is stored in the line item table BSEG. The header data for this document are stored in the table BKPF. At the same time this posting data are also transfered as costs or revenues to Management Accounting. A specific CO line item is posted and stored in the line item table COEP. The header data for this CO document are stored in the table COBK. Up to now there is no link between the FI line item and the CO line item on the level of the line item tables COEP and BSEG. There is only a link between the document headers: the tables COBK and BKPF are linked to each other. This leads to a high reconciliation effort between FI and CO, because it is hard to reconcile documents of different granularity e.g. payroll records with more FI items than CO items. Overall reporting bringing together the legal view with details of responsibility and/ or market segments on a glance is not yet available. The lack of a link on line item level makes reporting and reconciliation cross the financial applications difficult – especially between FI and CO-PA.
7. All cost or revenue relevant postings in HR, MM, PP, SD like good issues, material consumption, creation of a billing document for a sales order result in a posting of a line item in Financial Accounting at the relevant profit and loss accounts. This line item is stored in the line item table BSEG. The header data for this document are stored in the table BKPF. At the same time this posting data are also transfered as costs or revenues to Management Accounting. A specific CO line item is posted and stored in the line item table COEP. The header data for this CO document are stored in the table COBK. Up to now there is no link between the FI line item and the CO line item on the level of the line item tables COEP and BSEG. There is only a link between the document headers: the tables COBK and BKPF are linked to each other. This leads to a high reconciliation effort between FI and CO, because it is hard to reconcile documents of different granularity e.g. payroll records with more FI items than CO items. Overall reporting bringing together the legal view with details of responsibility and/ or market segments on a glance is not yet available. The lack of a link on line item level makes reporting and reconciliation cross the financial applications difficult – especially between FI and CO-PA.
8. All cost or revenue relevant postings in HR, MM, PP, SD like good issues, material consumption, creation of a billing document for a sales order result in a posting of a line item in Financial Accounting at the relevant profit and loss accounts. This line item is stored in the line item table BSEG. The header data for this document are stored in the table BKPF. At the same time this posting data are also transfered as costs or revenues to Management Accounting. A specific CO line item is posted and stored in the line item table COEP. The header data for this CO document are stored in the table COBK. Up to now there is no link between the FI line item and the CO line item on the level of the line item tables COEP and BSEG. There is only a link between the document headers: the tables COBK and BKPF are linked to each other. This leads to a high reconciliation effort between FI and CO, because it is hard to reconcile documents of different granularity e.g. payroll records with more FI items than CO items. Overall reporting bringing together the legal view with details of responsibility and/ or market segments on a glance is not yet available. The lack of a link on line item level makes reporting and reconciliation cross the financial applications difficult – especially between FI and CO-PA.
9. In the traditional period close, the system created a list of valid orders and then looped through this order list to calculate e.g. WIP for each order in turn. This resulted in relatively small selects with an aggregation per order. This procedure did not benefit from the HANA architecture (in fact sometimes it was slower than on a classic database). In the new approach, stored procedures on HANA are used to select the valid orders, then the costs per order and to aggregate this data so that it is ready for use in the relevant calculation <WIP calculation/variance calculation/results analysis> Instead of performing a <WIP calculation> for each order in turn the system returns to ABAP to perform the calculation on the whole data set and update the tables with the results of the calculation. This results in significant performance improvements.
10. Next, I want to give you a short introduction about our approach for Code Pushdown. Let’s take Results Analysis for Sales Orders as an example. In the old ABAP transaction KKAK, the system first selects objects base on user input, and then loops and processes each object individually. Now we moved the data intensive logic highlighted in yellow box to HANA, as shown in this diagram, and skipped the logic which are not capable or not perform well in HANA, such as the authorization check, complex calculation depends on customizing settings etc.