GRPL

Integration with Group Reporting Preparation Ledger
S/4HANA Cloud 2202 – 2208 – 2302

S/4HANA OP 2021 FPS1 – 2022 – 2022 FPS1 – 2023
March 2023, SAP Product Engineering
Public
Disclaimer
The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission of SAP.
Except for your obligation to protect confidential information, this presentation is not subject to your license agreement or any other service
or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or any related
document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms directions and
functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this
presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality. This presentation is provided
without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. This presentation is for informational purposes and may not be incorporated into a contract. SAP
assumes no responsibility for errors or omissions in this presentation, except if such damages were caused by SAP’s intentional or gross
negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from
expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates,
and they should not be relied upon in making purchasing decisions.
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 2

About this Presentation
Introductory Remark
Author SAP S/4HANA Product Engineering
Revision March 2023
About This document highlights the key new features of integration with group reporting preparation ledger.
It is non-exhaustive and cannot be used as a training document as is.
Screenshots Screenshots in this presentation are taken from S/4HANA Cloud.

In S/4HANA OP systems you may notice slight differences (especially menues and screens in the IMG).
As shown on the title slide, this presentation covers various releases, starting with the initial scope of integration with
group reporting preparation ledger delivered with S/4HANA Cloud 2202 up to the release S/4HANA Cloud 2302.
As functionality of integration with group reporting preparation ledger enhanced over time, screens may look a bit
different in the current release. As far as possible these changes over time are described in the presentation.
Release Information Release information in this presentation refers to S/4HANA Cloud releases.
For your orientation with regards to S/4HANA OP releases, please refer to the following information:
Feature S/4HANA Cloud Release S/4HANA OP Release
Initial scope of integration with GR preparation ledger 2202 2021 FPS1

Flexible assignment of companies to cons units 2208 2022
Field mapping for data release task 2302 2022 FPS1
Option to configure local currency and quantity source 2302 2023
Prepare
Content
Analyze Collect
Consolidate
Initial shipment with S/4HANA Cloud 2202 with Enhancements in 2208 / 2302
Special Topic – Flexible Derivation of Consolidation Units

S/4HANA Cloud 2208
Special Topic – Field Mapping for Data Release Task

S/4HANA Cloud 2302
Outlook – Group View on Accounting

Labs Preview
More Information
4
Prepare
Content
Analyze Collect
Consolidate

S/4HANA Cloud 2208

S/4HANA Cloud 2302

Labs Preview
More Information
5
Integration with Group Reporting Preparation Ledger – Short Comparison
„Classic“ Accounting Integration Integration with Group Reporting

Preparation Ledger Powerful
substitution
Posting in Accounting Ledger framework may use
Posting in Accounting Ledger „Group view on accounting context
Accounting Journal (ACDOCA)
accounting“ not
which is a Group Reporting Preparation Ledger for derivation
Posting without group reporting specific information possible due to Posting with group reporting specific information Analytical
(i.e. w/o filling cons unit, partner unit, FS item, subitem, …) missing info (i.e. cons unit, partner unit, FS item, subitem, … are derived capabilities such as
in accounting journal (ACDOCA). „group view on
via substitution during accounting posting) in ACDOCA.
accounting“
possible
Realignment
In case substitution rules were added or changed, the
Only if required
realignment task reprocesses the derivation of group reporting
information and posts adjustments in ACDOCA using a special
group reporting reclassification document type.
Only simple
derivation rules
Data Release Task supported Lightweight
Data Release Task release task
Group Journal (ACDOCU)
During data release consolidation specific information working in

During data release data is simply transferred to group
(such as cons unit, partner unit, FS item, subitem, …) Heavy release incremental
journal (ACDOCU) without any further derivation.
is derived and persisted in group journal (ACDOCU). task working in mode
full mode only
New
Line Item Validation comprehensive
log
Consolidation Consolidation
Integration with Group Reporting Preparation Ledger – Schematic Overview
Initial Setup and Ongoing Configuration for Integration with Group Reporting Preparation Ledger
3 Consolidation Version Management 4 Consolidation Unit Master Data 14

Field Mapping for Data Release Task
Optionally Configure Source 15 16
Assign Group Reporting Activate Assign Company Define Custom Define
Field for Local Currency,
Preparation Ledger to „Accounting to Consolidation Fields for Group Field Mapping for
Group Currency, and
Quantity Consolidation Version Integration“ Unit Journal Data Release Task
1 2
Maintain From Year for Define Group 8 9
Preparation Ledger Reporting Accounting Trial
(upgrade customers only) Preparation Ledger Balance Data Release Task
(Inlcude GR Fields)
7
Maintain 5 11
G/L Account Manual Correction
Accounting Posting
Mapping to FS Item (Post/Import Group
(with Group Reporting
Journal Entries, Flex.
Field Derivation)
Upload or GRDC)
6Define Substitution
10 10
Rules for: Line Item Validation Line Item Validation
• Consolidation Units (Breakdown + (Breakdown + Group
• Partner Units
Accounting Journal Journal Validation,
• FS Items
Validation) incl. New Task Log)
• Subitems
i Tip: 13 12
Click on the green numbers (such as 1 ) in the graphic in order to navigate to the details on Realignment
the respective topic in the presentation. The numbers do not completely adhere to the Totals Validation
(if required)
technical sequence of steps, but focus on how the process can be understood most easily.
Use the button on the lower right hand corner of the details slides to navigate back to this
overview graphic. In some cases you have to use the button first to get back to an
…
overview slide from where you then can navigate back to this overview graphic. Accounting Journal Group Journal
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public
(ACDOCA) (ACDOCU)
7
Enable Group Reporting Preparation Ledger – SSCUI “Check Global System Settings”
From Year for (Group Reporting) Preparation Ledger
As of fiscal year 2023:

Integration with group reporting preparation ledger
1
Before fiscal year 2023:
„Classic“ accounting integration
1 The integration with group reporting preparation ledger is active in a system as of the „From Year for Preparation Ledger“. Before that group reporting relevant information such as financial
statement item or consolidation unit is not directly contained in the accounting journal but has to be derived when the accounting data is transferred to group reporting via release task.
i Note: Systems set up as of S/4HANA 2202 or later automatically have 1001 as “From Year for Preparation Ledger“. This cannot be changed.
With this setting, new systems automatically use integration with group reporting preparation ledger.
Systems upgraded to S/4HANA 2202 have empty value for “From Year for Preparation Ledger“. So customers have to enter the from year to enable the group reporting preparation ledger.
With this, upgrade customers have no day-1 impact and control when the integration with group reporting preparation ledger becomes active in their system.
Be careful: After maintaining the from year you cannot change it any more!
SAP recommends transition as soon as possible as further innovations depend on it. SAP furthermore recommends to choose a from year which did not yet start, so the derivation of group
reporting fields during accounting posting can start from the beginning of a fiscal year and does not have to be introduced by realignment.
SSCUI “Define Group Reporting Preparation Ledgers” – Part 1
1 As of S/4HANA 2202 a new SSCUI activity „Define Group Reporting Preparation Ledgers“ is available.
This can be found in „Configure Your Solution“ via: Finance → Corporate Close → Basic Settings → Define Group Reporting Preparation Ledgers
i Note: „Define Group Reporting Preparation Ledgers“ can only be launched when the „From Year for Preparation Ledger“ in the system is specified (i.e. is not initial).
Otherwise an error message will appear.

Create Group Reporting Preparation Ledger – Slide 1
1 Every accounting ledger that shall be used as source ledger for integration with group reporting preparation ledger needs to have an entry in the „Define Group
Reporting Preparation Ledgers“ table. By creating an entry in that table for an accounting ledger, this accounting ledger is designated as group reporting
preparation ledger. As of the „From Year for Preparation Ledger“ the system will derive group reporting relevant information (such as financial statement item,
consolidation unit, etc.) during accounting postings in such a ledger, and persist such group reporting relevant information in the accounting ledger.
2 To create an entry for an accounting ledger in this table you can either copy an existing entry („Copy As …“) and exchange the copied accounting ledger or you
create a new entry („New Entries“).

Create Group Reporting Preparation Ledger – Slide 2
1 2 3 4 5
Every „Group Reporting Preparation Ledger“ entry consists of:

1➢ A key „Config. ID“ (mandatory) Note: This „Config. ID“ won‘t be exposed anywhere else other than in this SSCUI.
2➢ An accounting ledger as „Group Reporting Preparation Ledger“ (mandatory). There can only be one entry per accounting ledger.
3➢ A consolidation chart of accounts „Consolidation COA“ (mandatory). With this the financial statement items are identified that may be used at accounting posting runtime.
→ A group reporting preparation ledger can only support a single consolidation chart of accounts.
➢
4 An „FS Item Mapping Version“ (optional). Besides the given G/L chart of accounts, consolidation chart of accounts and fiscal year period, this identifies the G/L account –
FS item mapping that shall be used to derive FS items during accounting posting in case the derivation does not happen via substitution rules (for details see here).
➢
5 An „FS Item Attribute Version“ (optional). Besides the given fiscal year period this will be used to identify time and version-dependent selection and/or target attribute values
of an FS item to be used in substitution rules. Please note that the usage of these attributes in substitution rules is future scope and not yet available.
S/4HANA Finance Group View
Consolidated Group Reporting
• Adding S/4HANA external companies
from other sources thru flexible file
Consolidated Consolidated Group View upload, GRDC, etc.
• Currency translation at closing rate
• Eliminations and consolidations
Accounting-side group reporting preparation

• Following group accounting principle
Group Reporting Financial
• Aggregation of companies in a common
Ledger 2 Consolidation Unit Statement (FS) …
Preparation Ledger item
period definition and cons CoA
• GC translated at transaction spot rate
• Group Cur: EUR • Group objects filled (consolidation unit,
• Consolidation CoA Y1 FS item, partner unit, subitem)
• Accounting: IFRS
• Calendar: K4
• Functional Cur: EUR • Functional Cur: EUR • Functional Cur: EUR • Functional Cur: USD
• CoA DE • CoA FR • CoA CH • CoA US
Accounting-side entity close

• Following local accounting principles
Ledger 1 German Entity French Entity Swiss Entity US Entity • Perspective of the single company,
not intended for company aggregation
• Local Cur: EUR • Local Cur: EUR • Local Cur: CHF • Local Cur: USD
• CoA DE • CoA FR • CoA CH • CoA US
• Accounting: HGB • Accounting: FR GAAP • Accounting: CH GAAP • Accounting: US GAAP
• Calendar: K4 • Calendar: K4 • Calendar: K4 • Calendar: 4-4-5

Extension Ledgers as Group Reporting Preparation Ledgers
4
2
1 3
Remark for extension ledgers:

1 In this example accounting ledger „E1“ is an extension ledger of „DS“, which itself is an
extension ledger of the standard ledger „0L“.
2 Extension ledgers (e.g. „E1“) may also be configured to be group reporting preparation
ledgers …
1 3 … but ALL underlying ledgers (here „DS“ and „0L“) have to be group reporting preparation
ledgers as well …
4 … and the group reporting preparation ledger entries of all accounting ledgers of such a
„ledger stack“ need to have the same attribute values for consolidation COA, FS item
mapping version, and FS item attributes version.
i In case your changes violate these rules the system will not allow you to save.

Removing a Group Reporting Preparation Ledger
Delete the entry of a group reporting preparation ledger:

1 In principle it is possible to delete the entry of a group reporting preparation ledger, but there are some exceptions when this is not possible.
You cannot delete group reporting preparation ledger entries …
➢ … that were delivered as content by SAP (you may adjust such an entry but not delete it).
➢ … that are still in use, i.e. that are assigned as group reporting preparation ledger to any consolidation version. This ensures that any accounting ledger
that is assigned to a cons version as group reporting preparation ledger is also configured to be a group reporting preparation ledger.
➢ … of an accounting ledger that is the underlying ledger of another accounting ledger which is also a group reporting preparation ledger. This ensures
that in case an extension ledger is a group reporting preparation ledger, all underlying ledgers are group reporting preparation ledgers as well.

Carryforward Reclassification Settings for Realignment Function
1 2
Opening reclassification subitems:
1 On the second level of the „Define Group Reporting Preparation Ledgers“ SSCUI …
2 … you can define opening reclassification subitems. In the example above, we assign subitem 950 („Reclass.“) as carryforward reclassification subitem to the
regular carryforward subitem 900 („Opening“) of subitem category 1 („Transaction Type“) for realignment purpose.
i In case of correction of the FS item derivation (e.g. instead of the balance sheet FS item „BS A“ the balance sheet FS item „BS B“ shall be derived),
transaction data has to be adjusted via reclassification process in realignment task. Reclassification of transaction data on a carryforward subitem (e.g. „900 –
Opening“) shall not happen on the same carryforward subitem, otherwise closing balance of previous year would not match opening balance of next year any
more. Therefore the reclassification shall happen on separate carryforward reclassification subitems. For an example see here.
SSCUI “Define Versions” – Part 1
Fields Specific for Integration with Group Reporting Preparation Ledger
i For the integration with group reporting preparation ledger several new fields were introduced in the
consolidation version management. All of them are optional fields from the perspective of a consolidation
version and are only relevant in case the data release task shall be used in the consolidation version to transfer
data from a group reporting preparation ledger to the group journal.
1 The first one is the „Preparation Ledger“. For integration with group reporting preparation ledger, a group
reporting preparation ledger has to be assigned to the consolidation version as „Preparation Ledger“.
Currency and fiscal year variant settings of company codes in that ledger as well as assignments of company
codes to companies affect the option to choose the “Transfer from Universal Journal” option in the consolidation
unit master data, which is required for integration with group reporting preparation ledger.
Note: The value help only shows the accounting ledgers which are configured to be group reporting preparation
ledgers.
1 2 The second one is the “Local Currency Source”. This determines from which source field in the group reporting
2 preparation ledger the data release task transfers amounts as local currency values to group reporting.
3 Note: This field is introduced with S/4HANA 2302. Before that “M – Functional Currency” is hard coded as
4 source for local currency. If this field is not filled the functional currency is used as source for local currency.
3 The third one is the “Group Currency Source”. This determines from which source field in the group reporting
preparation ledger the data release task transfers amounts as group currency values to group reporting.
Note: If this field is not filled the release task will not transfer any group currency values, only in case the local
currency of a consolidation unit is the same as the group currency of the consolidation version, the release task
will copy the local currency values it transfers also as group currency values. For other consolidation units the
currency translation has to be used to fill the group currency values.
4 The fourth one is the “Quantity Source”. This determines from which source field in the group reporting
preparation ledger the data release task transfers quantities to group reporting.
Note: This field is introduced with S/4HANA 2302. Before that “A – Quantity” is hard coded as source for
quantity. If this field is not filled “A – Quantity” is used as source for quantities.
i The availability of fields on this screen varies depending on the „From Year for Preparation Ledger“, the fiscal
year in your global parameters when you launch the „Define Versions“ SSCUI activity, the version setting
regarding plan data integration, and the release. The different cases are described on the next slide.
16
SSCUI “Define Versions” – Part 2
Availability of Fields Specific for Integration with Group Reporting Preparation Ledger
Case 1: „Define Versions“ launched with fiscal year as of Case 2: „Define Versions“ launched with fiscal year Case 3: „Define Versions“ launched for versions with
„From Year for Preparation Ledger“ for versions without before „From Year for Preparation Ledger“ or “From „Plan Data Integration“
„Plan Data Integration” Year for Preparation Ledger” is initial
2 3 5
1
1 The fields which are specific for integration with group reporting 3 In a fiscal year before the “From Year for Preparation Ledger” or in case 4 In consolidation versions where „Use Plan Data Integration“ is active
preparation ledger are available in the consolidation version management. the “From Year for Preparation Ledger” is initial, the „classic“ accounting data is read from the accounting planning journal (ACDOCP). For the
integration is used. For this only the „Source Ledger“ is relevant. accounting planning journal the integration with group reporting
Note: As of S/4HANA 2302 the fields “Local Currency Source” and preparation ledger is not supported.
“Quantity Source” are available in addition.
Therefore only this field is available when „Define Versions“ is launched
2 The „Source Ledger“ is not relevant for the integration with group reporting
with a fiscal year before the „From Year for Preparation Ledger“, while 5 Therefore only the „Source Ledger“ field is visible (same as for „classic“
the fields „Preparation Ledger“ and „Group Currency Source“ (which accounting integration). But in case of plan data integration this is
preparation ledger, but only for „classic“ accounting integration and for plan you see ôn the left screenshot) are not visible. independent of the fiscal year in the global parameters and the „From
data integration. When the integration with group reporting preparation Year for Preparation Ledger“.
ledger is activated, this field appears read only for information purpose in
case a source ledger was assigned to the consolidation version. If this is
not the case the field does not show up at all

