*DESTINATION_APP

Syntax

*DESTINATION_APP = {app name}

Often, the destination model shares only some of the dimensions of the original model. In this case, the missing dimensions can be dropped from the original records with the instruction:

*SKIP_DIM= {dimension name}[,{dimension name},…]

When the original model has dimensions that are not found in the destination model, the SKIP_DIM keyword is mandatory. Validation cannot pass without the SKIP_DIM keyword.

Multiple dimension names can be supplied to the instruction separated either by commas or by multiple SKIP_DIM instructions entered on separate lines.

If the destination model has dimensions that do not exist in the original model, these can be added to the passed records, using the instruction:

*ADD_DIM {dimension name}={value}[,{dimension name}={value} [, {dimension name} = {dimension name(source): Property name}, #]

Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple ADD_DIM instructions entered on separate lines. Dimension properties (dimension from the source model) are also supported.

Example:

The keyword RENAME_DIM can be used, to change name of one or more dimensions. The syntax is:

*RENAME_DIM {dimension name}={value}[,{dimension name}={value},…]

This instruction can be used when data is to be written into a model where a dimension is named with a different ID.

Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple RENAME_DIM instructions entered on separate lines.

Any combination of the three keywords, above, is supported.

Examples

Example 1

Environment: EnvironmentShell_V

Model: PLANNING

In this example, EnvironmentShell_V is a copy of EnvironmentShell and COPY_PLANNING is a copy of the PLANNING model. You can execute the script, shown in this example, in a PLANNING model to copy ACTUAL data to the COPY_PLAN model.

If the *DESTINATION_APP command appears once in the middle of the script, all remaining data writing of the script logic file occurs in the referenced destination model. Any data writes before the *DESTINATION_APP are written in the model where the script is currently being run.

               *XDIM_MEMBERSET TIME = 2006.AUG
               *XDIM_MEMBERSET CATEGORY=ACTUAL
               

               *DESTINATION_APP=COPY_PLANNING
               *WHEN CATEGORY
               *IS "ACTUAL"
               *REC(EXPRESSION=%VALUE%)
               *ENDWHEN
            

Example 2

To explain DESTINATION_APP with SKIP_DIM, ADD_DIM, and RENAME_DIM, another model DETAIL_PLAN is created by copying the PLANNING model from the delivered EnvironmentShell. It is necessary to:

• Create new dimensions PRODUCT and MARKET and add these to the DETAIL_PLAN model

• Replace P_ACCT with P_ACCTDETAIL

• Remove the P_ACTIVITY dimension from the DETAIL_PLAN InfoProvider

               *XDIM_MEMBERSET TIME = 2006.AUG
                *XDIM_MEMBERSET CATEGORY=ACTUAL
               

               *DESTINATION_APP=DETAIL_PLAN
               *SKIP_DIM = P_ACTIVITY
               *ADD_DIM P_DATASRC=INPUT, PRODUCT = NO_PRODUCT, MARKET = NO_MARKET
               *RENAME_DIM P_ACCT=P_ACCTDETAIL
               

               *WHEN CATEGORY
                       *IS "ACTUAL"
                       *REC(EXPRESSION=%VALUE%)
               *ENDWHEN
            

Explanation

DETAIL_PLAN is the target model, which has all dimensions of PLANNING except for P_ACCT. This dimension is replaced with P_ACCTDETAIL. Also, DETAIL_PLAN has two additional dimensions, namely PRODUCT, and MARKET.

The above script logic moves the data into DETAIL_PLAN with:

• Blank data in the PRODUCT and MARKET dimensions

• P_DATASRC defined by the keyword INPUT

• corresponding values of P_ACCT copied to P_ACCTDETAIL