Table of Contents:

Overview on this Blog

Hi SAP Community,
This is part three of a three part blog series on How to Build a GL Account Hierarchy for SAC Planning with CDS Views.

Part1 – Loading the ID & DESC of the GL Part2 – Loading the hierarchyPart3 – Loading the Desc for the Hierarchy nodes 👈

In Part 1, we focused on loading the GL Account ID and Description into an SAC public dimension by selectively filtering GLs from the Financial Statement Version (FSV).
In Part 2, we built the GL hierarchy structure, covering both leaf-level GLs and header nodes using CDS views.

In this final part, we will complete the hierarchy setup by loading the descriptions for hierarchy header nodes, so that the hierarchy in SAC is not only functional but also readable and user-friendly. Without descriptions , the Header nodes appear with technical IDs and the hierarchy becomes difficult to understand for business user.

Approach

The idea here is simple, the hierarchy structure is already available in ZCDS_GLHIER_FLAT_SAC. The hierarchy node texts are stored in HRRP_NODET. We join both using the hierarchy node ID. This approach ensures the texts are dynamically picked up from the source system and any changes to node descriptions are reflected automatically in SAC.

Technical Details & Source Code

@AbapCatalog.sqlViewName: ‘ZSQL_HIERTXT’
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: ‘Text for Hierarchy nodes’
@Analytics.dataExtraction.enabled: true
@OData.publish: true
define view ZCDS_GLHIER_TXT as select distinct from
ZCDS_GLHIER_FLAT_SAC as a left join hrrp_nodet as b on
a.Parent = b.hrynode {
key a.Parent,
b.nodetxt,
a.MasterParent,
case when a.Parent=’0FSV1′ then ” else a.SACAccountType end as SACAccountType
}
where b.hryid=’FSV1′ and b.spras=’E’ — Choose your FSV and Language key as English

Handling SACAccountType for hierarchy nodes

In many systems, SACAccountType is not maintained at hierarchy node level. In such cases, we can derive or retain the account type based on the master hierarchy branch. This is important because:

SAC relies on SACAccountType to understand sign behavior.Expense and Liability nodes need to subtract during aggregation.Income and Asset nodes need to add.

By passing or deriving the account type consistently, we ensure correct aggregation behavior across all hierarchy levels.

P.S: In scenarios where hierarchy nodes involve multiple account types, inverse formulas can be provided to help SAC handle aggregation events correctly.

Loading hierarchy node descriptions in SAC

Hierarchy texts are loaded as a separate query in the SAC public dimension using our ZCDS_GLHIER_TXT CDS view. Only hierarchy node descriptions are updated whereas the existing hierarchy structure remains unchanged. Once this step is completed both GL accounts and hierarchy nodes display meaningful texts. The GL Account Public dimension will be fully ready and can be used in the planning model. This when consumed in the Input sheets becomes easier to understand for users.

The sample result would be like this.

Description

Hierarchy

Account type

40010000

Revenue – Good (Export)

FSV1_019

INC

40010001

Revenue – Good (Service)

FSV1_019

INC

FSV1_08

Turnover

FSV1_0FSV1

INC

FSV1_09

Cost of Sales

FSV1_0FSV1

INC

FSV1_011

Other Income

FSV1_0FSV1

INC

FSV1_017

Taxation

FSV1_0FSV1

INC

FSV1_018

Local Sales

FSV1_08

INC

FSV1_019

Export Sales

FSV1_08

INC

FSV1_020

Lease Income

FSV1_08

INC

FSV1_0FSV1

Financial statement

FSV1_

FSV1_

<root>

With this final step:

GL Account IDs and descriptions are loadedHierarchy structure (leaf and header nodes) is builtHierarchy node descriptions are applied

This completes our end-to-end setup of a future-proof GL Account public dimension for SAC Planning using CDS views.

Conclusion

In this three-part series, we covered how to build a clean and scalable GL Account hierarchy for SAC Planning by selectively extracting FSV branches, constructing the hierarchy using CDS views, and finally enriching it with hierarchy node descriptions. This approach helps keep the SAC model & Input sheet clean, planning-friendly, and adaptable to future changes in the source system.

I hope this blog was helpful and proves useful for your upcoming planning implementations. If you found it helpful, feel free to hit a like, follow my profile, and drop a comment below. I’d love to hear your feedback.

