My company is in the early stages of making a move from ECC 6.0 to S/4HANA. I thought it would be interesting to give you my initial
Look and Feel
When you think about user interfaces with S/4HANA, you immediately think Fiori because that is one of SAP’s primary selling points moving to the new system. When I first logged on to the S/4HANA test client, I used SAPGUI interface. The surprise here is that there is no surprise. When 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. There is no need to learn new transactions and business processes, because the existing transactions (at least most of them) and processes can still be used. Although it might be worthwhile, there is no need to work through new business processes when making the transition. This makes the move more like an enhancement pack upgrade on steroids rather than a brand new implementation. I may need to back up here a bit. This is definitely not an enhancement pack upgrade and should not be treated as such. However, it is comforting to know that the transition can be made with minimal impact to the end user.
S/4HANA works pretty well with the traditional look, but one of the big selling points is the extensive use of Fiori tiles, intended to give a more modern interface into the system and to provide a way of displaying more real-time and predictive analytic information. I was looking for some tiles that might look at production orders for a plant and show a number indicating problem orders that needed to be reviewed. Then clicking on the tile would get to a list of those orders which could be drilled into to be reviewed. Unfortunately, I could not find a tile that could do that. What I mostly found was tiles that executed standard transactions (a must if you are using Fiori as your only interface) and enhanced reports. Very little was available for the kind of dashboard view that I was looking for. This by itself is not a major issue, as existing functionality is still there, but I have been a little disappointed in the apparent lack of predictive analytic tools that have been 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 truly gone.
When I initially logged on to the S/4HANA client, I wanted to see how SAP was handling obsolete transactions. Knowing that base planning objects were on the simplification list, I typed in transaction KKE1 hoping to see either that there was no such transaction or that there was a message indicating that KKE1 was obsolete. What I found instead was that KKE1 was still appeared to work. This was one of the transactions that was clearly in the S/4HANA 1709 simplification lists as being obsolete. However, if you look at 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 (February of 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 note 2270335 (S4TWL - Replaced Transaction Codes and Programs in FIN) and again in chapter 12.1 referring to 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 over to unit costing (CKUC) or Easy Cost Planning to create the ad hoc costs (note 2270335). The implication is that at some point these transactions will go away for good. On a side note, I think that the “return” of base planning objects to S/4HANA is a good thing, because they can be very useful as costs can be created without reference to a material (unit costing) or a costing model (Easy Cost Planning). In fact, base planning objects can be used in conjunction with Easy Cost Planning to enhance the power of that tool in creating ad hoc cost estimates. If I had a vote, I would hope that SAP reconsider whether base planning objects should be kept in future releases.
By the way, 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 truly gone, but others may still be available. However, I would expect that at some point in the future those on the list that are currently available may be gone, so plan accordingly.
The Universal Journal
One of the keystones of S/4HANA from the finance side is the Universal Journal. This is touted as the “single source of truth”, combining controlling postings and general ledger postings together in the same table: ACDOCA. Because of the speed of the HANA database there is no longer any need to use separate aggregate tables for period-based information. Not only is the duplication of data no longer required to get reports in a timely manner, there is also no longer any problem with reconciling FI and CO, because all the data is kept together. This is all true up to a point. If you take everything a 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 would still be able to work without making extensive programming changes.
A logical thing to conclude from this information 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 you 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. What you find is that for any actual CO postings (value type 4), everything is stored in ACDOCA as advertised. There are no updates to the aggregate tables for these postings. Statistical postings (value type 11) are treated the same way, but it appears that these are also updated in the old table COEP, although I have not done any testing of this at the time of this writing. For 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). One word about tables. Although the original COEP, COSP, and COSS tables still exist in S/4HANA, because these names are used as compatibility view names, 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.
The material ledger mandatory in S/4HANA. Of course, this does not mean that everyone will be forced into doing actual costing with the material ledger, but instead, the underlying data structures for how the material ledger does its thing will become a necessary part of the S/4HANA landscape. The material ledger table structures in ECC 6.0 and earlier are quite complex. As a part of moving to S/4HANA this data structure has been simplified (there’s that word again!). Of course, with simplification comes a change in functionality. According to Rogerio Faleiros, who had an excellent presentation on the 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. Some of the issues he lists may or may not apply to your situation. For example, my company does do the actual costing but does not use the full set of features available with the material ledger. I tested the actual cost run in a test S/4HANA client after forcing a lot of purchase price and usage variances to be posted. The costing run transaction CKMLCP is much more streamlined and many defects from the earlier version, including handling locked records and materials that hadn’t closed properly in the previous costing run. In addition, several of the steps have been combined into one Settlement step, which makes it much 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 much of the changes in database structure and functionality.
The major item that 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 worked to create purchase price and usage variances in the S/4HANA sandbox so that I could get differences to be posted when performing the actual costing run. First of all, let me say that the new actual costing run appears to be much easier to use and corrects some niggling little problems that CKMLCP currently has. For example, locking in the material master causes certain items not to close correctly. If these are not rerun or manually corrected with the material ledger helpdesk, you will not be able to see the correct cost. This appears to be corrected with the new material ledger, and I am looking forward to how it will perform in production. I cannot say much about the speed of the new CKMLCP transaction as my sample size of materials was necessarily small. The resulting financial documents look a bit different in S/4HANA than in ECC 6.0. First, there is no single-level or multi-level difference postings. There is only a difference posting, using accounts defined for transaction event PRV. This looked 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 appear to have a major impact for us. We definitely have less information when delving into the depths of variance analysis, but in reality, we don’t do that kind of analysis very often, if at all.
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.
For those of us that have not converted over to S/4HANA yet, there is a lot to think about. However, based on my experiences thus far, it does not appear to be as scary as it is sometimes portrayed. The look and feel can be the same in S/4HANA as it is in earlier versions making it easier for the user base to make the transition. Some older transactions have definitely bit the dust, but others have been resurrected due to the needs of the customer base. Be aware that there are certain transactions that will be permanently gone and that 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 pretty much 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 needs to be migrated when converting. The material ledger has been simplified, but it depends on your previous implementation to determine if you have lost or gained functionality. Definitely plan your conversion carefully and make sure to have more than sufficient time for testing. In the end, you will have a very familiar, but hopefully much improved ERP experience.