With this blog post you will learn which factors and circumstances have an impact on the data load of table ACDOCU in an On-Premise scenario.

The Release from Universal Journal task helps to release the reported financial data from the universal journal for consolidation purposes. The level of granularity coming from Universal Journal (ACDOCA) via the Release Task has a major impact on the performance/runtime of the Release task itself and on the data volume being posted into ACDOCU table.

The reported financial data is then the basis for all subsequent consolidation tasks (like Currency Translation, Validation, Reclassification, etc.) and the data volume being processed by the several automatic consolidation tasks heavily influences the response time and resource consumption (memory and CPU).

So, when implementing Group Reporting – as early as possible in the project – the granularity of the transferred data from ACDOCA into ACDOCU should be analyzed. If some additional characteristics are not needed by the business, these fields should not be taken over into Consolidation, to reduce data volume and hence potentially have better performance and lower resource consumption.

It will be always a tradeoff between business requirements and data volume/performance.

1 Challenge – High Data Granularity vs. Data Volume

SAP S/4HANA Finance for group reporting offers several options/technologies for data entry of reported financial data.

In the integrated scenario, where the consolidation units receive the reported financial data via the ‘Release from Universal Journal’ task from the Universal Journal Table (ACDOCA), the full granularity of data is available in the ACDOCA records (including the additional characteristics) can be taken over into the Group Reporting journals table ACDOCU. The additional characteristics are the following fields: being available in ACDOCA and ACDOCU.

Whereas some customers are interested in having this very detailed data in the Group Reporting application, there are other customers, who are – from a consolidation business perspective- not interested in having them or only interested in having some of them.

The level of granularity coming from ACDOCA via the Release Task has a major impact on the performance/runtime of the Release task itself and on the data volume being posted into ACDOCU table (with document type 0F and posting level blank). This dataset is then the basis for all subsequent consolidation tasks (like currency translation, validation, reclassification, etc.) and the data volume being processed by the several automatic consolidation tasks heavily influences the response time and resource consumption (memory and CPU).

So, customers, when implementing Group Reporting, should- as early as possible in the project- think about which (additional) fields they need to have transferred from ACDOCA into ACDOCU for their business. If some additional characteristics are not needed by the business, they should not be taken over into Consolidation, to reduce data volume and hence to potentially have better performance and lower resource consumption.

It will be always a tradeoff between business requirements and data volume/performance.

2 How to Reduce Data Volume in ACDOCU?

2.1 Reduce Data Volume during Data Release Task

By default, during the Release Task, all information available in ACDOCA for the so-called ‘Group Reporting additional characteristics’ will be kept, when the relevant records in ACDOCU are created.

The additional characteristics can be found in the customizing (SPRO) via this path: SAP S/4HANA for Group Reporting -> Master Data -> Define Consolidation Master Data Fields. (Refer to the product assistance Define Master Data for Consolidation Fields)

o.P. Release 2020: IMG Transaction ‘Define Consolidation Master Data Fields

2.1.1 S/4HANA Release oP 2020 and higher

Starting with the OP Release 2020, the option ‘Aggregate Data on Release’ is available in that transaction.

o.P. Release 2020: IMG Transaction ‘Define Consolidation Master Data Fields: Details

As mentioned, in the F1 help for this field, when the field ‘Aggregate Data on Release’ is selected, this has two major impacts:

1. Impact on Volume and Data Granularity: The marked additional field is not (more) filled during the Release Task and the Release task aggregates over all values being posted with that field in the source table ACDOCA. This can have a tremendous impact on data volume decrease. The level/percentage of data volume aggregation depends on the number of distinct values being posted in ACDOCA table.It is possible to mark more than one field with that flag. So, the overall data reduction depends on the distribution and combination of data in ACDOCA posted with those fields.Simple Example:
   
