Attributes in business rules

    Attributes in business rules


    does anybody have a working example of using attribute values in a business rule. The scenario is the following, I have an accounts -dimension with P&L and Balance accounts and I need to calculate roll-ups differently depending on the type of account used. This means that I have an attribute called account_code, which details the type of account used (eg. "p" for P&L and "b" for Balance) and I need to leverage this in a business rule. There is a good working example of semi-additive behavior in this post…ht=semi-additive#post6714 .

    If you have any working example of a syntax where you use attributes in business (enterprise) rules, then I would greatly appreciate it if you could post it here. Or, if you know of another post detailing the same problem please refer me to that thread.


    well I do not know whether I understood your problem well, but using an IF-statement it may do the trick:

    Source Code

    1. ['calculated']=IF(
    2. PALO.DATA("database","#_accounts","account_code",!'accounts")=="b",
    3. calculation for balance accounts,
    4. calculation for p&l accounts
    5. )

    actually the syntax for using attr in business rules is really like for any other cube:

    Source Code

    1. PALO.DATA(database,cube,coordinates)

    transposed in attr cube:

    Source Code

    1. PALO.DATA(database,#_dim,"attribute","element")

    Post hoc, non est propter hoc

    Post was edited 1 time, last by “laloune” ().


    laloune wrote:

    transposed in attr cube:

    Code source

    like laloune says, it is like every cube.
    Info: the attruibutes are not displayed in the rule-editor. You must type it manually.

    Djordja Markovic

    Interessant things:
    Internal derby:…ad&postID=14338#post14338
    Calculate your cube size:…ad&postID=14406#post14406
    ...thanks for these answers. The remaining issue I have is, on this setup, I have to enter a business rule for each balance account separately. This is due to the fact that the target area is "static". So, for instance, if I have a business rule that states:
    ['balance'] = C: IF(AND(PALO.ELEVEL("db", "time", !'time') > 0, PALO.DATA("db", "#_account", "acccode", !'account') == "B"), PALO.DATA("db", "cube", PALO.ECHILD("Tuotekehitys", "time", !'time', PALO.ECHILDCOUNT("db", "time", !'time')), !'account', !'msr'), STET())

    Where the account is named balance and another rule for the next account let's say active:

    ['active'] = C: IF(AND(PALO.ELEVEL("db", "time", !'time') > 0, PALO.DATA("db", "#_account", "acccode", !'account') == "B"), PALO.DATA("db", "cube", PALO.ECHILD("Tuotekehitys", "time", !'time', PALO.ECHILDCOUNT("db", "time", !'time')), !'account', !'msr'), STET())

    and so on...

    I guess this is an issue with setting up a new dimension for account type, thus being able to create a more general rule, and skipping the attribute idea.

    Isn't this the general rule?

    Source Code

    1. [] = C: IF(AND(PALO.ELEVEL("db", "time", !'time') > 0,
    2. PALO.DATA("db", "#_account", "acccode", !'account') == "B"),
    3. PALO.DATA("db", "cube", PALO.ECHILD("Tuotekehitys", "time", !'time',
    4. PALO.ECHILDCOUNT("db", "time", !'time')), !'account', !'msr'), STET())

    for all accounts with accountcode = B. You only need to define the Else-case for accountcode<> B as laloune proposed.