Page Comparison

This logic extracts data and formats them in a way understandable by the Optimization Engine. More details in Problem Tables. There is strict formatting for these tables.

Plumbing

If there are different data to send to the OE, it is the place where to write them. The fields SKU, customer and period are required by the space definition. All the other ones depend on the problem definition: Did the waterfall definition change? Did other pieces of the problem change? Depending on the modification done to the Problem Description File (in Calculation: Run Simulation described below), you may need to read new inputs from the data to instantiate the new parts of the model. These new fields must be added to the problem table. The way the model was changed will define where to add their name, space and scope in the Problem Description File.

For example, if we add a variable new_field_to_read in the scope all of the space BySKUCustomerAndPeriod.

[       "name": "NewVariable",
        "type": "static",
        "init": [                
                "type" : "data",
                "field": "new_field_to_read"        
                ],
]

We need to add this information in the model table Problem_BySKUCustomerAndPeriod_All, which means modifying the element Problem_BySKUCustomerAndPeriod_All in this logic to add the field new_field_to_read to it. For more information see Problem Tables and Problem Description.

If the new data is not available and requires for example reading new fields from the Datamart, then the Aggregation logic (Calculation: Aggregating) must also be updated accordingly and the new fields added to the AggregatedData table.

I want to add Results Charts

Let’s say we added a new discount in the waterfall, we now must change the existing charts to display this new information.

However, as we can only create tables in a calculation logic, some new charts may need to add an element to store the data in a usable fashion. It should be done in PSS_All_Calc_Prepare_Results (Calculation: Prepare Results).

Note that this can lead to slight differences in the implementation of the same chart between the Impact or Details tabs and the Analysis one as the Analysis tab must be updated given the set of filters inputted by the user. For example, the tables in Details are displayed using dmCtx.buildQuery(query) which is efficient but not usable for the tables in Analysis using a toResultMatrix() as their filtering relies on SQL query.

The dashboard displays three model tables corresponding to the aggregation by product, customer, and product/customer. These tables are built in Calculation: Prepare Results.

The last portlet provides a summary of the non-blocking errors, calculated in Calculation: Check Data.

The configurator logic PSS_All_Eval_Analysis_Configurator provides the user inputs: options parameters to filter the model tables. The main logic then provides the same portlets as the Impact tab Impact Tab but only in the scope that the user has defined.