2. Impact on Reporting Drill-Trough Possibilities: When you show the field as a dimension in reporting, it will obviously have initial values for the data that originally comes from ACDOCA.Also, as explained in the F1 help shown above, if you deselect this checkbox, the drill-through to journal entries displays incorrect results for postings in prior periods, where the aggregation was active.
   If you select this checkbox, the drill-through to journal entries displays incorrect results for postings in prior periods, where the aggregation was inactive.Remark: For being able to mark the option ‘Aggregate Data on Release’ also for fields that have not marked the field ‘Master Data possible’, it is necessary to implement the correction of SAP Note 3001188.

2.1.2 S/4HANA oP Release 1809 and 1909

The option ‘Aggregate Data on Release’ is only available in the aforementioned SPRO transaction with oP Release 2020.
For customers running S/4HANA Finance for group reporting on lower on-Premise Releases, the same functionality can be achieved by using a modification via a so-called Pilot Note. The relevant SAP Note is 2840676 – Read from Universal Document: Higher degree of aggregation required.
Customers need to open a Support ticket and ask for being added as a Pilot customer to this Note, in case they want to make use of this option.

For on-Premise Releases 1809 and 1909, there is one additional impact:
Impact on Reporting Drill-Trough Possibilities: The function “jump to journal entries” will only show those journal entry line items from accounting in which this field was initial. Line items with non-initial values in this field are ignored.
This means, that the drill-through works as expected, you cannot select such a field as a column or row in your report.

Note:
When upgrading from a source Release 1809 or 1909 – where this modification (Pilot Note) was active- to a target Release (2020 or higher), customers need to make sure, that those additional fields, that were entered in the Z-table (ZFINCS_SUPPADDLC) in the source Release are marked with ‘Aggregate Data on Release’ in the SPRO transaction ‘Define Consolidation Master Data Fields’ in the target Release to keep the same granularity of data.

2.2 Reduce Data Volume during automatic posting tasks

For the Group Reporting automatic posting tasks (like currency translation or reclassification) the customer has the option to keep the level of detail for the additional characteristics or to aggregate over these fields during the automatic task processing. The relevant option is ‘Enable Inputs’.

Again, this setting is made in the relevant IMG transaction ‘Define Consolidation Master Data Fields’.

Things to be considered:

• As mentioned in the IMG help shown in the below picture, the setting ‘Enable Inputs’ is not relevant for the Release Task. Release Task will not interpret this setting.
• Only when ‘Enable Inputs’ is marked, the system allows data entry in the field. E.g. user can post manual documents and enter a value for that field.
• Note the disabled fields that contain data integrated from the universal ledger ACDOCA (from the Release Task) are still available in analytics, but the subsequent processing that occurs in automatic tasks aggregates over disabled fields, meaning the integrated data entries are disregarded.

This setting can be made per additional characteristic in the IMG Transaction ‘Define Consolidation Master Data Fields’ via the option ‘Enable Inputs’. Again, this can have a big impact on the data volume being processed and created during such an automatic task.

o.P. Release 2020: IMG Transaction ‘Define Consolidation Master Data Fields’: Details

Here, a simple Example for the Currency Translation task shall illustrate the effect of ‘Enable Inputs’ on the automatic posting Task.

The below picture shows ACDOCU records. The first 5 data records were posted in Local Currency with the additional characteristic ‘Assignment Reference’ filled by the Release Task. The other data rows are the result of the Currency translation task.

In the transaction ‘Define Consolidation Master Data Fields’, the ‘Enable Inputs’ was marked for ‘Assignment Reference’. So, the currency translation is posted with the level of detail for the ‘Assignment Reference’.

SE16H – Table ACDOCU

The below picture shows the records in table ACDOCU. The first 5 data records were posted in Local Currency with the additional characteristic ‘Assignment Reference’ filled by the Release Task. The other data rows are the result of the Currency translation task.

In the transaction ‘Define Consolidation Master Data Fields’, the ‘Enable Inputs’ was NOT marked for ‘Assignment Reference. So, the currency translation posted aggregated for ‘Assignment Reference’ and hence, the level of granularity and the number of posted records is lower.

