Skip to Content

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

 

 

 

13 Comments
You must be Logged on to comment or reply to a post.
  • Hi Lucas

    It’s informative. We are doing a 1709 on Prem implementation and am confused with the Cost and PCA planning options available. BPC is not an option. Though the classic planning options of CCA and PCA are available it seems it will written to the traditional totals table and not acdocp. The Q is what to do ?

    Kartik

    • Although the blog was based on 1609, It hasn’t been much improvement in 1709. If BPC is not an option, you’d have to stick with the classic tables I am afraid.

  • Hello Lucas,

     

    Nice blog and very informative.  A quick question I had, I am contemplating  to add a custom dimension similar to Data Source as available in Standard version, can I add this directly to ACDOCP table and later to Planning Virtual Provider and Aggregation level?

    Do you have any other ideas to track the flow of data within BPC using ACDOCP table?

     

    Regards,
    Sachin

  • Hello,

    Thanks for the details.

    Please guide where I am going wrong – I have been able to upload entries in ACDOCP using FINPLAN_API_POSTDATA. We are not using BPC or BW but my understanding is that the Apps like Cost Centers – Plan/Actual should show the Plan column with values. I am able to see the Actual but Plan column remains blank. Is BPC mandatory?

    Regards,

    Ankit

    • Hi Ankit, that’s because the CO planning features as far as I know are still reading the data from the classic CO tables and not ACDOCP – check the session “Road Map” in this blog. Although this was in the roadmap, I am really uncertain whether SAP is spending any time in this.

      In order to see the data in CO, I recommend you using the classical CO transaction for planning. KEPM for example.

      If you want to plan using let’s say AO with ACDOCP, you definitely need a BPC license to do so. And is are standard content to move the data from ACDOCP (or any planning cube for what matter) to CO-OM.

    • Hi Ankit not sure if you resolved this issue already but I had this same issue and what worked for me was to access the backend filter which the front end FIORI app (which has an underlying bex query) uses. In there you need to set the filter variable to read plan data from ACDOCP instead of R01.

      Cheers,

      Nish

  • Hi Lucas,

    Is it possible to bypass the master data validation ? My customer is loading future planned data and they use fictitious materials/customers ?  Is there anywhere we can change the message control from E to W ? In Fiori we cannot see the error message work area

    Regards,

    Hu Ghee

  • Hi All,

    We are with the same problem right now, it seems that ACDOCP is not fully connected as we thought.

    When we load from BPC 11 Embedded to S4/HANA (Rel 1809) using the Fiori app ‘Import Financial Plan Data’ (Flat file), the table ACDOCP is loaded successfully. However, the standard reports on S4/HANA are still reading the old tables (COSP for example for CO/FM) and the retractions tx as FMCI_COPY is still moving the data from the old tables as well.

    Is there a way to do only one retraction and covering all case uses of the budget?

    Regards