THJ is a feature for hierarchies with a time-dependant structure. In these kind of hierarchies, nodes and leaves can exist more than once with each node/leaf having its own time-validity (→ see here). Only the ones valid for the relevant hierarchy-keydate are displayed in the reporting. With the Temporal Hierarchy Join it's possible to evaluate the hierarchy historically. Hierarchy nodes that are assigned to different places in the hierarchy structure are then displayed more than once.
In the QueryDesigner a derivation type for the keydate needs to be specified in order to activate this THJ feature. The derivation type is maintained in transaction RSTHJTMAINT. It specifies the rule for determining the keydate from the data(data records retrieved by the query).
- First determine the time characteristic
- Specify how the keydate is derived from the time characteristic. The following derivation types are available:
- First day of the period
- Last day of the period
- Offset by number of days
After maintaining the derivation type in transaction RSTHJTMAINT, the THJ-feature can be set to active in the QueryDesigner for the hierarchy by specifying the deriv. type.
SAP Online Documentation
We have the following hierarchy and the following booked data in the provider the query is based on:
A query using hierarchy "0D_FC_SEMP_HIER001" (shown above) without the THJ-feature and keydate 15.08.2004 displays the following hierarchy-structure in the query-result:
All leaves appear only once, hanging under the relevant node valid for the specified keydate. Lets focus on leaf "Birgitta Kivi" (node '2') for this example. This leaf is displayed under node "Sales Organization - Orange" since the validity interval of this leaf (01.01.2003 - 15.12.2004, see Fig.4) is relevant for keydate 15.08.2004. The value displayed for this leaf is 27.
With THJ active
With THJ the keydate is retrieved from the data using the time-characteristic maintained in the derivation-type. We get the following displayed for hierarchy "0D_FC_SEMP_HIER001" after activating the THJ-feature in the query (see Fig.3):
In order to understand the THJ-feature more easily, the time-characteristic "Calendar Year/Month" used in the derivation-type "SEMP_THJT1" (Fig.2) is drilled down in the query-result:
The derivation-type "SEMP_THJT1" (Fig.2) retrieves the last day of the booked "Calendar Year/Month"-value. This keydate is used to display the valid hierarchy-leafs/nodes in the query-result. As an example we focus again on leaf "Birgitta Kivi" (node "2):
|Netsales||keydate retrieved |
|parent-node in THJ-hierarchy||node-validity in hierarchy "0D_FC_SEMP_HIER001"||comments|
|Birgitta Kivi||12.2004||2 EUR||31.12.2004||"Sales Organization - Hutchisson"||16.12.2004 - 15.06.2006|
|12.2006||2 EUR||31.12.2006||"Not assigned"-node||not part of hierarchy|
"Birgitta Kivi" is only part of the hierarchy for the following validity-intervals:
|03.2007||2 EUR||31.03.2007||"Not assigned"-node||not part of hierarchy||see row 2|
|05.2007||3 EUR||31.05.2007||"Not assigned"-node||not part of hierarchy||see row 2|
|10.2007||3 EUR||31.10.2007||"Not assigned"-node||not part of hierarchy||see row 2|
|11.2007||15 EUR||30.11.2007||"Not assigned"-node||not part of hierarchy||see row 2|
Only leaf "Birgitta Kivi" with "Calendar Year/Month"= DEC 2004 and Netsales = 2 EUR is displayed in the THJ-hierarchy. The remaining data-records for "Birgitta Kivi" (Netsales = 25 EUR in total) are booked for "Calendar Year/Month" = 12.2006 - 11.2007" and "Birgitta Kivi" is only part of the hierarchy until 15.06.2006. That's the reason why 25 EUR are displayed under the "not assigned"-node for "Birgitta Kivi".
There are new objects: for each infoobject "IOBJ" which supports THJ-hierarchies an additional characteristic "IOBJ1" (with 1 at the end of the technical name) is created.
- In table RSRHIEDIR_OLAP we get two entries for the THJ-hierarchy. Both entries contain '?' in the SVER-field. The entry with the negative HIESID refers to the hierarchy regarding the technical infoobect "IOBJ1" (in our example 0D_FC_PERS1, note: we have 0D_FC_PERS1 and not 0D_FC_SEMP1, since 0D_FC_SEMP refers to 0D_FC_PERS):