Table of Contents:Overview on this BlogHi SAP Community,This is part three of a three part blog series on How to Build a GL Account Hierarchy for SAC Planning with CDS Views.Part1 – Loading the ID & DESC of the GLPart2 – Loading the hierarchyPart3 – Loading the Desc for the Hierarchy nodes 👈In Part 1, we focused on loading the GL Account ID and Description into an SAC public dimension by selectively filtering GLs from the Financial Statement Version (FSV).In Part 2, we built the GL hierarchy structure, covering both leaf-level GLs and header nodes using CDS views.In this final part, we will complete the hierarchy setup by loading the descriptions for hierarchy header nodes, so that the hierarchy in SAC is not only functional but also readable and user-friendly. Without descriptions , the Header nodes appear with technical IDs and the hierarchy becomes difficult to understand for business user. ApproachThe idea here is simple, the hierarchy structure is already available in ZCDS_GLHIER_FLAT_SAC. The hierarchy node texts are stored in HRRP_NODET. We join both using the hierarchy node ID. This approach ensures the texts are dynamically picked up from the source system and any changes to node descriptions are reflected automatically in SAC. Technical Details & Source Code@AbapCatalog.sqlViewName: ‘ZSQL_HIERTXT’
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: ‘Text for Hierarchy nodes’
@Analytics.dataExtraction.enabled: true
@OData.publish: true
define view ZCDS_GLHIER_TXT as select distinct from
ZCDS_GLHIER_FLAT_SAC as a left join hrrp_nodet as b on
a.Parent = b.hrynode {
key a.Parent,
b.nodetxt,
a.MasterParent,
case when a.Parent=’0FSV1′ then ” else a.SACAccountType end as SACAccountType
}
where b.hryid=’FSV1′ and b.spras=’E’ — Choose your FSV and Language key as EnglishHandling SACAccountType for hierarchy nodesIn many systems, SACAccountType is not maintained at hierarchy node level. In such cases, we can derive or retain the account type based on the master hierarchy branch. This is important because:SAC relies on SACAccountType to understand sign behavior.Expense and Liability nodes need to subtract during aggregation.Income and Asset nodes need to add.By passing or deriving the account type consistently, we ensure correct aggregation behavior across all hierarchy levels.P.S: In scenarios where hierarchy nodes involve multiple account types, inverse formulas can be provided to help SAC handle aggregation events correctly.Loading hierarchy node descriptions in SACHierarchy texts are loaded as a separate query in the SAC public dimension using our ZCDS_GLHIER_TXT CDS view. Only hierarchy node descriptions are updated whereas the existing hierarchy structure remains unchanged. Once this step is completed both GL accounts and hierarchy nodes display meaningful texts. The GL Account Public dimension will be fully ready and can be used in the planning model. This when consumed in the Input sheets becomes easier to understand for users.The sample result would be like this. IDDescriptionHierarchyAccount type40010000Revenue – Good (Export)FSV1_019INC40010001Revenue – Good (Service)FSV1_019INCFSV1_08TurnoverFSV1_0FSV1INCFSV1_09Cost of SalesFSV1_0FSV1INCFSV1_011Other IncomeFSV1_0FSV1INCFSV1_017TaxationFSV1_0FSV1INCFSV1_018Local SalesFSV1_08INCFSV1_019Export SalesFSV1_08INCFSV1_020Lease IncomeFSV1_08INCFSV1_0FSV1Financial statementFSV1_ FSV1_ <root> With this final step:GL Account IDs and descriptions are loadedHierarchy structure (leaf and header nodes) is builtHierarchy node descriptions are appliedThis completes our end-to-end setup of a future-proof GL Account public dimension for SAC Planning using CDS views. ConclusionIn this three-part series, we covered how to build a clean and scalable GL Account hierarchy for SAC Planning by selectively extracting FSV branches, constructing the hierarchy using CDS views, and finally enriching it with hierarchy node descriptions. This approach helps keep the SAC model & Input sheet clean, planning-friendly, and adaptable to future changes in the source system.I hope this blog was helpful and proves useful for your upcoming planning implementations. If you found it helpful, feel free to hit a like, follow my profile, and drop a comment below. I’d love to hear your feedback. Read More Technology Blog Posts by Members articles