Show TOC

Syntax documentation*PRIOR Locate this document in the navigation structure

It might sometimes happen that two different data categories need to be linked in time for a logic calculation. A good example is a BUDGET category that must retrieve the opening balances of the balance sheet from category ACTUAL.

This link can be established with the following instruction:

*PRIOR {dimension name} = {member ID}

Example Example

*PRIOR CATEGORY = ACTUAL

End of the example.

This instruction automatically forces the retrieval of prior period’s values from a different category (in this case ACTUAL).

An alternative syntax allows the dynamic retrieval of the name of the prior category reading a property of the current category, like in this example.

Example Example

*PRIOR CATEGORY = CATEGORY.PRIORCAT

End of the example.

Note that this syntax only makes sense in a case where the logic needs to go backwards in time to retrieve values from past periods. For example, assume you want to load in memory the three months preceding the first modified month. This can be achieved with the instruction:

*XDIM_MEMBERSET TIME = PRIOR(3),%SET%

However, if the first modified period is FEB, going backwards three months crosses the year-end boundary, and NOV and DEC are retrieved from last year. Now, if last year’s data is not stored in the current category but in a different one, the above instruction works.

Important Notes

  1. The prior category does not need to be included in the set of categories to load in memory: its data is automatically loaded in memory if needed (according to the number of periods the logic goes backwards).

  2. The values of the prior category are available for processing by the logic, but it is likely that these should not be modified (last year's data might even be locked) and the logic must skip them. However, you cannot control this by checking the name of the category, for example, using the following:

    // This will not work!!!

    *WHEN CATEGORY

    *IS ACTUAL

    It is not necessary to skip the values coming from prior category, but the values coming in any of the prior periods, irrespective of whether they belong to ACTUAL or BUDGET (if the first modified period is FEB, all three periods NOV, DEC, and JAN must not be changed). This condition can be tested with these instructions:

    // This will work!!!

    *WHEN TIME

    *IS PRIOR

  3. The logic always works as if all periods come from current category, even while reading records that come from prior category. For this reason the destination category does not need to be specified in the REC instructions.

    // This will write in ACTUAL, even if reading a record coming from BUDGET *REC(ACCOUNT=”#TEMP”,TIME=NEXT(3))

  4. In lead and lag calculations, the most common (and sometimes difficult) decision to take is whether to retrieve values from the past, or push values into the future. This sometimes depends on the type of formula. In most cases, it is more practical to push values into the future using the existence of values in the past as triggers.

    // Example

    *WHEN ACCOUNT

    *IS COLLECTIBLES_AT_THREE_MONTHS

    *REC(ACCOUNT=#COLLECTIONS_AT_THREE_MONTHS, TIME=NEXT(3))

    *ENDWHEN

    Note that this logic only writes in valid periods (<>PRIOR). This is why the logic stores the value in a temporary variable (using a leading pound sign #). The temporary values can then be written only if the period is correct.

    *WHEN TIME

    *IS <> PRIOR

    *WHEN ACCOUNT

    *IS #COLLECTIONS_AT_THREE_MONTHS

    *REC(ACCOUNT=COLLECTIONS_AT_THREE_MONTHS)

    *ENDWHEN

    *ENDWHEN

  5. This instruction only works as desired if only one CATEGORY at a time is modified by the user during data entry (or processed from a Data Manager task). The administrator should somehow make sure that a logic containing this instruction is used correctly.

  6. Remember to use the above techniques with the *CALC_EACH_PERIOD option. This enforces the calculation of all periods in the correct sequence.