Updating the business logic

In the Knowledge Model, we use variables and formulas to provide better maintainability as well as permit the bulk change of values. During the first setup of the app, you need to check both the variables and formulas. You should start by validating and adjusting the variables and then validating and adjusting the formulas.

Although it uses many new studio components, all calculations (such as Filters, KPIs, Variables, Charts, and Tables) are still based on PQL within the Knowledge Model. If you get any error messages, you can narrow them down to the respective PQL-statement and test your code in an analysis or view to check if you have any syntax errors.

The IM Control Center enables you to not just explore how your inventory has developed in the past, but it also gives you a glimpse of how said inventory will develop in the future based on current orders.

To achieve this, the following (order) objects are considered:

From a conceptual standpoint, the starting point is always today’s inventory. Any outgoing future orders will be subtracted while incoming orders will be added to compute a future inventory:

The required tables are combined at runtime rather than in the data model. Instead, the PQL-operator UNION_ALL() is used to create a record combining all the required tables at runtime.

Ultimately, one UNION_ALL()-object (record attribute or KPI) is required for every relevant field. The “shared columns” used to identify a unique instance of this virtual record consist of the following fields:

Creating this set of columns requires a total of six separate UNION_ALL()-objects - one for each field.

A limitation of the operator is that currently at most eight tables can be leveraged. Thus, if you plan to add additional order types during your implementation project, you may need to either drop existing order types from the logic or combine the tables for the new order types with those of existing orders (e.g. combining EKET and EKEH if you plan to integrate Purchase Scheduling Agreements).

UNION_ALL()-objects can contain either references to a specific table or other KPIs computed by Celonis using Pull Up Aggregation.

Conceptually, a single UNION_ALL()-object is created as shown below:

To obtain the Inventory Projection, the UNION_ALL()-object containing the relevant quantity fields is then wrapped by the RUNNING_SUM()-operator. This covers a single Material-Plant combination.

To compute an aggregated Inventory Projection -e.g. on the level of Material Group or Plant- the RUNNING_TOTAL()-operator is used instead.

The combined record created in this manner can be used to compute KPIs such as “Days until Stockout”.

The results provided by it are however quite expensive as far as computational performance is concerned. It is therefore recommended to use alternatives where possible.

To address the aforementioned impact on computational performance, visualizations of the Inventory Projections should in most cases be handled using the TIMELINE_COLUMN() and TIMELINE_TABLE() operators instead.

Both operators are required to create a date field as well as actual KPIs. The assets required to populate a chart are introduced below: