In this blog I will explain the new Event-Based Revenue recognition functionality in S/4HANA 1610.
The Purpose of event based revenue recognition in a nutshell:
With Event-Based Revenue Recognition, postings to relevant account assignment objects will lead to revenue recognition calculations. The basis for the revenue recognition calculations are all document line items that are assigned to the account assignment object.
Processes that do not write a prima nota do not result in any real-time revenue recognition postings (for example, changes of plan data do not directly result in revenue recognition postings). If necessary, period-end closing postings (periodic revenue recognition) will correct the event-based postings.
In S/4HANA 1610 only the Sales Project with contract type Fixed Price, Time & Expense and Periodic Billing is supported as account assignment object.
As mentioned, the basis for the revenue recognition calculations are all document line items that are assigned to the account assignment object (Project in this case). The entry of a source document (e.g. time confirmation), produces two separate journal entries:
A journal entry for the initial cost or revenue posting
A journal entry for the revenue recognition posting
Supported Revenue Recognition Proceedings
The below Revenue Recognition proceedings and billing types are supported in the current release:
Cost/Working Hours Based (POC) – Fixed Price Billing
Invoice Based (POC) – Fixed Price Billing
Cost Based (T & E) – Time & Expense Billing
Time Based Revenue recognition – Periodic Billing
No Deferral – All Types of Billings
Completed Contract – All Types of Billings
Manual Revenue Recognition – All Types of Billings
Customizing steps for event based revenue recognition
In the S/4HANA 1610 system all the required customizing in Cost Object Controlling – Event Based Revenue Recognition must be done. I won’t bother you with the customizing steps in detail but it consists of the following:
Source Assignment and Posting Rule
Result Analysis Key
Document Type and Financial Statement Version
Sales Project with T&M billing and Cost Based POC
Let’s see how Event-Based Revenue Recognition works.
In this example I use a sales project with T&M billing and Cost Based POC. The time confirmations are posted as expense and realized revenues are posted based on DIP profile. Invoices are posted to P&L and reposted to deferred Revenue.
Sales price for man hours is € 100 and cost price is € 50. The process steps are as below.
The yellow outlined steps are the postings resulting from the event based revenue recognition. In addition the cost object to which the postings belong are indicated.
Sales Project with Periodic Service and Time Based Billing
Confirmations are posted as COS adjustments / WIP. Invoices are posted as realized revenues and reposted to deferred revenues. COGS are calculated and posted based on DIP profile and COGS will post accrued costs. The periodic run recognizes cost and revenues time based on the basis of the invoice schedule / billing plan.
New App: Event Based Revenue Recognition
The purpose of this new app is to monitor revenue recognition postings and perform manual adjustments.
The object list displays all billing elements that are relevant for the event-based revenue recognition with the value posted on the object in separate columns for actual, accrued/deferred and recognized values.
It is possible to select one object and drill-down to the details.
It is possible to enter temporary manual adjustments through the app. Entered manual adjustments will be cleared again with the next periodic revenue recognition run.
Next to manual adjustments it is also possible to enter reserves. Manual Reserves will not be cleared again with the next periodic revenue recognition run. The adjustments have to be cleared manually if needed.
Realignments finally available in Account Based CO-PA with S/4HANA 1610
Since the introduction of Simple Finance (now S/4HANA Finance) Account Based CO-PA is the preferred Profitability Analysis method. Costing Based Profitability Analysis is still available and both types can be used in parallel. However all new features will be introduced in Account Based Profitability Analysis and this is the only type which provides complete integration with the General Ledger.
So to make use of all the benefits of S/4HANA and the Universal Journal (ACDOCA), Account Based Profitability Analysis is the way to go. At least, if you don’t have reasons which are keeping you away from this type of Profitability Analysis. In my first Blog “Finance in S/4HANA 1610: The What, Why and How” I had already mentioned some gaps and limitations in Account Based Profitability Analysis. One of these limitations is finally solved in S/4HANA 1610, well at least partially solved because there are still some minor limitations.
One of the things I liked most of Costing Based Profitability Analysis was the possibility of cancelling and reposting CO-PA documents independent from the General Ledger posting. This is at the same time one of the downsides of this type of Profitability Analysis, since there is now alignment with Financial Accounting or the General Ledger. However it gives you a lot of flexibility to add or change characteristics, even to historical data.
Introduction of Realignments in Account Based CO-PA
Account Based Profitability Analysis in S/4HANA gives us the advantage of full integration with the General Ledger. However there was no possibility to change or add characteristics after a posting was completed. The Profitability Characteristics were tightly integrated in the General Ledger posting in the Universal Journal (ACDOCA).
As of S/4HANA 1610, the Realignment functionality comes to Account Based CO-PA. Some of you will already be familiar with Realignment in CO-PA (KEND), since this is an already existing functionality in SAP. I barely used it because I mostly preferred to cancel and repost the CO-PA document to reflect changes instead of Realigning. With Account Based CO-PA, Realignment is your only option to make changes to Characteristics.
Why is the availability of this functionality that important and what are the business requirements? The most important are the following:
Reflect organizational changes in your product, sales or customer structure in already posted documents.
Make corrections to inconsistencies or incorrectly assigned characteristics at the time of the original postings.
Enrich profitability data by information not yet available at the time of posting.
General Facts and limitations
Since there is no separation of Financial Accounting and Management Accounting data anymore in the Universal Journal there are some limitations in changing document.
Changes to journal entries have to always follow the guidelines of standard accounting principles
Realignment of Universal Journal can only be processed for non-GL relevant information
Changeable CO-PA Characteristics are pre-defined by SAP and selection cannot be changed by users
Available Characteristics for realignment
As mentioned, the list of Characteristics is pre-defined by SAP. Some characteristics can be changed only when they are initial at the time of realignment. The complete list of Characteristics is provided below.
By SAP defined and by customer activated CO-PA characteristics
Vol. Rebate Grp
Form of manufacturer
‘* other Customer defined characteristics’
Characteristics are always changeable without restrictions.
Fixed Characteristics that are not GL Relevant
Characteristics are only changeable if field is initial at time of realignment.
Fixed Characteristics that are not GL Relevant
Sales Order Item
Can only be changed if not true account assignment and initial
Characteristics that cannot be changed
The table below contains all Characteristics of the Operating Concern that cannot be changed:
Partner Profit Center
Executing the Realignment
As mentioned, the realignment functionality is not new, it was already available before. The transaction code is not changed and is still KEND. If Costing Based CO-PA is activated, Realignment is processed for both Profitability Analysis methods (Account and Costing Based). This is in order to keep the information in sync.
The realignment characteristics are updated in the Universal Journal (ACDOCA) and in case of Costing Based also in the Segment Tables (CE4xxxx). So there are no new line items generated through the realignment run.
The original information (as posted view) from the Universal Journal is stored in a dedicated table.
You can execute transaction KEND in SAP GUI or do it in Fiori:
The following selection does not make sense, since Realignment will be updated in both types of CO-PA:
I created the following Realignment run:
I would like to change the material group of a specific material. So in the Selection Condition of the run I have selected the material number:
The Material Group in one material in the selected billing document has changed. I just want to update the Material Group. So this is my selection in the Conversion Rules:
This indicator can be set if you want to re-derive Attributed Profitability Segments:
If you are new to Attributed Profitability Segments you can read my blog on this newly released functionality.
The old Material Group was 01 in the initial document. This can be checked in ACDOCA:
Material Group in material changed to 02:
Execute the Realignment run:
The Realignment run is finished successfully:
In ACDOCA you can see that the Material Group in the original Journal entry is changed:
Original “As Posted” values
As you have noticed, after Realignment the Characteristics in the original Journal posting are changed. However the initial Characteristics values are still available for the “as posted view’’ of the document. In case of Account Based CO-PA these values are stored in the dedicated table ACDOCA_KENC. For Costing Based CO-PA these values are stored in table CE4****_KENC.
The original “as posted” values are taken from ACDOCA_KENC:
When a Realignment Run is restored the values in ACDOCA_KENC for that Realignment run are deleted. So there are no additional line items created for the Restore of the Realignment.
Restoring the original values
Since the original values are kept in a dedicated table. It is always possible to restore the Realignment.
After executing the Restore you will see that the status of the Realignment run is changed:
The posting in the Universal Journal (ACDOCA) will be restored to the default Material Group 01:
Availability for S/4HANA Finance
The Realignment functionality for Account Based CO-PA is available in 1610. However you can also activate the functionality if you are on S/4HANA Finance 1605 (SAP_FIN 730). The functionality comes with support package 05 (SAP_FIN 730: SP 0005) or you can enable it by implementing a bunch of OSS notes. The main OSS notes are the following, and these will guide you to all the other relevant notes:
2350123 – S/4 HANA Finance: Realignment for account-based profitability data I
2344759 – S/4 HANA Finance: Realignment for account-based profitability data II
To conclude, I’m very pleased to see the availability of Realignment for Account Based CO-PA. This was one of the major gaps between Account and Costing Based CO-PA preventing customers to completely switch over to Account Based. In daily practice you can’t avoid organizational changes or the fact that attributes are wrongly assigned. Without completely cancelling and reposting Documents it was not possible to reflect these changes in Account Based CO-PA before. This was the major argument for customers to not work with Account Based CO-PA in S/4HANA.
With the release of Realignment for Account Based CO-PA I think we are a step closer to a complete integration of General Ledger and CO-PA. There is just one major gap left in Account Based CO-PA: The support of statistical SD condition not posting to GL.
Together with S/4HANA 1610, SAP Fiori 2.0 has been launched. Fiori 2.0 is SAP’s latest iterations of the SAP Fiori design language. Next to the fact that it looks better and there are much more apps available compared to Fiori 1.0, the most important revolution in my opinion is that we now have a harmonized user experience across all application components.
In this blog I will share my experience and challenges with Fiori 1.0 and the huge benefits and breakthrough in Fiori 2.0.
After the first serious release of Fiori back in 2014 we had mostly Simple Finance specific apps. With the release of S/4HANA 1511 the amount of apps significantly increased. Together with the increasing amount of apps I had, as a consultant and trusted advisor, a really hard time explaining customers how to position all the different user interfaces SAP has provided.
We still have SAP GUI, NetWeaver Business Client (now Business Client) and SAP Fiori. We had to avoid the situation were users need to login multiple times in multiple screens. My strategy was to use the Business Client as single point of entry for all users and cherry pick some relevant Fiori apps (mostly Analytical) for Management and C-level executives which they access directly via the Launchpad URL or via a shortcut in Business Client. It was not ideal and we were unable to provide users with a heterogynous and harmonized user experience. Not even mentioning the additional work in setting up authorizations for apps and Tile Catalogs/Groups.
It was not possible to position Fiori as a full blown user interface for all users simply because not all business processes and transaction were provided. Therefore Business Client was the user interface for daily operations and some users had access to Fiori for (mostly) Analytical Apps and reports.
SAP Fiori 2.0 Launchpad as single entry point for all applications and users
What has been changed in Fiori 2.0? The first thing you probably notice when you enter a Fiori 2.0 Launchpad the so called ‘Viewport Concept’. The desktop has been expanded to the left and right sides.
On the right side we have the ‘Notification Area’ for the complete list of notifications, workflows etc.. On the left we have the ‘Me Area’ to access recently used Apps and some menu areas for personalization and configuration. In the ‘Me Area’ the App Finder is new as well. This replaces the App Catalog from Fiori 1.0.
The ‘App Finder’ is exactly the specific improvement and breakthrough which I will explain further in this blog. More general information and details about Fiori 2.0 can be found in the SAP document via below URL.
One of the most important improvements in Fiori 2.0 is the harmonious user experience. There is no native Fiori App yet for all SAP transactions. But all “Classic” applications, such as Web Dynpro and SAP GUI for HTML are facelifted and received the new SAP Fiori visual theme Belize. This makes it possible to use the Launchpad as a single entry point for all users. It’s not only the theme change in the “classis” transaction. The facelift consist of more functional changes like Merged headers and other Fiori like control elements. You will directly notice that it is not a native Fiori app since it will open in a new window or tab. I will show some examples further on.
Adding SAP GUI and Web Dynpro transactions to you Launchpad
In the App Finder, which is available in the Me Area you can search for Fiori Apps in the available Catalogs, but you can also search for “Classis” transaction from the SAP GUI menu or User Menu.
This finally makes it possible to deploy Fiori in full for all users across the entire organization.
Let’s see how it works:
From the SAP Menu I navigate to Financial Accounting submenus. As you can see all transactions are displayed as Tiles. For the people among us with nostalgia for the GUI menu, this feature is enlightening. You can still browse through the GUI menu.
From here I can add a transaction to a group, in this case My Home:
Even if there is a native Fiori App for a specific use, like the ‘Post General Journal Entry’ App. You can still decide to choose for the “classic” FB50 transaction if you think this is more productive for the user. They can coexist side by side and the transaction code is mentioned in the tile.
Another good example is the Create Sales Order (VA01) transaction. As you can see, merged headers and the control buttons at the bottom like in native Fiori apps are the first things you notice next to the color theme.
I’m happy to see that with Fiori 2.0 SAP managed to create a uniform and harmonized user interface. The Launchpad can work as a single point of entry and the look and feel of transactions are more or less the same.
Experienced users will probably recognize the facelifted SAP GUI apps, but with the Belize theme, coherent menu and control functions everything seems to be in harmony.
I received a lot of question related to the availability of Fiori 2.0 for older releases. The answer is yes, it is available for older releases. You just need to upgrade your front end server to 3.0. This applies for both Business Suite on HANA and S/4HANA Finance (1503/1605) systems. You can find more detailed info on SAP Help and the related OSS notes.
In S/4HANA 1610 a new functionality called ‘Attributed Profitability Segments’ is introduced. It is now possible to derive a (statistical) profitability segment when there is another real CO object with a settlement rule to COPA.
I was hoping that this would fix some occurring issues with Account Based COPA in S/4HANA. Below, I will explain the scenario I have been dealing with in my example with a revenue bearing time & material service order which is billed with a debit memo. The debit memo request has an account assignment to the service order. The service order has an settlement rule to COPA. In this example I use an S/4HANA Finance 1503 environment.
In my second example I will show you how the Attributed Profitability Segment in S/4HANA 1610 works. See the difference yourself and decide if you can benefit from this new enhancement.
Current issues in Account Based Profitability Analysis
Here I will show you a time & material service order scenario and the reporting issues in Account Based COPA without having attributed profitability segments.
As you can see in the settlement rule, the order will be settled to COPA:
The Debit Memo request is created with DP90:
In the account assignment in the sales order line items you can see the assignment to the service order and no assignment to a Profitability Segment.
This means that you cannot report on the Revenu in Profitablity Analsyis untill the Service Order is settled. Even then, you will see the revenue on the settlement cost elements, not on the original revenue cost element.
Let’s have a look on the data of this Invoice and service order in the ACDOCA table.
The top rows in the blue rectangular are the actual postings on the service order (e.g. Revenue Accounts). The others are postings resulting from the settlement of service order (settlement cost elements). In this example I have my COPA characteristic Ship to Party and Ship to Country. As you can see these fields are not derived during the daily postings. They are only derived when the service order is settled to COPA.
The result is that I don’t have my COPA characteristics on my revenue GL accounts. Reporting in COPA with the use of standard ACDOCA reports and KPI Fiori tiles will result in incomplete figures in these cases.
Have a look at the Actual Revenue KPI tiles in Fiori which come with SAP Smart Business as part of Embedded Analytics. The Revenue KPI app is based on Account Based COPA, thus Cost Elements and corresponding profitability characteristics. In this current scenario the profitability characteristics are not assigned to the revenue accounts. What you will see is this:
The same issues applies on the new ACDOCA report ‘Market Segment Actuals’:
The only way to overcome this is building your own reports in HANA Live and making reports in one of the SAP Business Object tools available (Lumira, Webi or Analysis for Office). Similar to what I have done for my T&M service order profitability in Analysis for Office:
Using the attributed Profitability Segments in S/4HANA 1610
As mentioned at the beginning of this post, the new functionality called ‘Attributed Profitability Segments’ has been introduced. If there is a real account assignment to one of the objects below, the system can derive “statistical” (or attributed) COPA segments for reporting purpose:
Unfortunately the service order is not included in this list as object. Thus a direct solution for my scenario explained above has not been provided yet by SAP. I hope the service order will be supported soon as receiving CO object.
However let’s see how this new functionality works with a supported object, the internal order. Technically it’s the same issue we are solving, but instead of the service order we use an internal order as account assignment. In the configuration I have activated the Attributed Profitability Segment for internal Orders only for postings on P&L accounts. As mentioned at the beginning of my post, I will use a S/4HANA 1610 environment in this example.
The below internal order has an settlement rule to COPA.
I create a sales order with assignment to the above internal order in the line item. As you can see there is no assignment to COPA.
Final posting of the invoice:
After posting the invoice you will see the attributed segment in the revenue line item in the ACDOCA table.
The real CO account assignment can be found in field Object Type (ACCTASY) which is the Internal Order in this case. As you can see the COPA characteristics like the Material, Customer, Material Group, Customer Group and Ship to Party are derived as well!
I see huge benefits in this new functionality for reporting purposes since profitability characteristics are derived directly at the moment of posting even if there is another CO assignment. For me it was a long awaited functionality, however I’m very disappointed that it isn’t working yet in scenarios were the service orders is the receiving cost object. I have addressed this to SAP and waiting for a reply.
I hope you have enjoyed reading this and I wonder if you have experienced similar issues with CO objects as well? If you have other thoughts or questions related to this subject, please don’t hesitate to leave a comment. If there are any other S/4HANA related cases you would like to see, just let me know and perhaps I can write a future post on the topic.
Finance in S/4HANA 1610 the what, why and how: Part 2
Last week I shared the What and How on Finance in S/4HANA. In part 1, we have learned the product and understand the key benefits of Finance in S/4HANA. Now I will continue with possible migration scenarios.
The How… different scenarios and migration paths
One of the 5 pillars of S/4HANA is the choice of deployment. Both On-Premise as well as Cloud deployments are supported. In this blog you will gain an inside in the On-Premise deployment and migration scenarios.
When you go for the On-Premise deployment option there are 3 options; a completely new installation, a system conversion or a landscape transformation.
A new installation is quite straight forward since no migration activities are necessary except from bringing in your balances, stocks, open items and other standard cut-over activities. In a system conversion scenario however, there are additional steps to perform which will be explained further on.
The best strategy for your company, either new install, conversion, cloud or On-Premise depends on the requirements and complexity of the current IT environment / SAP systems. After reading this blog you will get more insights in de system conversion options and activities involved. A specific assessment and analysis should be performed on your individual situation to define the best path.
Currently there are 3 major migration scenarios for customers running SAP ERP 6.0 on any database. Starting from the bottom these are the following:
Migrate to Suite on HANA:
This scenario is purely a technical database migration. This can be an intermediate step if your company has to renew its hardware but there is no time and/or budget for an additional migration project to S/4HANA. Of course there can be more valid reasons. Maybe the company needs to upscale or renew hardware because of performance issues or expansion. In these situations going for an in memory HANA appliance is a no-brainer.
Since this is only a technical migration, no application migration is involved. However you still get the performance improvements and the data compression provided by the HANA technology.
The biggest advantage is that HANA Live will be available so you can make use of real-time in memory reporting.
Migrating to S/4HANA Finance:
Migration to S/4HANA Finance can be chosen for different reasons. Your company can move to S/4HANA Finance when only the innovations in Finance are relevant, you would like to enable specific functionality like Central Finance or you use this path to mitigate risk and shorten the lead time of the project. There can be many other reasons like these. If the last applies keep in mind that you still need to go for a migration to reach the final destination.
In this blog I will go further with the details of the S/4HANA Finance migration. These steps are also valid for a migration to S/4HANA 1610.
In S/4HANA Finance, I have already explained all the innovations in Part 1 of my blog. As mentioned in the previous blog, S/4HANA Finance 1605 and S/4HANA 1610 are now equal in terms of functionality in Finance. In terms of migration there are however still some deltas such as the business partner and the 40-digit material number.
Migrate to S/4HANA
If you want to enable all S/4 innovations including the ones in Supply Chain, Sales and Procurement a direct migration to S/4HANA 1610 is the preferred path. During this path, the Finance migration, which is also required for an S/4HANA Finance migration, is part of the game as well. And I can say that the finance migration part is the most difficult one (see below).
There are also additional migration activities like the migration of the customer/vendors to business partners. Along these, there are also transactions or even functionality which is replaced or removed to another module.
To capture this information and to be able to perform a fit-gap SAP provides a so called simplification list for each release where you can find all deltas compared to previous releases. I have more to say about the simplification list further in the blog.
The migration and system conversion process
SAP provides are clear process for the conversion to S/4HANA. In the below figure you can see the required steps and sequences. Along the technical migration steps, there are application specific preparation steps (from t2 to t4). For a successful migration it is important that functional expertise of all the relevant domains are involved in this phase of the project.
T1: you need to be aware of system requirements, start releases and data volume. All information is provided in the Conversion Guide.
T2: the maintenance planner checks your components, add-ons and business functions to ensure compatibility with S/4HANA.
T3: The Pre-check tools provide a detailed report about the technical readiness of your system to S/4HANA. There is separate pre-check available for the migration of financial data.
T4: the migration tool checks the code of your SAP Business Suite system where it does not comply with the scope and data structures of SAP S/4HANA.
T5: this is the technical step where the database migration (if needed) and the software update is performed.
T6: in the final part we perform the adoption of the innovations. E.g. adopting the new UI (Fiori 2.0), configuring and modeling the Fiori apps and enabling and modeling KPI dashboards based on CDS views.
More about the simplification list
The Simplification List provides the key information by application or functional area about the simplifications in SAP S/4HANA. Each simplification item details the steps that need to be taken for the conversion from a business and a technical point of view. Actually it is a collection of all business impact SAP notes. All items in the simplification list refer to a business impact note.
This is your entry document to an application conversion from the business suite to S/4HANA.
An example of an item in the simplification list is about master data and specifically the business partner. All related information is provided in detail. The purpose, the business process related information and obsolete transaction codes. But also the required actions. This document in combination with the relevant SAP notes really gives all the information for a smooth conversion.
The most tricky part: Migration of Finance
Now let us discuss the migration of finance. Whether you go for a full S/4HANA migration or only for an S/4HANA Finance migration, in both cases you always need to migrate your financials. The migration tasks consist of the following steps:
Preparation and migration of Customizing (GL, CO, AA, ML, Banks)
Data Migration (migrate transactional data into the new data structures and generating Compatibility Views of obsolete tables)
Activities after migration (some last steps, enriching transactional data and releasing the system).
To give you an idea of some of the migrations in customizing you can think of defining document types for posting in Controlling, migration to New Asset Accounting or migrating your House Banks to the new structure. Check the previous blog to see the differences with Finance in R/3, it will clarify some of the necessary migrations steps.
For the preparation and migration for Finance a very clear path is provided in the IMG for the above mentioned steps. There is some guidance, however the steps in the IMG are not always in the correct sequence! Functional expertise is very essential.
Finally to control all migration activities a migration monitor is now provided in S/4HANA 1610. In the monitor you can keep track of all activities and the status of the individual steps.
As you can see a migration to S/4HANA should be taken as a project in which the involvement of both technical (ABAP and Basis) and functional application consultants is required. Especially for the Financial migration the expertise and experience of a SAP FiCo consultant is a must. In the last part (t6) experience and knowledge of Fiori UX and Embedded Analytics options is very welcome as well. These things will make the difference compared to your old R/3 system.
As mentioned before, a migration to S/4HANA is non-disruptive and backwards compatible. Compatibility views (CDS views) are generated for all obsolete tables meaning that old programs will continue to work. Even your custom programs, except when you have INSERT/WRITE statements to one of the obsolete tables. These should be redirected to the new data structure. All these necessary steps are captured in the migration path and tools are provided by SAP to make your system ready for S/4HANA.
I hope you have enjoyed part 2 of this blog and gained some insights in typical S/4HANA migration options and activities.
Stay tuned for more S/4HANA news and demo videos on specific topics.
Nowadays there is a tremendous interest in S/4HANA, especially from current SAP customers. It’s about what, why and how to go to S/4HANA. This motivated me to start writing a series of blogs on the subject matter.
In this part 1 of the blog I will explain the what and the why of S/4HANA. In part 2 the How will be explained further.
Let’s start from the beginning by knowing the product. The What. In the title of this post I say ‘Finance in S/4HANA’ and not ‘S/4HANA Finance’. That has a reason which you will find out below. This post expects some entry level knowledge about S/4 HANA and the HANA technology in general. I will dive into the different S/4 HANA product versions and the Finance specific topics.
The What… Let’s know the product
In 2014 SAP introduced the simple innovations starting in the area of Finance. The new product was initially named ‘Simple Finance’ and at that time there were already rumors about ‘Simple Logistics’. The Simple naming convention lasted until the release of Simple Finance 2.0. In 2015 SAP announced that the name Simple Finance will be changed to S/4 HANA Finance. By doing this, SAP introduced heterogeneous naming across different product lines. Simultaneously it created a lot of confusion with all the different release numbers.
Let me try to help you understand the differences. As you can see in the figure below, S/4 HANA Finance is a different product that S/4HANA (Enterprise Management).
S/4HANA Finance includes only the finance innovations (replacement of classis FiCo) on to the already existing system. So everything in logistics will remain as it is. You can imagine that the migration effort to this product is lower than directly going to S/4 HANA. More about this in the ‘How’ topic.
In S/4HANA 1610, SAP has included all the available functionality of the latest release of S/4HANA Finance 1605. This means that in terms of Finance S/4HANA 1610 and S/4HANA Finance 1605 are in sync.
Except for some minor differences which are listed below. This make things a bit easier to understand later on :).
The Why… Key differences and innovations in the area of Finance in S/4HANA 1610
Now we have to understand the product. Let’s look at the benefits of S/4HANA for our organization. In this topic I will hit the key differences compared to classic FiCo in R3.
To make the list comprehensive I will also mention some features which were already included in Simple Finance 1.0 back in 2014.
One Single Source of truth and all accounts become GL accounts
All actual line items will be stored in the new table ACDOCA. The will be no redundant, aggregate or total tables anymore. All dimensions of GL, CO, COPA, AA and ML will be in ACDOCA.
In the ACDOCA whe have multidemsional GL, parallel ledgers, parallel currencies, 999,999 line items and custom defined fields. The chalenges of gathering combined content of several tables to represents the truth and reconcile the different level of detail stored in the different components/tables of SAP (e.g. CO= much detail, Fi= less detail) is now somehting of the past.
The reason of the merge of secondary and primary cost elements is the fact that all actual line items will now be stored in one single table. The ACDOCA. This also applies on purely (internal) CO postings. You should not include these secondary accounts in your P&L.
Parallel currencies and parallel valuation
In S/4HANA 1610 we can now have up to 10 parallel currencies per ledger. Real-time conversion for all currency types is possible, Zero balance per document is guaranteed for each currency and CO-area currency is now calculated for all accounts (also non cost element).
Parallel valuation functionality is significantly enhanced in S/4HANA 1610. SAP now provides two options to store multiple valuations:
Parallel valuation updated in parallel single-valuation ledger
Separate ledger for each valuation
Transparent separation of posting and reporting based on different regulations
Parallel valuation updated in multi-valuation ledger
Separate amount columns in the same ledger
Reduce memory footprint
Reduce effort and time for closing
See an example of the 2 methods below.
Profitability Analysis in S/4HANA 1610
With S/4HANA SAP focuses on the enhancement and integration of Account based COPA. This is the preferred type of Profitability Analysis. Costing Based profitability analysis is still available and can be used in parallel, but there will be no integration with the Universal Journal (ACDOCA table).
Below you will find the list of enhancements on Account Based profitability analysis. Critical gaps of the past are closed.
Split of Cost of Goods Sold on multiple accounts based on cost component split. This is done during posting of the Goods issue.
Split of production variances on multiple accounts. This is done at order settlement.
3 new quantity fields provided in the line items and a BAdI for conversion of the logistical quantities to common quantities in Finance.
Real-Time derivation of market segment information from cost postings (Cost Center, order etc.)
Summary of the enhancement:
Unfortunately there are still some limitations which are on the future roadmap. Current limitations of Account Based profitability analysis:
Sales conditions which are not posting to GL (statistical) are not supported
Realignment of characteristics which are changed after posting are partially supported. Not for all characteristics!
Creation of sales order generates expected revenue, COGS etc. in profitability analysis is not supported.
Attributed Profitability Segments
In my opinion, this is one of the greatest enhancements in Profitability Analysis. I was always thinking why this was not possible in SAP and now it is here! With a couple of additional configuration steps the ‘Attributed PA segment’ can be activated.
Another good example is when you have a debit memo request in a Time & Material Service order which has a settlement rule for settlement to COPA. The debit memo request will have an account assignment to the service order and no profitability segment. That means that you do not have the profitability segment information until the service order is settled to COPA. With this new functionality you can have the real account assignment to the service order and an attributed assignment to a profitability segment. Great stuff!
Event based revenue recognition
The revenue recognition process is now fully integrated with the Universal Journal. There is no separate storage for Revenue Recognition data anymore.
Cost and revenues are recognized as they occur. The entry of the source document will generate two postings. An entry for the initial costs and revenue and an entry for the revenue recognition posting.
There is even a new app ‘Event based revenue recognition’ for monitoring of revenue recognition postings and manual adjustments.
Bank Account Management (lite)
In the ‘old’ setup there were house banks and bank accounts in SAP. In S/4HANA basic functions of the Bank Account Management functionality of Cash Management is brought in to the core. This is called Bank Account Management Lite.
The main new features and differences compared to the old house bank and bank account setup are the following:
Group-wised account management
Opening and Closing with approval process
Easily maintain bank accounts
To highlight the latest point. Bank accounts are now part of master data and can be maintained by users through a dedicated Web Dynpro or Fiori application. The house banks itself are still created in customizing. Transaction Fi12 is obsolete and the new transaction Fi12_hbank is introduced for this purpose.
So the process of creating the house bank and the house bank account are separated and executed in two different places.
New Asset Accounting
Migrating to New Asset Accounting is a pre-requisite for migration to S/4HANA (Finance). The reason and motivation behind New Asset Accounting is:
No data redundancy
Reconciliation between GL and AA ensured
Transparent assignment of depreciation area to accounting principle
Simplified chart of depreciation: only 1 CoD per valuation
No delta depreciation areas
Asset balance in real-time (APC posting run not needed)
Plan values in real-time
Usage of the New Depreciation Calculation Engine is mandatory and the tables ANEA, ANEP, ANEK, ANLC, and ANLP are not updated anymore in New Asset Accounting.
An example of the new posting logic during integrated asset acquisition with two ledger with two different accounting principles:
As you can see a new ‘technical clearing account’ is used to post accounting principle specific documents. The balance of the technical clearing account is zero.
Embedded Analytics and Reporting
SAP blends transactions and analytics in one system allowing operational reporting on live transactional data.
I can talk hours about reporting in S/4HANA. With the new data structure (e.g. ACDOCA), all the pre-delivered Virtual Data Models (VDM’s), the performance of HANA and the modern and state of the art reporting tools/interfaces, there are so many new possibilities.
The concept of embedded analytics in S/4HANA is to provide pre-defined models across the entire suite in which the business logic is embedded. So the provided data models are delivering contextual information rather than raw data.
In a nutshell I can say that the following reporting tools are mostly used at my customers where I did S/4HANA implementations:
Analysis for Office
Each tool has its own purpose of course. I can say that with out of the box analytical Fiori apps and the KPI Modeler in SAP Smart Business together with the Analytical Path Framework already provides a lot of content and satisfies a lot of customers.
Some examples of Smart Business cockpit and the Analytical Path Framework apps.
Next to these type of apps, SAP provided multi-dimensional reporting apps. For example the Market Segment Actuals app in which I can report on my P&L with in addition my Profitability Analysis characteristics.
For more flexibility the products from the BO suite (additional license) Analysis for Office and Lumira can be used. This is worth another separate blog.
After reading this blog I hope you have gained a good understanding of the S/4 product and the key differences and innovations in the area of Finance. Part 2 will explain the How. With the different migration scenarios and deployment possibilities.
Stay tuned! Soon I will also start sharing demo videos on specific topics on an S/4HANA 1610 system.