Skip to Content

IMPLEMENTING AND DISPLAYING STANDARD HIERARCHY WITH SAP HANA


INTRODUCTION


STANDARD HIERARCHY


Definition:

Standard hierarchy is a tree hierarchy which is used to organize business processes of a controlling area. The highest node of a standard hierarchy is normally the first business process group. The groups created thereafter make of the remaining nodes of the standard hierarchy.

The standard hierarchy is assigned directly to the controlling area and has itself a set of business process groups assigned to it. This ensures that all business processes belonging to a controlling area are grouped together.

Example:

Sales Hierarchy

/wp-content/uploads/2015/03/1_664135.jpg

Root

Root is at the top of Hierarchy, It doesn’t have superior Nodes.

Nodes

The upper-most node is the root.

Each node has exactly one parent node (predecessor)

Nodes that can be posted to refer to the hierarchy basic characteristic.

Nodes that cannot be posted either text nodes or external characteristic nodes.

Leaves

A node without lower-level nodes (successors).

Consist of characteristic values for the basic characteristic.

Hierarchy Levels

The level of the node corresponds to the number of its predecessors increasing up to the root of one

All nodes on the same level of the hierarchy (nodes that are the same distance away from the root) form a hierarchy level.

The root equals level 1.

Intervals

Set of leaves that are described by its upper and lower boundaries.

Can be created if a node has more than one leaf.



STANDARD HIEARCHY IN SAP


There are different standard hierarchies available in SAP ECC like cost center, profit center, cost element etc.

There are three tables in SAP for groups in standard hierarchy.

  • SETHEADER
  • SETNODE
  • SETLEAF

SETHEADER holds the top nodes of the groups with SETTYPE either as S or B. If SETTYPE is S, then the top node has sub groups. Then take the SETNAME from SETHEADER and filter SETNODE table with SETNAME.

To build a standard hierarchy, we have to read SETNODE for each level of the hierarchy and build the tree.

In SAP, there are many different groups such as Cost Center Group, Cost Element Group, and Profit Center Group etc. Each and every group is identified with unique code in field SETCLASS (ex: 0106 for Profit Center, 0101 for Cost Center and 0102 for Cost Element Groups etc.). If the SETTYPE is B, then the top node have reached the last sub group and with that SETNAME, filter SETLEAF with SETCLASS, SUBCLASS and SETNAME.

The following is one of the examples of how a standard hierarchy looks in SAP ECC. This hierarchy is a cost center hierarchy with group (root) node C1000 and controlling area 0001.


/wp-content/uploads/2015/03/2_664217.jpg


The details of the above cost center hierarchy are provided below:

CHARACTERISTICS

DETAILS

Controlling Area

0001

Root

C1000

Nodes

C1010, C1110, C1120, C1200, C1300, C1400

Leaves

1234, 4568, 98763, C1210, C1220, C1230, C1310, C1320, C1410, C1420, C1430, C1440, C1450

Hierarchy Levels

Highest Level – 4 (1234, 4568, 98763)

Group Nodes

C1000, C1010, C1110, C1120, C1200, C1300, C1400, C1210, C1220, C1230, C1310, C1320, C1410, C1420, C1430, C1440, C1450

Cost Center (KOSTL)

1234, 4568, 98763

NOTE: Either group node or cost center will be a leaf node.

The text in the above hierarchy is description of the nodes obtained from two text tables i.e. SETHEADERT for group nodes (for all hierarchies) and CSKT for cost center (specific to cost center hierarchy).

This cost center hierarchy will be used to explain implementation of standard hierarchy in SAP HANA.


IMPLEMENTATION OF STANDARD HIERARCHIES IN SAP HANA


In ECC, there are several function modules which can be used to implement as well as display standard hierarchies. But in SAP HANA there is no Standard way to create and view this type of hierarchy (like simple parent-child and level hierarchies available).

Here the above shown cost center hierarchy will be used to explain implementation and displaying a standard hierarchy in SAP HANA.

Here group (root) node and controlling area will be required initially; hence SETHEADER table will not be used. So, only SETNODE and SETLEAF tables, group (root) node, controlling area, and CSKS (cost center), CSKT (cost center text) and SETHEADERT (group nodes text) tables will be required.