Consolidation Unit Master Data for Integration with Group Reporting Preparation Ledger
Overview
i For integration with group reporting preparation ledger two things
need to be done in consolidation unit master data:
1 1) A company needs to be assigned to the consolidation unit.

As of S/4HANA 2208 any company may be assigned to a
consolidation unit. The same company may be assigned to
several consolidation units, which is a prerequisite to split up
data from a single company to several consolidation units, e.g.
for a full fledged segment consolidation. The assignment is time
dependent.
Before that release the assignment of company to consolidation
unit took place automatically, but only worked for a company
which had the same key as the consolidation unit (same as for
“classic” accounting integration and accounting integration in
planning versions).
For further details on the assignment of companies to
consolidation units see here.
1
2 2) The “Transfer from Universal Journal” option has to be chosen.
Only in case the “Transfer from Universal Journal” option is
chosen for a consolidation unit in a consolidation version and
2 fiscal year period, the data monitor in that consolidation version
and fiscal year period will provide a data release task for the
consolidation unit to transfer data from accounting journal to
group journal.
Several prerequisites have to be met, in order to be able to
choose the “Transfer from Universal Journal” option for a
consolidation unit. In case any of these prerequisites is violated
the option is inactive and an information icon is shown. Clicking
this information icon will show the missing prerequisite(s).
Fur further details on the prerequisites and activation of the
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public “Transfer form Universal Journal” option see here. 18
Assignment of Company to Consolidation Unit – Part 1
Flexible Assignment of Company to Consolidation Unit for Integration with Group Reporting Preparation Ledger
i In earlier releases the company assignment to consolidation unit

was a kind of „automatic assignment“ which could not be
influenced. Whenever a company existed in accounting which had
the same key as the consolidation unit this company was
„assigned“ to the consolidation unit.
1 As of S/4HANA 2208 release the company assignment to

consolidation unit can be explicitly maintained.
This assignment is time-dependent. So it can change over time and

also there might be time intervals where no company is assigned to
a consolidation unit.
Any company existing in accounting may be assigned (no matter

what the key of this company is). Whenever a key identical
company exists, this is suggested as default when a consolidation
unit is created, but the assignment may be changed or removed.
1 The same company may be assigned to several consolidation

units. This is actually the logical prerequisite to split up data from
one company to several consolidation units in order to reflect for
example segment contributions of these companies.
Every consolidation unit may have assigned only one company at a

time. This helps to avoid that data from multiple companies ends up
in the same consolidation unit as intercompany elimination of that
data would not be possible within the consolidation unit.
i Note: In case the company assignment is changed for fiscal year

periods where accounting postings already took place, the
consolidation unit information for the already existing transaction
data has to be corrected by using the realignment function or by
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public importing correction data. 19
Automatic Assignment of Company to Consolidation Unit for “Classic” Accounting Integration
1 Before the „From Year for Preparation Ledger“ the company

assignment cannot be influenced.
2 Therefore the company field is read only in that case.
1 Whenever a key identical company exists, this is automatically

“assigned” to the consolidation unit.
3 Whereas when such a key identical company does not exist,

no company is assigned to the consolidation unit.
2
i Note: Even in the rare case when a key identical company is
not yet existing when a consolidation unit is created, but is
created later, it will nevertheless automatically be „assigned“
to the consolidation unit.

Automatic Assignment of Company to Consolidation Unit for Accounting Integration in Planning Versions
1 Plan versions don’t support group reporting preparation ledgers.

Hence, company assignment to consolidation units in planning
consolidation versions as of the „From Year for Preparation
Ledger“ behaves in principle the same as in every consolidation
version before this from year (see previous slide).
I.e. the company assignment cannot be explicitly maintained but in

case a key identical company exists, it is automatically „assigned“
to the consolidation unit.
2 The only difference is, that the company assignment is not even
shown read only, but the company field is not shown at all.
1
This happens because a planning consolidation version may
share the same consolidation units attribute special version as a
non planning consolidation version, in which a flexible company
assignment could be maintained.
2
By showing the automatically „assigned“ key identical company in
the planning consolidation version and listing the non planning
versions (which actually have a different company assignment)
3 when clicking on the other affected versions link in the context box
may be confusing. Therefore the company assignment is not
shown at all in this case.
3 But clicking the button for „Missing Prerequisites for Transfer from
Universal Journal Option“ will show „Company <XXX> does not
exist.“ in case this is the missing prerequisite for the integration.

Summary
Maintenance of Company Assignment to Consolidation Units - Summary
Time before Time as of

„From Year for Preparation Ledger“ „From Year for Preparation Ledger“
2 2 Company assignment is maintained automatically

Consolidation Version with key identical company (if existing)
is a Planning Version
Company assignment is maintained automatically → Not even displayed in “Define Consolidation Units” app
with key identical company (if existing)
→ Read only display in “Define Consolidation Units” app 1 Company assignment is maintained by user
Consolidation Version (time-dependent any company may be assigned)
is not a Planning Version
→ Writing enabled in “Define Consolidation Units” app
i The graphic above summarizes the differences in the assignment of companies to consolidation units, which were described
on previous slides.
1 Only in consolidation versions which are not a planning version and as of the “From Year for Preparation Ledger” the mapping
of companies to consolidation units may be maintained and with that flexible derivation of consolidation units is possible.
2 In all other cases the assignment of companies to consolidation units cannot be maintained explicitly but is established
automatically based on key identical companies and consolidation units. Flexible derivation of consolidation units is not
possible in these cases.

Configuration of Integration with Group Reporting Preparation Ledger for Cons Unit – Part 1
Integration with group reporting preparation ledger
1 requires the selection of the universal journal integration
option „Transfer from Universal Journal“ on consolidation
unit master data.
When the „Transfer from Universal Journal“ option is
selected for a consolidation unit in a given consolidation
version and fiscal year period, the data monitor will show
a data release task in that version and fiscal year period.
i In the „Define Consolidation Units“ app this option is only

active and can be chosen if all of the subsequent checks
were successful (more details on subsequent slides):
➢ The consolidation version has a group reporting
preparation ledger assigned.
➢ A company is assigned to the consolidation unit.
➢ A company code is assigned to that company.
1 ➢ The “Local Currency Source” results in the same
currency for the assigned company code(s) in the
group reporting preparation ledger of the
consolidation version as the local currency of the
consolidation unit.
➢ If a „Group Currency Source“ has been maintained
for the consolidation version (this is optional), the
assigned company code(s) have to provide the same
currency for this source field in the group reporting
preparation ledger of the consolidation version as the
group currency of the consolidation version.
➢ The assigned company code(s) have the same
fiscal year variant in the group reporting
preparation ledger of the consolidation version as
the fiscal year variant of the consolidation version.
2 If any of the before listed checks is not successful, the

„Transfer from Universal Journal“ option is inactive and
2 cannot be chosen.
In that case an information icon is shown. Clicking on
that icon opens a pop-up which shows the missing
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public prerequisites for an integration with group reporting23
preparation ledger.
Prerequisites for Integration with Group Reporting Preparation Ledger for Cons Unit – Part 1
First Prerequisite – Group Reporting Preparation Ledger Assigned to Consolidation Version?
i First prerequisite is that the consolidation version has a group reporting
preparation ledger assigned. This defines later on when the release task is
executed, from which accounting ledger transaction data shall be transferred.
1 In our example we maintain cons unit master data in consolidation version “Y10”.
2 In SSCUI (Configure Your Solution → Finance → Corporate Close → Basic

Settings → Define Versions) consolidation version “Y10” has assigned the group
reporting preparation ledger “0L”.
3 In case no group reporting preparation ledger is assigned to the consolidation

version (as here in our example for version “Y11”) the “Transfer from Universal
Journal” option in cons unit master data maintenance is not active and the
1
information “No accounting source ledger is maintained for version Y11.” is
shown as missing prerequisite.
2 3

Second Prerequisite – Company Assigned to Consolidation Unit?
Second prerequisite is that a company is assigned to the consolidation unit. In the initial scope of integration
i with group reporting preparation ledger (S/4HANA 2202) this had to be a company with the same key as the
1 consolidation unit and it was assigned to the consolidation unit automatically in case it existed. This is required
because in S/4HANA 2202 any kind of universal journal integration could only take place between a cons unit
and a company which had the same key. This is shown in the screenshots on this slide.
1 In our example we maintain cons unit master data of a cons unit with the cons unit key “1010”.
In SSCUI “Define Company” (Configure Your Solution → Organization → Organization→ Define Company) a
2 company with the same key “1010” exists.
In case no company with the same key as the cons unit key exists (as here in our example the key “9999”) the
3 “Transfer from Universal Journal” option in cons unit master data maintenance is not active and the information
“Company 9999 does not exist in accounting.” is shown as missing prerequisite.
i As of S/4HANA 2208 a more flexible mapping of company to consolidation units was introduced. With this any
company may be assigned to a consolidation unit. The same company may even be assigned to several
consolidation units to allow splitting up the data from one company to these consolidation units, e.g. for full
fledged segment reporting. For more details see here.
So as of S/4HANA 2208 it is checked whether a company is assigned to the consolidation unit and if this is not
the case “No company “Transfer from universal journal not possible without specifying a company.” is shown
as missing prerequisite.

Third Prerequisite – Company Code(s) Assigned to Company?
i Third prerequisite is that at least one company code is assigned to the company, which is
assigned to the consolidation unit. The mandatory organizational entity, accounting data is
1 posted to, is the company code. In case no company code is assigned to a company, the
release task could not find any data to be transferred.
1 In our example we maintain cons unit master data of a cons unit with the cons unit key
“1010”.
2 In SSCUI (Configure Your Solution → Organization → Organization→ Assign Company

Code to Company) company code “1010” is assigned to company “1010”.
3 In case no company code is assigned to the company which is assigned to the consolidation
unit (as here in our example the company “1090”), the “Transfer from Universal Journal”
option in cons unit master data maintenance is not active and the information “No company
code is assigned to company 1090 in accounting.” is shown as missing prerequisite.

Fourth Prerequisite – Currency of Local Currency Source of Company Codes and Local Currency of Cons Unit Matches? – Slide 1
i Fourth prerequisite is that the currency of the local currency source of the
assigned company codes is the same in the group reporting preparation
ledger of the consolidation version as the local currency of the consolidation
unit.
In the initial scope of integration with group reporting preparation ledger

(S/4HANA 2202) the functional currency is hard coded as source key figure
1 for local currency. Therefore the integration is only possible if the functional
currency of all relevant company codes in the relevant ledger is the same as
the local currency of the cons unit.
As of S/4HANA 2208 the local currency of a consolidation unit may change

2 in period 001 of a fiscal year. Therefore the check as of this release takes
into account the time dependent local currency of a cons unit.
As of S/4HANA 2302 the local currency source may be configured on

consolidation version level. Therefore as of this release this check compares
the local currency of the consolidation unit with the currency which is
provided by the local currency source in the assigned company code(s).
1 In our example we have the local currency “EUR” in the master data of cons
unit “1010” …
2 … and we maintain the master data of this cons unit in consolidation

version “Y10”.
3 This consolidation version “Y10” has assigned the group reporting

preparation ledger “0L” in version management (Configure Your Solution →
Finance → Corporate Close → Basic Settings → Define Versions).
3 4
4 With this ledger “0L” and the company code(s) assigned to the company
which is assigned to the consolidation unit (so in our example company
code “1010” → see previous slide) …
1 4 2
1 … we look into the SSCUI for defining currency settings for ledgers and 3 When we look into the dialog “Currency Types” in that SSCUI we see
company codes (Configure Your Solution → Finance → General Settings that currency type “10” is the “Company Code Currency”.
→ Currencies → Define Currency Settings for Ledgers and Company
4 Looking once more in the dialog “Company Code Settings for the
Codes). In this we see for company code “1010” and ledger “0L” …
Ledger” we can see that the “Company Code Currency” for company
2 … currency type “10” assigned as functional currency type in the dialog code “1010” in ledger “0L” is “EUR”, so EUR is the functional currency.
“Company Code Settings for the Ledger”. As this is also the local currency of the cons unit (see previous slide) the
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public fourth prerequisite is fulfilled. 28
1 In case the functional currency for any of the relevant

company code(s) in the relevant ledger (in our example
company code “1210” has for ledger “0L” the functional
currency type “10 – Company Code Currency” which is
“EUR”) …
2 … differs from the local currency of the consolidation unit

(in our example cons unit “1210” has the local currency
“USD”) …
3 … the “Transfer from Universal Journal” option in cons unit

master data maintenance is not active and the information
2 “Functional currency of company codes differs from local
currency of CU.” is shown as missing prerequisite.
As of S/4HANA 2302 where the local currency source may

be configure on consolidation version level, the message
for the missing prerequisite would be: “Local currency (LC)
differs from LC source in accounting.”
3

Fifth Prerequisite – Group Currency of Consolidation Version Matches Group Currency Source of Company Code(s)? – Slide 1
Fifth prerequisite is that if a „Group Currency Source“ has been maintained for the consolidation
i version (this is optional), the assigned company code(s) have to provide the same currency for
1 this source field in the group reporting preparation ledger of the consolidation version as the group
currency of the consolidation version.
When the data release task is executed in a consolidation version which has a “Group Currency
Source” maintained, it will transfer accounting data from that source key figure as group currency
values (besides the accounting data from the local currency source key figure as local currency
values). Therefore, the integration is only possible if the group currency of the underlying
accounting data matches the group currency of the consolidation version.
1 In our example we stick to cons unit “1010” …
2 … and its company “1010” with the assigned company code “1010” (the latter not shown on this
slide, but as derived in the example of third prerequisite) …
3
3 … and the maintenance of cons unit master data in consolidation version “Y10”.
2
4 For consolidation version “Y10” “Group Currency” is maintained as group currency source and
“0L” as group reporting preparation ledger in the “Define Versions” SSCUI.
5 With this ledger “0L”, the company code(s) assigned to the company “1010” (in our example this is
company code “1010” as we saw in the example of third prerequisite) and the source key figure
“Group Currency” we look into the SSCUI for defining currency settings for ledgers and company
codes (Configure Your Solution → Finance → General Settings → Currencies → Define Currency
Settings for Ledgers and Company Codes). In this we see for company code “1010” and ledger
“0L” group currency “USD” assigned in the dialog “Company Code Settings for the Ledger”.
6 As this is the same as the consolidation version group currency, this integration prerequisite is
fulfilled.
6 5
4

Fifth Prerequisite – Group Currency of Consolidation Version Matches Group Currency Source of Company Code(s)? – Slide 2
1
1 Looking at the same example but now from perspective of
consolidation version “D10” …
4
2 … which has the group currency “EUR” instead of “USD”.
3 The dialog “Company Code Settings for the Ledger” of SSCUI
“Define Currency Settings for Ledgers and Company Codes” still
provides the group currency “USD” for the relevant combination of
Ledger “0L”, company code “1010” and source key figure “Group
Currency”.
4 As this differs from group currency “EUR” of consolidation version

“D10”, it violates the fifth prerequisite for integration with group
reporting preparation ledger. So the “Transfer from Universal
Journal” option in cons unit master data is deactivated with the
2 information “Group currency (GC) of version D10 differs from GC
source in accounting.”

Sixth Prerequisite – Fiscal Year Variant of Company Code(s) and Consolidation Version Matches? – Slide 1
Sixth prerequisite is that the assigned company code(s) have the same fiscal year variant in the
1 i group reporting preparation ledger of the consolidation version as the fiscal year variant of the
consolidation version. This is because the fiscal year periods including special periods are
integrated 1:1 from accounting into group reporting, therefore no conversion can take place. An
additional parallel ledger for own statutory close could be used in accounting by company codes
with a fiscal year variant different from the corporate fiscal year variant in group reporting.
1 We stick to our example of cons unit “1010” …
2 … and its company “1010” with the assigned company code “1010” (the latter not shown on this
slide, but as derived in the example of third prerequisite) …
3 … and the maintenance of cons unit master data in consolidation version “Y10”.
4 For consolidation version “Y10” “K4” is maintained as fiscal year variant …
3 5 … and “0L” as group reporting preparation ledger in the “Define Versions” SSCUI.
2 6 With this ledger “0L” and the company code(s) assigned to the company “1010” (company code
“1010” as we saw in the example of third prerequisite), we look into the SSCUI for assigning fiscal
year variants to ledgers and company codes (Configure Your Solution → Finance → General
Settings → Currencies → Fiscal Year → Assign Fiscal Year Variants to Ledgers and Company
Codes). In this we see for company code “1010” and ledger “0L” fiscal year variant “K4” assigned.
As this is the same as the fiscal year variant of the consolidation version, this integration
prerequisite is fulfilled.

Sixth Prerequisite – Fiscal Year Variant of Company Code(s) and Consolidation Version Matches? – Slide 2
1 Looking at the same example but now from perspective of

