By Janet Salmon
I've been working with the first accounting customers to validate and implement SAP Accounting powered by SAP HANA.
SAP Accounting, powered by SAP HANA, was made available on 1 August 2014.
This blog explains how the new solution differs from earlier versions and discusses what I've learned.
Table of Contents
- Is this as simple as Hasso Plattner promises
- Is this just a newer version of the general ledger
- How do I report in SAP Accounting powered by SAP HANA
- What are the deployment options
- What about the cloud
- Why does all this matter
1. Is SAP Accounting powered by SAP HANA as simple as Hasso Plattner promises?
If you've been following the blogs by Hasso Plattner, one of the SAP founders, you'll know that he has declared war on aggregates. The rationale is simple: aggregates are old technology. In the past, we needed them to provide aggregated data quickly in a report or during a process that required that data, such as an allocation or settlement. With SAP HANA, data can be aggregated from line item tables on the fly.
Developers in the past knew that cost center managers and project managers would need a report on their spending at month end, so they built tables that contained the cost center/project/order, period, and the various cost elements (the primary and secondary cost tables, COSP and COSS). This worked, but it shaped the way the managers saw their data, seeing their spending in period chunks.
SAP Accounting, powered by SAP HANA, frees managers up from this, allowing them to directly query the data in the line item table (COEP) to determine which suppliers they have been spending the most with or which employees have the highest travel expenses. We've all gotten used to this type of reporting - the cost center reports, project reports, financial statements, and so on- that build on the aggregates tables. Indeed, we're so used to this report that we forget what's in the line item tables.
Think of the line item table in the general ledger, BSEG, which contains over 300 fields. By comparison, the totals table for the general ledger (GLT0) contains around ten fields: the main ones being the period, the fiscal year, the company code, the business area, and the debit/credit indicator. The new general ledger uses the totals table FAGLFLEXT, which offers more possibilities, including the ability to report additionally by profit center, segment, functional area, and trading partner, but is by no means infinitely extensible.
Developers used the totals tables primarily for performance reasons. Most of the processes in Financials are designed to read from the period tables, so allocations and settlements are typically read from COSP and COSS. A reason to avoid the line item tables is that normally the other fields that are filled depend on the type of posting so that an asset acquisition will fill different fields from an expense posting or a receivable item. We have a sparsely filled matrix, but with SAP HANA, the many empty cells cease to be an issue as a column store results in only those filled fields being read.
SAP Accounting, powered by SAP HANA, takes the radical step of removing these aggregate tables. Updating the totals tables can be a bottle neck when you're trying to post huge amount of data from an external system or perform complex allocations because each time you write a document you also need to lock the totals record (cost center, period, cost element) and then release it when the posting is complete. Take the totals away, and your accounting records are created more quickly because the program only has to update the line items table rather than multiple aggregate tables.
This is simpler, but it will likely involve a complete rewrite of the existing code, both SAP and the many partner and customer add-ons. The totals tables are gone, but views replace them with the same name, so a program that previously read from table COSP now selects the relevant line items and then aggregates them into the period block. SAP code and your code will continue to work as before, as will the extractors to SAP BW. Figure 1 shows the view that now replaces table GLT0.
This ensures that the move to SAP Accounting, powered by SAP HANA, will not disrupt your existing code. The index tables are also gone. When you perform a dunning run or create a list of open items by vendor or customer, you no longer read index tables such as BSIK and BSID, but instead using the equivalent views.
Figure 1: Replacement View for Table GLT0
2. IS THIS JUST A NEWER VERSION OF THE GENERAL LEDGER
Some arguments for SAP Accounting powered by SAP HANA are not new. I've talked about a single version of the truth for at least ten years. In the context of the new General Ledger, this meant the ability to report not just by company code and business area but also by profit center, functional area, and trading partner. The FAGLFLEXA table meant that several special ledgers became obsolete, and you could balance, e.g., by profit center, without waiting for period close to assign your payables and receivables to the correct profit center.
Real-time integration also allowed SAP to switch off the reconciliation ledger between CO and FI and update FI in real time when a secondary posting crosses company codes, profit centers, etc.
All this functionality is inherited in SAP Accounting powered by SAP HANA. SAP has also extended the table structure to link the line items in the BSEG table with the line items in the COEP table and the CO-PA characteristics entries in the CE4XXXX table.
Figure 2 shows new fields in the CO line item table COEP. The first three, reference procedure, object key, and logical system, connect the FI line item and its partner CO line item. This connection used to be made at the header level but is now available for every profit and loss line item with an equivalent revenue or expense line in Controlling. Going down the list, you'll also notice that alongside the CO object field (previous page), we can also see the real account assignments (cost center, activity type, and order number).
Figure 2: New fields in the CO line item table
When you took your first training class, you learnt how the P&L accounts have a sister cost element and how a salary posting to a cost center or a goods issue to an internal order flows into CO. The link between the tables means you can now see those cost centers and internal orders within your income statement without drilling into a separate report via the report-report-interface.
Figure 3 shows a simple income statement in the report rows and the associated cost centers in the report columns. To achieve this sort of report in the past, you would have had to leave the income statement and drill down into the relevant cost center reports by passing the relevant selection parameters. The same is possible for orders/WBS elements and other CO account assignments.
Figure 3: New income statement showing cost centers associated with the accounts
Since the Segment Reporting requirements were introduced with IFRS 8 and IAS 14, internal and external accounting requirements have come back together, and people have been trying to reconcile their income statement in FI-GL with the income statement in CO-PA. This reconciliation is tricky because the general ledger is based on accounts. In contrast, costing-based CO-PA is based on key figures, and the customizing involves transforming accounts and cost elements into value fields.
SAP Accounting, powered by SAP HANA, continues to support costing-based CO-PA, but it puts a much stronger emphasis on account-based CO-PA to inherit the link by account. Figure 4 shows the operating profit line in the income statement, broken out, this time, by customer. The advantage of account-based CO-PA is that the revenue and cost lines in the income statement naturally line up.
Figure 4: New income statement showing customers associated with the accounts.
If you aren't already using account-based CO-PA, beware that no migration tool takes you from costing-based to account-based CO-PA. You can allocate your cost center costs and settle your order/project costs to account-based CO-PA, but you will need to build new assessment cycles since there is no systematic way to interpret the semantics of your existing value fields. There are also a few myths out there. Several sources claim you cannot perform top-down distribution (transaction KE28) in account-based CO-PA. This has been a myth since Release 4.7. Moving top-down distribution to account-based CO-PA has the benefit that real-time integration between CO and FI will result in postings that cross organizational boundaries, triggering an additional posting in the general ledger.
In the past, there were a couple of places where account-based CO-PA didn't provide as much detail as costing-based CO-PA. In SAP Accounting powered by SAP HANA, SAP has extended the configuration to allow you to break out the cost of goods manufactured according to the cost components in the underlying cost estimates. SAP has introduced new quantities in the COEP table so that you can convert the logistics quantities in your materials documents (boxes, pallets, and so on) into consistent quantities for management reporting (tons or kilograms). Where manufacturing customers rejected account-based CO-PA in the past, they now find that the main gaps are gone. Functionally, they effectively have their value fields as accounts, and because SAP HANA is a column store, they can easily select and aggregate along the CO-PA dimensions.
3. How do I report in SAP Accounting powered by SAP HANA
Figures 3 and 4 show one reporting option. We use a HANA view to combine the BSEG, COEP, and CE4 tables. You'll need to install the SAP HANA live content alongside the traditional ABAP components to use this option. In addition to SAP Business Objects Analysis for Microsoft Excel, you can run the same reports as queries in Web Dynpro. Figure 5 shows a sample financial statement in Web Dynpro.
Figure 5: Financial Statement in Web Dynpro
While you're thinking about reporting, it's worth considering where you previously worked with aggregates. In CO, we didn't just use the totals tables (COSP and COSS) and summarization levels in CO-PA and summarization objects in CO-PC. As you move to SAP Accounting powered by SAP HANA, you can revisit every drill-down report and switch them to read on each navigation step rather than reading pre-filled aggregates. This is potentially game-changing in that you will no longer be working with summarization levels for each dimension in the CO-PA report, but navigating freely through up to 50 characteristics in CO-PA.
You can also revisit your period close processes and remove the data collection runs in CO-PC that created summarization levels to allow you to aggregate the costs on your orders, projects, and sales orders. You'll still need to create a summarization hierarchy to determine the characteristics you'd like to select your orders. Figure 6 shows a sample summarization hierarchy that aggregates by plant and material. In the past, the data collection run would write additional data records for each plant and material in the list - these are CO objects beginning with VD - and the summarization reports would read these records from the totals tables. With SAP Accounting powered by SAP HANA, the figures per plant and material are aggregated on the fly.
Figure 6: Sample Summarization Hierarchy
Of course, if you want to carry on using a data warehouse, the existing extractors will continue to pull data from SAP Accounting, powered by SAP HANA, into SAP BW.
4. What are the deployment options for SAP Accounting powered by SAP HANA
If you want to move to SAP Accounting powered by SAP HANA, you have two main options. The first is to migrate to SAP HANA (unless you're already running SAP Business Suite powered by SAP HANA) and then run an application migration to remove the aggregate tables, link the FI and CO line items, etc. If this sounds too far, another option is to deploy SAP Accounting powered by SAP HANA on a dedicated HANA system and then feed data from your existing systems into this box. Before you begin such a journey, please read the documentation. You can access all release notes, installation, and upgrade information via the SAP Library documentation in the link below.
https://help.sap.com/viewer/
If you're considering the migration path, remember that the application migration includes a migration to the new GL tables and new Asset Accounting. The migration to the new GL will give you real-time integration between CO and FI and activate the profit center, segment, cost of goods sold, and consolidation preparation scenarios. At the time of writing, migration programs are not yet available for document splitting or parallel ledgers, so if you aren't already running the new GL, consider performing this migration in the classic ERP world before embarking on the HANA migration.
Migration to SAP Accounting, powered by SAP HANA, also involves migrating to new Asset Accounting. This was introduced as a business function in SAP Enhancement Package 7 for SAP ERP 6.0 to improve parallel accounting by making it possible to assign accounting principles, ledgers, and charts of depreciation cleanly. There are new transactions to allow ledger-specific postings (for example, where freight costs are handled differently depending on the GAAP) and the ability to make one-sided postings where an asset isn't considered an asset in all GAAPs.
Figure 7 shows the implementation guide that will walk you through the various steps of the application migration. It begins with migrating to the new General Ledger, then migrating any custom ledgers you may have created. Then, it moves on to the generation of the CDS views we saw in Figure 1, which represent the former totals and index tables and link the FI and CO line items.
Beyond the obvious project management aspects of such a migration, there are a few more things to consider in association with your existing data. The balance carried forward for each fiscal year was traditionally stored in the totals tables. With SAP Accounting powered by SAP HANA, a document will be written to the line item table FAGLFLEXA to record this balance. It's also common for customers to archive their line items early while keeping the equivalent data in the totals records or index tables. During the migration, the system works with backup tables, such as BSIS_BCK. In this case, any partially archived documents will be read from BSIS_BCK instead of the line items. In the case of the total records, there is not only a back-up table, such as KNC1_BCK, but also a difference table, KNC1_DIF, that is filled where differences occur between KNC1_BCK and BKPF/BSEG.
Figure 7: Implementation Guide for the Migration to SAP Accounting powered by SAP HANA
Instead of taking the migration path, another option is to set up a separate HANA box and deploy SAP Accounting powered by SAP HANA on this box. This second box may seem expensive in the war against redundancy. Still, it allows customers to build the financial system they want going forward using the new GL features, account-based CO-PA, etc. In contrast, their existing systems remain on their current release with their current implementation approach. The data transfer to this central journal uses SLT (software landscape transformation tools), which allows significant mapping. In the central system, customers can use new GL, account-based CO-PA, and so on, and map to a central chart of accounts, central profit center hierarchy, central operating concern, and so on. However, significant thought is needed to decide how master data will be handled in such a constellation.
5. What about the cloud
If you followed the announcements at Sapphire, SAP Simple Finance is a suite of finance applications for the cloud. The Financials Add-On for SAP Business Suite powered by SAP HANA (SAP Accounting powered by SAP HANA is a part, along with SAP Cash Management and Integrated Business Planning) can be deployed on premise and in the cloud. We're all familiar with what on-premises means, but there are many variants of cloud implementations. At the time of writing, "cloud" means SAP HANA Enterprise Cloud, and SAP offers a hosting service to customers who run their financial processes in this cloud environment.
6. Why does all this matter
After one of my presentations, a customer surprised me by announcing that SAP Accounting powered by SAP HANA was the biggest innovation in Finance since R/2. To understand the impact, I've found myself back in my early SAP R/3 slides, talking tables more than I've done for years.
It's easy to be misled by the Powered by SAP HANA label, but don't let the conversation about the new accounting solution be an entirely technical discussion. Remember that the technology is an enabler. It can be about pure speed, as when we have to get the result of a query back to a mobile device before the connection times out. More often, it's about revisiting what we already do or asking what we can do differently. SAP has just rewritten parts of the settlement programs, the WIP calculation programs and the variance calculation programs so that instead of preparing an order list and then working sequentially down the list, an SQL statement selects the orders and the associated costs, then joins in the customizing tables to bring these costs into the correct aggregation (e.g. line IDs for WIP calculation) and then passes the results back to ABAP for posting. These transactions' UI and period close procedure are virtually unchanged, but the performance change is significant.
In my conversations, I see customers working with their controllers to see how they can do things differently. Now that they have Material Ledger data in flat tables (FCML_MAT and FCML_REP), they are starting to simulate what happens if they use this data to forecast and simulate their product costs. Gradually, the conversation moves from a technical conversation (table size, memory footprint) to a business conversation (how can I get more insight from the information I'm collecting?), making SAP Accounting powered by SAP HANA very exciting.
Join us at the SAP Controlling conference to network with Janet Salmon, John Jordan, Paul Ovigele, and other expert SAP speakers. You'll also learn about the latest developments in SAP S/4HANA.
Click here for details
Glossary
Activity Type
An activity type identifies activities provided by a cost center to manufacturing orders. The secondary cost element associated with an activity type identifies the activity costs on the cost center and detailed reports.
Actual Costing
Actual costing determines what portion of the variance is debited to the next-highest level using material consumption. All purchasing and manufacturing difference postings are allocated upward through the BOM to assemblies and finished goods. Variances can be rolled up over multiple production levels to the finished product.
Assembly Scrap
Assembly Scrap allows you to plan for faulty or damaged assemblies.
Since no production process is perfect, some scrap is always produced. You can scrap or rework assemblies and components not meeting quality standards. Depending on the problem, you may scrap cheaper items and rework costly items.
Component Scrap
Component scrap is the percentage of component quantity that does not meet the required quality standards before being inserted into production. The planned quantity of components is increased. Component scrap is an input scrap because it is detected before use in the production process. You plan component scrap in the MRP 4 view and the Basic Data tab of the BOM item. An entry in the BOM Item field takes priority over an entry in the MRP 4 view.
GRIR
SAP Goods Receipt Invoice Receipt performs a three-way match between the purchase order, goods receipt, and invoice receipt.
You use the GR/IR clearing account to record the offset of the GR and IR.
Internal Order
An internal order monitors an organization's costs and revenue for short—to medium-term jobs. You can carry out planning at a cost element and detailed level, as well as budgeting at an overall level with availability control.