The below steps will be followed for implementation of this hierarchy:

  • Create a scripted calculation view to get parent child relation of the hierarchy using, SETNODE, SETLEAF and the module table i.e. CSKS for cost center, CSKA for cost element, CEPC for profit center etc. As in this case, we are implementing cost center hierarchy, so CSKS table will be used.
  • To get the description texts, join the text tables to the above created view. The text tables SETHEADERT for group nodes and specific text tables for the module like CSKT for cost center, CEPCT for profit center text, etc. will be used. As in this case, we are implementing cost center hierarchy, so CSKT table will be used.
  • Flatten the above parent child-relation view (with texts/description) to get level wise data/hierarchy.


STEP 1: CREATE A SCRIPTED CALCULATION VIEW TO GET PARENT-CHILD RELATION

The code below will be used to implement the above given cost center hierarchy as a parent child relation in a scripted calculation view.

Note: By doing some changes you can implement this code for other FI/CO hierarchies like cost element, profit center etc., doing some minor changes in the code. (Example: for profit center, use CEPC table will be used instead of CSKS and changing some key fields like PRCTR instead of KOSTL, and some basic conditions will be changed like SETCLASS = 0106, instead of 0101)

The following are the details of the scripted calculation view:

NAME

TYPE

PARAMETER CASE SENSITIVE

CA_HIERARCHY

Scripted

True

Input Parameters:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

ControllingArea

NVARCHAR

12

to input controlling area of the hierarchy

  1. 2.     

Group_Root_Node

NVARCHAR

24

to input the group node (root node)

Output Columns:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

MANDT

NVARCHAR

3

Client

  1. 2.     

PARENT

NVARCHAR

24

Parent group node

  1. 3.

GROUP_NODE

NVARCHAR

24

Group Node (it can also be a leaf node)

  1. 4.

COST_CENTER

NVARCHAR

24

Cost Center (this can only be a leaf node)

  1. 5.

LEVEL

INTEGER

Level of the group node/cost center (for root node, LEV = 1)

  1. 6.

CONTROLLING_AREA

NVARCHAR

4

Hierarchy controlling area (it will be same as the input controlling area)

Conditions:

  1. S. NO.

CONDITON

DETAILS

  1. 1.

SETCLASS = ‘0101’

This condition will be same for all cost center hierarchies (for profit center- 0106, for cost element – 0102, etc.)

Source Code:

/********* Begin Procedure Script ************/

/* Compute the Cost Center Standard Hierarchy */

NUM int := 0;

LEV int := 1;

BEGIN

/*In case Group_Root_Node is empty, retrieve only leaf(Cost center) node from SETLEAF table*/

if :Group_Root_Node = then

LT_CC_TMP = SELECT MANDT AS MANDT, NULL AS PARENT, NULL AS GROUP_NODE, VALOPTION AS VALOPTION, VALFROM as VALFROM, VALTO as VALTO, 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM SETLEAF

WHERE SETCLASS = ‘0101’ and SUBCLASS = :ControllingArea;

                                                

var_out = SELECT MANDT, PARENT, GROUP_NODE, VALFROM AS COST_CENTER, LEVEL, CONTROLLING_AREA

FROM :LT_CC_TMP;

                                

LT_CC_TMP2 = SELECT CC.MANDT AS MANDT, NULL AS PARENT, CC.GROUP_NODE AS GROUP_NODE, CSKS.KOSTL AS COST_CENTER, CC.LEVEL AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM :LT_CC_TMP as CC inner join CSKS as CSKS ON (CSKS.MANDT = CC.MANDT and CSKS.KOSTL >= CC.VALFROM and CSKS.KOSTL <= CC.VALTO)

WHERE CSKS.KOKRS = :ControllingArea;

                                                       

var_out = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :var_out

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_CC_TMP2;

/*If Group_Root_Node is empty, empty cost center should also be considered*/

LT_CC_TMP_2 = SELECT DISTINCT MANDT AS MANDT, NULL AS PARENT, NULL AS GROUP_NODE, AS COST_CENTER, 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM SETLEAF

WHERE SETCLASS = ‘0101’ and SUBCLASS = :ControllingArea;