SE16H – Table ACDOCU

3 Which additional fields in ACDOCU are the main volume causers?

It is important to think about the requirements regarding additional fields coming through from Accounting via Release Task to the Group Reporting from the beginning of the implementation project. To optimize performance and to reduce data volume and resource consumption, only the fields required by the Consolidation business department should be transferred. Useless information should not be taken over to the Consolidation table ACDOCU. This is especially true for those (unnecessary) additional fields that have many distinct values and that are filled in many data records. Those are potentially high-volume causers.

The challenge is to identify those additional fields.

If the data has been transferred from ACDOCA to ACDOCU already (e.g. during test activities or during a Proof of Concept- PoC- activities) the resulting data in table ACDOCU can be analyzed e.g. by tools like SE16H or via relevant SQL/SELECT statements.

If customers want to analyze the data posted by the Release task in ACDOCU with the help of transaction SE16H and check how many distinct values per additional field exist, on the section screen the field ‘Group’ for that field can be used.

In the below example we look at the table ACDOCU with transaction SE16H and check the data distribution for the example additional field ‘Functional Area’ by marking field ‘Group’ and then we execute this analysis.

SE16H – Table ACDOCU

The outcome of this table analysis is shown in the next picture. For the analyzed data, there were 993 different/distinct values for the Functional Area posted in the ACDOCU records. Most of the values are only posted a few times (within some data records), whereas in 894.064 data records no Functional Area is recorded at all. So, in this example, this additional field Functional Area is typically no main causer for high data volume, because in most of the data records it is not filled at all.

SE16H – Table ACDOCU

For those fields that have many distinct values and that are filled in many/most of the data records, the consolidation business departments should check, whether the information is needed and if not so, the option ‘Aggregate Data on Release’ could be marked.

Typically selecting more than one of these ‘unnecessary’ fields, helps to achieve a higher aggregating factor, because the overall aggregating factor depends on the distribution/combination of the additional field values among all data records.

Important: The analysis is more effective by using appropriate SQL statements, that are run on the HANA database to analyze the combined distribution of the additional fields.

4 Which additional fields in ACDOCA might cause the biggest volume impact on ACDOCU data

There can be situations, where data in Finance (ACDOCA) already exists before customers think about implementing SAP S/4HANA Finance for Group Reporting on that system. Customers might wonder, how big the data volume will become in ACDOCU when the data is taken over via the ‘Release from Universal Journal task’.

For such cases, the considerations are very similar to the ones explained in the prior chapter 3.

As a first step, it should be analyzed and checked which are the additional fields in table ACDOCA with the highest number of distinct values. This can be evaluated with the help of tools like SE16H or by running appropriate SQL/SELECT statements on ACDOCA.

Remark: In the Appendix below a sample SQL statement can be found that allows checking the number of distinct values per additional field in the ACDOCA table.

5 What needs to be considered when changing the ‘Aggregate Data on Release’ and ‘Enable Inputs’ options?

Remark: For S/4HANA on Premise Releases < 2020, the option ‘Aggregate Data on Release’ is not available in the IMG Transaction ‘Define Consolidation Master Data Fields’, yet. Instead, the option mentioned in chapter 2.1.2 (SAP Note 2840676/ Table ZFINCS_SUPPADDLC) can be used.

In an optimal situation, the best-fit settings for the customer’s environment are used from the beginning (before the Go-Live). That means, that after test activities and dependent on the consolidation business requirements for the relevant additional fields, the options ‘Aggregate Data on Release’ and ‘Enable Inputs’ have been enabled/disabled.

5.1 ‘Aggregate Data on Release’

However, there might be situations, where customers find out only after Go-live, that the data coming through from Accounting includes a too high level of detail for unnecessary additional fields and thus the customer wants to set the ‘Aggregate Data on Release’ option for certain additional field(s) after data has been posted already in ACDOCU with full level of detail.

