Introduction

This article covers some of the differences between S/4HANA and previous versions of
SAP.

Simple Finance was the first part of the Business Suite to be rewritten to run on SAP’s
new superfast in-memory HANA database. Simple Logistics followed, and the combined
new product, with New GL and New Asset Accounting as prerequisite, became known as
S/4HANA.

S/4HANA exists as the S/4HANA Cloud which is a standardized Multi-Tenanted Cloud

(i.e. all customers share the same software instance although the data is secure and
private). This comes with a mandatory Fiori user interface, quarterly releases, and
bespoke programming is not possible as you are sharing your system with others. There
is also the On-premise S/4HANA with greater flexibility, freedom to customize as before,
and optional Fiori and annual releases.

The exact functionality will vary depending on the release, and this article is mostly
based on S/4HANA 1610, which is the October 2016 On-premise release, although some
of the functionality below may already be available in the later enhancement packs of
ECC6. I have used print screens mainly from the GUI to help users to compare the
functionality, but mostly the Fiori apps are quite similar.

A lot of the ECC6 functionality is still available in S/4HANA in the SAP GUI;
sometimes transactions are enhanced and easily recognized and both the old and new co-
exist (e.g. FAGLL03 and FAGLL03H), and sometimes you are redirected to new
functionality automatically (e.g. FK01->BP). It seems where the letter H is added at the
end of the transaction, it tends to be a new S/4HANA specific transaction, the letter N has
often been added to new transactions anyway, including those introduced with the New
GL (and some are already available in later versions of ECC). The letter L at the end of
some transactions seems to allow posting to different ledgers e.g. FB01 and FB01L as
well as a lot of the new asset transactions, but these are just guidelines not strict rules.

Fiori

Described as the new User-Experience, Fiori replaces most of the SAP GUI transactions,
resembling the more user-friendly Smartphone apps instead of the traditional SAP GUI
menu structure. Fiori is available on multiple devices i.e. desktops, phones, tablets etc.
Informative, interactive apps are available so you can already see the number of
outstanding items, or account balances on the face of the Fiori app before you click on it
to drilldown further, see Figure 1. Some apps have graphs, calendars (e.g. leave requests),
pie charts etc. and the launch pad can contain customized apps and also personas
transactions in the same style as the Fiori apps.
Figure 1 Two Fiori Tiles

Ledgers and Currencies

In addition to the normal parallel ledgers which were introduced with the New GL, there
are now Extension Ledgers (original called appendix ledgers). The difference is that with
an additional parallel ledger, postings are physically made to both the leading ledger and
the parallel ledger, with only adjustments made to the parallel ledger, whereas extension
ledgers have to be linked to a base ledger and only take delta postings. Therefore, when
you run a report for the extension ledger it pulls in both the base ledger and the extension
ledger to show you the complete picture. The extension ledgers however cannot be used
in asset accounting.

There are now 8 additional freely definable currencies available, although they may not
all be available in other modules and a conversion project would be required to ensure
historical data is dealt with appropriately.

Data structure

HANA has the power to calculate on the fly, which means that for financial transactions,
index tables such as BSIS, BSAS, BSID, BSAD, BSIK, BSAK, BSIM, FAGLBSIS and
FAGLBSAS, as well as aggregate tables such as GLT0, GLT3, FAGLFLEXT, KNC1,
LFC1, KNC3, LFC3, COSS, COSP are no longer required and have been
removed. FAGLFLEXA and some other New GL tables are now obsolete and there are
also new customizing tables.

However, if you have your own ABAP reports using these tables, don’t worry as there
are now Compatibility views with the same name, which recalculate the same values as
the tables would have had, allowing any bespoke programs reading the information to
continue to function. There are new tools which you can run prior to migration, which
allow you to check which of your bespoke programs are read only and will continue to
function and which need rewriting. In any case you may find that some of your bespoke
programs are no longer required because that functionality is now available as standard,
or that it will be more efficient to rewrite them using the new tables anyway.

Universal journal

