If the SAP-BW (or BI) is chosen as a data warehouse solutions for Generating Financial application component reporting requirements (like Analytical, Operational, etc) where the GL account hierarchy (as shown in the Figure 1) is used extensively to generate the reports as per selected GL account sub-groups and in the BW system if there is any scenario where an ABAP code is written in the one of the update rules of Info cube or ODS (as shown in the Figure 2) where the selected GL accounts are hard coded (as shown in the Figure 3) then the post maintenance at the BW side after changes happened at the SAP-R/3 side GL Hierarchy will have consequence like Data deletion, re-loading, writing ABAP code for new addition or deletion of GL Account in the update rule start routine and move the CTS across landscape, etc, 
In order to minimize the post changes of SAP-R/3 GL hierarchy impact at BW side if any scenarios are exist as said above, the below given sample ABAP code will enable the dynamic changes of GL accounts, which mean if any changes happened at selected GL hierarchy Group or sub-group then we don’t need to alter the update rules start routine-ABAP code at the BW side, as the data get populated into the info cube or ODS automatically. Sample ABAP code to enable the dynamically data getting populating into the Info cube or ODS, the code which is predominately worked based on GL account group instead of selected GL accounts DATA: PARENTID TYPE /BI0/HGL_ACCOUNT-PARENTID, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, NODENAME1 TYPE /BI0/HGL_ACCOUNT-NODENAME, FLAG TYPE C. DATA: BEGIN OF I_HNODES OCCURS 0, NODEID TYPE /BI0/HGL_ACCOUNT-NODEID, IOBJNM TYPE /BI0/HGL_ACCOUNT-IOBJNM, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, END OF I_HNODES. DATA: BEGIN OF I_GLNODES OCCURS 0, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, PARENTID TYPE /BI0/HGL_ACCOUNT-PARENTID, END OF I_GLNODES. DATA: temp_GL(10) type n. SELECT NODEID IOBJNM NODENAME FROM /BI0/HGL_ACCOUNT INTO TABLE I_HNODES WHERE OBJVERS = 'A' AND IOBJNM = '0HIER_NODE' AND TLEVEL = '03' NODENAME LIKE 'AMER%' IF SY-SUBRC EQ 0. SORT I_HNODES BY NODEID. ENDIF. LOOP AT DATA_PACKAGE. IF (DATA_PACKAGE-CO_AREA EQ 'AMER'). CLEAR: PARENTID, NODENAME, NODENAME1, I_GLNODES, flag. REFRESH: I_GLNODES. temp_GL = DATA_PACKAGE-GL_ACCOUNT. CONCATENATE 'GEBS' temp_GL INTO NODENAME1. SELECT NODENAME PARENTID FROM /BI0/HGL_ACCOUNT INTO TABLE I_GLNODES WHERE NODENAME = NODENAME1 AND tlevel = '04'. IF SY-SUBRC EQ 0. SORT I_GLNODES BY PARENTID. ENDIF. LOOP AT I_GLNODES. LOOP AT I_HNODES WHERE nodeid = I_GLNODES-PARENTID. MOVE I_HNODES-NODENAME TO NODENAME. IF (NODENAME = ‘AMER29’) OR (NODENAME = ‘AMER30’) OR (NODENAME = ‘AMER31’) OR (NODENAME = ‘AMER32’) OR (NODENAME = ‘AMER33’) OR (NODENAME = ‘AMER35’) OR (NODENAME = ‘AMER36’) OR FLAG = 'X'. ENDI. ENDLOOP. ENDLOOP. If flag NE 'X'. Delete DATA_PACKAGE. End if. ELSE. DELETE DATA_PACKAGE. ENDIF. ENDLOOP. Once this kind of functionality is enabled than the Business Users (Report owners) can execute their reports based on the selected GL account group or sub-group (as shown in the Figure 4) as per business reporting needs, instead of selecting GL accounts individually, this kind of scenarios also enable the cost bucket reporting scenarios 
Conclusion: With this kind of functionality, whenever at SAP-R/3 side any changes happened in the GL Hierarchy the impact at BW side will be minimal and moreover in case any commutations is missed to send a note to BW team to update the code or have a check on it or do impact analyses, the data gets populated automatically.
In order to minimize the post changes of SAP-R/3 GL hierarchy impact at BW side if any scenarios are exist as said above, the below given sample ABAP code will enable the dynamic changes of GL accounts, which mean if any changes happened at selected GL hierarchy Group or sub-group then we don’t need to alter the update rules start routine-ABAP code at the BW side, as the data get populated into the info cube or ODS automatically. Sample ABAP code to enable the dynamically data getting populating into the Info cube or ODS, the code which is predominately worked based on GL account group instead of selected GL accounts DATA: PARENTID TYPE /BI0/HGL_ACCOUNT-PARENTID, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, NODENAME1 TYPE /BI0/HGL_ACCOUNT-NODENAME, FLAG TYPE C. DATA: BEGIN OF I_HNODES OCCURS 0, NODEID TYPE /BI0/HGL_ACCOUNT-NODEID, IOBJNM TYPE /BI0/HGL_ACCOUNT-IOBJNM, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, END OF I_HNODES. DATA: BEGIN OF I_GLNODES OCCURS 0, NODENAME TYPE /BI0/HGL_ACCOUNT-NODENAME, PARENTID TYPE /BI0/HGL_ACCOUNT-PARENTID, END OF I_GLNODES. DATA: temp_GL(10) type n. SELECT NODEID IOBJNM NODENAME FROM /BI0/HGL_ACCOUNT INTO TABLE I_HNODES WHERE OBJVERS = 'A' AND IOBJNM = '0HIER_NODE' AND TLEVEL = '03' NODENAME LIKE 'AMER%' IF SY-SUBRC EQ 0. SORT I_HNODES BY NODEID. ENDIF. LOOP AT DATA_PACKAGE. IF (DATA_PACKAGE-CO_AREA EQ 'AMER'). CLEAR: PARENTID, NODENAME, NODENAME1, I_GLNODES, flag. REFRESH: I_GLNODES. temp_GL = DATA_PACKAGE-GL_ACCOUNT. CONCATENATE 'GEBS' temp_GL INTO NODENAME1. SELECT NODENAME PARENTID FROM /BI0/HGL_ACCOUNT INTO TABLE I_GLNODES WHERE NODENAME = NODENAME1 AND tlevel = '04'. IF SY-SUBRC EQ 0. SORT I_GLNODES BY PARENTID. ENDIF. LOOP AT I_GLNODES. LOOP AT I_HNODES WHERE nodeid = I_GLNODES-PARENTID. MOVE I_HNODES-NODENAME TO NODENAME. IF (NODENAME = ‘AMER29’) OR (NODENAME = ‘AMER30’) OR (NODENAME = ‘AMER31’) OR (NODENAME = ‘AMER32’) OR (NODENAME = ‘AMER33’) OR (NODENAME = ‘AMER35’) OR (NODENAME = ‘AMER36’) OR FLAG = 'X'. ENDI. ENDLOOP. ENDLOOP. If flag NE 'X'. Delete DATA_PACKAGE. End if. ELSE. DELETE DATA_PACKAGE. ENDIF. ENDLOOP. Once this kind of functionality is enabled than the Business Users (Report owners) can execute their reports based on the selected GL account group or sub-group (as shown in the Figure 4) as per business reporting needs, instead of selecting GL accounts individually, this kind of scenarios also enable the cost bucket reporting scenarios Conclusion: With this kind of functionality, whenever at SAP-R/3 side any changes happened in the GL Hierarchy the impact at BW side will be minimal and moreover in case any commutations is missed to send a note to BW team to update the code or have a check on it or do impact analyses, the data gets populated automatically.
3 Comments
