I'll attempt:
- It depends on if you want to surface the result/value of the compound master data type on the key figures in your planning level. If you do then you'll need to include it in the planning level.
If the question is why would I want a compound master data type, then my attempt at that answer is as follows:
- From my understanding, the idea of a compound key figure is that you are able to derive an attribute or attributes that are related to, in this case, two master data types - all without having to 'store' that attribute on the transactional record.
Here is a simplistic example:
Master data on PRODUCT (where PRODID is the key)
PRODID,PRODDESCR,PRODSIZE
P1,Widget A,Big
P2,Widget B,Big
P3,Widget C,Small
P4,Widget D,Small
Master data on CUSTOMER (where CUSTID is the key)
CUSTID,CUSTDESCR,CUSTREGION
C1,Store A,West
C2,Store B,West
C3,Store C,East
C4,Store D,East
Master data on compound MDT PRODUCT-CUSTOMER (where PRODID and CUSTID are the key)
PRODID,CUSTID,SALESREGION
P1,C1,BIG_WEST
P1,C2,BIG_WEST
P1,C3,BIG_EAST
P1,C4,BIG_EAST
P2,C1,BIG_WEST
P2,C2,BIG_WEST
P2,C3,BIG_EAST
P2,C4,BIG_EAST
P3,C1,SMALL_WEST
P3,C2,SMALL_WEST
P3,C3,SMALL_EAST
P3,C4,SMALL_EAST
P4,C1,SMALL_WEST
P4,C2,SMALL_WEST
P4,C3,SMALL_EAST
P4,C4,SMALL_EAST
Finally you have some transactional data for the Key Figure on the planning level (ex: Sales)
PRODID,CUSTID,SALES
P1,C1,10
P3,C4,15
P4,C3,30
P1,C3,20
P2,C2,15
*Note that you don't need to 'store' the sales region attribute on the record
Then on your report, you can pick the SALESREGION and get your aggregated values:
SALESREGION,SALES
BIG_WEST,25
BIG_EAST,20
SMALL_WEST,0
SMALL_EAST,45