consolidation version “D10” …
1 2 … which has the fiscal year variant “V9” instead of “K4”.

3 The SSCUI “Assign Fiscal Year Variants to Ledgers and Company
Codes” still provides the fiscal year variant “K4” for the relevant
4 combination of Ledger “0L” and company code “1010”.
4 As this differs from fiscal year variant “V9” of consolidation version

“D10”, the sixth prerequisite for integration with group reporting
preparation ledger is not fulfilled and the “Transfer from Universal
Journal” option in cons unit master data maintenance is not active
and the information “Fiscal year variant of company codes in
accounting and version D10 differ.” is shown as missing prerequisite.
i Notice: If there is more than one missing prerequisite figured out by

the system, all of them are shown in the pop-up, as you can see in
this example.
This is applicable to prerequisites four, five, and six. Whereas if

2 prerequisites one, two, or three are missing, the subsequent
prerequisites cannot be checked any more (if for example no
company is assigned to the cons unit, prerequisites three to six
cannot be checked any more). Therefore, these prerequisites may
only show up one by one in the missing prerequisites pop-up, with
the consequence that after solving the displayed missing prerequisite
the next missing prerequisite may be shown.
3

Configuration of Integration with Group Reporting Preparation Ledger for Cons Unit – Part 2
Comparison of Consolidation Unit Master Data Settings between the cases of Integration 1 The universal journal integration options are the
same but the checks that have to be successful
with Group Reporting Preparation Ledger and „Classic“ Accounting Integration: to get the „Transfer from Universal Journal“
option active are different to some extent.
2 For „classic“ accounting integration a deviating
Consolidation Unit Master Data in the case of Integration with Group Reporting Preparation Ledger
fiscal year variant from that of the consolidation
version may be entered.
While in the case of integration with group
reporting preparation ledger, the deviating fiscal
year variant field is inactive as it is prerequisite
2 for the integration that the company codes
which are „assigned“ to the consolidation unit
1
have the same fiscal year variant in the group
reporting preparation ledger of the consolidation
version as the fiscal year variant of the
consolidation version.
3 For „classic“ accounting integration the source
Consolidation Unit Master Data in the case of „Classic“ Accounting Integration field for the local currency key figure and the
source field for the group currency key figure is
configured in the consolidation unit master data.
While in the case of integration with group
reporting preparation ledger these cannot be
2 3 configured individually on consolidation unit
level but may be configured on consolidation
1 version level. For the source for local currency
this is the case only as of S/4HANA 2302.
Before that release this cannot be configured at
all, instead the amounts in functional currency
are used for local currency (hard coded).

Group Reporting Fields Derivation in Accounting – Part 1
Accounting Posting with Group Reporting Field Derivation – Slide 1
i During accounting posting in a group reporting i These group reporting fields cannot be entered
preparation ledger, the system tries to fill and persist directly, but they have to be derived via substitution
seven group reporting fields: rules during accounting posting.
➢ Company This is why you don’t see these fields e.g. in the “Post
➢ Consolidation Unit General Journal Entries” app, as shown above.
➢ Partner Unit A combination of SAP delivered and customer
➢ Consolidation Chart of Accounts defined substitution rules is used for the derivation of
➢ Financial Statement (FS) Item the group reporting fields.
➢ Subitem Category Further details are explained here.
➢ Subitem
Accounting Posting with Group Reporting Field Derivation – Slide 2
6 4
5 3
1 When you created an accounting posting a pop-up with a success 4 … or adding the group reporting fields in the settings dialog …
message is shown. On this popup you have the option to trigger the … to the layout …
display of the posted document in the “Manage Journal Entries” app.
5
6 … which may also be saved as view.
In this app the derived group reporting fields can be shown …
i Note: As the group reporting fields cannot be entered directly, you can’t see
2 … by selecting the appropriate (group reporting preparation) ledger (in the derived values in the “Entry View” but you have to choose a ledger view.
our example “Ledger 0L”)…
i The group reporting fields can also be activated in the accounting “Trial
3 … and either navigating to the line item details … Balance” app. This is shown here.
Group Reporting Fields Derivation Flow – Overview
Substitution Substitution Rules with Business Context Substitution Rules with Business Context
Derivation
Sequence
Rules for „GRPL Core Fields“ „GRPL Subassignments to FS Item“

Accounting
Field SAP Defined Customer Defined SAP Defined SAP Defined Customer Defined SAP Defined
Derivation Initialization Rules Rules Correction Rules Initialization Rules Rules Correction Rules
Derivation Target  Derivation Source

Source & Target
Company Company Code Subitem

Derivation
Category FS Item → Breakdown Cat.

Consolidation Unit Company Substitution Rule(s) If Inconsistent: Revert
Subitem Sender Field Substitution Rule(s) BDT0: Clear; BDT2: Default
Cons Chart of Acc. GR Prep Ledger Setting
Partner
FS Item GL Account Mapping Substitution Rule(s) If Empty: &NOMAP Trading Partner Substitution Rule(s) BDT0: Clear; BDT2: Default
Unit
i Guiding principles of group reporting field derivations during i For integration with group reporting preparation ledger two substitution business contexts were introduced to derive group reporting
accounting posting: specific information during accounting posting:
• The group reporting fields are embedded into the “accounting • GRPL core fields: This derives company, consolidation unit, consolidation chart of accounts, and financial statement item
interface” and derived for all accounting postings including • GRPL subassignments to FS item: This derives subitem category, subitem, and partner consolidation unit
data from Central Finance. Overall sequence:
• Group reporting fields are exclusively derived by substitution, • For each line item of an accounting posting all active substitution rules for accounting journal are executed.
i.e. no manual entry of these fields needed or allowed. • The substitution rules are bundled according to their business context and the business contexts have an order defined by SAP:
• First the substitution rules with a business contexts for accounting field derivation are executed (the sequence within these is
• Group reporting data consistency is ensured where required
not relevant for group reporting).
by reverting fields back to SAP defined derivation result, or by
• After that the substitution rules with the business context “GRPL core fields” are executed.
clearing fields or setting a default according to the breakdown
• And last but not least the substitution rules with the business context “GRPL subassignments to FS item” are executed.
type.
• We don’t stop/block accounting postings and don’t raise Sequence of substitution rules within a business context:
group reporting specific messages during accounting posting. • First the SAP defined initialization rules are executed in the same order as the target fields are displayed in the chart above (i.e.
first for company, then for consolidation unit, consolidation chart of accounts, …).
• We accept group reporting inconsistencies in accounting data • Then customer defined substitution rules are executed. Regarding the sequence of customer defined substitution rules see here.
from breakdown category definitions and group reporting line- • Finally the SAP defined correction rules are executed.
validations where we cannot prevent them at posting time. • The results of each individual substitution rule may be used as derivation source for any of the subsequent substitution rules.
• We enhanced line item validation task to check consistency
Resulting sequence of execution of substitution rules:
and identify the root cause of issues (see here).
• With this the substitution rules are executed in the sequence which is visualized with the arrows.
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public The group reporting field substitution rules mentioned above are executed in three places: 37
• Accounting journal posting, realignment of preparation ledger, and accounting balance carryforward
“Manage Substitution / Validations Rules – Journal Entries“ App – Slide 1
1 i As stated before, the group reporting fields cannot be entered
directly, but they have to be derived via substitution rules during
accounting posting.
A combination of SAP delivered and customer defined

substitution rules is used for this.
1 You maintain customer substitution rules for accounting postings

in the Fiori app „Manage Substitution / Validation Rules – Journal
Entries“.
Note: The subtitle „Journal Entries“ is important as there is

another Fiori app with a similar title: „Manage Substitution /
Validation Rules – Group Journal Entries“. In this app you won‘t
be able to maintain substitution rules for the accounting postings.
2
2 In this app you do not only create and maintain customer
substitution rules, but you can also see the SAP delivered
3
substitution rules (which you cannot change or delete).
3 There are SAP delivered substitution rules for all seven group
reporting fields.
i The following fields are available for customer substitutions to

overwrite the SAP predefined substitution rules:
3 ➢ Consolidation Unit
➢ Partner Unit
➢ Financial Statement (FS) Item
➢ Subitem
The remaining fields are accessed by SAP predefined rules only.
Further details are explained on the following slides.
“Manage Substitution / Validations Rules – Journal Entries“ App – Slide 2
1 To create a customer substitution rule for group

reporting fields derivation in accounting, …
2 … make sure that you select one of the following

business contexts in the “Create Rule“ dialog:
1) GRPL core fields

“GRPL” stands for “Group Reporting Preparation
Ledger”.
The “GRPL core fields” business context you use to
1 create substitution rules for:
• Consolidation Units
2
• FS Items
2) GRPL subassignments to FS item

This business context you use to create substitution
rules for:
• Partner Units
• Subitems
i It is not the ambition of this presentation to explain all

possibilities you have in defining your customer
substitution rules. But in order to give you an idea of the
options you have, you‘ll see three examples on the
following slides using different substitution types to
derive the consolidation unit during accounting posting.
You may skip this part by using the button.
Afterwards we explain how SAP delivered and
customer substitution rules work together and why two
different business contexts are required.
39
Customer Defined Substitution Rules – Examples
Example 1 – Rule Using Substitution Type „Substitute with Constant“
i This is a very simple, straight forward example of a substitution rule.
1 In the „Precondition“ section the criteria is defined, when this rule shall
take affect. In our example this is when the company code of the
posting is „4711“ and the segment is „1000_A“.
Note: You may use different fields or add additional fields to the
precondition (you have basically any context of the accounting posting
available) or you may even use functions (such as substring or
concatenate) in the precondition. Also there are many more operators
than „Equal To“ available.
1 2 In the „Substitution“ section you have to select „ConsolidationUnit“ as

„Target Field“ (note: This business context allows to substitute
consolidation units as well as financial statement items.).
3 As „Substitution Type“ in this example we have chosen „Substitute

with Constant“ …
2 3 4 4 … which allows us, to directly enter the consolidation unit value

„4711_A“ which shall be derived in case the precondition is met.
i As said this is a very simple example, which may end up in a huge

number of individual substitution rules. Therefore please also check
subsequent examples.

Example 2 – Rule Using Substitution Type „Substitute with Field / Function“ – Part 1
1 In this example the precondition is defined in a way, that the

substitution rule is only applied in case company and segment in the
accounting posting are not empty and the consolidation unit field is not
yet filled (e.g. by the SAP delivered rule of step 1 or a customer
defined rule which was already executed before).
1 2 Again we select „ConsolidationUnit“ as „Target Field“ in the

„Substitution“ section.
3 As „Substitution Type“ in this example we have chosen „Substitute

with Field / Function“ …
4 … and we chose a „Concatenate“ function, the details of which you‘ll

see on the next slide.
2 3 4

Example 2 – Rule Using Substitution Type „Substitute with Field / Function“ – Part 2
1
2 3
4
5
6
1 In the concatenation we define as first part the field value „Company“. So the conca- 6 As „Separator“ in the concatenation we define „_“.
tenated value will start with the company value from the accounting posting line item.
i Whenever the company and the segment are filled in the line item of an accounting
2 As second part we define a „substring“ function … posting and the consolidation unit has not yet been substituted, the concatenation will
take effect and provide values such as „4711_A“ or „ABC_C“.
3 … which takes the segment value of the accounting posting line item …
This example shows that with one substitution rule the derivation of many consolidation
4 … offsets 5 characters … units can be achieved.
5 … and then takes 1 character. As the segments in our system are „1000_A“, However the consolidation units in this case have to follow the naming convention of
„1000_B“, and „1000_C“, this substring function will result in „A“, „B“, or „C“ as the concatenation rule, company values may not be too long, so that the concatenation
„1000_“ is cut off by the offset. result does not exceed the consolidation unit field length (current limit: 6 characters, as
of S/4HANA 2302 enhanced to 18 characters), and the concatenation result may not
even exist as consolidation unit (in this case step 3 of the substitution would clear or
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public revert the value again). 42
Example 3 – Rule Using Substitution Type „Table Lookup“ – Part 1
1 In example 3 we use the substitution type „Table Lookup“.
2 The idea is that customers define in the extensibility framework a lookup table
with lookup criteria for the consolidation unit derivation as „Custom Business
Object“. In our example this is the custom object „YY1_DD_TEST“. When the
precondition of the customer substitution is met by the accounting posting, the
system searches with the relevant criteria from the posting in the lookup table
and returns a consolidation unit value that is then used as derivation result.
How this works in detail you‘ll see on the following slides.

1 2

1 1 Let‘s start with the definition of the lookup table. You define this 3 In our example we chose „Association to Business Object“ in order to
as custom business object via the Fiori app „Custom Business associate both with the already existing respective business objects for
Objects“ of the extensibility framework. company code and segment. With this we later on automatically get
value helps with all company codes and segments when we maintain the
2 In our example we defined two fields as lookup criteria: lookup table entries.
„Company Code“ and „Segment“. Note: The number and content
of the lookup criteria can be feely defined. Note: You can also use other types for the fields of your lookup table
(e.g. „Code List“ which allows to define a list of values that is later on
available as value help, or „Text“ which allows to freely enter texts during
maintenance of the lookup table entries).
4 As field for the lookup result we defined „Consolidation Unit“ which we

also assigned to the SAP delivered business object.
5 It is important that any field of the lookup criteria has to be maintained as

„Key“ field in the lookup table. This guarantees a unique lookup result.
Later on we‘ll see that for each key field of the lookup table a row in the
3 5 substitution rule definition will be created where the context of the
accounting posting has to be mapped to.
2
The field of the lookup result has to be maintained as non key field. Only
4 the non key fields of a lookup table may be used later on as lookup result
(i.e. „Source Field“) in the substitution rule definition.

1 Make sure that you switch on the „User Interface“ flag in the „General
Information“ of the custom business object definition.
This will result …
2 … once you published your custom business object …
3 … in two links on the „General Information“ tab of the custom business object
(which are only visible when you‘re not in edit mode).
4 With „Go To Generated UI“ link you can launch a generated UI where you can
maintain the lookup table entries. To have this link available however requires
that the users who shall maintain the lookup table entries have extensibility
authorization.
5 Therefore alternatively you can use the „Maintain Catalogs“ link to add the
generated UI for the custom business object to a business catalog.
1 6 This will result in a Fiori tile (with the title of your custom business object) on the
Fiori launchpad which then may be used by business users to launch the
maintenance of the lookup table entries without having extensibility authorization.
2
3
4 5

1 3 Note: You have to fill all key fields for every lookup table entry, i.e. in our example you
cannot create lookup table entries where only the company code or the segment is
filled.
2 In case you want to achieve different sets of lookup fields (e.g. company code –
segment, company code – segment – profit center, company code only) you have to
define multiple lookup tables and consume them in separate substitution rules.
4 Note: There is no check on the consistency of the lookup table entries from a
consolidation master data point of view. E.g. you may assign the company codes from
different companies (in our example „1210“ and „1710“ to the same consolidation unit
„DD“). In the master data of the consolidation unit you can only assign one of the
companies. Lookup results which are not consistent from master data perspective will
be cleared or reverted by step 3 of the consolidation unit substitution.
1 Independently from the way it was launched (either link in the „Custom Business
4
Objects“ app or Fiori tile), the generated UI is the environment in which the lookup
table entries are maintained. 3
2 By using filters you can easily find out which objects are linked in the lookup table
(e.g. in our example which consolidation units a company code is assigned to, or
which consolidation units are related to a certain segment).

4 Furthermore a row for every key field of the custom business object is created in the „Conditions“
section of “Select Source Field” popup, all of which have to be completed and cannot be removed.
5 In our example we map them with an „Equal To“ operator to the company code and segment of the
accounting line item. So at accounting posting runtime the system will identify the lookup table entry
with the given company code and segment, and will return the consolidation unit value of that entry
as substitution result. In case the result is not consistent from a master data perspective (e.g. the
consolidation unit does not have assigned the company of the accounting line item in the given fiscal
year period) the consolidation unit field will be cleared or reverted by step 3 of the derivation.
2
3
5
1 Once the lookup table has been defined as custom business object and published, it may
be used as source in a customer substitution rule with the substitution type „Table Lookup“. 4
2 The details screen of the source does not only contain the selection of the data source
(i.e. the custom business object) …
3 … but also the selection of the source field. As source field all fields of the custom business
object which are not part of the key are offered. This “Source Field” of the lookup table
provides the value which then results as “Target Field” in the substitution rule.

1 From the context of the

accounting posting the
company code “4711” …
2 … and the segment “1000_C”

are taken …
3 … to identify an entry in the

3 4 lookup table.
1
4 The resulting consolidation
unit “4711_C” from the lookup
table …
5 … is then used as
consolidation unit field value in
the accounting posting.
i Note: The consolidation unit