Preferably, customers should check whether changing the setting is possible in the context of a fiscal year change. If detailed data exist in ACDOCU for certain additional fields in the current fiscal year already and a customer wants no longer to store that level of detail for that additional field in the next year, there is the possibility to mark the option ‘Aggregate on Carryforward’ in the IMG transaction ‘Define Consolidation Master Data Fields’.

Marking that option is technically only possible when the ‘Enable Inputs’ is enabled for that field as well.

Release 2020: IMG Transaction ‘Define Consolidation Master Data Fields’: Details

After the relevant additional field’s values have been aggregated during BCF, it would be a good starting point to set ‘Aggregate Data on Release’ after the BCF, so that in the new fiscal year both, the BCF data in period 000 and the reported financial data coming from Release task (data on document type 0F) in current periods of the new fiscal year do not more store the level of detail for that field.

If the change for the option ‘Aggregate Data on Release’ needs to be made during a fiscal year, there are some dependencies to be considered:

• As mentioned in the prior chapters, changing that option has an influence on the drill-through capabilities for that field in analytical apps/reports. The drill-through to journal entries might display incorrect results for postings in prior periods, where the aggregation was active/inactive
• In analytical apps/reports, there might be a mixture of aggregated and not aggregated data when the field is shown as a dimension in the app/report. However, when the relevant additional field(s) are not shown as reporting dimension, the field is aggregated anyway
• Some consolidation tasks (can) operate on a cumulative level (YTD), like Currency translation and Integration task (only relevant when old reporting logic is used). In such tasks, the already existing data from prior periods (including the higher level of detail) on document type 0F will be read and processed and hence a mixture of detailed and not detailed data will be processed. The customers need to test the results carefully before making any changes in production.

5.2 ‘Enable Inputs’

Typically the need to disable that option for certain additional field(s) comes together with the need of disabling the option ‘Aggregate Data on Release’ after it was detected that the level of detail coming from Release task is not needed and causes high data volumes.

From the point in time, when the ‘Enable Inputs’ option is disabled, no data can be entered any longer on that additional field and the automatic posting tasks will no longer create documents with that level of detail and will instead aggregate over that field.

Also, when ‘Enable Inputs’ is disabled, the automatic consolidation tasks (like reclassification or currency translation) will read the processing-relevant ACDOCU data by aggregating over that field. In situations where highly granular data exists and consolidation tasks might run into memory resource issues, disabling this option for the relevant additional field typically will reduce the resource consumption.

Again, changing this option has an impact on reporting/analytics when this field is used as reporting dimension as mentioned in prior chapters.

Preferably, customers should check whether changing the setting is possible in the context of a fiscal year change. If detailed data exist in ACDOCU for certain additional fields in the current fiscal year already and customer wants no longer to store that level of detail for that additional field in the next year, there is the possibility to mark the option ‘Aggregate on Carryforward’ in the IMG transaction ‘Define Consolidation Master Data Fields’.

Marking that option is technically only possible, when(as long as) the ‘Enable Inputs’ is enabled for that field as well.

When changing this setting during the current year, there is not the full benefit in terms of data volume reduction possible, as tasks that are reading cumulative data will still read and process the granular data of the prior periods.

Especially for customers who are still using the old reporting logic and hence are still using the ‘Integrate Data into Consolidation Group’ task in the consolidation monitor, a change of the ‘Enable Inputs’ option in the middle of the fiscal year would not help to achieve the desired data reduction to a full extent for the data records created by that task (Data records with Record Type R).

This is because the Integration Task operates on cumulative data. The Integration task reads the Year-To-Date (YTD) records from ACDOCU, aggregates them (=creates totals records), and writes the aggregated YTD figures in the relevant execution period into the ACDOCU table with record type ‘R’ for all the relevant consolidation Groups in the processed cons. group hierarchy.

This means the processed data volume and hence the runtime will grow, the higher the period is, and the task will always read and process the granular data of the prior periods as well.

The results of the automatic posting tasks need to be tested carefully before making any changes in production.

