Positioning ACDOCP as planning repository

The new ACDOCP table became available in the S/4HANA 1610 release without any fanfare from SAP. In fact, ACDOCP was just the first step to provide a full integration between planning and actuals. More than a year after its release, this new feature still on baby steps in terms of functionality, but even now, after taking into account a number of factors, using ACDOCP can proportionate good advantages in a S/4HANA context.

Is it for me?

In a nutshell, using ACDOCP now, is a future oriented decision. Obviously, it is not wise to base any design on a roadmap that is not yet fully apparent, however in some special cases the reward can present itself in the short term. What I can confirm is that for my situation it made all the difference to use ACDOCP, short and long term:

• Both options, ACDOCP or BW, would require customised development
• This was not a forecasting solution. We were loading data from different planning platforms
• My master data for plan was the same as actuals
  • In some situations planning customers for instance, had to be created in the customer master
• My plan data was available via HANA views(SDAs)
  • It could be easily read via BW or ABAP layer, but it was the next point that turned the game pro-ACDOCP
• As part of a Central Finance implementation, we had already built dozens of objects to be used in master data mappings, derivations and conversions for actuals (ABAP).
  • We were looking to leverage those objects for plan as well, avoiding duplications and inconsistencies in rules, mappings and also dual maintenance
  • Although, these objects could also be used in BW, it would require many additional mappings between the BW and ABAP layer
• We were also implementing RTC – Real-time Consolidation, which makes it easier to get plan data from ACDOCP.

Advantages

If you need to summarise why you would use ACDOCP in one word – the word is consistency. Not just in terms of master data but also in how data is structured in comparison to actuals. ACDOCP is closing the triad of tables in S/4:

1. ACDOCA – For actuals
2. ACDOCC – For Consolidation
3. ACDOCP – For Planning

For now, you could potentially get the same result using info cube or aDSOs, but in terms of roadmap, there is heaps of functionality to be built by SAP that will allow bringing actuals and plan closer together with reporting, object based reporting, approvals based on budget data etc.

Maintenance

Simple question: is it easier to find an ABAP developer or a BPC with embedded skills? Furthermore, existing ABAP objects can be easily re-used in planning scope.

Downsides

1. BPC Features

   If you setup work status in BPC, they’re not taken into consideration by the ABAP API whatsoever. The option here is to work on a custom WS check prior to posting planning data.

   Audit Log also is not supported in ACDOCP (it is in 1709)

2. Provisional Master Data

   ACDOCP is an ABAP table and its fields will have master data validation checks when saving data. Example, if you require a planning customer, this planning customer needs to exist in your customer master – KNA1.

3. Performance

   While using aDSO or a Real-time info cube you could potentially leverage HANA IN-Memory Planning (PAK) performance in some planning functions, for ACDOCP you will have ABAP classic speed, this is considering the standard planning functions. As an upside, depending on the planning function and what you’re looking to achieve you can certainly have options to get an even better performance using the new stuff such as CDS, HANA Views, AMDP…

How to write data to ACDOCP

If you have installed BPC Optimised for S/4 in your system you must have noticed that, in addition to the Real-time Info-cube /ERP/SFIN_R01 – S/4HANA Financials: InfoCube for Plan Data, there will be a second one, type virtual: /ERP/SFIN_V20 – S/4HANA Financials: Plan Data from ACDOCP. This cube has a read interface based on HANA view (FCO_C_IBP_ACDOCP) and already leverages a standard write interface based on ABAP Class, that will take care of the mapping between BW info objects and ACDOCP fields.

The good thing is that this cube is already assigned to the Multi Provider used in all delivered workbooks, and to start saving data in ACDOCP via the pre-delivered workbooks, all you need to do is to switch the default value in the Bex Variable /ERP/P_0INFOPROV to V20.

Another way is via ABAP, well because ACDOCP is an ABAP table! And there is a standard API for that: Function Module FINPLAN_API_POSTDATA. Be aware that, this function (at least in version 1610 FSP02) is set as “not released”. My guess is that SAP is still improving this API, but right now it has very little documentation and it will need to interpret the code to know what it’s doing sometimes.

There is a BAdI available in the API as well, in case you require additional mappings to the data being saved – BADI_FINPLAN_POST. Some other options to be considered are: the class: CL_FINPLAN_API (within this FM) and even direct update if you’re up to it.

Road map

I cannot speak for SAP but I guess the roadmap is filled with options on how you interact with actuals based on plan. Currently, ACDOCP does not have much functionality built on top of it in S/4, but SAP already gave signs that this is going to change.

Allocations

Currently you can use the pre-delivered content to integrate plan data (from ACDOCP or R01 info cube) with CO-OM (Overheads Management) classic tables, this includes costs by cost object – cost centre, internal order or WBS. But this involves duplication of data and can cause inconsistencies.
The ideal approach is to run the CO allocations reading and posting data straight from/to ACDOCP, similar to what has been done for ACDOCA for actuals.

CO-PA (Profitability Analisys) allocations it is also an old request from most clients I had. This would allow applying the same rules used for actuals in the planning data, again, consistency… Last I heard this will be available in 1809 release.

Object based plan

Production orders, maintenance orders.

Consolidation

In RTC for release 1709 plan data is integrated to ACDOCC from ACDOCP for consolidation.

Central Finance

My experience with ACDOCP, as I said above, was in a Central Finance environment with Plan data being mapped from different source systems with different master data to one global financial environment leveraging the same mappings used by actuals. The key thing here is that we could use the CFIN mappings and also other S/4 mappings like BRF Rules in the planning data without having to work on the BW layer and mapping between BW and ABAP. Bear in mind that our loading process for plan data however, was entirely customised.

Hybrid approach

It is important to understand that the usage of ACDOCP is not a global decision. You can leverage classic/embedded BPC with ACDOCP altogether, and in the future the inverse way as well, such as exporting your planned production orders from ACDOCP to BPC to support financial planning, why not?

Wrap-up

There will be benefits and disadvantages in whatever option you chose, but the key thing is to find a balance between the current functionality available, the roadmap and how much you want to future-proof your solution.

References:

2270407 – S4TWL – Profit and Loss Planning, profit center planning, cost center planning, order planning, and project planning

1972819 – Setup SAP BPC optimized for S/4 HANA Finance and Embedded BW Reporting (aka Integrated Business Planning for Finance)

2081400 – SAP BPC Optimized for S/4 HANA Finance (aka: Integrated Bursiness Planning for Finance): Compilation of Information

2490888 – Enhance ACDOCC to Support End-User Extension

ACDOCP vs InfoCube in BPC Optimized