Skip to main content

Celonis Product Documentation

MDI App Configuration

In order to correctly apply the logic that defines the content of the Starter Kit different variables, KPIs and filters need to be configured and validated. The following section will guide you through the app configuration process, with a main focus on the KM configuration.

Variable Configuration

To start with the variable configuration, please go to the Knowledge Model (KM).

Go through the variables section in the view mode and validate whether the input used for the variables is correct for your business needs. To view all variables in use, you can navigate to the variables section of the KM.

For the apps, only non-auto-generated configurations are used, so you can disable the auto-generated definitions. In some cases, variables are used for storing values (strings, integers, etc.) that are used inside of KPIs and inefficiencies, such as the Planned Lead Time, for storing target and benchmark values of KPIs and frequently used activity names like the “Goods Issue” activity.

Some variables are more important than others to update, in the sense that the business logic of the app will not work if they are not set correctly. An example are the variables that reference different fields and activity names, e.g. the ‘Record Goods Receipt' activity.

On the other hand, all variables are set with a default value and, in some cases, the app will still function properly if they are not updated, e.g. the ‘Desired Service Level’. If you identify some variables that need to be adjusted, you can easily update them directly inside of the variable part of the KM visual editor.

Other variables are stored in the plain text variables section of the package settings. These variables can also be changed if needed and are only affecting the package in which they are defined.


If you are not using the IM Control Center's default Knowledge Model but decided to set up a dependency to the IM Starter Kit:

Logic created inside the local package Knowledge Model will only be applied to the CC and not the Starter Kit or other connected apps.

To be able to reference customizations made in the IMCC Knowledge Model in other apps using the IM Master Knowledge Model, copy and paste the changes to the Master Knowledge Model, publish the IM Starter Kit, and update the dependencies of any connected apps.

Please be aware changes to the Starter Kit's runtime variables will not be forwarded to any dependent package. 

Note: Runtime variables present in the IM Starter Kit but not in MDI are stored as regular Knowledge Model variables in the latter. 

Important Variables to Validate and Update

Below you find a list of variables that should be validated during the app configuration. These variables can only be updated from the runtime variable editor or KM editor with ANALYST or ADMIN permissions.

Variable ID

Type of variable

Variable name/ description


Runtime variable

Currency to be displayed in app


Runtime variable

Original currency


Runtime variable

Currency conversion type



Number of past months (excl. current month) considered for parameter recommendations.

Default: 12



Number of future months (excl. current month) considered for parameter recommendations.

Default: 4



Tolerance used for highlighting and prioritizing parameter recommendations.

Default: 0.2


Runtime variables not listed here are inherited from the IM Starter Kit and do not need to be reconfigured for MDI.

Updating the Business Logic

The business logic is packaged into formulae (KM KPIs) to reuse in the different parts of the app or inside of other KPIs/formulae to make the setup more concise.

These PQL-statements define the calculations of KPIs, filter statements on your data, and inefficiencies. Hence they are one of the most important parts of the app.

To give you an example, the formula KPI_MATERIAL_CALC_ACTUAL_PURCHASE_LEAD_TIME is used both for evaluating purchase orders as well as for computing related planning parameters (e.g., Recommended Purchase Lead Time, Recommended Safety Stock, etc.). So by adjusting the underlying business logic in that one place, you adjust the business logic for all KPIs and related definitions at once.

This list is not exhaustive and should be checked inside of the Knowledge Model. Make sure to also check nested formulas that might be used within the listed KPIs below. You can identify by the prefix whether it’s defined as KPI or formula.


Formula description


Computes actual Purchase Lead Time. Will be used for lead time recommendations if Machine Learning is not used.


Computes actual Production Lead Time.

Will be used for production lead time recommendations.


Computes a recommendation for safety stock based on King’s formula.

This formula is used if there are past replenishments for a material.


Computes a recommendation for safety stock based on King’s formula.

This formula is used if there are no past replenishments for a material.


Handles which safety stock formula is used for a recommendation and which materials should not get a recommendation (e.g. due to their planning strategy).


Computes a recommendation for reorder point.


