Introduction
The spread of SAP S/4HANA is gaining momentum. Unfortunately, whether as part of a new launch or a conversion project, the path to introducing this solution is not without difficulties. In recent years, we have seen a wide variety of scenarios among our customers, and tackled all of these together. In the context of integrated financial planning with SAP S/4HANA and the SAP Analytics Cloud (SAC), I would like to explain a few of these challenges in this blog, and identify potential ways of handling them. I will refer to S/4HANA On Prem throughout this post.
I will restrict myself to cost center planning with SAC and S/4HANA, without further intermediate systems. Many of the classic objects (COSP, COSL tables, etc.) remain in S/4. However, the recommendation is that users no longer use these, and instead switch over to the “new” tables and applications. The key components are the “ACDOCP” (Accounting Documents Planning) table, which contains planning data, and the “ACDOCA” (Accounting Documents Actuals) table, which contains actual values.
Fiori apps are available for (financial) planning and reporting in the “new world” of the S/4HANA system. They access these two new tables. Data in the classic tables cannot be displayed with these apps. However, there are transfer programs with which planning data can be transferred from the classic tables to the new tables. The transfer works in both directions. This makes it possible to continue using the classic transactions (KP06) and use SAC at the same time.
Once a decision has been made to handle cost center planning in the future with the combination of SAC and S/4HANA, there are essentially three often-encountered scenarios:
- Planning is handled completely in SAC, and planning data is extracted to ACDOCP. Usually seen with new customers and “green field” S/4 implementations.
- Planning is handled completely in SAC, planning data is extracted to ACDOCP and then transferred to the classic tables. “Classic” reporting can continue to be used in this case.
- Planning is handled partially in SAC and partially in the classic ERP transactions (KP06) in Controlling, then “synchronized” with the transfer programs. This option is used if not all plans can or should be implemented directly in SAC. In this case, part of planning remains in the classic CO.
To simplify the migration and obtain results quickly, there are planning applications prepared by SAP within SAC. These packages can be activated via the SAC Content Network. Then, it is only necessary to set the connection to the corresponding source system and activate the interfaces in the source system. However, this content assumes that planning is handled in the new tables in the S/4HANA system. The content cannot access the old tables without customizing. Before you activate this content, you should check whether its functions will be sufficient for your planning.
What you need
To handle cost center planning with SAC, you will need not only an SAC system and corresponding planning licenses, but a few other things as well. We have already provided an overview of the licensing issue HERE (Please enter link to SAC licensing).
SAC can be connected to an S/4HANA ERP system in different ways. However, for planning the data must be imported to SAC. This means that data from S/4 is replicated in SAC. The import connection is designed for this purpose. In this case, the connection is handled via the so-called Cloud Connector. This is installed on a server in your network and allows SAC and S/4 to be connected to one another in a technically secure manner. A corresponding S/4 interface user can be used to determine which data SAC can access. In contrast to a live connection, this user is added directly in the SAC connection so that all authorized SAC users (developers, administrators, key users, …) can use this connection regardless of their own authorizations in S/4.
As part of developing the SAC Business Content “Integrated financial planning,” SAP also developed interfaces for typically required master and transaction data in S/4. The SAC help page on Business Content provides a list of these interfaces. Using the available interfaces is preferred over developing your own interfaces. These already reflect complex logics, especially when hierarchies need to be integrated. The interfaces can be expanded for simple field extensions (such as own Z fields on the cost center).
Ultimately, it should also be possible to review and report planning data in the ACDOCP table. Here as well, standard SAP Fiori apps are available for this purpose, that mean different app numbers and different levels of setup work required depending on the version of the S/4HANA system. Commonly used Fiori apps include, for instance:
- Upload financial planning data
- Delete financial planning data
- Copy financial planning data
- Record financial planning data
- Plan/actual cost center comparison
In addition, the following transfer programs are required in S/4 if data from the classic tables is to be used:
- R_FINS_PLAN_TRANS_CO_ERP_2_S4H
- R_FINS_PLAN_TRANS_CO_S4H_2_ERP
- R_FINS_PLAN_TRANS_ACTY_S4H_ERP
- R_FINS_PLAN_TRANS_ACTY_ERP_S4H
- Others starting with “R_FINS_PLAN_TRANS_”
These are available from S/4 version 2022 (to a restricted extent in 2021 as well). There is also a mechanism for integrating amortizations from the AfA simulation.
Last but not least, at least one plan category is required in ACDOCP for the planning data. We should note that the new world thinks in categories in S/4, and not in versions.
Planning in SAC
The first two scenarios are simple scenarios. Planning data is recorded in SAC, and then transferred to S/4. The SAC functions are used, for instance, to implement business logics and reviews. The planning process can be designed in a targeted way without disrupting other functions, as would be the case with development directly in S/4.
There are different standard interfaces in S/4 to transfer data from SAC to S/4HANA, if the S/4 version is current enough. Different interfaces are used depending on whether you are dealing with demand rates or budgets. The transfer is set up like an import job and then a target scope for the export method “Delete & replace” is selected. The target scope determines which data is deleted in S/4 before the actual SAC planning data import. For example, if “fiscal year + cost center” is selected, all combinations of fiscal year and cost center that are in the export data are deleted in S/4 and replaced by SAC planning data. If the G/L account is added as a dimension in the target scope, only the G/L accounts in the combinations transferred from SAC are deleted. G/L accounts that are not in the SAC export remain unaffected in S/4. Which setting is correct depends on what you want to achieve.
There can be many reasons why data would need to be written from SAC to S/4, from S/4 reporting to a BW extracting data from the ACDOCP, for instance to fill historical reports. One frequent reason to do so is that data is loaded from the ACDOCP to classic Controlling, in order to use the CO functions that have been set up there. This could be a cost allocation, for example, or deriving additional personnel expenses. It doesn’t always make sense to transfer these functions directly to SAC, especially in the case of a short project team or tight budget. If the results of these allocations and derivations need to be sent back to SAC, then we are in a hybrid scenario. In this case, correctly designing the integrated data flow is essential. The following section describes scenario 3, a hybrid scenario, and addresses common pitfalls.
Architecture of a hybrid scenario
In the list of the three scenarios mentioned above, the third scenario is the most complex. This is because planning data must be entered into the system at 2 different points. In the following section, I have shown one possible structure:
The process would be as follows:
- Planning entry in SAC (top) and KP06 (bottom) by different groups of people
- Copy S/4 planning data from classic tables to ACDOCP by IT (one copying job per planned fiscal year)
- Import planning data to SAC
- Consolidate planning data in SAC
- Export planning data to S/4
- Copy SAC planning data from ACDOCP to classic tables by IT (one copying job per planned fiscal year)
This process has several weaknesses. First, each version of one of the jobs can only copy one fiscal year. However, generally multiple years are planned in SAC. There are different Fiori apps available in the Fiori landscape to delete planning data, export it directly from a CSV/XLSX file, or enter it directly. Data from SAC can only be imported to ACDOCP with the “Delete and replace” mode with a defined scope. The scope determines what data is deleted. for example, if we enter an accounting area and cost center, all combinations contained in the SAC export are deleted in S/4. But what about a cost center that is already contained in the ACDOCP but not in the source scope of the export from SAC? It remains unaffected in the ACDOP! Because of this, it is possible for an “overall report” in S/4 to show different values than those planned in SAC (inconsistent reports!). To bypass this problem, a separate planning category is created in our project; it must first be completely deleted and then reloaded from both directions.
Data can be copied to the classic tables using one of the transfer programs. This can be the case, for example, if you want to keep using the old allocation rules, or if overall reporting via the classic tables is required. The target tables (COSP, etc.) are not deleted, however, but instead only the values in the transfer are overwritten. This can cause problems at the latest when planned values (in SAC) need to be deleted again (for instance if the wrong cost type was used). Since this data set is no longer present in the SAC source scope, it remains in the target table. First, the (classic) target table must be deleted, or no planned values may be deleted from the planning in SAC. Instead, the planned values can be set to “0”. In this case, the combination remains in the source scope and the value is set to “0” in the target (classic table). However, we must consider than all planned values are deleted with “Delete and replace,” including values that were not yet recorded in the last transfer to SAC. The process is very important in this case. Either input must be blocked in the ERP until data has completed its “round trip,” or a version must be created in the classic landscape, that is first deleted completely and then loaded from ACDOCP and he classic tables. However, correct filtering is important since some data is already available in the ACDOCP.
Unfortunately, options for filtering the transfer jobs are another weak point. Although the SAP GUI offers 4 filtering options for this purpose, only the “Include filter” works! If part of the data is planned using KP06 and another part of the data using Fiori/SAC, then the correct Include filter is important when transferring the data. Otherwise there is a danger of data being copied (and therefore overwritten!) that should not be copied. In some of our projects, some cost types and accounting areas are planned via SAC, and others via KP06. Due to the quantity of cost centers (>1,000) and accounting areas (>30), creating these filters was very complex and they needed to be adjusted continuously. In addition, there are NO technical errors (dump) if the wrong filter is used. Because of this, you don’t even notice that the filter should be ignored. This is a transfer program behavior documented in a SAP Note.
Although there have been extensive trainings, some planners have still not recorded their data at the right place (SAC or KP06), which has worsened the problem. To avoid overwriting data, multiple planning categories can be created in ACDOCP. Original input values are retained in this case.
You can easily see the problem in the image above. Depending where the overall reporting takes place, data still needs to be copied together. We should also note that both SAC export jobs and the transfer programs in S/4 consider the dependency of G/L accounts on accounting areas. SAC forgives errors in exporting to S/4 just as rarely as the transfer programs. Typically, you can record all possible combinations of G/L account/cost type and accounting areas in KP06. When recording these, there is rarely a check whether the G/L account or cost type is also available in the accounting area of the planned cost center.
If data is then written from the classic tables to the ACDOCP by the transfer program, there is a technical error and the transfer is canceled completely if the planned cost type is not valid for the corresponding accounting area. There is no standard check within SAC itself regarding which G/L accounts/cost types are valid for which accounting areas. However, this can be resolved through skilled programming in the SAC Application Designer, in order to avoid export problems. Likewise, an app can be used to implement rules for G/L accounts and activity types. A simple controlling table allows the central CO team to approve and block activity types for certain cost centers and G/L accounts without having to go over to S/4. Unfortunately, transferring the activity types results in similar challenges to transferring costs.
Conclusion and recommendation
As we have seen in projects, it is important to try and have a clear planning process right from the start and design the flow of data accordingly. Entering planning data at multiple points (KP06, SAC, …) makes the design much more complicated and increases the danger of planning data being overwritten. Entering planning data both in SAC and S/4 in a separate “input layer” (version, category) and copying/transferring/consolidating via separate layers has proven to be the best practice.
Avoiding different “input points” can help further reduce complexity. Using classic input options via KP06 and planning directly in Fiori at the same time should be avoided if SAC is used. Through the script options in the Application Designer and Data Actions, SAC offers good options for applying reviews to the entered data and avoiding incorrect entries.
SAC supports multiple hierarchies for the same dimension. By using different hierarchies for G/L accounts/cost types, different views of the same G/L accounts can be generated. Therefore, hierarchies can be used very well as “natural filters” for data entry and the display of reports and input screens can be designed accordingly.
When introducing S/4, always be sure to check whether the S/4 functions are sufficient for the planning process. For instance, if the new allocation functions in S/4 are not used, then SAC can handle this task directly. Due to the challenges described above, the classic allocation rules should be avoided in the data flow if there is not a good reason not to use these new functions.
Ultimately, using classic planning in conjunction with SAC is possible, but requires the design of the data flow to be well thought-out, and requires good management of the planning process. This helps avoid a “big bang” and continue using selected functions from classic SAP CO cost center planning until the new functions are well developed.