Professional Documents
Culture Documents
Time Charateristics and Current Member Variables: Symptom
Time Charateristics and Current Member Variables: Symptom
Symptom
Symptom 1:
A query is using a current member variable, for example, defined on 0CALDAY.
The query also uses a different time characteristic from the one that current member variable is defined on. For
example, 0CALMONTH is in drill down.
When run the query in RSRT, it hits an exception and gets error information as below:
Symptom 2:
A query is using a current member variable defined on 0CALMONTH
0CALDAY is added into section "Free Characteristics", drill down in row/column, or used in a global filter
When save the query, or run it in RSRT, it hits and exception and gets error information as below:
Element "xxxx": CURRENT MEMBER not compatible with free characteristic "Calendar Year/Month"[0CA
LMONTH] (BRAIN_DEV 050)
Symptom 3:
There are two reference time characteristics ZCALMONTH and ZCALYEAR in the infoprovider.
ZCALMONTH refers to 0CALMONTH
ZCALYEAR refers to 0CALYEAR
In the query, you have restricted a key figure with current member variable on ZCALMONTH
In the query result, when ZCALMONTH is drilled down, the key figure is cumulated along ZCALMONTH.
When you only have ZCALYEAR in drill down, the key figure is not cumulated along ZCALYEAR.
Environment
BW 7.4 SP05 above
Cause
Current member variables can work for standard time characteristics (except 0CALMONTH2, 0FISCPER3) delivered in
BI_CONT and time characteristics refer to them. See details at: Current Member Variables.
The derivation relationship of standeard time characteristics is taken into account in the query result. That is:
1. If you define current member variable on 0CALMONTH, the value will also be cumulated if you drill down 0CALYEAR
only.
2. Only time characteristics that can be derived from the one current member variable is defined on, are allowed in the global
filter or as a free characteristic. (In Symptiom 2, you can add 0CALYEAR as a free characteristic. 0CALDAY is not allowed.
Because 0CALYEAR value can be derived from 0CALMONTH, while 0CALDAY can't.)
To make sure query can get a correct result in different navigation states, time dimension consistency is a pre-requisite. Read
more about time consistency in KBA 1772036. (Symptom 1)
But for a user defined time characteristic that refers to a standard time characteristic, the relationship of different time
characteristics is undefined.
In the example described in the symptom 3, you may save document creation time in 0CALMONTH. In ZCALMONTH
it might be the goods delivery time. The meaning of ZCALYEAR (also its relationship with other time characteristics) is purely
user defined. System can't know in general whether ZCALYEAR should align with ZCALMONTH or 0CALMONTH.
Therefore in the query result, ZCALMONTH is treated as a normal characteritic, no time derivation relationship is
considered. (Symptom 3)
Resolution
0CALMONTH2 and 0FISCPER3 is NOT supported for current member feature. See detailed list of restrictions at
online help.
Standard time characteristics (0CAL* and 0FISC*) will use the time derivation relationship. Please make sure the time
dimension of the infoprovider is consistent (or the standard time characteristics fields are consistent in aDSO).
You can check and correct the time dimension inconsistency in transaction RSRV -> Tests in Transaction RSRV ->All
Elementary Tests -> Transaction Data -> Consistency of time dimension for InfoCube
Even if you are sure the data in cube or aDSO is consistent, still please run this check so that the correct time consistency
flag is set as below:
A reference time characteristic is treated as a normal characteristic. No time derivation relationship is considered. If you
need the time derivation relationship in the query result, please use standard time characteristic instead.
Keywords
referencinig, CurrentMember, BRAIN_DEV054, BRAIN_DEV050
Attributes
Key Value
Products
Products