Handles reorder point is used for a recommendation (value based on formula, median consumption, or 1) and which materials should not get a recommendation (e.g. due to their MRP Type).

In case you update the underlying business logic or used variables, please make sure to also update the documentation for the business users in the Documentation folder.


Recommendations based on Machine Learning are currently only available for Purchase Lead Times.

Adjusting the Knowledge Model in General

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.

  1. To perform the validation, align with your customer’s SAP IT Business Partner and Process Owner. They have knowledge about the data structure and are aware of customizations that might need to be included.

  2. To validate the PQL statements of the variable/ formula, use analysis in the same Data Model, copy and paste the PQL statements into it and validate the results with your SAP IT Business Partner.

  3. If required, adjust the variable/formula in the Knowledge Model by:

    1. Copying relevant code in View mode.

    2. Entering Edit mode and pasting your selection.

    3. Adjusting the formula/KPI according to your preferences/needs.


Links to the formula /KPI from dependent areas, such as filters for tasks and views, flags for inefficiencies, or KPI definitions, are automatically updated. This does not hold for changes made in the dependent Knowledge Model. If a customization is also to be used in other Inventory Management apps, the change must be transitioned to the Master Knowledge Model in the IM Starter Kit.

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.

Calculating Past and Future Consumption

All past consumptions are taken from the Inventory Management Activity Table (CEL_IM_ACTIVITIES).

These past consumptions are combined with future consumptions from:

  • Reservations (dependent requirements)

  • Sales Orders

  • Independent Requirements

The consumption is then used for computing recommendations on both Safety Stock and Reorder Point based on this logic.

Since the required values are stored in different tables in the Inventory Management Data Model, they are combined in the Knowledge Model via a PQL operator called UNION_ALL.


You can identify any object using UNION_ALL via their Knowledge Model ID - each KPI, variable, or filter using this operator has “_UNION_” in its ID.

To avoid any duplicated logic, there is a combined “Stock Requirements List” containing not just the consumption tables listed above.

The entire logic is built from:

  • Planned Orders

  • Purchase Requisitions

  • Purchase Orders

  • Production Orders

  • Material Movements

  • Reservations

  • Sales Orders

  • Independent Requirements

without the need for them to have a common JOIN path in the data model.

Any value computed in this UNION_ALL space can be retrieved using the operator “UNION_ALL_PULLBACK”. For the out-of-the-box KPIs, this pullback is executed such that any result can be retrieved via the Inventory Management Activity Table (_CEL_IM_ACTIVIITES). The results are then uniquely assigned to a single Material-Plant combination by using PU_FIRST to the MARC table.

For more information on what to look out for when working with or expanding this logic, consider the FAQ section of this guide.


Values for future consumption will be similar to what you see in your MD04 in SAP but it is not the goal to achieve a complete match.

This can be caused by multiple reasons such as (non-exhaustive):

  • Change in situation since the latest data load

  • Customizations of your SAP system

Leveraging Machine Learning for Purchase Lead Times


Out of the box, the app computes recommendations for Purchase Lead Times using the average or median. Leveraging recommendations made by Machine Learning is an add-on which requires additional implementation effort.

If you would like to leverage this add-on, contact your CVM, Account Executive or create a Service Desk Ticket.

The results of the algorithm are stored in a distinct data model table called “CEL_P2P_ML_LEADTIMES”. This table is joined directly to the “MARC” table.

If Machine Learning is used, the following adjustments need to be made to the Knowledge Model:

  • If Actual Purchase Lead Time (i.e. recommendation without Machine Learning) still is to be displayed for reference:

    • Add additional KPI for recommended lead time, referencing the field "_CEL_P2P_ML_LEADTIMES"."RECOMMENDED_VALUE"

    • Add additional KPI for standard deviation of recommended lead time, referencing the field "_CEL_P2P_ML_LEADTIMES"."RECOMMENDED_STD"

    • Create copies of KPIs for actual replenishment lead time to use when computing other recommendations:



    • Update existing recommendation KPIs referencing actual lead time data to consider recommended data instead, especially the following:



  • If Actual Purchase Lead Time (i.e. recommendation without Machine Learning) is to be replaced: