SAP BPC Version 10 – Script Logic (An overview!)

BACKGROUND:

1. Once the initial versions of dataset are chosen/prepared, there comes the need of “script logic” in BPC, which are required to help in the copy process, to apply various seasonality, to reflect external conditions to the plan data, to calculate various rebates, discounts & offers etc, Anything that your company participates in a normal business process can be integrated into the plan data, automatically using script logics. Script logics can also be used for on-the-fly-calculation (real-time) nature and also for obvious/automatic data transformations such as currency transformation, consolidation etc at a chosen/scheduled time.
2. Script Logics can be used for PLANNING; as well as for CONSOLIDATION activities.
3. Script Logics, for most of the Consolidation activities are provided through available SAP Standard scripts
4. Technically; Script Logic is always created against a model, for a model. Example model: HR, Overheads, Exchange Rates, Project systems.
5. Functional planning is done at each model, before they are merged into management model, where financial statements are formed, such as P/L Statement, Balance Sheet or a Cash flow statement.
6. And Custom built Script logics are used for COMPLEX transformation during functional planning, during management model integration, for consolidation, during transfer between the models.
7. Standard (SAP Delivered) script logics can also be used/edited before they are used for balancing the Cash flow statement or working out the Consolidation steps (Currency Translation, Intercompany elimination etc)

TECHNICAL :

1. Administration tab in BPC –> Rules –> Logic Scripts –> Select Model –> New/Edit/Delete/Copy –> Editor screen –> Add code
2. DEFAULT.LGF is the standard (SAP Delivered) script logic, which is executed anyway during any planning process. In order to achieve efficiency & easy maintenance; it is probably a good idea to include/embed all other script logics into this DEFAULT script logic using INCLUDE command.
3. During a SAVE process, data is first committed to the SELECTED model and the DEFULT logic is run on the model data.
4. DEFAULT LOGIC can also be invoked from a DATA MANAGER, during execution of a planning process.
5. Beauty is with the standard logic, “SYSTEM_CONSTANTS.LGF” which is used to default the actual “Dimension” names in the BPC system. Every time, dimension name changes, the constants in the file have to change, manually.

STRUCTURE OF SCRIPT LOGIC:

1. “Scoping” (Restrict the dataset; using which the calculation will be performed)
2. “Body part / coding” (Perform Calculation, Transformation, Aggregation etc )
3. “Commit” (Save the calculated result to the database)

TYPES OF SYNTAX IN SCRIPT LOGIC:

1. SQL based syntax (Choose this option for better performance)
2. MDX based syntax (Choose this option for specific record level calculations)

ADVANTAGES:

Helps in model level calculation, not at a member level of the dimensions. It has multiple uses, it can be done using many different ways and it can be executed from many different places and also it has many different options, as far as syntax selection goes. Name of the game is therefore; flexibility.

DISADVANTAGES:

Can’t handle very complex calculation processing or bigger data volume. That is when the ABAP-BADI option comes into picture. ABAP-BADI codes can be executed from the script logics. Script Logics can be executed/run using Data Manager. ABAP-BADIs can also be executed directly from the DATA MANAGER.

TESTING / DEBUGGING:

1. Can be done using transaction UJKT. Script Logic code can be directly inputted into the screen, data set can be selected, and Test is executed.
2. The analysis will show various things such as: data selection, performance, error analysis etc

PERFORMANCE CONSIDERATION:

1. Use *COMMIT statement as few times as possible (if possible once, at the most) in a script logic.
2. Access the complexity of the requirement and choose whether a script logic or ABAP-BADI is a better option.
3. Using MDX should be avoided as much as possible; due to lower performance reasons.
4. Use memory carefully to load only the data records, which are required in the script logic for calculation.
5. Make sure less numbers of nested statements, loops are used within the script.
6. Script logic should be used only for real-time calculations only. All other calculations for the existing data, actual data, market data; etc are completed before they are used in the planning process or in the script logic.

Good news is? You don’t need to be skilled programmer to write Script Logic. As long as you have a logical mind and you understand business process flow of your organization; you can so pretty well in Script Logic. For more complex need; when GOOGLE is here; why fear?