I’ve spent the last six months working with the first accounting customers to validate and implement SAP Accounting powered by SAP HANA. I’ve talked with even more customers about the possibilities of the new solution. SAP Accounting powered by SAP HANA will be made generally available on 1st August 2014. In this blog, I’ll explain how the new solution differs from earlier software versions and discuss some of my learnings.
Is SAP Accounting powered by SAP HANA as simple as Hasso Plattner promises?
If you’ve been following the blogs written by Hasso Plattner, one of SAP’s founders, you’ll know that he has declared war on aggregates. The rationale is simple: aggregates are yesterday’s technology. In the past we needed them to provide aggregated data quickly in a report or during a process that operates on that data, such as an allocation or settlement. With SAP HANA such data can be aggregated from the 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 and so they built tables that contained the cost center/project/order, the period, and the various cost elements (the primary and secondary cost tables – COSP and COSS respectively). The approach 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 kind of thinking, allowing them to directly query the data in the line item table (COEP) to find out which suppliers they have been spending most with or which employees have the highest travel expenses. We’ve all got 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 all so used to this kind of report that we tend to forget what’s actually in the line item tables. To take one example, think of the line item table in the general ledger, the 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, 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 reading from COSP and COSS. A reason to avoid the line item tables is that typically the other fields that are filled depend on the type of posting, so an asset acquisition will fill different fields from an expense posting or a receivable item. What we essentially have is 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 fields that are filled 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 radically simpler, but sounds like it will involve a complete rewrite of the existing code, both SAP’s and the many partner and customer add-ons. In fact the totals tables are gone, but they are replaced by views 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’s code and your code will continue to work as before, as will extractors to SAP BW. Figure 1 shows the view that now replaces table GLT0. This simple trick ensures that the move to SAP Accounting powered by SAP HANA will be non-disruptive for your existing code. In the same brush stroke the index tables are gone. When you perform a dunning run or create a list of open items by vendor or customer you will no longer be reading index tables such as BSIK and BSID, but instead using the equivalent views.
Figure 1: Replacement View for Table GLT0
Is SAP Accounting powered by SAP HANA just a newer version of the general ledger?
Some of the arguments for SAP Accounting powered by SAP HANA are not new. I’ve been talking about a “single version of the truth” for at least ten years. In the context of 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 was also a powerful tool allowing SAP to switch off the reconciliation ledger between CO and FI and update FI in real-time whenever a secondary posting crossed company codes, profit centers, and so on.
All this functionality is inherited in SAP Accounting powered by SAP HANA but there is more. SAP has now extended the table structure to link the line items in FI (the entries in the BSEG table) with the line items in CO (the entries in the COEP table) and the CO-PA characteristics (the entries in the CE4XXXX table). Figure 2 shows some of the new field in the CO line item table (COEP). The first three, reference procedure, object key, and logical system, are used to make the connection between the FI line item and its partner CO line item. This connection used to be made at header level but is now available for every profit and loss line item that has 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, order number, and so on).
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 that you can now see those cost centers and internal orders from within your income statement without having to drill-down into a separate report via 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 requirements for Segment Reporting were introduced with IFRS 8 and IAS 14, the requirements for internal and external accounting have come back together and people have been trying to reconcile their income statement in FI-GL with the income statement in CO-PA. What makes this reconciliation tricky is that the general ledger is based on accounts whereas costing-based CO-PA is based on key figures. Much of the CO-PA 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 in order 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 there is no migration tool to take 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. I’ve found several sources that claim that you cannot perform top-down distribution (transaction KE28) in account-based CO-PA. This has been a myth since Release 4.7. In fact moving top-down distribution to account-based CO-PA has the additional benefit that real-time integration between CO and FI will result in any 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 are now finding 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.
How do I report in SAP Accounting powered by SAP HANA?
Figures 3 and 4 showed one option for reporting – we’re effectively using a HANA view to combine the BSEG, COEP, and CE4 tables. To use this option, you’ll need to install the SAP HANA live content alongside the traditional ABAP components. Besides 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 were working with aggregates in the past. In CO, we didn’t just use the totals tables (COSP and COSS) but also 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 according to which you want 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.
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, and so on. If this sounds like a step too far, another option is to deploy SAP Accounting powered by SAP HANA on a dedicated HANA system and then feed data into this box from your existing systems. Before you embark on such a journey, read the documentation. You can access all release notes, installation and upgrade information via the SAP Library documentation in the link below.
If you’re considering the migration path, then bear in mind that the application migration includes a migration to the new GL tables and to 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 you might 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 a migration to new Asset Accounting. This was introduced as a business function in SAP Enhancement Package 7 for SAP ERP 6.0 with a view to improving 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, beginning with the migration to the new General Ledger, then migrating any custom ledgers you may have created before moving on to the generation of the CDS views that we saw in Figure 1 that represent the former totals and index tables and linking the FI and CO line items.
Beyond the obvious project management aspects of such a migration, there are a few additional aspects 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 back up tables, such as BSIS_BCK. In this case, any partially archived documents will be read from BSIS_BCK instead of from the line items. In the case of the totals 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 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 but it allows customers to build the financials system that they want going forward using the new GL features, account-based CO-PA, and so on while their existing systems remain on their current release with their current implementation approach. The transfer of data to this central journal is made using SLT (software landscape transformation tools) which allow 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, though clearly significant thought is needed to decide how master data will be handled in such a constellation.
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 (of which 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 premise 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 choose to run their financials processes in this cloud environment.
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. The UI and period close procedure for these transactions are virtually unchanged but the performance change is significant.
In my conversations, I’m starting to see customers working with their controllers to see how they can do things differently. Now that they have their material ledger data in flat tables (FCML_MAT and FCML_REP) they are starting to simulate what happens if they use this data as a basis for forecasting and simulating their product costs. Gradually the conversation is moving from a technical conversation (table size, memory footprint) to a business conversation (how can I get more insight out of the information I’m collecting?) and that makes SAP Accounting powered by SAP HANA very exciting indeed.