SAP Accounting powered by SAP

HANA - Frequently Asked Questions

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.
https://blogs.saphana.com/2014/07/05/the-impact-of-aggregates/
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.
https://help.sap.com/viewer/product/SAP_S4HANA_ON-
PREMISE/1809.000/en-US 
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.