Skip to Content

S/4HANA Planning and Consolidation: Modelling Best Practice and use of ACDOCP

Hi folks,

Apologies in advance for the long question. We are embarking on a Proof of Concept using S/4HANA Planning and Consolidation (formerly BPC Optimized for S/4HANA), and are having some interesting conversations around correct/best practice modelling in this environment. We're hoping somebody here could suggest some pointers.

Firstly, is the intention that ALL plan data lives in ACDOCP? If not, what would determine the choice of planning provider?

To give a simple, common, concrete example, let's say I want to do Headcount planning, and maintain some drivers such as Pay Rate by Pay Grade, and multiply them to produce a cost which will then impact the P&L.

In BPC Standard, this would be pretty straightforward. I would do something like:

  • Add a new dimension for Pay Grade
  • Add some new members to an Account dimension to hold the driver rates
  • Make a new Headcount model
  • Set up some ETL to bring actuals in from the HR source system

In S/4HANA Planning and Consolidation, what is the equivalent?
Should I...

  1. Add a new column for Pay Grade be added to the ACDOCP table so I can hold data there, and build a new Virtual Provider cube on top?
  2. Modify an existing cube like /ERP/SFIN_V20 and build a different Agg. Level to split out Headcount functionality?
  3. Create a stand-alone planning cube which is not on top of ACDOCP at all?
  4. Something completely different?

Should the actuals from the external source system be pulled into ACDOCA?

Even for the standard concent built on /ERP/SFIN_M01, what factors determine whether we should write back to SFIN_V20 (on ACDOCP) or SFIN_R01 (not on ACDOCP)?
I am looking for a logical "why?" rather than technical "how?" answer... I understand the role of paramater /ERP/P_0INFOPROV in this context.

Secondly, with regards to external (non-SAP) systems, I have seen recommendations that no more than 20% of data should be external. I understand that S4 should not be treated as if it were an actual BW system, but am curious as to the technical basis for this. Is it 20% by record count? By DB table size? Is this primarily for performance reasons? Doesn't this depend on how many concurrent users are processing transactions?

In situations where external systems are being used, e.g. for reference prices, is the suggestion that this should be treated in the BW fashion, setting up ETL and pulling it into a DSO? Or set up a BPC Local Provider? Or migrate this over into native S4 equivalents?

Kind Regards,


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Sep 12, 2017 at 11:33 PM

    Hi Elliot, long question, long answer...

    The whole direction around ACDOCP is still a mystery to be honest. From what I understood, ACDOCP is intended to be most commonly used in ECC processes that allows some sort of planning functionality such as production orders... If you're on S/4 1610 onward you will notice ACODCP being used in miscellaneous processes such GL allocations as well.

    I'm currently using ACDOCP but the reason for that is not based on planning functionality but simply because we're on a Central Finance environment and wanted to leverage the same mappings/derivations from actuals when loading plan data from source systems (BPC, Flat file, BW-IP). This could be achieved in the BW layer as well, but as currently there is no standard process of integrating plan data to S/4, we decided not to use BW at all in the loading process. Such process involves SDA's, HANA procedures and ABAP so data is read from source system, mapped/derived, without any staging, straight to ACDOCP for downstream reporting. Furthermore, ACDOCP is in sync with ACDOCA, which means that CO-PA and customer fields are automatically generated in ACDOCP.

    Bear in mind that master data is almost the same for actuals and plan and they are maintained in the same place (MDG), e.g.: company code, customer master, material master etc... - THIS IS MANDATORY when saving data to ACDOCP.

    The alternatives your drew for the headcount example, are mixing up the concepts. ACDOCP works with the Account Based principle, along Multiple currencies and quantities, embedded BPC it's totally flexible, it can be account based, can be key figure based or both..

    In your case, where you do have a planning process, you should consider NOT using ACDOCP at all for the sake of flexibility on modelling and master data and also performance, as the PAK will leverage HANA pushdowns only for BW based models.

    Below is my attempt to put everything is perspective:

    1. When using ACDOCP - Actuals and plan master data are maintained in the same place
    2. ACDOCP does not leverage "provisional" master data, unless you go and maintain in the master tables
    3. ACDOCP is account based - if you need a rate account - you will need to create a GL account for that (Item 1)
    4. ACDOCP does not leverage PAK Hana performance

    To deicide if that is saved to ACDOCP or R01 you'd need to change a Bex Variable for InfoProvider check here:

    Also, if ACDOCP is necessary for whatever reason, consider implementing a hybrid approach - where planning is executed using BW/BPC and integrated to ACDOCP afterwards.

    Now for the question around External systems, the reason for that is because you don't want to overload your operational system with non-operational stuff such as planning. In case you have huge amounts of data and need to concentrate everything in a single environment you should look at having a separate instance for that.

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Lucas,

      You are right and the "Write Back to ERP" section of the SAP's material should be updated for the sake of clarity :) as it mentions these "two" options for retraction:

      1. Store plan data in BW (SFIN_R01) and use the retraction workbooks for further calculations in CO or...

      2. Store plan data in ACDOCP (with a note that this table is currently "isolated" in ERP and no further calculation is possible).

      But, as you mentioned, a third option (or workaround for the ACDOCP isolation) can be considered by using the same "retraction" workbooks to actually copy ACDOCP data to CO tables for further calculations until ACDOCP gets integrated.

      Thanks for pointing that out.