var_out = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :var_out

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_CC_TMP_2;

/*Retrieve all hierarchy groups and the cost center from both SETNODE and SETLEAF, incase Group_Root_Node is not empty*/

else

LT_ROOT = SELECT DISTINCT MANDT AS MANDT, NULL AS PARENT, SETNAME AS GROUP_NODE, NULL AS COST_CENTER, 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM SETNODE

WHERE SETCLASS = ‘0101’ and SUBCLASS = :ControllingArea and SETNAME = :Group_Root_Node;

/*inacase for a group node, there is no subgroup, then it will not be in SETNODE, but only in SETLEAF*/

LT_ROOT2 = SELECT DISTINCT MANDT AS MANDT,  NULL AS PARENT, SETNAME AS GROUP_NODE, NULL AS COST_CENTER, 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM SETLEAF

WHERE SETCLASS = ‘0101’ and SUBCLASS = :ControllingArea and SETNAME = :Group_Root_Node;

                                                

LT_HIERARCHY = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_ROOT

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_ROOT2;

while 1 = 1 do

LT_HIERARCHY_TMP = SELECT part.MANDT AS MANDT, part.SETNAME AS PARENT, part.SUBSETNAME AS GROUP_NODE, NULL AS COST_CENTER, :LEV + 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM :LT_HIERARCHY as main inner join SETNODE as part ON (part.MANDT = main.MANDT and main.GROUP_NODE = part.SETNAME)

WHERE part.SETCLASS = ‘0101’ and part.SUBCLASS = :ControllingArea and main.LEVEL = :LEV;

     

SELECT COUNT(*) INTO NUM FROM :LT_HIERARCHY_TMP;

     

if :NUM = 0 then

       break;

       end if;

     

LT_HIERARCHY = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_HIERARCHY

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_HIERARCHY_TMP;

     

LEV := :LEV + 1;

end while;

LT_CC_TMP = SELECT CC.MANDT AS MANDT, CC.SETNAME AS PARENT, NULL AS GROUP_NODE, CC.VALOPTION AS VALOPTION, CC.VALFROM as VALFROM, CC.VALTO as VALTO, CC_gr.LEVEL + 1 AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM :LT_HIERARCHY as CC_gr inner join SETLEAF as CC ON (CC.MANDT = CC_gr.MANDT and CC_gr.GROUP_NODE = CC.SETNAME)                      

WHERE CC.SETCLASS = ‘0101’ and CC.SUBCLASS = :ControllingArea;

                                                

LT_CC = SELECT MANDT, PARENT, GROUP_NODE, VALFROM AS COST_CENTER, LEVEL, CONTROLLING_AREA

FROM :LT_CC_TMP;

                                

LT_CC_TMP2 = SELECT CC.MANDT AS MANDT, CC.PARENT AS PARENT, CC.GROUP_NODE AS GROUP_NODE, CSKS.KOSTL AS COST_CENTER, CC.LEVEL AS LEVEL, :ControllingArea AS CONTROLLING_AREA

FROM :LT_CC_TMP as CC inner join CSKS as CSKS ON (CSKS.MANDT = CC.MANDT and CSKS.KOSTL >= CC.VALFROM and CSKS.KOSTL <= CC.VALTO)

WHERE CSKS.KOKRS = :ControllingArea;

                                                       

LT_CC = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_CC

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_CC_TMP2;

var_out = SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_HIERARCHY

UNION

SELECT MANDT, PARENT, GROUP_NODE, COST_CENTER, LEVEL, CONTROLLING_AREA from :LT_CC;

end if;                   

END /********* End Procedure Script ************/



After executing the view for the given hierarchy, and providing the following values for the two input parameters.

/wp-content/uploads/2015/03/3_664218.jpg

The following output of the above scripted view, for the given cost center hierarchy:

  /wp-content/uploads/2015/03/4_664219.jpg

The above shown is the parent child relation of the hierarchy with cost center.

STEP 2: JOIN THE SCRIPTED HIERARCHY VIEW WITH THE TEXT TABLES TO GET DESCRIPTION TEXT


