Finance Differences in SAP S/4HANA

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

I have written more about New Asset Accounting in my latest E-Bite Introducing New Asset Accounting in SAP S/4HANA – you can find out more at https://goo.gl/qIbdQZ which is a short cut to the SAP Press site. This book covers how new asset accounting works in S/4HANA and is aimed at users who are new to SAP as well as those migrating from earlier versions of SAP.

S/4 HANA Finance: Questions and Considerations

Here are some things to consider when assessing a move to S/4 HANA Finance:

HANA & S/4 HANA

HANA is the superfast powerful “in-memory” database. It organizes data differently to reduce complexity, it is faster to access, indexing, aggregating not required etc. Instead of holding totals in tables, totals are calculated on the fly (a phrase you will hear a lot – meaning recalculated as you go). 

Considerations/Questions: 

• Some customizing will still work as there will be “views” with the same name as the obsolete tables (recreated from the new table for this purpose). Your bespoke program can read from these views but if your bespoke programs were writing to tables, you cannot write to the views

• You should be told about various tools to check your bespoke customizing well before any migration. In any case, it is a good idea to review as you may now be able to replace some programs with standard functionality

• You may find a separate charge for the database, in addition to the S/4 HANA and the landscape

S/4 HANA is the SAP Business Suite that is built and optimized to run (only) on the HANA database.

You will see two different types or editions of S/4 HANA (i.e. the business suite “software”) but the combination with different landscape options can be confusing.

The names of the two different S/4 HANA editions are:

• SAP S/4 HANA Cloud (although a number of different versions exist) with quarterly releases

• SAP S/4 HANA on-premise – each release is named after the year and month – we have had 1503 (Simple Finance only), 1511 and 1610 releases (1610 the current one was released on Oct 2016 next will be 1709 i.e. Sept 2017)

The first is sold as a service and is available on a multi-tenanted public cloud (i.e. your data is secure, but you share the programs with other customers - simplified, standardized, almost no custom programming) whereas the on-premise version is available how you want it, on third party or your servers/cloud, with custom programming allowed (and when we did it more complex to license and buy/hire the different pieces)  

(Be careful because the first is called The Cloud edition, and usually what people mean when they say Cloud, but you can also have your on-premise edition in a cloud)

 Considerations/Questions:

• If you are using an Industry solution check whether it is compatible specifically with edition that you are going with

• Check any restrictions - e.g. AFS with 1511 edition did not use BP (Business Partners) although BP was mandatory for the standard solution

• Free trials are available but careful that you understand which edition you are trialing

• Check paths (if on e.g. 4.6 you may have to migrate first to higher version, then convert to S/4 HANA if not a new implementation)

Landscape

Public Cloud 

Multi-tenant, scalable, operated by service provider and not customer, and lot of simplification, pre-configuration and Fiori front end. Different versions such Enterprise Management Cloud (the main Business programs), Finance Cloud, Professional Services Cloud, Hybris Marketing Cloud and Manufacturing Cloud.

Effectively the Public Cloud has one set of programs that you are sharing with other customers. It should be very secure but it does mean that very little, if any bespoke work can be carried out.

Very different concept to standard SAP. You have access to a reduced version of the SPRO/IMG (the configuration menu) and you cannot write your own ABAP programs. You have quarterly updates and you do not have a choice about implementing them. In the past, you may have had a Development system for configuring and unit testing, a Quality/Testing system and perhaps a Training system as well as the final Production client, the public cloud structure is very different (you usually have production and one other)

Generally sold as Opex rather than Capex (operating rather than capital costs) or subscription based for the combination of software and hardware. Self-service configuration allows business users more access to set up e.g. of organizational structure, house banks

Considerations/ Questions:

• Security

• Check into different versions (mentioned above) there seem to be a lot more available now

• Licensing (subscription – user/revenue based)

• Backups

• Upgrades

• OSS notes

• If system crashes – time to reboot and get data back into memory – how the data is backed up while you work and how much time you might lose (should be minimal but they should be able to explain this)

• Service level agreements, incident support, monitoring, what is included

• Check how many systems involved (usually production plus one other).

• Check – but I think it uses only Fiori will you have enough Fiori transactions that you need as not all GUI transactions may be available in Fiori

HEC (HANA Enterprise Cloud)

