Technical User Reference (Optimization - Price List Impact Simulation)

Owned by Jana Volencová (Deactivated)
Last updated: Jan 02, 2024
11 min read

This project is not yet an accelerator, meaning that you need to manually deploy the logics and ensure that the Price Setting Type (PLPGTT) configuration is correct. The code is available in the Price Setting Simulation repository: https://gitlab.pricefx.eu/accelerators/price-setting-simulation/

This section details the ModelClass and the logics that define the Price List Impact Simulation feature. For each step, its aim, outputs, and the main reasons to modify the logics are explained.

In this section:

Model Class Structure

The Price Setting Simulation (PSS) Model Class organizes a list of logics to create the model architecture. It is a JSON file that refers to some logics and it is transformed into an optimized UI in the Pricefx platform. See Models and Model Classes for more information.

The general architecture of the Price Setting Simulation Model Class is:

It defines two steps:

  • Input – Settings of the simulation.

  • Results – Simulation itself and its results.

There are two types of logics: calculation, which writes tables in the model, and evaluation, whose purpose is only to display some results. The standard Model Class definition is documented in Model Class (MC).

The logics of the Model Class follow a naming convention. They are all prefixed by PSS_All_, then their type is indicated by Eval or Calc. The configurations are suffixed by _Configurator.

Library

The logic is PSS_Lib.

This library contains the definition of the various columns, names, Datamart, etc. manipulated by the logics.

It is the first place where to rename the source Datamart and the fields used by the price simulation. But as this Model Class is the first step toward a generic definition of the simulation problem and its use in an accelerator, therefore some names referring to the current use case are still hardcoded in the logics. Don’t forget to check elsewhere in the other logics too.

Input Step

There is no calculation logic in this step, and there is one tab with related configurator logic PSS_All_Eval_Price_List_Configurator.

This logic allows the user to enter a set of filtering options that will be applied to the simulation. These inputs are defined in a single configurator which is displayed in the drawer when we start a simulation from a Price List.

This is the place from where the date range and the custom filters defined by the user are provided to the rest of the model.

But this logic also determines the type of the source (either a Price List or a Live Price Grid) and its ID.

Later in the logics, you will access those outputs with the command model.inputs("input", "price_list")['output key'].

The most common reason is to change the inputs in the drawer. Be careful not to use several tabs as only the first one will be rendered in the Price Setting module.

Also, keep in mind that this configurator must work from the drawer tab as well as from the Models view. The current coding of the Price List input gives an example of how to deal with this requirement with inputs initialized from configuration or awaiting input from the user depending on the use case.

Results Step

This step performs first a sequence of calculations:

  • The aggregation of the data is done by PSS_All_Calc_Aggregating.

  • The data is checked by PSS_All_Calc_Check_Data.

  • The tables that are required to instantiate the Optimization Engine are stored by the logic PSS_All_Calc_Store_Problem.

  • The Optimization Engine is set and triggered by PSS_All_Calc_Run_Simulation.

  • After its run, some postprocessing tasks are done to provide good inputs to the dashboards, in PSS_All_Calc_Prepare_Results.

Then, three tabs are displayed, based on these logics:

  • The Impact tab is based on PSS_All_Eval_Impact.

  • The Details tab is based on PSS_All_Eval_Details.

  • The Analysis tab is based on PSS_All_Eval_Analysis and PSS_All_Eval_Analysis_Configurator.

Calculation: Aggregating

The logic is PSS_All_Calc_Aggregating.

Calculation: Check Data

The logic is PSS_All_Calc_Check_Data.

Calculation: Store Problem Tables

The logic is PSS_All_Calc_Store_Problem.

Calculation: Run Simulation

The logic is PSS_All_Calc_Run_Simulation.

Calculation: Prepare Results

The logic is PSS_All_Calc_Prepare_Results.

Impact Tab

The logic is PSS_All_Eval_Impact.

Details Tab

The logic is PSS_All_Eval_Details.

Analysis Tab

The logics are PSS_All_Eval_Analysis and PSS_All_Eval_Analysis_Configurator.

Configuration in PLPGTT

In order to enable the simulation for a PL/LPG, we need to link them together. This is done by setting a specific “Contextual Actions Configuration” in the correct Price Setting Type.

Menu to the Price Setting Types definitions
Place of the Contextual Actions Configuration definition

The field is named contextualActions and is a JSON following this model:

[ { "targetPage": "newModelPage", "targetPageEntityType": "PriceSettingSimulation", "targetPageTarget": "drawer", "targetPageInputs": { "input": { "price_list": { "SourceTypedId": "{typedId}", "secondaryKeyColumnName": "Country" } } } } ]

It defines:

  • The Model Class to use for the simulation in the targetPageEntityType.

  • The view type of its first step for configuration from the PL/LPG list in the targetPageTarget – here it is a "drawer".

  • Matching between the PL information and the automatic setting of the inputs in the drawer in the targetPageInputs. Here we set the inputs SourceTypedId and secondaryKeyColumnName of the tab price_list, which is the only tab of the first step of the Model Class.

Creation from a Model Object List

Finally, note that the Simulation can be instantiated from the Model Objects list, allowing the creation of several simulations per a Price List and making the development and debugging easier. To do so, simply create a new Model Object using the correct Model Class (more details in Models). The first step will then allow configuring the input to use for the simulation (PL, LPG and optional secondary keys). Be sure that when you add inputs in the first step, they are both usable from the Models view and from the drawer in the PL/LPG simulation option and auto-filled with the PL data when needed. For that two actions are needed:

  • Updating the logic building the user inputs (refer to Input Step).

  • Updating the mapping in the drawer (refer to the previous paragraph Configuration in PLPGTT).