derivation happens
individually for every line item
of the accounting posting.
Consequently different line

2 items of the same accounting
document may end up in
5 different consolidation units.

Group Reporting Fields Derivation Flow – Details Slide 1
Substitution 1 Substitution Rules with Business Context Substitution Rules with Business Context
Derivation
Sequence

Accounting

Source & Target
2 Company 3 Company Code 4 5 Subitem

Derivation

6 Consolidation Unit 7 Company 8 Substitution Rule(s) 9 If Inconsistent: Revert
10 Cons Chart of Acc.11 GR Prep Ledger Setting 12 13
Partner
14 FS Item 15 GL Account Mapping 16 Substitution Rule(s) 17 If Empty: &NOMAP Trading Partner Substitution Rule(s) BDT0: Clear; BDT2: Default
Unit
1 The substitution rules with the business context “GRPL core fields” derive the following group reporting fields: 10 • Consolidation chart of accounts
2 • Company 11 • The consolidation chart of accounts is derived from the group reporting preparation ledger settings by an
SAP defined rule, which looks up the consolidation chart of accounts which is assigned in the group
3 • The company is derived from the company code of the accounting posting by an SAP defined rule, which looks up the reporting preparation ledger configuration to the ledger of the accounting posting.
company the company code of the accounting posting is assigned to.
12 • Customers cannot influence this derivation.
4 • Customers cannot influence this derivation.
13 • Therefore there is also no need for an SAP defined correction rule.
5 • Therefore there is also no need for an SAP defined correction rule.
14 • Financial statement item
6 • Consolidation unit
15 • Step 1: An SAP defined substitution rule takes the G/L chart of accounts and the fiscal year and period
7 • Step 1: An SAP defined substitution rule takes the derived company from the previous step and checks if this company is from the accounting posting, the consolidation chart of accounts and the FS item mapping version from the
assigned in the fiscal year and period of the accounting posting to exactly one consolidation unit. If this is the case this
consolidation unit is derived in that step. If the company is assigned to several consolidation units in the fiscal year and period group reporting preparation ledger settings of the ledger in which the accounting posting takes place and
of the accounting posting, if it is not assigned to any cons unit, or no company was derived in the previous step, the with this tries to identify an FS item from the G/L account to FS item mapping. For details on this see here.
consolidation unit field is empty after this step. If an FS item is found this is the result of step 1, otherwise the field is still empty after step 1.
16 • Step 2: Customers have the possibility to derive FS items by customer defined substitution rule(s). This is
8 • Step 2: Customers have the possibility to derive consolidation units by customer defined substitution rule(s). This is especially
relevant if the data from one company shall be splitted to several consolidation units, as the previous step will not provide any especially relevant if no G/L account mapping was maintained, or in case the FS item shall not be derived
derivation value because of the multi-assignment of the company. For examples for such customer defined substitution rules from an G/L account directly, but from a combination of several fields (e.g. G/L account and functional
see here. area for a P/L statement by nature of expense (DE=Umsatzkostenverfahren)).
17 • Step 3: An SAP defined substitution rules checks if there is an FS item derived after step 2. If the FS item
9 • Step 3: An SAP defined substitution rules checks the consolidation unit value derived after step 2 with regards to master data
consistency. In case the company for which the accounting posting is created is assigned in the master data of the derived field is still empty it is either filled with the FS item “&NOMAPBS” or “&NOMAPPL” depending on whether
consolidation unit in the given fiscal year period, the value is consistent and therefore is kept. If this is not the case (i.e. if the the G/L account of the accounting posting is a balance sheet account (→ &NOMAPBS) or a profit and loss
derived consolidation unit either has no company or a different company assigned in the given fiscal year period, or the derived account (→ &NOMAPPL). This helps to identify and correct data with missing FS item derivation.
value does not even exist as consolidation unit) the value is not consistent and step 3 reverts the field to result of step 1, i.e.
there is either no consolidation unit value, or the consolidation unit with unique assignment of the given company in the
resulting journal entry of the accounting posting. This has to be fixed afterwards either by using the realignment function or by
importing correction data.
Group Reporting Fields Derivation Flow – Details Slide 2
Substitution Substitution Rules with Business Context 1 Substitution Rules with Business Context
Derivation
Sequence

Accounting

Source & Target

Derivation
2 Category3 FS Item → Breakdown Cat. 4 5