APPENDIX

Below you find a Sample SQL statement (template) that, when executed, displays the number of distinct values for a certain company code, for a certain GL ledger, for a certain year and period in the ACDOCA table ordered by the number of values for each additional characteristic. The variables (<value>) need to be adapted according to the customer-specific situation.

SELECT COUNT( DISTINCT SFAREA ) AS CHARACTERISTIC, 'SFAREA' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RBUSA ) AS CHARACTERISTIC, 'RBUSA' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT SCNTR ) AS CHARACTERISTIC, 'SCNTR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT SBUSA ) AS CHARACTERISTIC, 'SBUSA' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KOKRS ) AS CHARACTERISTIC, 'KOKRS' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KONZS ) AS CHARACTERISTIC, 'KONZS' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT PRCTR ) AS CHARACTERISTIC, 'PRCTR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT SEGMENT ) AS CHARACTERISTIC, 'SEGMENT' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RFAREA ) AS CHARACTERISTIC, 'RFAREA' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RMVCT ) AS CHARACTERISTIC, 'RMVCT' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT AUFNR ) AS CHARACTERISTIC, 'AUFNR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT FKART ) AS CHARACTERISTIC, 'FKART' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT PSEGMENT ) AS CHARACTERISTIC, 'PSEGMENT' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KTOPL ) AS CHARACTERISTIC, 'KTOPL' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KUNNR ) AS CHARACTERISTIC, 'KUNNR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT LIFNR ) AS CHARACTERISTIC, 'LIFNR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT MATKL_MM ) AS CHARACTERISTIC, 'MATKL_MM' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT MATNR ) AS CHARACTERISTIC, 'MATNR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RASSC ) AS CHARACTERISTIC, 'RASSC' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT PS_POSID ) AS CHARACTERISTIC, 'PS_POSID' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT PS_PSPID ) AS CHARACTERISTIC, 'PS_PSPID' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT PPRCTR ) AS CHARACTERISTIC, 'PPRCTR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RACCT ) AS CHARACTERISTIC, 'RACCT' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT WERKS ) AS CHARACTERISTIC, 'WERKS' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT VKORG ) AS CHARACTERISTIC, 'VKORG' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT VTWEG ) AS CHARACTERISTIC, 'VTWEG' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT SPART ) AS CHARACTERISTIC, 'SPART' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT MATNR_COPA ) AS CHARACTERISTIC, 'MATNR_COPA' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT MATKL ) AS CHARACTERISTIC, 'MATKL' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KDGRP ) AS CHARACTERISTIC, 'KDGRP' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT LAND1 ) AS CHARACTERISTIC, 'LAND1' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT BRSCH ) AS CHARACTERISTIC, 'BRSCH' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT BZIRK ) AS CHARACTERISTIC, 'BZIRK' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KUNRE ) AS CHARACTERISTIC, 'KUNRE' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT KUNWE ) AS CHARACTERISTIC, 'KUNWE' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT RCNTR ) AS CHARACTERISTIC, 'RCNTR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
UNION SELECT COUNT( DISTINCT ZUONR ) AS CHARACTERISTIC, 'ZUONR' AS name FROM acdoca
WHERE RCLNT = '<client>' AND RLDNR = '<ledger>'
 AND RBUKRS = '<cc>'
 AND GJAHR = '<year>'
 AND POPER = '<period>'
 ORDER BY CHARACTERISTIC DESC

Summary/TakeAways

A number of factors and circumstances need to be considered to keep the data clean and thus optimize the performance. The blog post explains the options to influence data volume in ACDOCU in an On-Premise scenario.

For the Cloud version of this document, refer to KBA 3000154 – SAP S/4HANA Group Reporting – How to influence data volume in table ACDOCU – Cloud version

For more Group Reporting-related articles and community questions follow the tag SAP S/4HANA Finance for group reporting

If you have questions or feedback regarding the content of this article, leave a comment in the comment section below.