This is the name of the enhanced financial document in S/4HANA. A Universal

Journal is created whenever anything is posted to Finance from any module and each
journal can be displayed as before using the display document transaction FB03. Many of
the journal entry, invoice entry and other posting transactions are still available in the
SAP GUI, so you can still for example use FB50 or FB50L (by ledger) to post a journal,
although the Fiori equivalents are more user-friendly. The Universal Journal is the Single
Source of Truth for finance, Controlling and COPA, and includes all the cost objects
traditionally found in Controlling such as cost centers, internal orders and WBS elements
as well as columns for the standard CO-PA characteristics and up to fifty additional
characteristics. See also the next section on merging Finance and Controlling. New
reports are available, mainly in Fiori, but the old Controlling reports continue to work
(using compatibility views), including those for planning

ACDOCA is the name of the Finance module’s important new S/4HANA table, which is
based on the Universal Journal line items, containing all of the financial fields, as well as
a lot of information from other modules. Figure 2 shows an extract of the ACDOCA table
showing some of the asset and material ledger fields available.
Figure 2 ACDOCA Table Showing Some of the Fields

Single Source of Truth

Finance and Controlling are now merged, getting rid of data redundancies and the need
for reconciliations, and making visible the internal CO actual postings in FI as well. The
real-time FI-CO integration is also obsolete and Controlling data is stored in the new
finance table ACDOCA.
To have only one field available in the Universal Journal for both the GL account and
cost element numbers, the cost elements are contained inside the GL account master
records. To achieve this, there are now four types of GL account, instead of the previous
two, i.e. Balance Sheet and Profit & Loss - see Figure 3.

Figure 3 GL Account Type

If you select Primary or Secondary Costs as the GL account type, then on the Control
Data tab you will see Controlling Area settings such as the cost element category (see
Figure 4). The dropdown options in Figure 4 are based on choosing primary costs as the
GL account type. Categories relating to secondary costs are available if you choose the
secondary costs GL account type. Cost element groups are still available.
Figure 4 Cost Element Category
Default account assignments from the cost elements are automatically migrated to the
OKB9 configuration transaction and configuring cost object defaults in OKB9 is the only
option going forwards.

An additional column appears in Transaction OB52 (opening and closing periods) for
postings from Controlling to Finance, (although you still need OKP1 at Controlling Area
level), and you have the option of selecting the posting period variant prior to entering the
time interval screen.

Account-based profitability analysis must be activated but you can still use costing-based
profitability analysis in parallel. Initially realignment was not supported but this has been
brought in with release 1610.

Enhanced Search

If you click on the colored icon at the far right of the top menu bar in the S/4HANA GUI
and choose options (see Figure 5), then go to Interaction Design->Visualization 2 you
can choose whether to use the enhanced search or not, or only with a keyboard shortcut
(Ctrl + Shift + Q), see Figure 6.

Figure 5 GUI Options Menu

Figure 6 Enhanced Search Functionality Settings

The enhanced search functionality can be used in many places, for example in the vendor
line item report to find the vendor by name (Figure 7), by vendor number (Figure 8) by
postcode, country, search term or anything else available on that specific enhanced search
screen. If you search for example for a material (Figure 9) you will see different search
options.
Figure 7 Enhanced Search Using Name

Figure 8 Enhanced Search Using Vendor Number

Figure 9 Enhanced Search for Material

Vendors and Customers

Customers and vendors can only be maintained using the Business Partner functionality
(of which there is of course a Fiori equivalent) and if you try to use the old codes e.g.
FK01/2/3 or XK01/2/3 to create/amend/display a vendor or FD01/2/3 and XD01/2/3 to
create/amend display a customer you will be redirected to transaction BP.

Many of the screens are fairly similar to the old master data transactions, but a lot more
data is available and one Business Partner may have roles in MM, SD, and FI.
Employees, banks and other contacts can also be set up as Business Partners. Multiple
relationships can be specified and new time dependent data is available for e.g. addresses
and bank data. See Figure 10 and Figure 11. You will need to migrate your customers and
vendors to Business Partners as part of the migration if you are not already using them.
Figure 10 Business Partner Payment Tab
Figure 11 Business Partner Identification Tab
Figure 12 Business Partner Relationship contact example