Consolidation Unit Company Substitution Rule(s) If Inconsistent: Revert
6 Subitem 7 Subitem Categ. → Sender Field 8 Substitution Rule(s) 9 BDT0: Clear; BDT2: Default
Partner
FS Item GL Account Mapping Substitution Rule(s) If Empty: &NOMAP 10 11 Trading Partner 12 Substitution Rule(s) 13 BDT0: Clear; BDT2: Default
Unit
1 The substitution rules with the business context “GRPL subassignments to FS item” derive the following 10 • Partner unit
group reporting fields: • Similar to the consolidation unit derivation in the business context „GRPL core fields“ there is a partner consolidation unit derivation in the
2 • Subitem Category business context „GRPL subassignments to FS item“. The partner consolidation unit derivation is also following a three step approach.
The differences compared to the consolidation unit derivation are in step 3, while steps 1 and 2 are working basically the same in both
3 • The subitem category is derived from the breakdown category the derived FS item has assigned by an derivations.
SAP defined rule, which looks up the subitem category in the breakdown category which is assigned to
the FS item which was derived by the substitution rules with business context “GRPL core fields”. 11 • Step 1: In case the trading partner for which the accounting posting takes place is assigned as company to a single consolidation unit in
• Customers cannot influence this derivation. the consolidation unit master data, then this consolidation unit is derived as partner unit. If the trading partner is assigned as company to
4 several consolidation units or not assigned to any consolidation unit, then no value is derived for the partner unit. As a result, the field for
5 • Therefore there is also no need for an SAP defined correction rule. partner unit stays empty in step 1.
6 • Subitem 12 • Step 2: Customer substitution rule(s) overwrite the partner unit value derived in step 1. This is especially relevant if the trading partner is
7 • Step 1: An SAP defined substitution rule identifies the sender field of the subitem category derived in assigned as company to several consolidation units. As explained in step 1, the system doesn’t derive a partner unit value in this case.
previous step (e.g. the subitem category “1 – Transaction Types” has the sender field “1 – Transaction Instead, the field is empty after step 1. So, it’s the job of the customer defined substitution rules to derive the partner unit value in step 2
Type” assigned. Therefore the transaction type value of the accounting posting is used as subitem. based on the context of the accounting posting. For example, this context could be the partner company, partner segment, partner profit
center, and/or partner functional area. In this way, step 2 is crucial for deriving a partner unit value in the flexible derivation of partner
8 • Step 2: In case customers have defined an own subitem category without a sender field (as e.g. there units. Regarding the modelling of customer defined substitution rules there is no principal difference to the derivation of consolidation
is no appropriate sender field supported), then step 1 cannot derive a subitem. Therefore customer
defined substitution rules are required to fill the subitem. E.g. customers may define a subitem category units, but of course in this case “PartnerConsolidationUnit” is used instead of “ConsolidationUnit” as target field in the substitution rule.
“Aging” with different aging categories (e.g. 1-3 months, 3-6 months, 6-12 months. <12 months) as One especially interesting aspect regarding derivation via lookup tables is explained on the next slide. If step 1 provided a partner unit
values. In accounting the aging information is filled via reclassification. This information could be value already, then there’s no need for the substitution rules in step 2. In other words, if you don't assign a trading partner to several
transferred to a statistical FS item with the subitem category “Aging” by substitution rules. partner units, you don't need to define any substitution rules yourself. Instead, the system derives the partner unit correctly.
13 • Step 3: In case there is a partner consolidation unit value filled after step 2, step 3 checks the consistency of that value with regards to the
9 • Step 3: In case there is a subitem value filled after step 2, step 3 checks the consistency of that value
with regards to the breakdown type. In case the breakdown category of the FS item derived in the breakdown type. In case the breakdown category of the FS item derived in the „GRPL core fields“ derivation has the breakdown type „0“
„GRPL core fields“ derivation has the breakdown type „0“ (i.e. „no breakdown“) regarding subitem, (i.e. „no breakdown“) regarding partner unit, step 3 clears the derived partner consolidation unit value. In case no partner consolidation
step 3 clears the derived subitem value. In case no subitem has been derived after step 2, but the unit has been derived after step 2, but the breakdown type regarding partner unit is „2“ (i.e. „breakdown required, if blank, the default
breakdown type regarding subitem is „2“ (i.e. „breakdown required, if blank, the default value is used“), value is used“), step 3 fills the default value. Note: A validation of the derived partner consolidation unit against the company assigned in
step 3 fills the default value. consolidation unit master data does not happen in any of the cases.
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public i • The SAP defined substitution rules for subitem category and subitem derivation, and partner unit correction require information on 50
the breakdown category of the finally derived FS item. Therefore all three steps of the FS item derivation have to be completed for
this, which requires a separate business context, so that the final FS item derivation result can be used as source information.
Customer Defined Substitution Rules
Orchestration of Customer Substitution Rules – Part 1
i During accounting posting the consolidation unit derivation will be processed (as any other group
reporting related derivation) in case all of the following preconditions are fulfilled:
➢ Posting is taking place in a group reporting preparation ledger.
➢ The fiscal year of the posting is not before the „From Year for Preparation Ledger“.
➢ The company code of the accounting line item is assigned to a company.
➢ The company is assigned at least to one consolidation unit in the given fiscal year period.
1 After executing the SAP delivered substitution rule in step 1 of the consolidation unit derivation
all customer defined substitution rules with the business context „GRPL core fields“ which are in
status „Active“ are executed in step 2 of the derivation.
2
Besides disabling substitution rules which shall not be executed any more you have no influence
on the rules which are executed. But there are several ways to orchestrate the execution of
customer defined substitution rules:
1 1. Influence execution sequence of substitution rules:
3 Substitution rules are executed in a certain sequence. You can display this sequence by clicking
„Analyze Rules“ …
2 … and choosing „GRPL core fields“ as „Event“ in the “Manage Substitution and Validation Rules
– Journal Entries” app.
3 Besides some logical grouping according to dependencies between the substitution rules (which
we can basically ignore for the consolidation unit derivation), the customer defined substitution
rules are executed in alphanumerical order of their rule name.
Tip: Consequently you can influence the sequence of rule execution by choosing respective rule
names (or starting rule names with a sequence number).
i The sequence of substitution rules has an effect on the derivation result only in case different
substitution rules provide different derivation results. In that case the derivation result of the last
substitution rule which is executed wins.

Customer Defined Substitution Rules
Orchestration of Customer Substitution Rules – Part 2
1 2. Influence execution of substitution rule by preconditions:

By defining preconditions in the substitution rules you can influence which
1 substitution rules take effect in which situation.
In case you want to use for example more than one lookup table
representing different sets of lookup fields, you may use preconditions as
shown on the left hand side to determine which lookup table is used
depending on which lookup criteria is filled in the accounting posting.
Another example is, if you want to use different sets of substitution rules in
different group reporting preparation ledgers. In that case you may use a
precondition field „Ledger“ in order to execute different substitution rules
depending on the ledger the accounting posting takes place in.
The same applies to time-dependent rule execution for which you may use
for example „Fiscal Year“ or even a combination of „Fiscal Year“ and „Fiscal
Period“ as precondition.
2 3. Define overwriting:
A third option is to enable or disable the „Overwrite“ flag in the „Substitution“
2 section.
In case the consolidation unit value has already been derived by a previous
substitution rule, a subsequent rule will have no effect in case the
„Overwrite“ flag is not enabled.
i With the definition and the orchestration of substitution rules you‘ve a very
powerful toolset at hand, to influence the consolidation unit derivation result.

Maintain G/L Account Mapping to FS Items
Step 1 – Define Time- and Version-Independent G/L Account Mapping Containers
1 4
i The G/L account mapping to FS items is maintained in
a two-step approach.
In a first step time- and version-independent mapping
containers are maintained. These mapping containers
carry the G/L account mapping information as such,
i.e. which G/L account is mapped to which FS item.
This is explained on the current slide.
In a second step time- and version-independent
mapping containers are assigned as of a fiscal year
and period to a consolidation version. This is stored in
the G/L account mapping special version of a
consolidation version. This is explained on the next
slide.
1 Time- and version-independent G/L account mapping

containers are defined and maintained in the “Map FS
Items with G/L Accounts” app.
2 A mapping container is identified by a mapping ID, a

2 revision (which is a kind of versioning of the mapping
ID), a G/L chart of accounts, and a consolidation chart
of accounts. So a mapping container is always based
on G/L accounts of a single G/L chart of accounts and
FS items of a single consolidation chart of accounts.
3 In the details page of a mapping container G/L

accounts of the G/L chart of accounts of the mapping
container are assigned to FS items of the
consolidation chart of accounts of the mapping
container. Of course each G/L account can only be
3 assigned to a single FS item, but several G/L
accounts could be assigned to the same FS item.
4 G/L account mapping containers may also be created

and maintained with the “Import FS Item Mappings”
app.
Maintain G/L Account Mapping to FS Items
Step 2 – Assign G/L Account Mapping Containers
1
1 In a second step the “Assign FS Item

Mappings” app is used …
2 … to assign a G/L account mapping

container as of a fiscal year and period to a
consolidation version.
3 For each combination of G/L chart of
accounts, consolidation chart of accounts,
consolidation version, and fiscal year and
period, a single G/L account mapping
container may be assigned.

Integration with Group Reporting Preparation Ledger – FS Item Derivation
Logic of FS Item Derivation via G/L Account Mapping during Accounting Posting
i The integration with group reporting
2 1 preparation ledger supports two ways to derive
FS items during accounting posting. #1, we
derive FS item via the existing G/L account
mapping infrastructure. #2, the result can be
overwritten by substitution. Prerequisite for #1:
3 you configure an FS item mapping version for
a group reporting preparation ledger (see
here). To derive the FS item the following
happens:
4 1 The G/L chart of accounts and the fiscal year

and period come from the context of the
accounting posting.
2 The FS item mapping version and the

consolidation chart of accounts come from the
group reporting preparation ledger entry of the
accounting ledger in which the accounting
5 posting is taking place.
3 This identifies the time- and version dependent

G/L account – FS item mapping assignment
that shall be used to derive the FS item from
the G/L account in the accounting posting.
4 Looking into the G/L account – FS item

mapping container behind this assignment …
5 … shows which FS item will be derived from

which G/L account when the G/L account
mapping is used.
Group Reporting Fields Derivation in Accounting Reports – Part 1
Group Reporting Fields in Accounting “Trial Balance” App – Slide 1
i With the integration with group reporting preparation ledger the group reporting fields can also be used in particular accounting reports.
1 For example group reporting fields can be made available in the “Trial Balance” report in accounting.
i As a prerequisite for showing the group reporting fields in the “Trial Balance” report, the fields need to be activated in the accounting
“Trial Balance” report in the extensibility framework. How this is done, is shown on the next slide.
Group Reporting Fields Derivation in Accounting Reports – Part 2
Group Reporting Fields in Accounting “Trial Balance” App – Slide 2
1
i As a prerequisite for showing the

group reporting fields in the “Trial
Balance” report, the group reporting
fields need to be activated in the
2 accounting “Trial Balance” report via
the “Custom Fields” app of the
extensibility framework.
1 To do so launch the “Custom Fields”

3 app, …
2 … navigate to the “Data Source

Extensions” tab, …
3 … and create custom data source

extension for the “Trial Balance” data
source (C_TRIALBALANCEQ0001).
4
4 On the “Field Selection” tab of the
details of the created custom data
source extension …
5
5 … you can select the group reporting
fields from the list of available fields.
i When the custom data source

extension has been published the
group reporting fields can be shown
in the accounting “Trial Balance” app.
Data Release Task
Special Aspects in Integration with Group Reporting Preparation Ledger – Slide 1
i No derivation during data release:

While in the “classic” accounting integration the group reporting
field derivation needs to happen during the data release, the
release task in accounting integration with group reporting
preparation ledger selects data from accounting journal (ACDOCA)
using the already derived group reporting fields (especially the
consolidation unit information) and transfers the data without any
further derivations to the group journal (ACDOCU).
1
For special issues which may arise from this in case of flexible
consolidation unit derivation see here.
1 Delta mode:
While in the “classic” accounting integration the release task always
works in full mode (i.e. data from previous execution in the same
fiscal year period and consolidation version is deleted and all data
is transferred again), the release task in accounting integration with
group reporting preparation ledger works in delta mode when it is
run in the data monitor. This means only data is transferred which
was created since the last data release. No data is deleted in group
journal.
Note: For technical reasons there is a time-lag of several seconds,

2 i.e. the release task may not pick accounting documents that were
posted in the last couple of seconds prior to the task execution.
2 This delta-mode behavior is also documented in the application log.

Data Release Task
Special Aspects in Integration with Group Reporting Preparation Ledger – Slide 2
1 Scheduling the release task as job:
When scheduling the release task as a job, there is the option to either execute it
in delta mode (replication type “Delta Period”) or in full mode (replication type
“Complete Period”).
2 Also here the execution mode of the release task is documented in the job log.
i Full mode:
In case of execution in full mode data of previous runs is deleted.
The full mode is slower and only needs to be executed in exceptional cases. For
example when a field mapping for the data release task was introduced after data
has already been replicated and the already replicated data shall be enhanced
with the additionally mapped fields.
1 3 Support of special periods:

In the accounting integration with group reporting preparation ledger the data
release task supports special periods (i.e. data release task no longer aggregates
special periods into period 12 but transfers data wrt fiscal periods 1:1).
Below a data monitor with a release task in period 013 is shown.
2 3
3
Data Release Task
Special Aspects in Integration with Group Reporting Preparation Ledger AND Flexible Cons Unit Derivation
i ➢ Even in case of flexible consolidation unit derivation the data release task works the same as before in integration with group
reporting preparation ledger:
➢ The data release task selects all accounting journal items in the group reporting preparation ledger for a given consolidation unit
which are relevant from a fiscal year and period perspective and transfers them to the group journal.
➢ However with the introduction of flexible derivation of consolidation units some special aspects become relevant in the context of
data release task:
➢ In case the consolidation unit should have been filled, but was not filled during accounting posting (e.g. because a customer
substitution rule was missing or was incomplete, or the derived consolidation unit value was inconsistent and therefore removed
in step 3 of the derivation) the resulting accounting journal items are not processed by the data release task and therefore won‘t
be transferred into the group journal. Realignment of the accounting journal data is required, to correct this, and to enable the
data release task to process the accounting data as expected. Alternatively correction data may be loaded into group journal
using posting level 0C.
➢ In case the consolidation unit was properly derived during accounting posting, but due to subsequently changed assignment of
companies to consolidation units, or changed customer substitution rules is not correct any more when the data release task is
executed, the accounting data will end up in group journal on the meanwhile wrong consolidation unit. Also in this case
accounting journal data may be realigned and by re-processing the data release task wrong data in group journal will be inverted
and data on correct consolidation unit will be added. Alternatively correction data may be loaded into group journal using posting
level 0C.

Line Item Validation – Part 1 Purpose of line item validation:
Line Item Validation in Data Monitor – Purpose and Scope i In the guiding principles for the execution of group reporting
substitution rules in accounting (see here) the following was stated:
• We don’t stop/block accounting postings and don’t raise group
reporting specific messages during accounting posting.
• We accept group reporting inconsistencies in accounting data
from breakdown category definitions and group reporting line
item validations where we cannot prevent them at posting time.
Therefore the purpose of the line item validation is to check data
consistency and to identify issues and their root causes as starting
point for corrections.
Scope of line item validation:
1 When the line item validation is executed in the data monitor, the
following happens:
• It checks whether the breakdown settings of the breakdown
category assigned to an FS item are met (e.g. with regards to
1 breakdown by subassignments, subitem value, …).
• It executes all active validation rules defined in the “Manage
Substitution / Validation Rules – Group Journal Entries” app.
2
• This is done for data in group journal (ACDOCU) with posting
level blank (release of universal journal) and 0C (corrections of
universal journal).
i Note: The line item validation currently runs exclusively on the
group journal (ACDOCU). It is planned to also support running the
line item validation on the accounting journal (ACDOCA) before
data is transferred to group journal.
Navigation to task log of line item validation:
i When the line item validation is executed in the data monitor, the
task log is automatically displayed and shows the detected issues.
2 It is also possible to open the task log of the last execution of the
line item validation later by choosing “Last Log” in the context menu.
Line Item Validation – Part 2
Task Log of Line Item Validation in Data Monitor
5 6
1
8
3
2 7
i Only checked data resulting in issues is shown in the task log, “Item Type” classifies the rows in the list: You may use …
i.e. if no issues are found no items are displayed in the list.
2 • Data resulting in breakdown check issues is classified with 5 • … the settings dialog to add or remove columns,
1 “Row Number” represents aggregated data records: the item type “Standard Validation”. define filters, or sorting and grouping criteria.
• Data with the same line item validation relevant criteria (e.g. the 3 • Data which violates validation rules is classified with the 6 • … download dialog, to for example download the
same consolidation unit, partner unit, FS item, subitem, segment, item type “User Validation”. validation results to MS Excel for further analysis.
profit center, …) and the same validation result (i.e. the same
4 • Rows with item type “Message” show an error or warning • … the menu on the journal entry amount, to
errors and/or warnings) is bundled in the same row number.
message resulting from the data with the respective row
7 perform a context sensitive navigation to the
• Data differing in not line item validation relevant criteria (such as number. “Display Group Journal Entries” app.
user, date of entry, …) is aggregated under the same row number.
i • For each row number there is exactly one row with the item 8 • … the pop up which opens when you click
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public type “Standard Validation” or “User Validation” and in a validation rule issue to navigate to the 62
addition one or several rows with the item type “Message”. validation rule definition.
Correction of Line Item Validation Errors
i Note that unresolved issues from breakdown category check are likely to i Options to correct line item validation errors:
impact the execution of other tasks. • Correction in accounting
1 Above you see an example for the impact of an unresolved breakdown • Adjustment of posting data in accounting with correct sender field values
check error on the execution of the currency translation task. The (e.g. transaction type or trading partner), or
currency translation task fails because of the unresolved breakdown • Correction of derivation logic (e.g. group reporting field substitution rules in
check errors. accounting or G/L account mapping, consolidation unit master data, or
breakdown category definition in group reporting).
As the task log of the currency translation task is the same as before the
• Run realignment job in accounting (for further information see here).
introduction of accounting integration with group reporting preparation
• Re-run data release task.
ledger, it is not that easy to find the root cause for the failing task in that
log. • Correction in group reporting
• Post manual journal on PL 0C without auto-reversal in next period, or
2 Whereas the line item validation task log was massively enhanced with • Use GRDC forms for corrections on posting level 0C, or
S/4HANA 2202 and helps users a lot to analyze issues and root causes.
• Post manual journals on PL 0C with auto-reversal in next period if the issue
i Hence the recommendation is, to correct line item validation errors is planned to be corrected with a YTD realignment in the next period.
before proceeding with other tasks.
• Also lowering quality definition in breakdown category (e.g. lowering breakdown
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public type from “mandatory” to “optional”) may be acceptable in some cases. 63
Totals Validation
2 Besides the line item validation there

is of course the instrument of totals
validation available. As the totals
validation functionality as such did
not change with the introduction of
accounting integration with group
reporting preparation ledger, there is
no further focus on this topic in this
presentation.
1
1 However SAP delivers new totals
validation rules on account mapping
in 1SG.

Realignment – Overview
Scenario & General Behavior
What: How:
• The realignment function offers a possibility to re-process the derivation of • Schedule job for immediate run or specific time
group reporting relevant fields which are derived during accounting posting.
• Periodic mode vs. YTD mode: The user needs to decide if only the data of the current
• Based on some filter criteria defined in the realignment job, the realignment period or the cumulated data including past periods shall be realigned, both of which
function selects all relevant accounting journal items and re-processes all result in realignment documents in the current period. Both modes should not be
active substitution rules for the two group reporting relevant business mixed in the same period.
contexts in accounting:
• The realignment function only reclassifies group reporting fields (+/-) in group
• GRPL core fields: This derives company, consolidation unit, reporting preparation ledger(s) with no effect on G/L account balances.
consolidation chart of accounts, and financial statement item.
• The realignment accounting journals are released into group reporting as normal
• GRPL subassignments to FS item: This derives subitem category, accounting documents using the data release task.
subitem, and partner consolidation unit.
When:
Two Schematic Examples:
• When derivation logic changes (e.g. changes in substation rules, lookup
1. Realignment from FS item A to FS item B:
tables, assignment of companies to consolidation unit, G/L account
mapping, FS item breakdown category assignment, breakdown category GL Account FS Item Amount Origin
definition, …) and already posted data shall be corrected.
123456 A (old GR field value) 1000 EUR Original GL posting
• Month end close/during the month if needed
123456 A -1000 EUR Realignment posting
• Can only be used after integration with group reporting preparation ledger
has been activated. 123456 B (new GR field value) 1000 EUR Realignment posting
• Exceptional use case: After the activation of integration with group reporting
2. Realignment for missing FS item mapping
preparation ledger, when there are documents posted in years as of the
“From Year for Preparation Ledger” before integration with group reporting GL Account FS Item Subitem Amount Origin
preparation ledger had been activated.
Not recommended in case of mass data! 123456 NOMAPBS 915 1000 EUR Original GL posting
Who 123456 NOMAPBS 915 -1000 EUR Realignment posting
• E.g. local accountant upon request from group accountant, … 123456 111100 915 1000 EUR Realignment posting
• … or group accountant with proper authorization.

Realignment – Details and Example – Part 1
Introduction
1 i High level concept of realignment function:
The realignment function offers a possibility to re-process the

derivation of group reporting relevant fields which are derived
during accounting posting.
4 Based on some filter criteria defined in the realignment job, the

realignment function selects all relevant accounting journal
items and re-processes all active substitution rules for the two
group reporting relevant business contexts:
• GRPL core fields: This derives company, consolidation
2 unit, consolidation chart of accounts, and financial
3 statement item.
• GRPL subassignments to FS item: This derives subitem
category, subitem, and partner consolidation unit.
This is relevant in case the respective substitution rules

changed (e.g. substitution rules were modified, enhanced,
1 Here you see an example for a posting resulting from the realignment function. added, deactivated, etc., or lookup tables were modified) after
the accounting postings took place and in case group reporting
Due to a change in the lookup table which was used for the consolidation unit derivation a posting on company code master data or configuration influencing the result of the
“4711” and segment “1000_A” shall not go to consolidation unit “4711_A” but to “4711_C”. Therefore the realignment substitution was changed (e.g. the assignment of companies
function reclassified postings for that combination that already were posted on consolidation unit “4711_A” (using the to consolidation units, or the assignment of breakdown
lookup table information before it was changed) to “4711_C”. category to financial statement item was changed).
2 In this case the amount of 100 € on GL account “1001000 (Petty Cash)” was inverted on consolidation unit “4711_A” … The realignment is not processing each and every selected
accounting journal entry individually, but works on
3 … and posted to consolidation unit “4711_C” … appropriately aggregated data from these journal entries.
4 … realignment postings are identified e.g. by the reference document type for group reporting periodic reclassification. In case the realignment results in adjustments, these are
posted with separate document numbers on a special group
i The subsequent slides show in more detail how to get to such realignment postings. reporting reclassification document type using the timestamp
of the realignment execution.
Open Periods for Realignment Please note: In order to be able to process the
1
realignment function successfully, periods have
to be opened for respective company codes and
accounting ledgers.
2 In addition to open posting periods for the

general ledger with the “Manage Posting
Periods” app, you need to open periods for the
realignment function in the “Manage Posting
Periods – Cost Accounting” app.
Besides other filter criteria such as company

3
3 code, fiscal year, etc. make sure that you select
the “Business Transaction Type” “GRRA
2 (Realign Journal Field Values)”.
4 Then select entries in the list and press the

“Open” button to open the periods for the
4
selected entries for the realignment function.
1 i Note: With this the period control for posting in

accounting is managed by business transaction
types. For example you can close the
accounting period for all business transaction
types except for the realignment posting, so it is
still possible to post group reporting realignment
documents in accounting, whereas the period is
already closed for other kind of postings.
In case the period is not open for the business

transaction type “GRRA (Realign Journal Field
Values)” the realignment cannot post
reclassification postings. Instead warning
messages “Period is not open for GL account
xyz” for G/L accounts the realignment tries to
post reclassifications for will appear in the
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public log of the realignment run. 67
Schedule Realignment Job – Slide 1
1
3
2
4
i Realignment tasks are scheduled as jobs.
1 You can create a realignment job either by using the “Schedule Jobs for Consolidation Tasks” app
(which requires a group reporting role) …
2 … or by using the “Schedule Accounting Data Changes” app (which requires an accounting role).
3 Either way you end up in this screen …
4 … where you press the “Create” button. This starts a guided procedure to schedule jobs.

Schedule Realignment Job – Slide 2
1 In order to schedule a realignment task job, make sure to select “Realign Group
Reporting Preparation Ledger” as “Job Template” in step 1 of the guided procedure.
i Even thought the list of job templates in both apps differ, the “Realign Group
Reporting Preparation Ledger” job template is available in both apps.

1 In step 3 of the guided procedure you have to fill some
Realignment – Details and Example – Part 5 mandatory parameters:
2 • “Consolidation Unit”:
Schedule Realignment Job – Slide 3 You may select individual consolidation unit(s) or use
conditions such as “between”, “starts with”, “contains”,
etc. to determine the consolidation units to be processed.
Note: The realignment will not directly process
accounting journal entries which have the selected
consolidation unit value included, but based on the
consolidation unit master data in the selected fiscal year
and period ( 4 ) the assigned company is used to
identify company codes assigned to that company in
accounting. Then the accounting journal entries for the
identified company codes are processed.
3 • “Version”:
Here you select a single consolidation version. This
version is used to determine the accounting ledger for
which the realignment function shall be executed. It is the
accounting ledger which is maintained as preparation
1 ledger in the selected consolidation version.
2 3
4 • “Fiscal Year” and “Period”:
4 Obviously this determines for which fiscal year and
period the realignment task is executed. Beyond that it
5 determines the fiscal year and period the company
assignment to the selected consolidation unit(s) is taken
6 from.
5 Besides that you may add some optional parameters to
schedule the realignment task on a more granular level
(e.g. for particular segments or profit centers).
6 Realignment postings are always written into the fiscal
7 period of parameter “Period” (in the example this is “006”).
However the selection behavior depends on the chosen
period mode:
• In case of “Periodic Mode” data is selected from
parameters “Period” and “Fiscal Year” only.
• In case of “YTD” data is selected from the period
interval 000 to the parameter “Period” in “Fiscal Year”.
7 By pressing “Schedule” you complete the scheduling. 70
Example – Slide 1
Realignment Example – Part 1

1 Initially the lookup table for
consolidation unit derivation
foresees consolidation unit
“4711_A” when a posting is
executed for company code
“4711” and segment “1000_A”.
1 3 2 Consequently a posting on this
combination results in the
derivation of consolidation unit
“4711_A” in an accounting
posting.
3 Subsequently the lookup table
content is modified and now
the same combination of
company code “4711” and
segment “1000_A” results in
consolidation unit “4711_C”.
4 Another posting on this
combination therefore results in
the derivation of consolidation
unit “4711_C” in an accounting
2 posting.
i Note: The screenshot at the
4 bottom shows the result in
group journal after executing
the data release task for
consolidation units “4711_A”
and “4711_C” (see also next
slide).

Example – Slide 2

1 After the accounting postings on
the previous slide the data
release task for both
consolidation units “4711_A” and
1 “4711_C” is executed.
As the data release task simply
transfers the data according to
the consolidation unit
information in the accounting
journal items, but does not
check or correct any
consolidation unit derivation, this
results in the group journal …
2 … in data with is correct
according to the content of the
consolidation unit lookup table
(data for consolidation unit
“4711_C”) …
3 … and data which is incorrect

according to the content of the
3 consolidation unit lookup table
2 (data for consolidation unit
“4711_A”).

Example – Slide 3

1 Then the realignment job is
scheduled and executed.
2 3 2 After that the data release task is
executed once more for both
consolidation units.
3 As you can see, it creates/updates

two documents for each of the
2 3

Example – Slide 4
2
3
4

After realignment and release task execution we see in the “Display Group Journal Entries” app:
1 The results of the original accounting postings (before realignment).

2 The results of the realignment, where the data from the accounting posting with the “outdated” consolidation unit derivation …
3 … is inverted on the “outdated” consolidation unit “4711_A” …
4 … and reclassified to the “correct” consolidation unit “4711_C”.

Example – Slide 5
1 2 3 4
5 6
6

In the “Manage Journal Entries” app you can directly look at the reclassification postings created by the realignment task.
With the following filters you can easily find the respective journal entries:
1 Company Code
2 Ledger Group: Here you enter the individual group reporting preparation ledger of the realignment processing
3 Fiscal Year and Period
4 Business Transaction “GRRA”
5 Reference Document Type “GRRFP”
6 Reference Key: The reference key consists of: Log run ID (e.g. 0000000005; this you can get from the log of the realignment job) + company code (e.g. 4711) +
fiscal year (e.g. 2022) → 000000000547112022
i In case you know the reference key, no other filter is required but you will directly get the list of the relevant journal entries.
From the resulting list of journal entries you may navigate to the details of individual journal entries. The two of this list are shown on the next slide.
Example – Slide 6
Realignment Example – Part 6 The “Item Text” indicates which group reporting fields were reclassified using
3
After filtering on the relevant journal entries in the “Manage Journal Entries” app you may look at the the field following abbreviations:
details of these journal entries. The two from the list on the previous slide are shown above: • FS item = RITEM
As already explained the “Reference Document Type” of the postings created by the realignment • Subitem category = SITYP
1
task is “GRRFP – Group Reporting Periodic Reclassification“. • Subitem = SUBIT
• Consolidation unit = RBUNIT
2 The line items of a realignment posting are sorted in the following way:
• Uneven line-item numbers indicate a reversal of the old posting lines based on the old derivation. • Partner unit = RBUPTR
• The next even line-item number shows the corresponding new line based on the new derivation. In our example only the consolidation unit was reclassified. Therefore you
only see “RBUNIT” in the “Item Text”. But you may also see reclassification
records with something like “RITEMSITYPSUBIT”, which means the FS item,
the subitem type, as well as the subitem were reclassified.
Process of Special Treatment
1 In the „Define Group Reporting Preparation Ledgers“ SSCUI (see also here) …
Special Treatment of Opening Subitem in Realignment
2 … customers can configure a dedicated carryforward reclassification subitem
(e.g. “950”) …
i Introduction of Background
3 … for a regular carryforward subitem (e.g. “900”).
When the derivation logic for a balance sheet FS item changes (e.g. instead of
“BS A” “BS B” shall be derived) and a realignment task is used for this 4 After changing the FS item derivation (“BS A” → “BS B”) the realignment is
correction in YTD mode, then also the opening balance (e.g. on subitem 900) is executed in YTD mode and realigns all data using the original subitem (e.g.
reclassified. “915”) …
Without any special treatment of opening subitems in the realignment task, this 5 … except the data on the regular carryforward subitem (“900”) which is now
leads to a situation where the closing balance in previous year and opening realigned to the configured carryforward reclassification subitem (“950”).
balance in the year of the realignment do not match any more.
6 With this the closing balance of prior year equals the opening balance in
subitem “900” in the current year.
Original data before change of derivation Configuration
Period FS Item
Doc Type /
Subitem Value Comment
1
BTTYPE
Opening from accounting

00.2023 BS A ABCF 900 30
balance carryforward into 2023
3 2
Various original documents of
12.2023 BS A Various 915 100
current year
1 2
Change of derivation: BS A -> BS B
Data from realignment after change of derivation

Doc Type /
Period FS Item Subitem Value Comment
BTTYPE Schematic analytics
12.2023 BS A GRRA 5 950 -30 YTD realignment Closing Prior
Opening Opening Periodic
Closing
FS Item Current Year Current Year Changes
Year Current Year
12.2023 BS B GRRA 950 30 YTD realignment SI 900 SI 950 Current Year
12.2023 BS A GRRA 4 915 -100 YTD or periodic realignment BS A 30

=6 30 -30 0
12.2023 BS B GRRA 915 100 YTD or periodic realignment BS B 30 100 130

Prepare
Content
Analyze Collect
Consolidate

S/4HANA Cloud 2208

S/4HANA Cloud 2302

Labs Preview
More Information
78
Flexible Derivation of Consolidation Units for Segment Reporting –
Overview – Situation before Flexible Derivation of Consolidation Units
Accounting Automatic Group Reporting Accounting Integration
Assignment Possible?
1 2
Company Code A
5
Company Code B Company 4711 Consolidation Unit 4711 Yes
Company Code C
Company Code D Company 4712 Conssolidation Unit 4712 Yes
Company Code E Company ABCD Consolidation Unit 4713 No
Accounting Data in ACDOCA Group Reporting Data in ACDOCU

3
Accounting Postings for Company Code A – Consolidation Unit 4711 derived during posting
Data Transferred via Data Release Task
Accounting Postings for Company Code B – Consolidation Unit 4711 derived during posting Data transferred for Company Codes A, B, C
Accounting Postings for Company Code C – Consolidation Unit 4711 derived during posting 4
Accounting Postings for Company Code D – Consolidation Unit 4712 derived during posting Data transferred for Company Code D
Data Transferred via Flexible File Upload or GRDC

Data loaded for Company Codes E
Accounting Postings for Company Code E – w/o Consolidation Unit Information
→ Consolidation Unit information added during upload
1 Automatic assignment of companies to consolidation units which have the same key. 4 During data release data of integrated companies is transferred including
the already derived consolidation unit information.
2 Accounting integration possible for consolidation units that have a company
assigned with company codes assigned (plus further checks). 5 With that data of all company codes of an integrated company always ends
up in a single consolidation unit.
3 Consolidation unit information is derived during accounting posting for integrateable
company codes using automatic assignment information. ! → A consolidation unit always represents a complete company.
Overview – Situation with Flexible Derivation of Consolidation Units
Accounting Automatic
Group ReportingGroup Reporting Accounting Integration
Assignment Possible?
1 2
Company Code A
5
Company Code B Company 4711 Consolidation Unit 4711 Yes
Company Code C Consolidation Unit 4714 Yes
Company Code D Company 4712 Consolidation Unit 4712 Yes
Company Code E Company ABCD Consolidation Unit 4713 No
Accounting Data in ACDOCA Group Reporting Data in ACDOCU

3
Accounting Postings for Company Code A – Consolidation Unit 4711 derived during posting Data Transferred via Data Release Task
Accounting Postings for Company Code A – Consolidation Unit 4714 derived during posting
4
Data transferred for Company Codes A, B posted on Consolidation Unit 4711
Accounting Postings for Company Code B – Consolidation Unit 4711 derived during posting
Accounting Postings for Company Code B – Consolidation Unit 4714 derived during posting Data transferred for Company Codes A, B, C posted on Consolidation Unit 4714
Accounting Postings for Company Code C – Consolidation Unit 4714 derived during posting
… postings for other company codes as on slide before. … data transfer for other consolidation units as on slide before.
1 Replace automatic assignment by maintained assignment in consolidation unit master data. 4 During data release relevant data of integrated companies is transferred
A consolidation unit may have no company or a single company assigned (not multiple!). including the already derived consolidation unit information.
2 Same as before: Accounting integration possible for consolidation units that have a 5 With that data of an integrated company may be split up to several
company assigned with company codes assigned (plus further checks). consolidation units.
3 Consolidation unit information is derived during accounting posting. Postings for one ! → A consolidation unit does not need to represent a complete company any
company code may be split up to several consolidation units according to e.g. segment, more, but may represent only parts of a company relevant for a particular
functional area, profit center, …, or combinations of these by using substitution rules. segment, functional area, profit center, …, or a combination of these.
Short Step by Step Description
1 Flexible derivation of consolidation units is only available in integration with group reporting preparation ledger,
i.e. as of the „From Year for Preparation Ledger“.
2 Assign a company to several consolidation units via “Define Consolidation Units” or “Import Consolidation Master Data” app.
3 Maintain substitution rules in “Manage Substitution/Validation Rules – Journal Entries“ app using business context “GRPL
core fields” which derive the consolidation unit based on accounting posting context (e.g. company code, segment, profit
center, functional area, etc.). Only required in case of companies assigned to several consolidation units.
4 Maintain substitution rules in “Manage Substitution/Validation Rules – Journal Entries“ app using business context “GRPL
subassignments to FS item” which derive the partner unit based on accounting posting context (e.g. trading partner, partner
company code, partner segment, partner profit center, etc.). Only required in case of trading partners assigned to several
5 Maintain consolidation unit hierarchies and/or consolidation groups to consolidate/aggregate data of consolidation units
representing a specific entity (e.g. a segment, profit center, etc.).
6 Execute realignment function to reprocess the derivation of consolidation units and partner units. Only required in case of
changed substitution rules or consolidation unit master data.
7 Execute data release task.

Prerequisite for Flexible Derivation of Consolidation Units
i The consolidation unit derivation mechanism during accounting posting is

available in group reporting preparation ledgers only.
The logical basis of the flexible derivation of consolidation units for segment
reporting is to split up accounting data of a company to several consolidation units
already at posting runtime.
Based on context information from the accounting posting, such as company code,
company, segment, profit center, etc. the relevant consolidation unit is derived
during accounting posting and persisted in the accounting journal.
1
1 As a consequence the flexible derivation of consolidation units for segment
reporting is available only as of the „From Year for Preparation Ledger“.
i Note: Systems set up with S/4HANA 2202 or later automatically have 1001 as
„From Year for Preparation Ledger“ which cannot be changed (see screenshot).
With that newly set up systems by definition allow flexible derivation of
In systems upgraded to S/4HANA 2202 the „From Year for Preparation Ledger“ is
initial and has to be set by the customer. After maintaining this from year it cannot
be changed any more. With that upgrade customers control if and as of when the
integration with group reporting preparation ledger is active in their system and
with that as of when flexible derivation of consolidation units can be used.

Preparation of Consolidation Unit Master Data
i In earlier releases the company assignment to consolidation unit
was a kind of „automatic assignment“ which could not be
influenced. Whenever a company existed in accounting which had
the same key as the consolidation unit this company was
„assigned“ to the consolidation unit.
1 As of S/4HANA 2208 release the company assignment to

consolidation unit can be explicitly maintained.
This assignment is time-dependent. So it can change over time and

also there may be time intervals where no company is assigned to
a consolidation unit.
Any company existing in accounting may be assigned (no matter

what the key of this company is). Whenever a key identical
company exists, this is suggested as default when a consolidation
unit is created, but the assignment may be changed or removed.
1 The same company may be assigned to several consolidation

units. This is actually the logical prerequisite to split up data from
one company to several consolidation units in order to reflect for
example segment contributions of these companies.
Every consolidation unit may have assigned only one company at a

time. This helps to avoid that data from multiple companies ends up
in the same consolidation unit as intercompany elimination of that
data would not be possible within the consolidation unit.
i Note: In case the company assignment is changed for fiscal year

periods where accounting postings already took place, the
consolidation unit information for the already existing transaction
data has to be corrected by using the realignment function or by
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public importing correction data. 85
Consolidation Unit Derivation during Accounting Posting – Overview
Substitution 1 Substitution Rules with Business Context Substitution Rules with Business Context
Derivation
Sequence

Accounting

Source & Target

Derivation

2 Consolidation Unit 3 Company 4 Substitution Rule(s) 5 If Inconsistent: Revert
Partner
FS Item GL Account Mapping Substitution Rule(s) If Empty: &NOMAP Trading Partner Substitution Rule(s) BDT0: Clear; BDT2: Default
Unit
1 For integration with group reporting preparation ledger two substitution business contexts were introduced to derive group reporting specific information during accounting posting:
• GRPL core fields: This derives company, consolidation unit, consolidation chart of accounts, and financial statement item
• GRPL subassignments to FS item: This derives subitem category, subitem, and partner consolidation unit
2 For the flexible derivation of consolidation units the substitution for consolidation unit was adjusted. Same as the substitution for the financial statement item this is now following a three step approach.
3 Step 1: In case the company for which the accounting posting takes place is assigned to exactly one single consolidation unit in the given fiscal year and period, an SAP defined substitution rule filles the
consolidation unit field with this consolidation unit. If the company is not assigned to any consolidation unit, or is assigned to several consolidation units in the given fiscal year period, the consolidation unit
field is empty after step 1.
4 Step 2: By customer defined substitution rule(s) the result from step 1 may be overwritten (for details see also slides in the next chapter). This is especially relevant in case data from a company shall be
distributed to several consolidation units. In that case the company by definition has to be assigned to several consolidation units and step 1 will result in an empty consolidation unit field. In case step 1
already provided a consolidation unit there is no further customer defined substitution rule required (anyhow in that case the consolidation value from step 1 is the only allowed value).
5 Step 3: In case there is a consolidation unit value filled after step 2, step 3 checks the consistency of that value: In case the company for which the accounting posting is created is assigned in the master data
of the derived consolidation unit in the given fiscal year period, the value is consistent and therefore is kept. If this is not the case (i.e. if the derived consolidation unit either has no company or a different
company assigned in the given fiscal year period, or the derived value does not even exist as consolidation unit) the value is not consistent and step 3 reverts the field to result of step 1, i.e. there is either no
consolidation unit value, or the consolidation unit with unique assignment of the given company in the resulting journal entry of the accounting posting. This has to be fixed afterwards either by using the
realignment function or by importing correction data.
Partner Consolidation Unit Derivation during Accounting Posting
Substitution Substitution Rules with Business Context Substitution Rules with Business Context
Derivation
Sequence

Accounting 1 2

Source & Target

Derivation

1 Consolidation Unit Company Substitution Rule(s) If Inconsistent: Revert
Partner
FS Item GL Account Mapping Substitution Rule(s) If Empty: &NOMAP 2 Unit 3 Trading Partner 4 Substitution Rule(s)5 BDT0: Clear; BDT2: Default
1 Similar to the consolidation unit derivation in the business context „GRPL core fields“ …
2 … there is a partner consolidation unit derivation in the business context „GRPL subassignments to FS item“.
i The partner consolidation unit derivation is also following a three step approach. The differences compared to the consolidation unit derivation are in step 3, while steps 1 and 2 are working basically the same in both derivations.
3 Step 1: In case the trading partner for which the accounting posting takes place is assigned as company to a single consolidation unit in the consolidation unit master data, then this consolidation unit is derived as partner unit. If
the trading partner is assigned as company to several consolidation units or not assigned to any consolidation unit, then no value is derived for the partner unit. As a result, the field for partner unit stays empty in step 1.
4 Step 2: Substitution rules that you’ve created may overwrite the partner unit value derived in step 1. This is especially relevant if the trading partner is assigned as company to several consolidation units. As explained in step 1,
the system doesn’t derive a partner unit value in this case. Instead, the field is empty after step 1. So, it’s the job of your customer defined substitution rules to derive the partner unit value in step 2 based on the context of the
accounting posting. For example, this context could be the partner company code, partner segment, partner profit center, or partner functional area. In this way, step 2 is crucial for deriving a partner unit value in the flexible
derivation of partner units. Regarding the modelling of customer defined substitution rules there is no principal difference to the derivation of consolidation units, but of course in this case “PartnerConsolidationUnit” is used instead
of “ConsolidationUnit” as target field in the substitution rule. One especially interesting aspect regarding derivation via lookup tables is explained on the next slide. If step 1 provided a partner unit value already, then there’s no
need for the substitution rules in step 2. In other words, if you don't assign a trading partner to several partner units, you don't need to define any substitution rules yourself. Instead, the system derives the partner unit correctly.
5 Step 3: In case there is a partner consolidation unit value filled after step 2, step 3 checks the consistency of that value with regards to the breakdown type. In case the breakdown category of the FS item derived in the „GRPL
core fields“ derivation has the breakdown type „0“ (i.e. „no breakdown“) regarding partner unit, step 3 clears the derived partner consolidation unit value. In case no partner consolidation unit has been derived after step 2, but the
breakdown type regarding partner unit is „2“ (i.e. „breakdown required, if blank, the default value is used“), step 3 fills the default value.
Note: A validation of the derived partner consolidation unit against the company assigned in consolidation unit master data does not happen in any of the cases.

Prepare
Content
Collect


S/4HANA Cloud 2208

S/4HANA Cloud 2302

Labs Preview
More Information
88
Chapters
!
Tip:
➢ Introduction
➢ Overview Graphic and Table Use the navigation buttons to easily and
quickly navigate in this presentation.
➢ Things in Common of Newly Introduced Cases
➢ Overview on Things in Common The buttons will navigate to the first
slide of the respective chapter.
➢ Customer Group Journal Fields
➢ Field Mapping for Data Release Task With the button on the lower right hand
corner of every slide you can navigate
➢ Details on Individual Cases back to this chapter overview slide.
➢ Accounting Standard Fields
➢ Common Accounting Standard Fields
➢ Additional Selected Accounting Standard Fields
➢ Other Accounting Standard Fields (OP only)
➢ Custom Defined Accounting Fields
➢ Customer Extension Fields with Business Context “Accounting: Coding Block”
➢ Customer Extension Fields with Business Context “Accounting: Journal Entry Item”
➢ Customer Extension Fields with Business Context “Accounting: Market Segment”
➢ CO-PA Generated Customer Fields (OP only)

Introduction
➢ Before CE 2302 / OP 2022 FPS1 only transaction data of the following fields of accounting journal (ACDOCA) could be transferred
to group journal (ACDOCU):
➢ Standard fields which are also common in consolidation

(e.g. profit center, cost center, functional area, segment, distribution channel, etc.)
➢ Customer extension fields with the business context “Accounting: Coding Block”
➢ As of CE 2302 / OP 2022 FPS1 field mapping for data release task is introduced which allows to also transfer transaction data of
the following ACDOCA fields:
➢ Customer extension fields with the business context “Accounting: Journal Entry Item”
➢ Customer extension fields with the business context “Accounting: Market Segment”
➢ CO-PA generated customer fields (OP only)
➢ Selected additional standard fields which are not that common in consolidation
(e.g. asset class, document type, business transaction type, source ledger, cost analysis resource, etc.)
➢ Other standard fields (OP only)
➢ Note:
➢ All enhancements mentioned above are for integration with group reporting preparation ledger and ACDOCA data only.
Classic accounting integration does not support this. Plan data in ACDOCP is not supported by this.
Field Mapping for Data Release Task – Overview Graphic
ACDOCU Cases:
ACDOCU Extensibility Fields with Business Context Group Reporting: Journal Entry Item ACDOCA standard fields incorporated into GR views and ACDOCU
Nothing required from customer side (but customers may decide not to transfer some of
1 these fields by choosing the configuration option „Aggregate Data on Release“)
1 4 5 2 6 3 7 Already existing in all environments
ACDOCA standard fields incorporated into GR views but not into ACDOCU
Release Task 2 ACDOCU extensibility field and customer field mapping required
NEW - Integration with GR Preparation Ledger only!
Configuration not to transfer some of the fields during data release Automatic
(„Aggregate Data on Release“) Mapping Customer Field Mapping ACDOCA standard fields neither incorporated into GR views, nor into ACDOCU
Generated ACDOCU Customer Defined ACDOCU Extensibility Fields with Business Context 3 ACDOCU extensibility field, customer view extensions, and customer field mapping required
Group Reporting
Extensibility Fields Group Reporting: Journal Entry Item NEW - Integration with GR Preparation Ledger and OP only!
OP Only Accounting coding block key user extensibility fields with business scenario “Accounting:
Coding Block to Consolidation Journal Entry” enabled
4 ACDOCU extensibility fields generated and automatically mapped
Already existing in all environments
Integration with GR Prep Ledger View Stack
Accounting coding block key user extensibility fields with business scenario “Accounting:
I_CnsldtnIntegRptdFinData Generated View Extensions Customer Created View Extensions
5
Coding Block to Consolidation Journal Entry” disabled (not very common!)
ACDOCU extensibility field and customer field mapping required
OP Only NEW - Integration with GR Preparation Ledger only!
Accounting market segment and accounting journal entry item key user extensibility fields
6 ACDOCU extensibility field and customer field mapping required
CO-PA generated fields

7 ACDOCU extensibility field, customer view extensions, and customer field mapping required
NEW - Integration with GR Preparation Ledger and OP only!
Customer Created View Extensions

I_JournalEntryItem E_JournalEntryItem: Generated View Extensions (customer view extensions – OP customers only)
Accounting
OP Only
ACDOCA
ACDOCA Standard Fields ACDOCA Standard Fields Extensibility Fields with Business Context
ACDOCA Standard Fields Incorporated into GR Extensibility Fields with Business Context CO-PA Generated Fields
Views but not into Neither Incorporated into GR Views, Accounting: Coding Block
Accounting: Market Segment
OP customers only
Incorporated into GR Views and into ACDOCU ACDOCU nor into ACDOCU or Accounting: Journal Entry Item
ACDOCA Standard Fields ACDOCA Extension Fields 91

Field Mapping for Data Release Task – Overview Table
Case Source Field Target Field Availability
Customer CDS Field Mapping Environment & Release GR Logic and Accounting Integration Source Data
Accounting Accounting Group Group
Case-Number View for Data
Journal Journal Journal Journal New GR Logic Actual Plan
from Business Context of Customer Extensions Release Task New GR Logic
Case Description (ACDOCA) (ACDOCA) Further Detail of Customer Field (ACDOCU) (ACDOCU) Business Context of Customer Field As of & Integration Accounting Accounting
Overview Field Required Required As of OP Old GR & Classic
Standard Customer Standard Customer OP Cloud Cloud with GR Journal Data Journal Data
Graphic Release Logic Accounting
Field Field Field Field Release Preparation (ACDOCA) as (ACDOCP) as
Integration
Ledger Source Source
ACDOCA standard fields which are
common in consolidation and
1 X X X 1809 X 1708 X X X X X
therefore are part of ACDOCU as
well
Additional selected ACDOCA
standard fields which are not that
2 common in consolidation and X X Group Reporting: Journal Entry Item X X 2022 FPS1 X 2302 X X
therefore are not part of ACDOCU by
default
3 Other ACDOCA standard fields X X Group Reporting: Journal Entry Item X X X 2022 FPS1 X X
Usage “GR Realtime Reported Data - TAI"
and/or "GR Realtime Reported Data NGL"
Accounting coding block key user
and/or "GR Realtime Reported Data OGL"
extensibility fields with business X X
enabled
4 scenario “Accounting: Coding Block X Accounting: Coding Block (created Group Reporting: Journal Entry Item X 1909 FPS1 X 1911 X X X X as of OP 2023
to Consolidation Journal Entry” automatically) as of CE 2302
Business scenario "Accounting: Coding
enabled
Block to Consolidation Journal Entry"
enabled
and/or "GR Realtime Reported Data NGL"
Accounting coding block key user
and/or "GR Realtime Reported Data OGL"
extensibility fields with business
enabled
5 scenario “Accounting: Coding Block X Accounting: Coding Block X Group Reporting: Journal Entry Item X X 2022 FPS1 X 2302 X X
to Consolidation Journal Entry”
Business scenario "Accounting: Coding
disabled (not very common!)
Block to Consolidation Journal Entry"
disabled
Accounting market segment and Accounting: Journal Entry Item
6 accounting journal entry item key X or X Group Reporting: Journal Entry Item X X 2022 FPS1 X 2302 X X
enabled
user extensibility fields Accounting: Market Segment
n.a.
--> CO-PA generated customer field
7 COPA generated customer fields X (not using customer extensibility X Group Reporting: Journal Entry Item X X X 2022 FPS1 X X
framework and its business
contexts)
92
Field Mapping for Data Release Task – Things in Common of Newly Introduced Cases – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Things in Common of Newly Introduced Cases – Part 2 – Overview on Things in Common
As of CE 2302 / OP 2022 FPS1 the highlighted cases 2, 3, 5, 6, and 7 were newly introduced.
1
Common for all of these cases is:
2 The source fields from accounting journal (ACDOCA) which shall be transferred to group reporting
have to be present in I_CnsldtnIntegRptdFinData CDS view (either directly or via view extensions).
This is required as the data release task uses this CDS view to collect the transaction data to be
1 transferred in case of integration with group reporting preparation ledger.
3 How this availability in the I_CnsldtnIntegRptdFinData CDS view is achieved differs from case to
case. In case 2 the fields are automatically part of the view, in cases 5 and 6 view extensions are
generated when for the source custom field the entry “GR Realtime Reported Data - TAI” on the
“UIs and Reports” tab of the “Custom Fields” app is enabled, in cases 3 and 7 customers have to
create view extension with ADT (ABAP Development Tools). Further information you find in the
details of the respective cases.
4
3 The source fields from accounting journal (ACDOCA) which shall be transferred to group reporting
are not part of the group journal (ACDOCU).
2 Therefore it is required to create custom fields for the group journal which take over the transferred
data. For this customers have to define customer fields with the business context “Group
Reporting: Journal Entry Item” in the extensibility framework. This and further details are shown on
the next slide.
4 As the source fields in ACDOCA and the target customer fields in ACDOCU are different, the
release task does not automatically “know”, to which fields the transaction date shall be
transferred.
Therefore it is required to define field mappings for the data release task. For this customers use
the SSCUI/IMG activity “Data Release Task: Define Mapping for Jrnl Entry to Group Jrnl Entry
Fields” where they map the accounting journal fields which shall be taken over to the
corresponding customer fields in group journal. This and further details are shown further down.
i With that the data release task in case of integration with group reporting preparation ledger is
able to pull transaction data from the source fields in accounting journal and to transfer it to the
mapped custom fields in group journal.
! Note: This only works for the accounting integration with group reporting preparation ledger and
with actuals data in ACDOCA (not with plan data in ACDOCP).
Note: Data transferred to group reporting before setting up the field mapping won’t be enriched
with the customer field information by executing the data release task after the field mapping via
the data monitor, as the release task by default works in a delta mode and only processes
transaction data which has been created after the last execution of the data release task. But you
may schedule a data release task in a way that it runs in full mode instead of delta mode and then
customer field information for data which has been transferred to group reporting should be
updated as well.
Things in Common of Newly Introduced Cases – Part 3 – Customer Group Journal Fields
1 On the previous slide it was explained that in all cases which require a field mapping for data
release task customers have to define a customer group journal field with the “Custom Fields and
1 Logic” app. Note that this requires extensibility authorization.
2 In order to define a customer group journal field the business context “Group Reporting: Journal
Entry Item” has to be chosen.
3
3 The daa type of the customer group journal field has to be the same as the type of the source field
in accounting journal (ACDOCA). With “type” the technical data field type on the database not the
2 extension field type in the “Custom Fields and Logic” app is meant. E.g. a customer field of
extension field type “Code List” has the data field type “Char”, so in order to take over data from a
market segment customer field of extension field type “Code List” the target customer field in group
journal does not need to have the extension field type “Code List” as well, but could also be of type
“Text”.
! Note: The following extension field types are NOT supported in the field mapping for data release
task: “Number”, “Date”, “Time”, “Timestamp”, “Amount with Currency”, “Quantity with Unit”. If an
extension field type (such as “Association to Business Object”) which is principally supported uses
one of the before mentioned types inside it is also not supported. Fields which are not supported
won’t show up in the field mapping for data release task.
4 Note: In case the source and the target field are customer extension fields of extension field type
“Code List” there is no automatism that synchronizes the code lists of both customer fields. So this
5 has to be ensured by the customer (e.g. via double maintenance or via export and import).
In case the source and the target fields are customer extension fields of type “Association to
Business Object” and both are associated to the same business object there is no such
synchronization required, as the value help etc. come via the business object.
4 Also no synchronization is required when the target field is a customer extension field of type
“Code List based on CDS view” and the referenced CDS view provides a value help of the source
field.
Also note: Independently from whether the code lists of the accounting journal and group journal
custom field are in sync or not, the data release task will transfer the data from the accounting
journal to the group journal. A validation of the field values from accounting with the code list of the
group journal custom field does not happen.
5 The length of the customer group journal field and the source field in accounting journal (ACDOCA)
have to be the same.
Note: Every extensibility business context has a certain “capacity” which limits the number and size
! of customer fields you can create for this business context. This you need to have in mind when you
create customer fields for the group journal. The “capacity” of the business context “Group
Reporting: Journal Entry Item” has a limit of 120 customer fields and 1080 characters across all
customer fields in that business context. Whenever one of these limits is reached you cannot create
any further customer fields in that business context. You cannot change this “capacity”.

Things in Common of Newly Introduced Cases – Part 4 – Field Mapping for Data Release Task – Slide 1
1 1 On a previous slide it was explained that a field mapping for data release task is required so that
the release task “knows” to which target field in the group journal (ACDOCU) the transaction data
of which source field in the accounting journal (ACDOCA) shall be transferred.
This is done in the SSCUI/IMG activity “Data Release Task: Define Mapping for Jrnl Entry to Group
4 6 Jrnl Entry Fields”.
In OP this can be found in the IMG under “SAP S/4HANA for Group Reporting” → “Data
2 Collection for Consolidation” → “Data Release Task: Define Mapping for Jrnl Entry to Group Jrnl
Entry Fields”.
In cloud the SSCUI can be found via “Finance” → “Corporate Close” → “Data Processing” →
“Data Release Task: Define Mapping for Jrnl Entry to Group Jrnl Entry Fields” in “Configure Your
Solution”.
2 You can only map compatible source and target fields, i.e. both need to have the same type and
length.
With “type” the technical data field type on the database not the extension field type in the
“Custom Fields and Logic” app is meant. E.g. a customer field of extension field type “Code List”
has the data field type “Char”, so in order to take over data from a market segment customer field
3 of extension field type “Code List” the target customer field in group journal does not need to have
the extension field type “Code List” as well, but could also be of type “Text”.
3 In case you try to map incompatible fields, you’ll receive an error when you save your changes.
5 4 Every source field (i.e. accounting journal field on the left hand side of the table) can only be
mapped once.
5 In case you try to map the same source field several times, you’ll receive an error when you save
your changes.
7 6 Also every target field (i.e. customer extension field in group journal on the right hand side of the
table) can only be mapped once.
7 In case you try to map the same target field several times, you’ll receive an error when you save
your changes.

Things in Common of Newly Introduced Cases – Part 5 – Field Mapping for Data Release Task – Slide 2
1 1 The value help “Field in General Ledger” contains all potential source fields for the field mapping for data
release task, independently from whether they were already mapped or not. These are:
2 The additional selected accounting journal standard fields (case 2).
2 3 Other accounting journal standard fields and CO-PA generated fields which were added via customer
view extensions by OP customers (cases 3 and 7).
4 Published customer fields with business context “Accounting: Journal Entry Item” or “Accounting: Market
Segment” for which the entry “GR Realtime Reported Data - TAI” on the “UIs and Reports” tab of the
“Custom Fields” app has been enabled (case 6).
3 Published customer fields with business context “Accounting: Coding Block” for which the entry “GR
Realtime Reported Data - TAI” on the “UIs and Reports” tab of the “Custom Fields” app has been
4 enabled, but which are not automatically mapped to generated customer group journal fields, because
the business scenario “Accounting: Coding Block to Consolidation Journal Entry” on the “Business
Scenario” tab of the “Custom Fields” app has not been enabled (case 5). Note: There is no example for
that in the screenshot.
5 The value help “Extension Field in Group Journal” contains all potential target fields for the field mapping
for data release task, independently from whether they were already mapped or not. These are …
6 … all published customer fields with business context “Group Reporting: Journal Entry Item” which are
not automatically assigned to a corresponding customer field with business context “Accounting: Coding
Block” (case 4).

Field Mapping for Data Release Task – Common Accounting Standard Fields – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Common Accounting Standard Fields – Part 2
1 A set of standard accounting journal fields (in
ACDOCA) which are also common in consolidation
(e.g. profit center, cost center, functional area,
segment, distribution channel, etc.) …
2 … are existing in group journal (ACDOCU) as well.

2 6 3 These fields are passed through every CDS view
stack the release task is using.
5 4 As these fields are existing in accounting journal and

group journal, the release task can take transaction
4 data from these fields and transfer it to group journal
without any further mapping information and there is
3 no specific customer action required (besides the
preparation of accounting integration as such) in order
to be able to transfer transaction data for these fields
to group reporting.
5 For some of the standard fields, in case they are not

relevant in the consolidation of a customer, the
customer can configure the “Aggregate Data on
Release” option for these fields in the SSCUI/IMG
activity “Configuration of Additional Characteristics”
(see next slide).
1
6 In that case transferred data is aggregated with
regards to these fields and with that only a subset of
the standard fields is transferred to group journal.
i This applies to all environments (cloud and OP, old

and new reporting logic) and all releases.
Common Accounting Standard Fields – Part 3
1 In the SSCUI / IMG activity “Define Consolidation

Master Data Fields” customers may configure the
“Aggregate Data on Release” option for standard
accounting fields which are not relevant in their
consolidation.
Data release task will subsequently aggregate

transaction data with regards to these fields and
with that only a subset of the standard fields is
transferred to group journal.
Field Mapping for Data Release Task – Additional Selected Accounting Standard Fields – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Additional Selected Accounting Standard Fields – Part 2 1 As of CE 2302 / OP 2022 FPS1 in addition to the standard
accounting journal fields which are automatically
supported in group reporting (case 1) a small set of
selected additional standard fields which are not that
common in consolidation (e.g. asset class, document type,
business transaction type, source ledger, cost analysis
resource, etc.) are supported.
3
2 Even though these fields are passed through the CDS
view stack the release task is using in case of the
integration with group reporting preparation ledger …
5
4 3 … these fields are not existing in the group journal
(ACDOCU). Instead customers that want to make use of
2 such fields in group reporting have to define a customer
field with the business context “Group Reporting: Journal
Entry Item” in the extensibility framework. This customer
field has to have the same field type and length as the
accounting journal field which shall be taken over.
4 After maintaining a field mapping of the accounting journal

field which shall be taken over and the customer field in
group journal in the SSCUI/IMG activity “Data Release
Task: Define Mapping for Jrnl Entry to Group Jrnl Entry
Fields” (see also next slide)…
1
5 … the release task takes transaction data from these
accounting fields and transfers it to the customer fields in
group journal.
i This applies to integration with group reporting preparation

ledger and actuals data in accounting journal (ACDOCA)
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public only. 102
Additional Selected Accounting Standard Fields – Part 3
2 … contains (amongst others) all standard ACDOCA fields that are supported that
way. In detail these are:
Field in
Short Description External Field Name Data Type Length
ACDOCA
1 When a new field mapping for the data release task is created in
the SSCUI/IMG activity “Data Release Task: Define Mapping for 1 Asset Class AssetClass ANKL CHAR 8
Jrnl Entry to Group Jrnl Entry Fields”, the value help for the “Field 2 Business Transaction Type BusinessTransactionType CBTTYPE CHAR 4
in General Ledger” … 3 Closing Step FinancialClosingStep CLOSINGSTEP NUMC 3
4 Cost Analysis Resource CostAnalysisResource RSRCE CHAR 10
5 Document Type AccountingDocumentType BLART CHAR 2
6 Group Asset GroupMasterFixedAsset ANLGR CHAR 12
7 Source Ledger SourceLedger RLDNR CHAR 2
8 Subledger-Specific Line Item Type SubLedgerAcctLineItemType SLALITTYPE NUMC 5

Field Mapping for Data Release Task – Other Accounting Standard Fields (OP Only) – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Other Accounting Standard Fields (OP Only) – Part 2
1 OP customers are able to create CDS view extensions using the
ADT (ABAP Development Tools). With this they may define view
extensions for the E_JournalEntryItem CDS view …
2 … which can refer to any ACDOCA standard field.
Additionally they also have to define corresponding view

4 3 extensions for the I_CnsldtnIntegRptdFinData CDS view.
! For a schematic example on the required DCS view extensions

please have a look here. Note: This example is for CO-PA
generated fields, but it can easily be transferred to ACDOCA
5 standard fields. The only difference is, that in the view extension of
the E_JournalEntryItem CDS view standard ACDOCA fields are
referenced instead of CO-PA generated fields.
3
4 Furthermore they have to define a customer field with the business
context “Group Reporting: Journal Entry Item” in the extensibility
framework. This customer field has to have the same field type
and length as the accounting journal field which shall be taken
over.
5 Last but not least a field mapping of the view extension field and
the customer field in group journal needs to be maintained in the
1 SSCUI/IMG activity “Data Release Task: Define Mapping for Jrnl
Entry to Group Jrnl Entry Fields”.
i After that the release task takes transaction data from the
2 accounting field referenced in the view extension and transfers it to
the mapped customer field in group journal.
i Creating of view extensions for the above mentioned CDS views is

only possible for OP customers. Furthermore this scenario applies
to integration with group reporting preparation ledger and actuals
data in accounting journal (ACDOCA) only.
Field Mapping for Data Release Task – Coding Block Customer Fields – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Already as of CE 1911 / OP 1909 FPS1 the transaction data of accounting customer
1 fields with business context “Accounting: Coding Block” may be transferred to group
Field Mapping for Data Release Task reporting with data release task.
Coding Block Customer Fields – Part 2 2 By enabling the entry “GR Realtime Reported Data - TAI” on the “UIs and Reports” tab
of the “Custom Fields” app for an accounting customer field with the business context
“Accounting: Coding Block”, a view extension for such a customer field in the
“I_CnsldtnIntegRptFinData” CDS view is created. This view is consumed by the data
release task to retrieve data from accounting in case of integration with group reporting
preparation ledger.
Note: In case of old reporting logic or new reporting logic with classic accounting
integration other entries have to be enabled:
By enabling the entry “GR Realtime Reported Data NRL” a view extension for such
6 a customer field in the “I_RealTimeRptdFinDataEnhcd” CDS view is created. This view
is consumed by the data release task to retrieve data from accounting in case of new
5 reporting logic and classic accounting integration and usage of customer extensibility.
By enabling the entry “GR Realtime Reported Data ORL” a view extension for such
a customer field in the “I_RealTimeRptdFinData” CDS view is created. This view is
consumed by the data release task to retrieve data from accounting in case of old
4 reporting logic and usage of customer extensibility.
3 3 By enabling the business scenario “Accounting: Coding Block to Consolidation Journal

Entry” on the “Business Scenario” tab of the “Custom Fields” app for an accounting
customer field with the business context “Accounting: Coding Block”, a corresponding
customer field with business context “Group Reporting: Journal Entry Item” is created in
2 the group journal (ACDOCU). This customer field has the same name, type, length,
value list etc. as the accounting customer field. Changes in the configuration of either
field (e.g. changes in the code list values) are synchronized with the corresponding field
(this works in both directions).
4 As soon as such an automatically created corresponding group journal customer field

exists the release task automatically maps the two fields (i.e. no dedicated field
mapping has to be maintained by the user) …
5 … and transfers transaction data from the accounting customer field to the
corresponding customer field in group journal.
Note: In case the business scenario “Accounting: Coding Block to Consolidation

6 Journal Entry” is not enabled for the coding block customer field, there is no
corresponding group journal customer field created and no automatic mapping takes
place. In this case (this is case 5 in the overview picture) customers have to create a
1 customer field and have to maintain a field mapping on their own (same as case 6
which is explained on the next slides).
Case 4 applies to any group reporting logic (i.e. old and new group reporting logic) and
i any accounting integration (i.e. classic accounting integration and integration with
group reporting preparation ledger) and to actuals data in accounting journal
(ACDOCA) as well as plan data in accounting journal (ACDOCP) (plan data is
supported only as of OP 2023 and CE 2302).
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public Case 5 applies to integration with group reporting preparation ledger and 107
actuals data in accounting journal (ACDOCA) only.
Field Mapping for Data Release Task – Market Segment and Journal Entry Item Customer Fields – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

Market Segment and Journal Entry Item Customer Fields – Part 2
1 As of CE 2302 / OP 2022 FPS1 the transaction data of accounting

customer fields with business context “Accounting: Journal Entry
Item” and “Accounting: Market Segment” may be transferred to
group reporting with data release task by using the field mapping
for data release task.
3 By enabling the entry “GR Realtime Reported Data - TAI” on the
2
“UIs and Reports” tab of the “Custom Fields” app for an accounting
customer field with business context “Accounting: Journal Entry
5 Item” or “Accounting: Market Segment”, a view extension for such
a customer field in the “I_CnsldtnIntegRptFinData” CDS view is
4 created. This view is consumed by the data release task to retrieve
data from accounting in case of integration with group reporting
2 preparation ledger.
3 As for a customer field with such a business context no

corresponding field exists in group journal (ACDOCU), customers
have to define a customer field with the business context “Group
Reporting: Journal Entry Item” in the extensibility framework. This
customer field has to have the same field type and length as the
accounting customer field which shall be taken over.
4 After maintaining a field mapping of the accounting customer field

which shall be taken over and the customer field in group journal in
the SSCUI/IMG activity “Data Release Task: Define Mapping for
Jrnl Entry to Group Jrnl Entry Fields” …
1
5 … the release task takes transaction data from such an accounting
customer field and transfers it to the mapped customer field in
group journal.
i This applies to integration with group reporting preparation ledger

and actuals data in accounting journal (ACDOCA) only.
Field Mapping for Data Release Task – CO-PA Generated Customer Fields (OP Only) – Part 1
ACDOCU Cases:
Group Reporting
5


Accounting
OP Only
ACDOCA
OP customers only

CO-PA Generated Customer Fields (OP Only) – Part 2 1 OP customers are able to create CDS view extensions
using the ADT (ABAP Development Tools). With this they
may define view extensions for the E_JournalEntryItem
CDS view …
2 … which can refer to any CO-PA generated field in

ACDOCA (for an example see next slide).
4
3 Additionally they also have to define corresponding view
extensions for the I_CnsldtnIntegRptdFinData CDS view
(for an example see also next slide).
5 4 Furthermore they have to define a customer field with the

business context “Group Reporting: Journal Entry Item” in
the extensibility framework. This customer field has to have
3
the same field type and length as the CO-PA generated
field in accounting journal which shall be taken over.
5 Last but not least a field mapping of the view extension field
and the customer field in group journal needs to be
maintained in the SSCUI/IMG activity “Data Release Task:
Define Mapping for Jrnl Entry to Group Jrnl Entry Fields”.
1 i After that the release task takes transaction data from the
CO-PA generated field referenced in the view extensions
and transfers it to the mapped customer field in group
2 journal.
i Creation of view extensions for the above mentioned CDS

views is only possible for OP customers. Furthermore this
scenario applies to integration with group reporting
preparation ledger and actuals data in accounting journal
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public (ACDOCA) only. 111
CO-PA Generated Customer Fields (OP Only) – Part 3
1 In this schematic example an OP customer wants to

make two CO-PA generated fields in ACDOCA,
5
“BONUS_PA” and “VKGRP_PA”, available in group
4
reporting.
2 First the customer has to define a view extension (in this

example “Z_COPA_Z_JEI”) for the E_JournalEntryItem
CDS view using the ADT (ABAP Development Tools).
This view extension defines two fields “ZZ_BONUS” and

“ZZ_VKGRP” which reference the CO-PA generated
fields “BONUS_PA” and “VKGRP_PA” in ACDOCA.
3 With this the E_JournalEntryItem CDS view is extended

with the two fields “ZZ_BONUS” and “ZZ_VKGRP”.
4 In a second view extension (“Z_COPA_I_RFD”) the

3 I_CnsldtnIntegRptFinData CDS view is extended with
the two fields “ZZ_BONUS” and “ZZ_VKGRP” which
2 reference the corresponding extension fields in the
E_JournalEntryItem CDS customer view extension.
1
5 With this the I_ CnsldtnIntegRptFinData CDS view is
extended with the two fields “ZZ_BONUS” and
“ZZ_VKGRP”.
Content
Analyze


S/4HANA Cloud 2208

S/4HANA Cloud 2302

Labs Preview
More Information
113
Integration with Group Reporting Preparation Ledger – Outlook
Group View on Accounting – Slide 1
Motivation
Story 1:
As a corporate controller:
▪ I want to see real-time Group View P&L, BS, CF with any new
accounting document being reflected directly into the group view.
▪ I need access to the high-granular, most recent finance data in a group
view (incl. predictions).
Story 2:
As a company accountant submitting the data to GR, I need a system report
1 answering questions like:
▪ What has already been released and what will be the impact of another
new release (for e.g. On my P&L CF)?
▪ Where do I have reconciliation issues between accounting and GR?
▪ How is the GC amount different in GR and accounting due to the re-
translation in GR?
▪ What has been corrected in GR?
▪ Initially the lookup table for consolidation unit derivation foresees
consolidation unit “4711_A” when a posting is executed for company
code “4711” and segment “1000_A”.
Approach
▪ New Group financial review app built on accounting universal ledger
▪ Exposing accounting data into group structures
▪ With predefined column structures tailored for story 1 and story 2
Note
This roadmap information can be changed by SAP at anytime.
Refer to the link below for up-to-date information:
Link to the innovation
Integration with Group Reporting Preparation Ledger – Outlook
Group View on Accounting – Slide 2
Story 2:
As a company accountant submitting the data to GR, I need a report clearly indicating the status of my submission and answering questions like:
▪ What has already been released and what will be the impact of another new release (e.g. on my P&L CF)?
▪ Where do I have reconciliation issues between accounting and GR?
▪ How is the GC amount different in GR and accounting due to the re-translation in GR?
▪ What has been corrected in GR?
Amount in Local Crcy Amount in Group Crcy
Acc all Acc released Group Reporting Acc to be released Acc all Acc released Acc to be released GR released (@spot) GR translated (@clo)
ACDOCA ACDOCU ACDOCA ACDOCU
Note:
Accounting real- Accounting Accounting Group Group
This is a conceptual screen design picture. time view released impact of Reporting as Reporting,
The final implementation may look different and may contain ignoring release data next release translated in re-translated
different information! accounting, in GR, e.g.
© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public e.g. @spot @closing or 115
rate average rate
Prepare
Content
Analyze Collect
Consolidate

S/4HANA Cloud 2208

S/4HANA Cloud 2302

Labs Preview
More Information
116
SAP S/4HANA Cloud for group reporting
SAP Help Portal and Consulting notes
SAP Help Portal S/4HANA for group reporting Cloud

https://help.sap.com/S4_CE_GR
S/4HANA for group reporting On Premise

https://help.sap.com/S4_OP_GR
Group Reporting Data Collection (GRDC)

https://help.sap.com/viewer/product/SAP_Group_Reporting_Data_Collection/1.0/en-US
Consulting Notes 2659672 - FAQ about SAP S/4HANA Finance for group reporting (On Premise)
https://launchpad.support.sap.com/#/notes/2659672
2659656 - FAQ about SAP S/4HANA Cloud for group reporting

2916087 – Configuration guide for IC Matching & Reconciliation

3048807 - Group Reporting: Combined stack of Old and New reporting logic is delivered with S4H 2105 CE
SAP Road Map Explorer
SAP Road Map https://roadmaps.sap.com/board?BC=6EAE8B27FCC11ED892E919ED096400CC&range=FIRST-LAST
SAP Community, release blogs
Join our Group

https://community.sap.com/topics/s4hana-group-reporting
Reporting community
Product Engineering
https://blogs.sap.com/2019/05/13/sap-s4hana-finance-for-group-reporting-product-strategy/
strategy
New features’ in Group

https://blogs.sap.com/2020/05/20/sap-s-4hana-finance-for-group-reporting-release-blogs/
Reporting / SAP Blogs
SAP Community, how-to guides
How to create your own https://blogs.sap.com/2019/12/25/embedded-analytics-sap-analytics-cloud-in-sap-s-4hana-cloud-how-to-

Dashboard/Story create-your-own-dashboard-or-story/
How to create Data Analyzer https://blogs.sap.com/2019/12/29/embedded-analytics-sap-analytics-cloud-in-sap-s-4hana-cloud-how-to-

Report create-data-analyzer-report/
How to transport Embedded https://blogs.sap.com/2019/12/29/embedded-analytics-sap-analytics-cloud-in-sap-s-4hana-cloud-how-to-

Story/Data Analyzer Report transport-embedded-story-data-analyzer-report/
Intercompany Matching
https://www.youtube.com/watch?v=05jadAXVlEY
and Reconciliation video
Thank you.
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.

GRPL

Uploaded by

Copyright:

Available Formats

GRPL

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GRPL

Uploaded by

Copyright:

Available Formats

Integration with Group Reporting Preparation Ledger

S/4HANA Cloud 2202 – 2208 – 2302

March 2023, SAP Product Engineering

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 2

Revision March 2023

Screenshots Screenshots in this presentation are taken from S/4HANA Cloud.

Feature S/4HANA Cloud Release S/4HANA OP Release

Initial scope of integration with GR preparation ledger 2202 2021 FPS1

Special Topic – Flexible Derivation of Consolidation Units

Special Topic – Field Mapping for Data Release Task

Outlook – Group View on Accounting

Special Topic – Flexible Derivation of Consolidation Units

Special Topic – Field Mapping for Data Release Task

Outlook – Group View on Accounting

„Classic“ Accounting Integration Integration with Group Reporting

During data release consolidation specific information working in

3 Consolidation Version Management 4 Consolidation Unit Master Data 14

As of fiscal year 2023:

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 9

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 10

Every „Group Reporting Preparation Ledger“ entry consists of:

Accounting-side group reporting preparation

Accounting-side entity close

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 12

Remark for extension ledgers:

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 13

Delete the entry of a group reporting preparation ledger:

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 14

Opening reclassification subitems:

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 17

1 1) A company needs to be assigned to the consolidation unit.