Be careful when people mention Cloud as they usually mean public cloud. HEC is often referred to as on-premise rather than cloud as this is the edition of S/4 HANA that is used with it.

HEC is owned by customer or Third Party, but still scalable. One upgrade/release per year. Here you are the only one on the system (regardless of whether it is Cloud or not) so you are free to choose when the upgrades happen, what bespoke programming/customizing you want to carry out etc. Upgrade is an IT project (as opposed to private cloud upgrades which are done automatically by SAP)

Considerations/Questions:

• Licensing – It is a quite complicated, perpetual license and recurring hosting fee but a lot of licensing is based on revenue, number of objects etc.

Hybrid

Mix of two, you may have some systems in the cloud and some not.

Implementation

3 Options:

System Conversion - On-Premise Edition only

Data is directly converted with history in the existing system (but not necessarily all history–e.g. you could take last 5 years’ open items).  Figures have been quoted to me of downtime of one weekend for the physical conversion itself, but obviously depends how much data and the complexity and what other changes are taking place and you would.

You would still need many months testing and full project team in place, especially if you have many interfaces. It also assumes that you make copy your productive system to a sandbox to do the first test run, which will give you an indication. Bear in mind you will also have to convert all your development, quality, training etc. Systems. Can’t use with public Cloud

Considerations/Questions:

• Are you migrating to New GL or already on it? This has major effect on timing as New GL has to be at yearend

