Skip to Content

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

Sep 12, 2017 at 09:52 PM


avatar image

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,


10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Best Answer
Lucas Costa 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.

Show 5 Share
10 |10000 characters needed characters left characters exceeded

Thanks Lucas, I appreciate the quick response!

The main message I'm taking away here is to not use ACDOCP in our case at all, which is in line with what I was hoping to hear. Just wanted to make sure I wasn't missing a fundamental benefit of using it.

I had already read the thread you linked explaining how to change the data saving, but I was really after an explanation of how we would even arrive at that conclusion/decision in the first place, which you have definitely helped with.

With your comment on "you don't want to overload your operational system with non-operational stuff such as planning", I can't help but think, "Isn't that the whole point of S4 BPC? To add planning to the operational (well... just Finance) system?".

As for the master data needing to be the same in ACDOCA/P, surely for planning purposes we will almost always be making use of additional plan master data, such as accounts to hold drivers, alongside the actual GL accounts? I thought we could get away with just maintaining a delta InfoObject, and modifying the HANA Views provisioning the InfoObjects in the plan cubes (e.g. /ERP/MATERIAL) to include a Union with the relevant tables from the new InfoObject. Is that still valid?

Either way, I am hearing "Don't bother with ACDOCP", and will proceed along the 'usual' Embedded style approach one would take in a standalone BW. Given that, does this still seem like a sensible/appropriate use of Optimized?

Thanks again,



"Isn't that the whole point of S4 BPC? To add planning to the operational (well... just Finance) system?".

You need to weigh that S/4 usually is an operational system, will deal with supply chain, sales etc. It's not a good idea to overload that with stuff that will be used for reporting for example. BW exist for this. If you're only adding planning it's ok, but you mentioned loading actuals from third party, then wouldn't be a good idea.

Around the master data, there's no way to get away with it. ACDOCP is an ABAP table. If you go and check the GL Account field for example, it has the same data element as ACDOCA which means it will check for master data (SKA1) when saving. If the value doesn't exist in SKA1 it will fail. This workaround would work using BW objects (aDSO, Cubes).

The optimised is a good start as it provides good example around modelling, but it's quite simple and hardly will be enough in terms of planning. If you need to develop a lot on top of it, I'd recommend creating from scratch using the new stuff such as aDSOs, Composite providers etc.


Very interesting and relevant topic. I'm trying to get more visibility about the ACDOCP X "SFIN_R01" roadmap with SAP as I get mixed messages as well.

Complementing the list:

5. ACDOCP can't re-use the allocations in CO whereas "SFIN_R01" can be retracted to CO

6. ACDPCP is now supported as a data source for plan data consolidation in S/4HANA 1709


Hi George,

Point 5 is actually inaccurate. The delivered content will allow you to retract data from either R01 or V20 (Virtual Cube based on ACDOCP) to CO-OM. If CO-PA allocation required, only via custom development .

The roadmap from SAP in terms of allocations, last I heard of, is to run allocations on top of ACDOCP by 2018.




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.