(updated as of SAP S/4HANA release 1909)
As a controlling consultant I was very excited about the evolution of SAP ERP CENTRAL COMPONENT (ECC) to SAP S/4HANA.
Since the first release I was asking myself:
The main aim of this blog post is therefore to reply to these questions trying to talk about SAP S/4HANA new concepts and to describe how these concepts have been evolved and are evolving.
With the advent of SAP S/4HANA many things are changed in controlling; I have prepared a list based on SAP S/4HANA 1909, (of course since the product is continuously evolving this list is not exhaustive).
This is a list of topics that I will cover in the first part of this post:
UNIVERSAL JOURNAL
The universal journal is nowadays well known but to be honest when I saw the first description of the concept I was wondering what was the benefit for the final user.
I was able to understand and recognize the technical benefits contained in the Universal journal Concept like:
but I was struggling on how to transform it in a tangible business advantage for the Controller.
At that time, having the possibility to see new SAP FIORI APPS on Universal Journal the it was clear to me that the FIORI would have been a perfect match. And as a matter of fact fact I could verify some FIORI Apps able to offer Controlling Reports like never in the past. For example the Market Segment FIORI app.
Please see also the FIORI topic in second part of this blog (when it will be ready).
Regarding Controlling part, one of the consequences of the Universal Journal is that total tables are not in place anymore and if you remember ECC most of the Controlling Reporting was based on totals tables. So how these reports are now working in SAP S/4HANA? There is a non disruptive compatibility view mechanism that ensure that the reports are redirected and continue to work. So as mentioned By OSS 2270404:
“The former tables COEP, COSP, and COSS are replaced by views of the same name, so-called compatibility views, that aggregate the data in the universal journal on the fly in accordance with the old table structures”
Old reports continue to work based on the universal journal tables, CO Fiori Apps are based on the universal journal as well, that means that as matter of fact your reporting source is now the Universal journal. But which part of the Universal Journal? This is really the question that a Controller should ask himself (and I will try to reply further in this blog post).
There is one example I like to show to my customers about elimination of tables and unification of subledgers. Everybody knows that Payable, Receivable, Assets, Controlling and material ledger are now in the same universal journal table (the ACDOCA table). That also means that the granularity of Finance postings has augmented; if you for example think about an asset purchasing you will have a row for each asset you are buying (and not simply by a G/L Account representing the asset itself). But the concept of Universal Journal is much more than a technical concept: having a single place where to find every information regarding for example the purchasing to pay process is extremely useful.
An example, a customer raises a purchase requisition and a purchase order to a project, materials are to be considered in this case as Capex Cost. The goods receipt Is therefore directed to a Wbs element, then the Wbs element is settled to an Asset Under Construction (End of the period) and then to a Final Asset (End of the internal Construction). After a while an Invoice is raised and then the payment is posted.
In ECC you had to probably create a custom report to keep together the information from purchase requisition to payment among different tables. With the Universal journal you can find every record in one single table. (Anyway, if you want to keep the documents related one to another you should go analyze the problem a little bit deeper, maybe the new document flow FIORI app may help you a bit on that).
So with the progression of SAP S/4HANA I found my way to the real business value for Controllers.
REALTIME INTEGRATION
The Finance realtime integration, and before of it the Controlling Reconciliation Ledger were concepts used in ECC to keep aligned FI with CO.
For example one cross Cost Center CO posting belonging to different Profit Centers or Business areas or Company codes could create a misalignment between FI and CO. In ECC if you had an FI posting of 100 Euro on Cost center A (Profit Center A) and then a CO internal allocation from Cost Center A to Cost Center B (Profit Center B) as a matter of fact you would have Controlling reporting (cost center and Profit Center) not aligned with Finance Reporting.
Finance Reporting: Cost Center A (Profit Center A) 100 Euro
Controlling reporting: Cost Center A (Profit Center A) 0 Euro Cost Center B (Profit Center B) 100 Euro
If you had the requirement to have Finance and Controlling reporting reconciled (for example because your profit center represents your business segment and it should be always aligned in FI and CO) you could use the mentioned concept to realign FI with CO.
In other words, after the CO Allocation you could have an (only) FI posting like:
If the allocation was done on secondary cost elements you had the possibility to “represent” the Secondary Cost element with a specific G/L account in order to allow the posting in FI (by definition the FI posting could not be done on secondary cost elements).
In SAP S/4HANA, with the concept of universal journal, secondary cost elements are G/L accounts and every CO posting is represented in universal journal, therefore you do not need Reconciliation ledger or Realtime integration concept anymore.
Please note I am not talking about cross company clearing accounts, this has remained in SAP S/4HANA customizing as well.
COST ELEMENTS
The fact that cost element are now G/L accounts is also a known concept since a while. The fact of having the Universal journal suggested to have one single concept. That means that even if you are creating an internal positing in CO (e.g. CO internal allocation between two cost centers) you will obtain an FI document for it with an FI header (BKPF, not BSEG).
If you are concerned to have a challenge on separating the secondary cost element on your B/S or P/L structure you may want to know that there are ways to separate them from the primary cost elements.
The OSS 2841880 may help, it talks about Financial Statement Versions G/L Account Hierarchies Semantic Tags.
The definition of GL Account Hierarchies and Financial Statement Version helps in this way. You can assign primary and secondary cost element General Ledger Accounts to different Hierarchies to keep them separated for reporting and statutory purposes.
Sematic Tags helps on the creation on KPIs.
Anyway the total impact of secondary element is by definition zero (because you use them only to move costs from one cost object to another one) so you should not worry about them in total but only among Controlling objects.
If you put together the Universal journal concept (already explained) with the SAP trend to suggest the customers to use Margin Analysis based on the old Account Based CO-PA (that uses G/L Accounts instead of Costing based Value Fields) you may find the “marriage” of Cost elements and G/L Accounts as a simple natural consequence.
CO INTERNAL POSTINGS WRITING IN UNIVERSAL JOURNAL
With Universal Journal concept CO Postings are written in the Universal Journal table (ACDOCA).
To write on this table you need some basic concepts:
Basically you have the option of recording some of your postings in specific ledger group and to dedicate even CO postings to obtain an alternative Profit and Loss. Even with the new Universal Allocation you can run Allocation cycles by ledger. Moreover you have the possibility of executing CO specific postings (for example manual re-posting of cost) per ledger group. So manual or automatic allocation of costs may be a good way to start doing posting per ledger (accounting principle).
EVOLUTION OF SAP ECC PROFITABILITY ANALYSIS TO SAP S/4HANA MARGIN ANALYSIS
With the advent of Universal journal SAP suggests to use the Margin Analysis evolution of Controlling Profitability Analysis.
In ECC there were 2 types of CO-PA
(Actually for specific customers, there was also a third type of Profitability Analysis called “Combined” but this is now of not allowed anymore in SAP S/4HANA )
Most of customers who used Profitability Analysis opted for Costing Based cause it was much powerful and very integrated with Product Costing. For example it allowed the use of Valuations to import in CO-PA Sales Order Statistical Conditions, moreover it had functionalities to import COGS split into CO-PA Value Fields.
Being based on Value Fields (and not on G/L Accounts), writing on different tables, and sometimes not completely aligned with the General Ledger Document postings (for example Goods issue) Costing Based CO-PA was therefore not easily reconciled with General Ledger.
Following the integrated approach of the Universal Journal, SAP decided to use the integrated ECC Account Based CO-PA as a base to build the new SAP S/4HANA Margin Analysis. Margin Analysis concept became a new Version of Account Based CO-PA improved in the Universal Journal. Costing Based CO-PA can still be used in SAP S/4HANA but Margin Analysis will be the only solution improved by SAP
The fact that you now have characteristics in Universal Journal actually means that whatever characteristic you may want to create in your detailed P/L (for example Customer, Market Segment, Product Group and so on) you will be able to see this characteristic in your universal journal table ACDOCA as a column.
At the beginning this option to go for Margin Analysis was not easy to adopt for CO-PA Costing based customers cause, as previously mentioned, Costing Based CO-PA offered more functionalities; but then, release by release, SAP improved the Margin Analysis in the Universal Journal with new functionalities. Nowadays these improvements and new developments have transformed Margin Analysis in a very better solution.
Let’s see a comparison table:
As you can see most of the gaps between Costing Based CO-PA and Margin Analysis have been closed and most important, reconciliation with Finance is integrated in Margin Analysis but not in Costing Based CO-PA. You may object that even in the ECC the Account Based CO-PA was integrated with G/L Accounting but despite that, many customers chose Costing Based CO-PA. On the other hand you must admit that these customers did not have universal Journal in ECC and most important, that in terms of functionalities Account Based CO-PA is less powerful than Margin Analysis.
Having a look to the comparison you may see that some of the features (e.g. Statistical Sales Conditions or Incoming sales order) are realized thanks to the possibility of writing new rows in the Universal Journal on Extension Ledgers. If you stop to think for a minute about the concept of posting on a parallel ledger in ECC you may think of something belonging to Financial on a specific Financial table (BSEG or FAGLFLEXA). Now it is instead an Universal Journal posting and depending on which fields are filled you may want to consider them for Controlling as well, so they are to be considered as controlling postings.
An implication of that is that you will not find them on the classic SAPGUI reporting but only in FIORI.
PREDICTIVE ACCOUNTING
Let’s take in consideration the Predictive Accounting concept.
The Idea to have in a dedicated part of P/L Sales and Purchasing Orders in real time, before they become an actual posting may help customers to anticipate their month end closing and reporting.
You have the possibility to bring in SAP S/4HANA Sales and Purchase orders in a specific ledger and to obtain automatic reversals of these postings once the related Financial documents are posted.
This is what SAP calls “Bottom Up Predictive Accounting” and it is clearly explained at this link
The good thing about predictive accounting is that the “predicted postings” are automatically synchronized with the actual postings.
How many customers were in the past “simulating not posted goods receipts or goods issues (or even not posted invoices) as a part of the month end closing procedures to reverse them at the beginning of the following month? (I know some ECC customers doing that even in FI-SL Special Ledger).
Thanks to Predictive Accounting this in now over. Someone may object that having predictive postings is not the same to have financial postings and that financial posting may be different from what they were supposed to be in the Orders; well this may be true, but it is also true that we are talking about prediction, so in my opinion it is much better to insert a prediction in a P/L than to have nothing.
Please be aware that as of SAP S/4HANA release 1909 Predictive accounting related to Sales orders has limitations:
Again, would you as a controller consider these postings as a value added? I would.
Were these postings considered as standard in ECC? Maybe yes but in a specific separated not finance integrated reporting (in Costing based CO-PA).
Is it useful to have them in the Universal Journal with other actual postings even on a separate section of it on Extended Ledger? I would say yes.
COST COMPONENT SPLIT/COGS SPLIT AND PRODUCT COST VARIANCES
If you think at the differences between Account Based and Costing based CO-PA in ECC with regards to COGS split it was mainly a question of:
Costing Based CO-PA
Accounting Based CO-PA
The Costing Based CO-PA advantage was to have Material and Productive Cost split by Cost Components related to CO-PA Value Fields.
In Margin Analysis as per OSS note 2349278 “Cost of goods sold (COGS) postings are assigned to an account/cost element at the time of the goods issue from the warehouse”. New functions are available to split the COGS posting to multiple accounts in accordance with the relative weight of the assigned cost components. This split can be updated with the results of actual costing from SAP S/4HANA 1809”.
You can use a new customizing to put in relations Cost Components to G/L Accounts, in this way you can obtain the split when you post a goods issue in Margin Analysis. Cost components can be valuated at standard and since 1809 at Actual Price too.
The same it is relevant for Product Cost Variances (product variance split)
So the ECC gap of having Costs in CO-PA reconciled with Accounting at the time of Goods issue is now covered by Margin Analysis.
STATISTICAL SALES CONDITIONS
Another Costing Based CO-PA functionality is the possibility to calculate statistical sales conditions (e.g related to warranties or freight cost) that are in SD Order but are not part of the Sales Invoice. Those costs are calculated internally and brought to CO-PA Characteristic even if not calculated in Finance and debited to the customer (at least not directly). From SAP S/4HANA release 1809 it is possible to transfer these statistical sales conditions in an extension ledger and to have them in Universal journal.
ATTRIBUTED MARGIN ANALYSIS
Attributed Margin Analysis is a new way to derive Profitability Segment Characteristic in Universal journal even without executing manual activities. One possible example is to obtain the characteristic filled for a posting on a Wbs element that has settlement rule to CO-PA characteristic. If the settlement rules are properly compiled, a simple posting on the Wbs element will feed the Margin Analysis Characteristic as well without the need of executing the settlement itself. The Posting Controlling Object will still be the Wbs element but the characteristic fields will be filled in parallel. This process is of course not just limited to the example I have made and I think it is a very clear example of new functionalities we may find in SAP S/4HANA.
To have a more detailed description of what is included in Attributed Realtime Margin Analysis you can have a look to this blog as well brought to you by the RIG.
So to say some conclusive words on Margin Analysis, nowadays I think that apart from very specific functionality the Margin Analysis is now a suitable solution for customers. Main reasons are:
PRELIMINARY CONCLUSIONS.
When you think about Controlling in SAP S/4HANA you really need to mention other parts beside what I have already talked about, topics like Universal Allocation, Material Ledger, Reporting (FIORI), Planning Processes are fundamental.
I will try to use the second part of this blog to give a complete reply on the initial questions I raised at the beginning. To give anyway some preliminary conclusion, I think that the Controlling Consultant role will continue to be necessary, but consultants need to expand their knowledge to new arguments (and I think I have already mentioned some in this first post).
Moreover, the universal journal table (ACDOCA) is central and it should be learned by the controlling consultant.
In the next blog post I will also describe how the controlling Reporting has evolved to FIORI.
What do you think?
Brought to you by S/4 HANA RIG
Okumaya devam et...
As a controlling consultant I was very excited about the evolution of SAP ERP CENTRAL COMPONENT (ECC) to SAP S/4HANA.
Since the first release I was asking myself:
- Do we still have a “Controlling” concept in SAP S/4HANA or the Controlling part is evolving to a unique Finance concept?
- In the Universal Journal times in which direction the Controller knowledge should grow?
- Now that Universal Journal is the main source how should Controlling Reporting Transform?
The main aim of this blog post is therefore to reply to these questions trying to talk about SAP S/4HANA new concepts and to describe how these concepts have been evolved and are evolving.
With the advent of SAP S/4HANA many things are changed in controlling; I have prepared a list based on SAP S/4HANA 1909, (of course since the product is continuously evolving this list is not exhaustive).
This is a list of topics that I will cover in the first part of this post:
- Universal journal
- Realtime Integration
- Cost Elements
- CO Internal Postings writing in Universal Journal
- Evolution of SAP ECC Profitability Analysis to SAP S/4HANA Margin Analysis
- Predictive Accounting
- Cost Component Split/COGS Split and Product Cost Variances
- Statistical sales condition
- Attributed CO-PA
UNIVERSAL JOURNAL
The universal journal is nowadays well known but to be honest when I saw the first description of the concept I was wondering what was the benefit for the final user.
I was able to understand and recognize the technical benefits contained in the Universal journal Concept like:
- Simplification of Tables, and Unification of Subleders (for example FI, CO, AA, ML)
- Elimination of totals Concept
- Amelioration of performances
- Elimination of differences in OLTP and OLAP concept
- Elimination of reconciliation between different ledgers (e.g. FI and CO)
but I was struggling on how to transform it in a tangible business advantage for the Controller.
At that time, having the possibility to see new SAP FIORI APPS on Universal Journal the it was clear to me that the FIORI would have been a perfect match. And as a matter of fact fact I could verify some FIORI Apps able to offer Controlling Reports like never in the past. For example the Market Segment FIORI app.
Please see also the FIORI topic in second part of this blog (when it will be ready).
Regarding Controlling part, one of the consequences of the Universal Journal is that total tables are not in place anymore and if you remember ECC most of the Controlling Reporting was based on totals tables. So how these reports are now working in SAP S/4HANA? There is a non disruptive compatibility view mechanism that ensure that the reports are redirected and continue to work. So as mentioned By OSS 2270404:
“The former tables COEP, COSP, and COSS are replaced by views of the same name, so-called compatibility views, that aggregate the data in the universal journal on the fly in accordance with the old table structures”
Old reports continue to work based on the universal journal tables, CO Fiori Apps are based on the universal journal as well, that means that as matter of fact your reporting source is now the Universal journal. But which part of the Universal Journal? This is really the question that a Controller should ask himself (and I will try to reply further in this blog post).
There is one example I like to show to my customers about elimination of tables and unification of subledgers. Everybody knows that Payable, Receivable, Assets, Controlling and material ledger are now in the same universal journal table (the ACDOCA table). That also means that the granularity of Finance postings has augmented; if you for example think about an asset purchasing you will have a row for each asset you are buying (and not simply by a G/L Account representing the asset itself). But the concept of Universal Journal is much more than a technical concept: having a single place where to find every information regarding for example the purchasing to pay process is extremely useful.
An example, a customer raises a purchase requisition and a purchase order to a project, materials are to be considered in this case as Capex Cost. The goods receipt Is therefore directed to a Wbs element, then the Wbs element is settled to an Asset Under Construction (End of the period) and then to a Final Asset (End of the internal Construction). After a while an Invoice is raised and then the payment is posted.
In ECC you had to probably create a custom report to keep together the information from purchase requisition to payment among different tables. With the Universal journal you can find every record in one single table. (Anyway, if you want to keep the documents related one to another you should go analyze the problem a little bit deeper, maybe the new document flow FIORI app may help you a bit on that).
So with the progression of SAP S/4HANA I found my way to the real business value for Controllers.
REALTIME INTEGRATION
The Finance realtime integration, and before of it the Controlling Reconciliation Ledger were concepts used in ECC to keep aligned FI with CO.
For example one cross Cost Center CO posting belonging to different Profit Centers or Business areas or Company codes could create a misalignment between FI and CO. In ECC if you had an FI posting of 100 Euro on Cost center A (Profit Center A) and then a CO internal allocation from Cost Center A to Cost Center B (Profit Center B) as a matter of fact you would have Controlling reporting (cost center and Profit Center) not aligned with Finance Reporting.
Finance Reporting: Cost Center A (Profit Center A) 100 Euro
Controlling reporting: Cost Center A (Profit Center A) 0 Euro Cost Center B (Profit Center B) 100 Euro
If you had the requirement to have Finance and Controlling reporting reconciled (for example because your profit center represents your business segment and it should be always aligned in FI and CO) you could use the mentioned concept to realign FI with CO.
In other words, after the CO Allocation you could have an (only) FI posting like:
- – 100 Cost Center A
- + 100 Cost Center B
If the allocation was done on secondary cost elements you had the possibility to “represent” the Secondary Cost element with a specific G/L account in order to allow the posting in FI (by definition the FI posting could not be done on secondary cost elements).
In SAP S/4HANA, with the concept of universal journal, secondary cost elements are G/L accounts and every CO posting is represented in universal journal, therefore you do not need Reconciliation ledger or Realtime integration concept anymore.
Please note I am not talking about cross company clearing accounts, this has remained in SAP S/4HANA customizing as well.
COST ELEMENTS
The fact that cost element are now G/L accounts is also a known concept since a while. The fact of having the Universal journal suggested to have one single concept. That means that even if you are creating an internal positing in CO (e.g. CO internal allocation between two cost centers) you will obtain an FI document for it with an FI header (BKPF, not BSEG).
If you are concerned to have a challenge on separating the secondary cost element on your B/S or P/L structure you may want to know that there are ways to separate them from the primary cost elements.
The OSS 2841880 may help, it talks about Financial Statement Versions G/L Account Hierarchies Semantic Tags.
The definition of GL Account Hierarchies and Financial Statement Version helps in this way. You can assign primary and secondary cost element General Ledger Accounts to different Hierarchies to keep them separated for reporting and statutory purposes.
Sematic Tags helps on the creation on KPIs.
Anyway the total impact of secondary element is by definition zero (because you use them only to move costs from one cost object to another one) so you should not worry about them in total but only among Controlling objects.
If you put together the Universal journal concept (already explained) with the SAP trend to suggest the customers to use Margin Analysis based on the old Account Based CO-PA (that uses G/L Accounts instead of Costing based Value Fields) you may find the “marriage” of Cost elements and G/L Accounts as a simple natural consequence.
CO INTERNAL POSTINGS WRITING IN UNIVERSAL JOURNAL
With Universal Journal concept CO Postings are written in the Universal Journal table (ACDOCA).
To write on this table you need some basic concepts:
- Document Type. Even CO internal Postings are now written on document types (As per the FI documents). Potentially you need to choose one document type for each CO Business transaction. If you think about the Realtime Integration Concept explained previously the reasons why you need a document type should now be clear.
- Assignment of CO Version to the leading ledger or to every ledger. If you think about the new ledger concept like a way of grouping your P/L and B/S for internal and external (e.g IAS, US GAAP) reporting purposes you may find this possibility very interesting.
Basically you have the option of recording some of your postings in specific ledger group and to dedicate even CO postings to obtain an alternative Profit and Loss. Even with the new Universal Allocation you can run Allocation cycles by ledger. Moreover you have the possibility of executing CO specific postings (for example manual re-posting of cost) per ledger group. So manual or automatic allocation of costs may be a good way to start doing posting per ledger (accounting principle).
EVOLUTION OF SAP ECC PROFITABILITY ANALYSIS TO SAP S/4HANA MARGIN ANALYSIS
With the advent of Universal journal SAP suggests to use the Margin Analysis evolution of Controlling Profitability Analysis.
In ECC there were 2 types of CO-PA
- Costing Based (based on separate ledger and using Value Fields)
- Account Based (integrated with G/L Accounting and using G/L Accounts )
(Actually for specific customers, there was also a third type of Profitability Analysis called “Combined” but this is now of not allowed anymore in SAP S/4HANA )
Most of customers who used Profitability Analysis opted for Costing Based cause it was much powerful and very integrated with Product Costing. For example it allowed the use of Valuations to import in CO-PA Sales Order Statistical Conditions, moreover it had functionalities to import COGS split into CO-PA Value Fields.
Being based on Value Fields (and not on G/L Accounts), writing on different tables, and sometimes not completely aligned with the General Ledger Document postings (for example Goods issue) Costing Based CO-PA was therefore not easily reconciled with General Ledger.
Following the integrated approach of the Universal Journal, SAP decided to use the integrated ECC Account Based CO-PA as a base to build the new SAP S/4HANA Margin Analysis. Margin Analysis concept became a new Version of Account Based CO-PA improved in the Universal Journal. Costing Based CO-PA can still be used in SAP S/4HANA but Margin Analysis will be the only solution improved by SAP
The fact that you now have characteristics in Universal Journal actually means that whatever characteristic you may want to create in your detailed P/L (for example Customer, Market Segment, Product Group and so on) you will be able to see this characteristic in your universal journal table ACDOCA as a column.
At the beginning this option to go for Margin Analysis was not easy to adopt for CO-PA Costing based customers cause, as previously mentioned, Costing Based CO-PA offered more functionalities; but then, release by release, SAP improved the Margin Analysis in the Universal Journal with new functionalities. Nowadays these improvements and new developments have transformed Margin Analysis in a very better solution.
Let’s see a comparison table:
As you can see most of the gaps between Costing Based CO-PA and Margin Analysis have been closed and most important, reconciliation with Finance is integrated in Margin Analysis but not in Costing Based CO-PA. You may object that even in the ECC the Account Based CO-PA was integrated with G/L Accounting but despite that, many customers chose Costing Based CO-PA. On the other hand you must admit that these customers did not have universal Journal in ECC and most important, that in terms of functionalities Account Based CO-PA is less powerful than Margin Analysis.
Having a look to the comparison you may see that some of the features (e.g. Statistical Sales Conditions or Incoming sales order) are realized thanks to the possibility of writing new rows in the Universal Journal on Extension Ledgers. If you stop to think for a minute about the concept of posting on a parallel ledger in ECC you may think of something belonging to Financial on a specific Financial table (BSEG or FAGLFLEXA). Now it is instead an Universal Journal posting and depending on which fields are filled you may want to consider them for Controlling as well, so they are to be considered as controlling postings.
An implication of that is that you will not find them on the classic SAPGUI reporting but only in FIORI.
PREDICTIVE ACCOUNTING
Let’s take in consideration the Predictive Accounting concept.
The Idea to have in a dedicated part of P/L Sales and Purchasing Orders in real time, before they become an actual posting may help customers to anticipate their month end closing and reporting.
You have the possibility to bring in SAP S/4HANA Sales and Purchase orders in a specific ledger and to obtain automatic reversals of these postings once the related Financial documents are posted.
This is what SAP calls “Bottom Up Predictive Accounting” and it is clearly explained at this link
The good thing about predictive accounting is that the “predicted postings” are automatically synchronized with the actual postings.
How many customers were in the past “simulating not posted goods receipts or goods issues (or even not posted invoices) as a part of the month end closing procedures to reverse them at the beginning of the following month? (I know some ECC customers doing that even in FI-SL Special Ledger).
Thanks to Predictive Accounting this in now over. Someone may object that having predictive postings is not the same to have financial postings and that financial posting may be different from what they were supposed to be in the Orders; well this may be true, but it is also true that we are talking about prediction, so in my opinion it is much better to insert a prediction in a P/L than to have nothing.
Please be aware that as of SAP S/4HANA release 1909 Predictive accounting related to Sales orders has limitations:
Again, would you as a controller consider these postings as a value added? I would.
Were these postings considered as standard in ECC? Maybe yes but in a specific separated not finance integrated reporting (in Costing based CO-PA).
Is it useful to have them in the Universal Journal with other actual postings even on a separate section of it on Extended Ledger? I would say yes.
COST COMPONENT SPLIT/COGS SPLIT AND PRODUCT COST VARIANCES
If you think at the differences between Account Based and Costing based CO-PA in ECC with regards to COGS split it was mainly a question of:
Costing Based CO-PA
- Simulation of Material Cost (Fix and Variable) at the time of Sales Document
- Production Cost (Fix and Variable) at the time of sales Invoice
Accounting Based CO-PA
- Cost of Sales at the time of Goods Issue
The Costing Based CO-PA advantage was to have Material and Productive Cost split by Cost Components related to CO-PA Value Fields.
In Margin Analysis as per OSS note 2349278 “Cost of goods sold (COGS) postings are assigned to an account/cost element at the time of the goods issue from the warehouse”. New functions are available to split the COGS posting to multiple accounts in accordance with the relative weight of the assigned cost components. This split can be updated with the results of actual costing from SAP S/4HANA 1809”.
You can use a new customizing to put in relations Cost Components to G/L Accounts, in this way you can obtain the split when you post a goods issue in Margin Analysis. Cost components can be valuated at standard and since 1809 at Actual Price too.
The same it is relevant for Product Cost Variances (product variance split)
So the ECC gap of having Costs in CO-PA reconciled with Accounting at the time of Goods issue is now covered by Margin Analysis.
STATISTICAL SALES CONDITIONS
Another Costing Based CO-PA functionality is the possibility to calculate statistical sales conditions (e.g related to warranties or freight cost) that are in SD Order but are not part of the Sales Invoice. Those costs are calculated internally and brought to CO-PA Characteristic even if not calculated in Finance and debited to the customer (at least not directly). From SAP S/4HANA release 1809 it is possible to transfer these statistical sales conditions in an extension ledger and to have them in Universal journal.
ATTRIBUTED MARGIN ANALYSIS
Attributed Margin Analysis is a new way to derive Profitability Segment Characteristic in Universal journal even without executing manual activities. One possible example is to obtain the characteristic filled for a posting on a Wbs element that has settlement rule to CO-PA characteristic. If the settlement rules are properly compiled, a simple posting on the Wbs element will feed the Margin Analysis Characteristic as well without the need of executing the settlement itself. The Posting Controlling Object will still be the Wbs element but the characteristic fields will be filled in parallel. This process is of course not just limited to the example I have made and I think it is a very clear example of new functionalities we may find in SAP S/4HANA.
To have a more detailed description of what is included in Attributed Realtime Margin Analysis you can have a look to this blog as well brought to you by the RIG.
So to say some conclusive words on Margin Analysis, nowadays I think that apart from very specific functionality the Margin Analysis is now a suitable solution for customers. Main reasons are:
- It is integrated into the overall concept of the Universal Journal
- It has been extended broadly over the past releases
- It is fully aligned with SAP Financial Accounting development strategy and SAP has the intention of conducting new developments in this area only.
PRELIMINARY CONCLUSIONS.
When you think about Controlling in SAP S/4HANA you really need to mention other parts beside what I have already talked about, topics like Universal Allocation, Material Ledger, Reporting (FIORI), Planning Processes are fundamental.
I will try to use the second part of this blog to give a complete reply on the initial questions I raised at the beginning. To give anyway some preliminary conclusion, I think that the Controlling Consultant role will continue to be necessary, but consultants need to expand their knowledge to new arguments (and I think I have already mentioned some in this first post).
Moreover, the universal journal table (ACDOCA) is central and it should be learned by the controlling consultant.
In the next blog post I will also describe how the controlling Reporting has evolved to FIORI.
What do you think?
Brought to you by S/4 HANA RIG
Okumaya devam et...