Line Item Reports

The old reports, such as FBL1N, FBL5N and FAGLL03 still exist alongside FBL1H,
FBL5H and FAGLL03H which have slightly different screens. The selection screen is
quite similar, although note that the additional selections button (the red, green and blue
stripy one) now appears halfway down the selection screen instead of at the top and is
labelled Restrictions. Once you execute the report however, things look somewhat
different and the line items start off summarized by period.

Figure 13 Transaction FBL1H

If you want to see the line items you need to select the lines that you want to see and click
on the icon on the right call line item report. This will take you to your normal FBL1N
screen. In Figure 14, I chose only the last period, i.e. period 6 in 2017 containing one
row, (the cleared payment for the previous period). In Figure 15, I chose period 12, 2017
to show the other display setting in FBL1N. (to toggle between the two, go to Settings->
Switch List in the top menu in the line item display).

Figure 14 Vendor Line Item Display Called from FBL1H

Figure 15 Vendor Line Item Display Called from FBL1H

By clicking on the vendor number in the body of the report, you will be redirected to the
vendor master data (held in the Business Partner transaction)

Credit Management

FSCM replaces the previous Accounts Receivable credit management transactions (e.g.
F.28/F.31/F.32/F.33/FD32) and the Sales transactions (VKM3/VKM5). If you are not
already familiar with FSCM, this already used the Business Partner functionality prior to
S/4HANA and has additional functionality, in areas such as Credit Management,
Collections Management (including collection worklists), Dispute Management. It also
has additional reporting and allows you to import external credit information.

Materials

The Material Ledger is mandatory (although Actual Costing is still optional) and there
are also new tables for material documents (MATDOC), a Cost of Goods Sold variance
split and no locking of tables. The material number field is extended from 18 to 40
characters and this information is available in the Universal Journal document, and
therefore the ACDOCA table for reporting in finance. Note that the extended material
functionality can be switched off if for example you have a multi-system landscape.

Global trade Services (GTS)

GTS replaces the foreign trade functionality in Sales and Procurement. This allows the
pulling in of data from different systems, and is extensively integrated with SD and MM.

Revenue Recognition

Only the new Revenue Accounting and Reporting, which supports IFRS15, is available in
S/4HANA, i.e. the SD Revenue and Recognition is no longer available.

LSMW

The Legacy System Migration Workbench is still available in S/4HANA, but it is not
recommended for migrations as it has not been amended for the new data structures, and
some functionality is not available e.g. transaction recordings cannot be made with the
Fiori transactions.

The Maintenance Planner tool has to be used for a system conversion, which among other
things, checks add-ons, active business functions and industry solutions to ensure that
they can be converted.

Central Finance

Central Finance is a new concept introduced with S/4HANA. It allows users with a large
and distributed landscape to replicate both SAP and non-SAP finance data real-time to a
central S/4HANA system, but still allowing drilldown to the original document in the
SAP systems.

Cash Management

There is a suite of programs, Cash Operations, Bank Account Management (BAM) and
Liquidity Management that replace the classic cash and liquidity management, and you
can centrally manage the actual and forecast cash positions from SAP and non-SAP
systems by using the One Exposure operations Hub. Transactions such as FF7A and
FF7B (cash management and liquidity forecast) are now Fiori apps.

House banks and house bank accounts, which are now master data, can be managed by
users in Fiori, along with banks hierarchies or groupings, overdraft limits, signatories and
approvals flows and additional reporting such as the foreign bank account report, helps
compliancy. The hierarchy uses the bank business partner role
Bank accounts can also be downloaded and uploaded to and from Excel, for reporting,
migrations and mass changes. They are created in the productive system, but still need to
be replicated to the development and quality assurance systems etc. as configuration for
payments and bank statements still needs to be made in the development system and
moved through quality to production as usual.

