Logic Configuration Steps

Before you start creating the logic, you should familiarize yourself with the data that you will be using and you should have a general idea of what you want to achieve by the price optimization. To create a new model logic, go to Administration > Logics > PO Models.

In the backend, the Optimization Model is an object similar to a Datamart or a Data Source. It has its own DB table and a calculation configuration that stores the parameters and a calculation logic associated with the model. Additionally, it has a ModelFormulaContext that provides access to Optimization-specific functionality. When saving a model, its table fields are updated and a default Data Load of type Model Calculation is created.

The optimization process has several phases called Calculation Contexts and the structure of your logic will reflect this fact. There are currently 5 supported Calculation Contexts – Definition, Calculation, Analysis, Evaluation and Record and they can be set in the Calculation Context attribute of the main logic elements. Only the elements without Calculation Context or with matching Calculation Context will be evaluated in each phase. Additionally, there can be a separate sub-logic with elements for Analysis and Evaluation phase and each of the Calculation sub-steps. The name of a sub-logic must be the same as the main logic’s name with a corresponding suffix (“_Analysis”, “_Eval” or “_CalculationSubStepName”). These sub-logics can only be used if the Data Load of the model has the Allow distributed calculation checkbox checked (it is checked by default). A sub-logic cannot populate the model’s data table.

Details on Calculation Contexts

Definition

• Elements with this calculation context are executed:

  • After the logic is selected in the Logic Setup section of the Definition step.

  • When returning to the Definition step after navigating away to another step.

  • Each time an input is set/modified in the Definition step.

  • When the Definition is saved.

• In this step it is recommended to define at least:

  • User input for the transaction data source, usually a Datamart (the allowed source types – Data Source, Datamart, or even another Model).

  • A filter on the transaction source. Minimally, rows with zero quantity, zero or negative revenue and negative margin should be filtered out. Many times, certain document types such as credit and debit notes are filtered as well. In fact, establishing the set of transaction to be used is one of the most important points to get right, but fortunately the configuration effort is minimal as it merely involves setting the necessary filter criteria using the UI Filter Builder. It should be noted that the filter, or part of it, can be programmatically generated in the logic.

  • User inputs for mapping measures to actual variables in your data. The need for this is obvious: customers are free to name their transaction source fields any way they like, but Optimization needs to know where to get measures like revenue, margin, volume etc. from. You can program it to behave like a configurator – user's selection of a Datamart populates drop-down lists with options. The input parameters can be added to the model's definition using the model.def map.

  • A data model that is used in case you plan to store data in the model so that all the queries are run against the model’s data making the calculations quicker. Creating data fields in the model can be done using the model.addField function. The fields are created when you save the Definition.

Calculation

• This is where the actual calculation takes place.

• Elements with this calculation context are executed when the Model Calculation Data Load (DL) is run. The usual way to trigger the calculation is via the 'Calculate' button in the Calculation step.

• The calculation phase can have multiple sub-steps (for example, the reference logic implements sub-steps like DataPrep, DataProfile, PriceDrivers, Segmentation…). These sub-steps are configurable using the model.calculationStepsEntry method. The UI will automatically show a tab for each configured calculation step.

• When a calculation step is run, a calculation item is created/updated with the name of the step. It contains the logic outputs and calculation status. Calculation items are stored in a Company Parameter table and they can also be reviewed in the Parameters tab in the model.

• A calculation step can pre-create calculation items for another step using the model.addOrUpdateCalcItem method. In that case, the other step will be executed as a list processing operation for each calculation item (with api.currentItem function available – it returns the Data Load). Such a list can also be calculated incrementally – only the items that do not have OK Status will be processed. Within the logic, incremental calculation can be identified using api.currentItem().incremental flag and can be handled differently.

Analysis

• Elements with this calculation context are executed when navigating to the Analysis step.

• It is a custom to provide insight into the calculation results (mostly the segment level aggregated data) in a number of dashboard-like charts and tables.

Evaluation

• Elements with this calculation context are executed when navigating to the Evaluation step.

• This calculation phase should provide a way to access the outputs of the model and also some insights into these outputs.

Record

• Elements with this calculation context are executed when a Policy Record is calculated. Policy Records can be calculated within the main calculation phase or in the Policy Record UI, when opening and calculating/saving/submitting a Policy Record.

Each phase of the logic can have its inputs and outputs. These are displayed in a simple dashboard-like view with two blocks – Parameters and Results. The Parameters block contains the model inputs and the Results block contains the outputs. The Results block can hold up to 3 portlets:

1. Simple calculation results are displayed in the top-right portlet.

2. The first complex calculation result is stored in the left portlet.

3. The second complex calculation result is stored in the bottom-right portlet.