i In earlier releases the company assignment to consolidation unit

1 As of S/4HANA 2208 release the company assignment to

This assignment is time-dependent. So it can change over time and

Any company existing in accounting may be assigned (no matter

1 The same company may be assigned to several consolidation

Every consolidation unit may have assigned only one company at a

i Note: In case the company assignment is changed for fiscal year

1 Before the „From Year for Preparation Ledger“ the company

2 Therefore the company field is read only in that case.

1 Whenever a key identical company exists, this is automatically

3 Whereas when such a key identical company does not exist,

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 20

1 Plan versions don’t support group reporting preparation ledgers.

I.e. the company assignment cannot be explicitly maintained but in

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 21

Maintenance of Company Assignment to Consolidation Units - Summary

Time before Time as of

2 2 Company assignment is maintained automatically

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 22

i In the „Define Consolidation Units“ app this option is only

2 If any of the before listed checks is not successful, the

2 In SSCUI (Configure Your Solution → Finance → Corporate Close → Basic

3 In case no group reporting preparation ledger is assigned to the consolidation

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 24

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 25

2 In SSCUI (Configure Your Solution → Organization → Organization→ Assign Company

© 2023 SAP SE or an SAP affiliate company. All rights reserved. | Public 26

In the initial scope of integration with group reporting preparation ledger

As of S/4HANA 2208 the local currency of a consolidation unit may change