Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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. a nd the launch
pad can contain customized apps and also personas transactions in the same style
as the Fiori apps.
Figure 1 Two Fiori Tiles
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 y ou
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.
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.
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.
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.
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
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.
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.
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).
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
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.
Revenue Recognition
Only the new Revenue Accounting and Reporting, which supports IFRS 15, is
available in S/4HANA, i.e. the SD Revenue and Recognition is no longer available.
LSMW
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
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.
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.
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
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.
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.
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