In order to get the description of a hierarchy, we need to join the scripted view (CA_HIERARCHY), with the two text tables i.e. SETHEADERT for group nodes and specific text tables for the module like CSKT for cost center, CEPCT for profit center text, etc. will be used. As in this case, we are implementing cost center hierarchy, so CSKT table will be used.

The following are the details of the calculation view:

NAME

TYPE

DATA CATEGORY

CA_HIERARCHY_DESCRIPTION

Graphical

Dimension

Required Tables/Views:

  1. SNO.

NAME

VIEW/TABLE

COMMENTS

  1. 1.     

CA_HIERARCHY

VIEW

Scripted hierarchy view

  1. 2.     

SETHEADERT

TABLE

Table containing description text for groups (i.e. COSTCENTERGROUP in this view)

  1. 3.

CSKT

TABLE

Table containing description text for cost center.

Input Parameters:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

ControllingArea

NVARCHAR

12

to input controlling area of the hierarchy (map with that of the scripted view, CA_HIERARCHY)

  1. 2.     

Group_Root_Node

NVARCHAR

24

to input the group (root) node (map with that of scripted view, CA_HIERARCHY)

Output Columns:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

MANDT

NVARCHAR

3

Client

  1. 2.     

PARENT

NVARCHAR

24

Parent group node

  1. 3.

LEVEL

INTEGER

Level of the group node/cost center (for root node, LEV = 1)

  1. 4.

CONTROLLING_AREA

NVARCHAR

4

Hierarchy controlling area (it will be same as the input controlling area)

  1. 5.

Level

NVARCHAR

24

Calculated column for level

  1. 6.

Level_Description

NVARCHAR

50

Calculated Column for level text

Join details:

  1. SNO.

LEFT TABLE

LEFT FIELDS

RIGHT TABLE

RIGHT FIELDS

JOIN TYPE

JOIN NAME

DESCRIPTION FIELDS

  1. 7.     

CA_HIERARCHY

MANDT, GROUP_NODE

SETHEADERT

MANDT, SETNAME

TEXT

Join_1

DESCRIPT

  1. 8.     

JOIN_1

MANDT, COST_CENTER, CONTROLLING_AREA

CSKT

MANDT, KOSTL, KOKRS

TEXT

Join_2

LTEXT

Filter details:

  1. SNO.

FILTER FIELDS

TABLE

FILTER CONDITION

COMMENTS

  1. 1.     

SETCLASS

SETHEADERT

SETCLASS = 0101

SETCLASS specific to cost center

  1. 2.     

SUBCLASS

SETHEADERT

SUBCLASS = 0001

SUBCLASS specific to controlling area

As explained earlier, that the leaf node will either be a group node or cost center; or cost center will always be a leaf node. So, here these two columns will be combined into one, creating a calculated column, and doing the same for description.

Following are the two calculated columns:

  1. SNO.

NAME

DATA TYPE

SIZE

FORMULA

  1. 1.     

Level

NVARCHAR

50

if(isnull(“GROUP_NODE”),“COST_CENTER”,“GROUP_NODE”)

  1. 2.     

Level_Description

NVARCHAR

50

if(isnull(“DESCRIPT”),“LTEXT”,“DESCRIPT”)

Shown below is how the semantics will look:

/wp-content/uploads/2015/03/5_664200.jpg

Notice the hidden columns (As they are not required)

Shown below is how the graphical view will look:

/wp-content/uploads/2015/03/6_664201.jpg

Shown below is how the joins will look like:

Join_1

/wp-content/uploads/2015/03/7_664220.jpg

Join_2

/wp-content/uploads/2015/03/8_664221.jpg

OUTPUT:

Provide the values to the input parameters:

/wp-content/uploads/2015/03/9_664222.jpg

The final output of this view:

/wp-content/uploads/2015/03/10_664223.jpg


STEP 3: FLATTEN THE ABOVE VIEW TO GET LEVEL WISE DATA

The above created view with the group and cost center texts, will be flattened in this step.

This is done in order to get level wise data, i.e. each row for each traversal from root node to a leaf node. And addition to that, a calculated column will be created, which will contain leaf node of each field. This calculated column can be used to join the hierarchy with the transaction data (which is one of the major reasons to flatten this hierarchy).


The following are the details of the calculation view:

NAME

TYPE

