My company is in the early stages of moving from ECC 6.0 to S/4HANA. I thought it would be interesting to give you my initial impressions of what I found out about Controlling in S/4HANA. Since we started out with ECC 6.0, we don’t have the baggage of things like classic G/L versus new G/L.
We first got access to an S/4HANA sandbox for a test drive of the system. This is an important step in the transition and has helped me get a much better understanding of how the new system works rather than reading documentation and watching training videos. What follows are my initial impressions. Hopefully, this will be useful if you are making the move, or contemplating it.
Look and Feel
When you think about user interfaces with S/4HANA, you think Fiori because it is one of SAP’s main selling points. When I first logged on to the S/4HANA test client, I used the SAPGUI interface. The surprise here is there is no surprise. Whether using the SAPGUI or SAP Business Client interfaces, logging into S/4HANA looks exactly like logging into ECC 6.0. The traditional look and feel is still valid, and to me, this is a great advantage. You do not need to learn new transactions and business processes, because you can use existing transactions and processes. Although it might be worthwhile, you do not need to work through new business processes when making the transition. This makes the move more like an enhancement pack upgrade rather than a new implementation. I may need to back up here. This is not an enhancement pack upgrade and should not be treated as such. However, it's comforting to know that you can make the transition with minimal impact to end users.
S/4HANA works well with the traditional look, but one of the big selling points is the extensive use of Fiori tiles to give a modern interface and provide a way of displaying real-time and predictive analytic information. I looked for tiles for production orders to show some problem orders for review. I wanted to click on a tile to display a list of orders for review. Unfortunately, I could not find a tile specifically for that. I found tiles that executed standard transactions (a must if you are using Fiori as your only interface) and enhanced reports. Little was available for the dashboard view I was looking for. This is not a major issue, as existing functionality remains, but I was a little disappointed in the lack of predictive analytic tools provided for the Controlling community.
This is a must for everyone to understand before making the leap to S/4HANA. However, the list itself is not simple – the 1709 simplification list is 906 pages long. It also appears that not everything that is listed as replaced is gone.
When I initially logged on to the S/4HANA client, I wanted to see how SAP handled obsolete transactions. Knowing that base planning objects were on the simplification list, I ran transaction KKE1 expecting to see either that there was no such transaction or a message indicating that KKE1 was obsolete. Instead, I found that KKE1 still worked. This was one of the transactions S/4HANA 1709 simplification lists as obsolete. However, in SAP Note 2133644 (Error message SFIN_FI 004: Transactions KKE1, KKE2, KKE3 cannot be called), it appears that even back in the days of Simple Finance (Feb 2015), this functionality was brought back into use. A few other base planning object transactions were included with these three, but several of the reports continue to be obsolete. This is despite the fact that the 1709 simplification list chapter 8.2 referring to SAP Note 2270335 (S4TWL - Replaced Transaction Codes and Programs in FIN) and again in chapter 12.1 referring to SAP Note 2349294 (S4TWL - Reference and Simulation Costing) both indicate that these transactions are replaced in S/4HANA.
Base planning objects continue to live, albeit with the caveat that you should convert to unit costing (CKUC) or Easy Cost Planning to create ad hoc costs (SAP Note 2270335). The implication is that at some point these transactions will go away. On a side note, I think that the return of base planning objects to S/4HANA is good since costs can be created without reference to a material (unit costing) or a costing model (Easy Cost Planning). Base planning objects can be used in conjunction with Easy Cost Planning to enhance the power of the tool in creating ad hoc cost estimates. I hope that SAP reconsiders whether base planning objects should be kept in future releases.
If the transaction has been removed, the transaction window is displayed with the following dialog box showing message SFIN_FI004, or the message will be displayed at the bottom of an empty window.
Review the simplification list, but verify with testing. Some transactions on the list are gone, but others may still be available. I expect that at some point those on the list that are currently available may be gone, so plan accordingly.
The Universal Journal
One of the keystones of S/4HANA is the Universal Journal. This is the single source of truth, combining Controlling and General Ledger postings in the same table: ACDOCA. Because of the speed of the HANA database there is no need to use separate aggregate tables for period-based information. Not only is duplication of data no longer required to get reports in a timely manner, there is also no longer any problem reconciling FI and CO, because all the data is kept together. This is all true up to a point. If you take everything at face value, you might expect that tables such as COEP for CO line items and the COSP and COSS aggregate tables for primary and secondary postings would no longer be required. In fact, all of these table names have been converted into database views so that existing reports still work without making extensive programming changes.
It is logical to conclude is that these tables are no longer required in S/4HANA. However, not only are these tables not dead, they are not even mostly dead (for Princess Bride fans), and are an integral part of the Controlling database landscape in S/4HANA. The relevant SAP Note is 2270404 (S4TWL – Technical Changes in Controlling), which is also section 12.4 of the 1709 simplification list. For any actual CO postings (value type 4), everything is stored in ACDOCA. There are no updates to the aggregate tables for these postings. Statistical postings (value type 11) are treated the same way, but these are also updated in the old table COEP, although I have not tested this. All other value types, including plan costs (value type 1), and target costs (value type 5) are posted the same as before, using the old tables. I did test some manual activity type postings which updated the old COEP table with a new value type (U4). Although the original COEP, COSP, and COSS tables still exist in S/4HANA, because these names are used as compatibility views, the table names have changed. COSP and COSS are COSP_BAK and COSS_BAK, respectively. COEP may have an alternate table ID, but the only way to get to just the data stored in it, you need to use the view name V_COEP_ORI.
SAP Material Ledger
SAP Material Ledger is mandatory in S/4HANA. This does not mean that you will be forced into actual costing, but instead the underlying data structures become a necessary part of the S/4HANA landscape. The Material Ledger table structures in ECC 6.0 are complex. Moving to S/4HANA this data structure has been simplified. Of course, with simplification comes a change in functionality. According to Rogerio Faleiros, who had an excellent presentation on SAP Material Ledger in S/4HANA in the 2017 Controlling Conference (Myths vs. Fact: SAP Material Ledger in SAP S/4HANA), SAP has taken at least a small step backwards in functionality in his opinion. Some of the issues he lists may or may not apply to your situation. For example, my company does actual costing, but does not use the full set of features available with Material Ledger. I tested the actual cost run in a test S/4HANA client after posting purchase price and usage variances. The costing run transaction CKMLCP is streamlined and many defects from the earlier version, including handling locked records and materials that hadn’t closed properly in the previous costing run are resolved. In addition, several of the steps have been combined into one Settlement step, which makes it more convenient to set up and use. Of course, this streamlining comes with a price. You can no longer distinguish between single-level and multi-level differences. For details, see SAP Note 2354768: S4TWL – Technical Changes in Material Ledger with Actual Costing (section 12.3 in the 1709 simplification list). This highlights many of the changes in database structure and functionality.
What concerned me was the elimination of the distinction between single-level and multi-level differences in actual costing. This was on Rogerio Faleiros’ list of Material Ledger disappointments. I created purchase price and usage variances in the S/4HANA sandbox so that I could post differences when performing the actual costing run. The new actual costing run is easier to use and corrects some problems that CKMLCP currently has. For example, locking in the material master causes certain items to not close correctly. If these are not rerun or manually corrected with the Material Ledger helpdesk, you will not see the correct cost. This is corrected with the new Material Ledger and I'm looking forward to seeing how it performs in production. I cannot say much about the speed of the new CKMLCP transaction as my sample size of materials was small. The resulting financial documents look different in S/4HANA to ECC 6.0. There are no single-level or multi-level difference postings. There is only a difference posting using accounts defined for transaction event PRV. This looks strange when reviewing accounting documents, but since we do not distinguish single-level from multi-level differences with separate G/L accounts in our implementation, this does not have a major impact. We have less information in variance analysis, but we don’t do that analysis often.
The point I wish to make is that there have been major changes in how Material Ledger works in S/4HANA, and that you should review them to see if these changes will cause you any pain when upgrading. There are some additional notes to review that are included in the 1709 simplification list. These are 2332591 or section 16.2: S4TWL – Technical Changes in Material Ledger, 2352383 or section 16.6: S4TWL – Conversion to S/4HANA Material Ledger and Actual Costing, and 2267834 or section 25.5: S4TWL – Material Ledger Obligatory for Material Valuation.
If you have not yet converted to S/4HANA, there is a lot to think about. However, based on my experience, it is not as scary as sometimes portrayed. The look and feel can be the same in S/4HANA making it easier for you to make the transition. Some older transactions have disappeared, but others have been resurrected. Certain transactions are permanently gone and the lifetime of resurrected transactions may be brief. The Universal Journal has only taken over CO actual and statistical postings, so the existing CO table structure will remain intact when moving to S/4HANA. I have not concluded whether this is a good thing or a bad thing, but it will impact what you need to migrate when converting. The Material Ledger has been simplified, but it depends on your previous implementation to determine if you have lost or gained functionality. Plan your conversion carefully and make sure you have sufficient time for testing. In the end, you will have a very familiar, but much improved ERP experience.