• Are you introducing Parallel ledgers with new GL. Discuss with SAP whether better to migrate to new GL and parallel ledgers before implementation (only since the 1610 release can you add parallel ledgers after migration but not sure if you can add them during

• Document splitting – this cannot be added (in 1610) after migration so you may have to go to new GL before the migration to S/4 HANA

• Integration to other systems - depending what you have been using in the past there may now be more efficient ways of interfacing to other systems – this should be looked into

• Have to convert whole system at once – cannot move in stages (e.g. once company code at a time)

• Check steps – usually install HANA database before conversion, some config tasks

• maintenance planner to run through tasks and timing

Greenfield Implementation

Worth considering if on SAP for years. you can use the move to S/4 HANA to move to Best Practices, re-engineer business processes and get rid of a lot of obsolete or no longer necessary bespoke work. 

Considerations/Questions:

• See migrations considerations/questions about uploading data

Central Finance/Landscape Transformation

To consolidate a lot of diverse systems very quickly, you basically map your finance data from all your SAP and non-SAP data to a Central Finance S/4 HANA system. The data is reposted, but if coming from an SAP system you can drilldown to the original data and you get all the advantages of the speed and consolidation upfront and can migrate the individual systems when you are ready.

Considerations/Questions:

• this is not a migration of historic data

• still a great deal of mapping to do if individual companies on different systems, chart of accounts etc.

• was not a separate cost for the Central Finance itself – just the way it is configured but you may need tools for the mapping

Storage

Data aging strategies (i.e. which data is held in memory, which “nearby” and any archived on different system etc. – data used more frequently should in “hot storage” and “warm storage”.

Fiori

Described as “user experience”, consists of Apps or Tiles (rather like a smartphone than menu path/transaction codes). Includes interactive apps (see figure below) where key information is available on tile itself. Uses Launchpad for home page. Available for multiple devices, desktops, tablets/phones. Based on user roles, so smaller transactions tailored for specific role (not necessarily every field available for every user) 

Worth considering and mandatory for Public Cloud version. 

Considerations/Questions:

• Check in-house knowledge required for Fiori and U5 stuff

• Check whether Fiori is mandatory (generally shouldn’t be for on-premise), but SAP will try to sell it

• Are the transactions you need covered by Fiori (most standard ones should be)

• Worth looking at what is available on Fiori that is not on the SAP GUI

• Check what transactions are available for mobile devise (I presume e.g. approving a PO might be but not sure if everything is)

• Should be trial versions available

• If using personas – check how fits in with Fiori (should be seamless but you will need to know how)

• I believe the GR/IR cockpit is neither a GUI transaction nor a Fiori App as it is not in my 1610 S/4 HANA version nor the Fiori Apps I have access to, nor the Fiori catalogue

• If the GR/IR cockpit is indeed separate functionality/program; check whether separate licensing/cost is involved and what other functionality is included.

• Not all of the thousands of SAP ECC transaction codes were available on Fiori – check whether you still need GUI access

Finance, Controlling, COPA

Effectively merged, so cost element now part of GL account (and cost category field available in GL master).  In Finance, there is a new kind of document called the Universal Journal which posts to a single table (ACDOCA) which contains a lot of data from the other modules, so instead of having to run reports from a number of tables, you can now see almost everything in Finance, for example in line items, including COPA, MM, SD etc. Leads to Single Source of Truth i.e. you don’t have different results in different modules.

Considerations/Questions: 

• Different split of the modules with a lot of new areas for Treasury

• look into Cash Management/In-House Cash/ Bank Communications etc. House-banks for example have moved to a different module which is chargeable but there is a Bank Account Management LITE version so that you can still use the standard banking if you don’t have those modules

• Account-based COPA is the default – although can implement both

• revenue recognition changes coming with IFRS 15, and the SD Revenue Recognition being replaced in by Revenue Accounting and Reporting

• revenue recognition now in Universal journal and recognized as they incur – look into further – 2 postings one for initial costs/revenue and a separate posting for revenue recognition and new Fiori transactions/apps

• COPA data now in finance

• Check - standard credit management no longer available – only FSCM (Financial Supply Chain Management) Credit Management?

• Additional currencies available (from 1610 up to 10) – do you need this functionality?

• Extension/Appendix ledgers (normal ledgers hold complete sets of books, these only hold deltas and are linked to a base ledger so that reporting gives a complete set by combining the base and extension ledger)

• Check Cost of Goods Sold - more flexibility and a number of improvements (e.g. multiple accounts based on cost component split) but check whether when COGS in profitability analysis will be supported

• Closing cockpit – separate cost?

New GL

Considerations/Questions:

• If not already on new GL, don’t necessarily need all the new functionality, but recommend to set up in the beginning if you think you may need it in the future (document splitting can be tricky)

• Document Splitting – not mandatory but previously it was not possible to implement once on S/4 HANA – have to do it before (check this – it was due to be added soon)

• Parallel ledgers cannot be added in earlier versions of on-premise – only1610 versions – check how it works on cloud.

New Asset Accounting

In addition to better reconciliation, there is no data redundancy as you no longer need delta depreciation areas, real-time postings to all ledgers etc. Some considerations are below:

Considerations/Questions:

• New Asset Accounting is the only option on Hana, although available in ECC6 from enhancement pack 7

• During a system conversion, there will be some customizing changes to do particularly for new Asset Accounting, important to understand and decide in advance whether you want to follow ledger or account approach for different accounting principles (even account approach now requires a “dummy ledger” to be configured)

• Even if Greenfield implementation, you will probably have some restructuring to do. Need to match ledgers and currencies and depreciation areas and accounting principles

• You may see a lot of information about the New depreciation calculation engine. Generally, hardly any difference between the old and new calculations unless you are changing depreciation methods/useful lives mid-year - may be worth looking into that more if that is the case

Customer Vendor Integration

Vendor and customer master data held as BP (Business Partner) - if you have a customer that is also a vendor – use same general data (address), more data fields and addresses available, concept of relationship e.g. with contact person. Still keep original customer vendor number (so historic reports ok) but may have new BP number as well. Part of migration step is to synchronize customers and vendors to BP if not already using. 

Considerations/Questions:

• May need to clean up vendors/customers if not using BP and see if any fields exist in BP that were not in old transactions. If not linked may need to decide if you want to link them, how that would be done

• Check bespoke fields in the customer/vendor masters

Material Ledger 

Material Ledger now mandatory.  Change in tables (MATDOC =main table in material ledger), lot more information in Finance.

• Some field lengths change (e.g. Material length now 40 characters) – check any other systems feeding in can deal with increased length here and elsewhere

• multiple currencies and valuations

• check transfer pricing functionality

• check capture of price variances

IDOCS 

Check whether still available and whether any changes e.g. DEBMAS and CREMAS (for customer and vendor) still available but may using the BP number as leading object

Authorizations

Considerations/Questions:

• Fiori will work differently in any case, (one transaction may be split into roles) but if not using GUI should be standardized roles available for new implementation

• There are a number of new GUI transactions that are almost identical to the old but allow for example to post to each ledger group separately so if conversion will need to add them to roles

• If converting an existing landscape, there are a number of tasks as part of the migration to convert for example the cost elements into GL accounts, but going forward you will need to review authorizations e.g. if different people have access to cost elements and GL accounts master data

Licensing and Hosting

Varies greatly between the different options and landscapes. From subscription to itemizing everything out separately. (What I am mentioning here is from 2015, and may not apply depending on which options you go for).

Considerations/Questions:

• Some programs such as MDG (Master Data Governance) are based on each object for example if you want to use MDG for 5,000 GL accounts, 50,000 vendors, 2,000 cost centers, 10,000 customers, 5,0000 vendors, 20,000 materials that would be 92,000 items, and you may therefore need to buy the next available quantity that they are sold in e.g. 100,000

• Many of the financial packages are licensed based on revenue, regardless of whether you are only using IHC (In-house cash) for your vendors, and not customers/Treasury/intercompany etc.

• Types of users (used to have developer, self-service, professional, etc.)

• Is there a separate charge for HANA database?

• Charge for Fiori?

• Maybe review existing licenses – it may be possible to save money by reorganizing the assignment of licenses - not sure if reduced licenses still apply e.g. if somebody was only approving and not running transactions and one company I worked at saved a fortune by reorganizing the perpetual licenses.

• Check what is included for reporting (used to be BI Suite which had Design studio, HANA Live, crystal reports, web intelligence, advanced office analysis, business objects etc. included but may have changed)

• FSCM separate to main accounting license, if you had ordinary credit management you may now have to get FSCM

• Netweaver/web dynpro?

Migration 

Many different paths, especially depending whether Public Cloud or not – public cloud is new implementation but there are tools (SLT) to upload data quite simply from another SAP system.

Considerations/Questions:

• If planning to migrate in stages, you would have to go with a Greenfield migration or Central Finance

• On-premise system conversion – code-checker tool to check your bespoke ABAP programs do not write to tables, and for example whether there are any Z tables etc. You may want to understand more about this tool if you have a lot of bespoke programs.

• Check whether your bespoke programs are calling other transactions/programs. Most old transactions that are obsolete call the new transaction instead but not all (e.g. display house bank FI13 gives the message “please use the Manage Banks and Manage Bank Accounts Apps) so would not work with bespoke programs calling a transaction code

• Look in to SLT (SAP Landscape Transformation) tool if legacy system is SAP.

• Legacy Workbench functionality cannot be used in many areas for example Fixed assets and Business Partners, (does not support new data structure).

Timeline

Need to factor in what modules, complexity of business, integration with other systems, number of organizations/company codes, availability of users for testing training (especially at a year-end) etc. etc. so impossible to give a timeline.

As mentioned downtime for a system conversion can be very short (e.g. weekend) and business can carry on as usual, minimum training and disruption but a lot of testing and you need to factor in the downtime for the conversion and testing of each of your systems e.g. development, quality, test, training as well as the productive system

Activate 

A new concept to replace the traditional ASAP method used by SAP in the past, more applicable to new implementations. With Activate you are given a model company system to trial, you then do the fit/gap, choose your scope and activate it, rather than preparing a Blueprint first and then trying to tailor step by step the configuration to fit it. Everything is based on Best Practices – ready configured business processes and guided configuration to activate them.   With traditional methods of migration, you may have incurred most of the costs and completed most of the build before you realize something is not working, whereas here you get to try a lot more out in the early stages.

Considerations/Questions:

• Check that it can be used with all types of implementation (previously it could only be used with one of the S/4 HANA editions but check whether works with Central Finance landscape)

• check how it integrates with Solution Manager on all (I know Activate works with on Solution Manager 7.2 and higher and a lot of documentation and testing scenarios can be utilized are easily accessible here)

• Check which business processes work with which versions of S/4 HANA – not all work with all versions

Rapid Deployment Solution

This was deployed by SAP at a multinational project I worked on – they had a number or world templates and preconfigured building blocks in order to do a new implementation in a much shorter period of time than the traditional writing of the blueprint and then creating configuration line by line. 

Considerations/Questions:

• Worth looking into

• Check where it is available, not sure if replaced completely by Activate everywhere

Reporting

Number of new options, with embedded analytics you should no longer need to wait overnight for data to be transferred to BW or a data-warehouse, no need to create permanent info-cubes. New concept in S/4 HANA is that the reporting is real-time and virtual cubes or virtual data models that can easily be created as required. Some examples - Business Objects Design Studio, Lumira, Analysis for Office, HANA Live.