DATA CATEGORY

CA_HIERARCHY_LEVEL_FLATTEN

Graphical

Dimension

Required Tables/Views:

  1. SNO.

NAME

VIEW/TABLE

COMMENTS

  1. 1.     

CA_HIERARCHY_DESCRIPTION

VIEW

Scripted hierarchy view

Input Parameters:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

ControllingArea

NVARCHAR

12

to input controlling area of the hierarchy (map with that of CA_HIERARCHY_DESCRIPTION view)

  1. 2.     

Group_Root_Node

NVARCHAR

24

to input the group (root) node (map with that of CA_HIERARCHY_DESCRIPTION view)

Output Columns:

  1. SNO.

NAME

DATA TYPE

SIZE

COMMENTS

  1. 1.     

MANDT

NVARCHAR

3

Client

  1. 2.     

CONTROLLING_AREA

NVARCHAR

4

Hierarchy controlling area (it will be same as the input controlling area)

  1. 3.     

LEVEL1

NVARCHAR

24

Flattened column for level1

  1. 4.

LEVEL1_DESCRIPTION

NVARCHAR

50

Flattened column for level1 text

  1. 5.

LEVEL2

NVARCHAR

24

Flattened column for level2

  1. 6.

LEVEL2_DESCRIPTION

NVARCHAR

50

Flattened column for level2 text

  1. 7.

LEVEL3

NVARCHAR

24

Flattened column for level3

  1. 8.

LEVEL3_DESCRIPTION

NVARCHAR

50

Flattened column for level3 text

  1. 9.

LEVEL4

NVARCHAR

24

Flattened column for level4

  1. 10. 

LEVEL4_DESCRIPTION

NVARCHAR

50

Flattened column for level4 text

  1. 11. 

JOIN_FIELD

NVARCHAR

50

Calculated column to create a join field (to join this hierarchy with transaction tables)

Note: The maximum level here is 4, so the flattening here will be done till level 4. If the hierarchy goes beyond level 4, then further flattening will be required.

Join details:

  1. SNO.

LEFT TABLE

LEFT FIELDS

RIGHT TABLE

RIGHT FIELDS

JOIN TYPE

JOIN NAME

  1. 1.     

CA_HIERARCHY_DESCRIPTION (LEVEL = 1)

MANDT, LEVEL

CA_HIERARCHY_DESCRIPTION (LEVEL = 2)

MANDT, PARENT

Left Outer

Join_1

  1. 2.     

CA_HIERARCHY_DESCRIPTION (LEVEL = 2)

MANDT, LEVEL

CA_HIERARCHY_DESCRIPTION (LEVEL = 3)

MANDT, PARENT

Left Outer

Join_2

  1. 3.     

CA_HIERARCHY_DESCRIPTION (LEVEL = 3)

MANDT, LEVEL

CA_HIERARCHY_DESCRIPTION (LEVEL = 4)

MANDT, PARENT

Left Outer

Join_3

Filter details:

  1. SNO.

FILTER FIELDS

TABLE/VIEWS

FILTER CONDITION

COMMENTS

  1. 1.     

LEVEL

CA_HIERARCHY_DESCRIPTION

LEVEL = 1

This is to get level1 node and description

  1. 2.     

LEVEL

CA_HIERARCHY_DESCRIPTION

LEVEL = 2

This is to get level2 node and description

  1. 3.     

LEVEL

CA_HIERARCHY_DESCRIPTION

LEVEL = 3

This is to get level3 node and description

  1. 4.     

LEVEL

CA_HIERARCHY_DESCRIPTION

LEVEL = 4

This is to get level4 node and description

Calculated columns:

  1. SNO.

NAME

DATA TYPE

SIZE

FORMULA

  1. 1.     

JOIN_FIELD

NVARCHAR

24

if(isnull(“LEVEL4”),if(isnull(“LEVEL3”),if(isnull(“LEVEL2”),“LEVEL1”,

“LEVEL2”), “LEVEL3”),“LEVEL4”)

Shown below is how the graphical view will look:

/wp-content/uploads/2015/03/11_664224.jpg

Shown below is how the joins will look like:

/wp-content/uploads/2015/03/12_664225.jpg