If you don’t want to implement the full Bank Account Management (BAM), then Basic
Cash management is also available, previously known as BAM Lite.

Other Fiori apps available include for cash operations include the Incoming bank
statements monitor, cash payments and approvals, cash position reports, transfers, cash
pooling.

Figure 22 Examples of a Few Bank Management Apps in Fiori

FI12_HBANK is the SAP GUI transaction for the user that replaces the House Bank icon
in the customizing transaction FBZP, (see Figure 23), although you will find more
functionality in the Fiori App such as the hierarchies and groupings. After entering the
company code on the first screen you can display, amend or create new house banks.

Figure 23FI12_HBANK - House Bank Transaction in SAP GUI

New Asset Accounting
Depreciation Areas - You still have the choice of using the parallel ledgers brought in
by the New GL or accounting for different accounting principles using a different range
of GL accounts. However, even if you use different accounts for the different accounting
principles, you still need to set them up in asset accounting as dummy ledgers. You no
longer need to set up delta depreciation areas where you have additional accounting
principles, but you do need to have a one to one match for each currency and ledger in
Finance with a depreciation area in Asset Accounting.

The depreciation areas are now equal (i.e. depreciation area 1 does not have to be the
leading ledger) and transaction ASKB, (post additional depreciation areas periodically to
finance), has been removed because you can post all depreciation areas to Finance in
real-time if required. Because all the postings are real-time, you can navigate and drill
down to most of the financial documents not just those in depreciation area 1.

Postings – As with finance, a lot of the tables are now redundant and a lot of the asset
information comes across via the Universal Journal in table ACDOCA. The asset balance
sheet accounts are now all reconciliation accounts – even those in the additional
depreciation areas, which prevents manual postings that are not updating the assets. The
depreciation run posting has been improved and the depreciation journal contains asset
information at line item detail so in the GL line item report you can see the amounts by
asset, see Figure 16

Figure 16 Depreciation Account in GL Account Line Item Display

You can also drilldown to the asset accounting from the finance document (click on asset
accounting icon in Figure 17) to see the postings by ledger group.

Figure 17 Finance Document for Asset Acquisition

In Figure 18, you can see the Technical Clearing account functionality. This is required
to post the other depreciation areas in real-time, whilst allowing the flexibility to post
each asset differently in each ledger. Some accounts, for example vendors, customers,
GRIR account and tax accounts cannot be posted to unilaterally i.e. in one ledger and not
others. Therefore, the acquisition or retirement posting is split into at least two
documents. The first is called the operational posting and has a blank ledger group i.e. it
posts equally to all ledgers.

The posting for an acquisition is credit vendor and debit technical clearing account. The
second, valuating posting, then posts between the technical clearing account and the asset
with a separate document for each ledger. To get to the posting for the additional ledgers
and currencies, you have to click on the A/P Currency icon (which stands for Accounting
Principle/Currency) and you can see the document in Figure 22 shares the same
operational posting with document 1900000019 but has a different valuating posting with
document 7000000073 instead of 100000048 which was the document number for the
leading ledger.
Figure 18 Figure 14 Drilldown to Ledger Postings by Asset

Figure 19 Asset Acquisition, Parallel Ledger Posting

Accounting Principle and Depreciation Area are new fields now available in many new
transactions (e.g. ABZOL instead of ABZO, or ABUML instead of ABUM and so on), so
there is no longer a need for depreciation area specific transaction types.

Settlement rules can also be ledger specific if required, see example in Figure 20
Figure 20 Ledger Specific Settlement Rules

Year-End – this is now carried forward as part of the finance transaction FAGLGVTR,
in other words both the general ledger and assets are carried forward together

Statistical postings – instead of statistical cost elements with cost category 90 there is
now a special field in the GL account master record only in fixed asset and material
reconciliation accounts called Apply Acct Assignments Statistically in Fixed Asset
Acct/Material Acct.
Figure 21 Asset Statistical Account Assignment