This is the join between CA_HIERARCHY_DESCRIPTION (LEVEL=1) and CA_HIERARCHY_DESCRIPTION (LEVEL=2) i.e.Join_1.


So the following is how the semantics will look:

/wp-content/uploads/2015/03/13_664233.jpg

OUTPUT:

Provide the values to the input parameters:

/wp-content/uploads/2015/03/14_664234.jpg

The final output of this view:

/wp-content/uploads/2015/03/15_664235.jpg

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

    1. Amanpreet Singh Post author

      Hi Benedict,


      In the script view, level is one of the output field, with parent node and group node and cost center.


      In the script view you get levels dynamically.


      But you cannot flatten it without knowing the max depth, even if you implement it using a procedure or script view, as in that case also we need to mention the output columns, and that we can’t do dynamically (run time).


      So even if you use a procedure or a script view, you have to define a maximum level.

      (0) 
  1. Lars Breddemann

    I sincerely hope the “text layout and formatting police” will never see this… they would be coming after you… 😎 (<- this smiley wears glasses to prevent eye damage…)

    (0) 
  2. Michael Meusel

    Excellent write-up!

    Only thing to add is one needs to use the “Map Input Parameters” functionality of HANA Studio, to map your local parameters inside your graphical views CA_HIERARCHY_DESCRIPTION and CA_HIERARCHY_LEVEL_FLATTEN to the underlying views, as otherwise no results come out.

    Which took me 3 additional hours to find.

    One more thought on CSKT:
    I have never taken the time to identify if a HANA Text Join is a true lookup (i.e. maximum one record may come back), or is it a Left Outer?
    Because if the latter, your fetch of Cost Center Text can lead to duplication of records if different texts to the same KOSTL but different DATBI exist in selected language.

    (0) 
    1. robin hsueh

      I am stuck on step 2 trying to join the text to the CE_HIERARCHY.  I found your solution with the input parameter mappings, but still not working.  I see data coming through on the left table, but not the right table, SETHEADERT.  Any advice?

      (0) 
      1. Michael Meusel

        Check the filter conditions on SETHEADERT: the SETCLASS should equal 0101 (no quotes around it in filter condition in HANA Studio!) and the SUBCLASS should equal your Controlling Area Input Parameter $$ControllingArea$$.

        Then make sure your Text Join against that filtered SETHEADERT has the language column defined.

        (0) 
        1. robin hsueh

          Thanks Michael. I tried that and went through this document step by step at least 20x now. I think there is a bug in my software or I have issue with authorization. here is what I notice. When I do a preview on the projection of setheadert it comes up blank. I suspect this is the root of why the join is not bringing data from the right side. I previewed another developers projection of a different text table and I can see results. When I create that same projection as his, I don’t see results In The preview. I also noticed when I put an FI transaction table and join it with ce_hierarchy, I see the joins coming correctly in the preview.  I suspect there is either a security issue with creating and previewing my own text projections or I have a buggy tool. Im going to see if I can upgrade my sp. Any other thoughts? 

          (0) 
          1. Michael Meusel

            The preview on the projection of SETHEADERT comes up blank for you (but hopefully prompted you for the $$ControllingArea$$!).
            So what does the data preview directly on SETHEADERT itself come up with? If you add filters for SETCLASS and SUBCLASS in that preview, is the expected data showing up? If yes it’s difficult to believe you have a permissions issue.

            (0) 
          2. Sarah Walker

            I have the same problem in step 2, if I preview data in the projection on SETHEADERT it’s empty, even though the table is correctly populated. 

            (0) 
    2. Amanpreet Singh Post author

      Hi Michael, I have mentioned in the comments section of the input parameters, that you have to map the input  parameters (assuming that the reader is familiar with that concept i.e. how it can be done)

      and about the text join – i think that ideally each node should have only one description but different languages, so according to a text join, the description will be picked up based on the system language, so ideally cardinality should be 1:1.

      Thanks for your inputs… 🙂

      (0) 
  3. Sonni Jacobsen

    Do you recommend staging output in a table? I tried this for profit center hierarchy flattened hierarchy and have some performance issues with the code. Seems like >= inner join is the problem.


    Sonni

    (0) 

Leave a Reply