Hi,
In some cases, the calculation of certain KPIs has to be done using PU_FUNCTIONS.
However, as these function do not consider the actual analysis filters, the values calculated might not be the expected.
Although I agree that not taking into consideration the current analysis filters is quite useful, I believe that it would be a great improvement to have the possibility to consider also the filters.
Best Regards,
Bruno
Page 1 / 1
Hi Bruno,
I can see your point, that this would help for some analyses. We will take a look if that is actually possible.
Do you have a concrete example of an analysis where you came across this? Clear context of the use-case always helps us to find a better solution.
What KPI did you create in what context? So why did you use the PU function in the first place and what did you want to achieve with the analysis?
Best Regards,
Manuel
I can see your point, that this would help for some analyses. We will take a look if that is actually possible.
Do you have a concrete example of an analysis where you came across this? Clear context of the use-case always helps us to find a better solution.
What KPI did you create in what context? So why did you use the PU function in the first place and what did you want to achieve with the analysis?
Best Regards,
Manuel
Hi Manuel,
There are several examples of analysis where this would be helpful. Below you can find one of them:
Data model:
Cardinality
Customers (1:N) Sales Orders
Sales Orders (1:N) Deliveries
Now imagine you want to offer, in the same table, a list of customers (as a dimension) and two KPIs (e.g. sum of sales orders amount and a counter of the total number of deliveries).
Using the aggregation functions SUM(Sales Orders.Amount) and COUNT_TABLE(Deliveries) for the KPI calculation, only the last one would have the expected value, as it is based on the broader table.
image.png981350 22.1 KB
A solution for that would be to use a PU_FUNCTION for the KPI on the Sales Orders table
image.png1014364 22.8 KB
However, as soon as you apply a selection filter on the Sales Orders or Deliveries table, and as they are not considered in the PU_FUNCTION, the result wont change accordingly to the filters.
image.png1036426 18.1 KB
As I said, sometimes it is useful, but in many other cases it is not.
I hope you can offer the developers an option to either consider or not the current filters when using PU_FUNCTIONS.
Regards,
Bruno
There are several examples of analysis where this would be helpful. Below you can find one of them:
Data model:
- Customers
- Sales Orders
- Deliveries
Cardinality
Customers (1:N) Sales Orders
Sales Orders (1:N) Deliveries
Now imagine you want to offer, in the same table, a list of customers (as a dimension) and two KPIs (e.g. sum of sales orders amount and a counter of the total number of deliveries).
Using the aggregation functions SUM(Sales Orders.Amount) and COUNT_TABLE(Deliveries) for the KPI calculation, only the last one would have the expected value, as it is based on the broader table.
image.png981350 22.1 KB
A solution for that would be to use a PU_FUNCTION for the KPI on the Sales Orders table
image.png1014364 22.8 KB
However, as soon as you apply a selection filter on the Sales Orders or Deliveries table, and as they are not considered in the PU_FUNCTION, the result wont change accordingly to the filters.
image.png1036426 18.1 KB
As I said, sometimes it is useful, but in many other cases it is not.
I hope you can offer the developers an option to either consider or not the current filters when using PU_FUNCTIONS.
Regards,
Bruno
Hi,
Has this been reviewed any further? We are having a similar problem when calculating automation rates for customers on our sales order model. We want to contrast automation rates by sales order volume, value and customer volume.
Because customers may have some orders that are automated and some that are not, we need to first classify a customer as automated or not using an automation threshold. To do this I have a pull up function to KNA1 to calculate this:
COUNT (DISTINCT
(
CASE WHEN
(PU_COUNT_DISTINCT(KNA1, VBAK.VBELN, _CEL_C2C_ACTIVITIES.USER_TYPE != A AND _CEL_C2C_ACTIVITIES.ACTIVITY_EN = Create Sales Order Item)/
PU_COUNT_DISTINCT(KNA1, VBAK.VBELN, _CEL_C2C_ACTIVITIES.ACTIVITY_EN = Create Sales Order Item)) >= <%= customer_automation_threshold %> THEN KNA1.KUNNR
ELSE NULL
END
)
)
However, when filters are applied to the overall analysis, the pull up function doesnt take into account the filters. So if I, for example, filter on sales order type, it may still show that the customer is considered to be automated even if there is no automation for the orders of the type in question.
Any suggestions?
Has this been reviewed any further? We are having a similar problem when calculating automation rates for customers on our sales order model. We want to contrast automation rates by sales order volume, value and customer volume.
Because customers may have some orders that are automated and some that are not, we need to first classify a customer as automated or not using an automation threshold. To do this I have a pull up function to KNA1 to calculate this:
COUNT (DISTINCT
(
CASE WHEN
(PU_COUNT_DISTINCT(KNA1, VBAK.VBELN, _CEL_C2C_ACTIVITIES.USER_TYPE != A AND _CEL_C2C_ACTIVITIES.ACTIVITY_EN = Create Sales Order Item)/
PU_COUNT_DISTINCT(KNA1, VBAK.VBELN, _CEL_C2C_ACTIVITIES.ACTIVITY_EN = Create Sales Order Item)) >= <%= customer_automation_threshold %> THEN KNA1.KUNNR
ELSE NULL
END
)
)
However, when filters are applied to the overall analysis, the pull up function doesnt take into account the filters. So if I, for example, filter on sales order type, it may still show that the customer is considered to be automated even if there is no automation for the orders of the type in question.
Any suggestions?
Hi,
Unfortunately not. Celonis customer service is, to be honest, quite poor.
Best Regards,
Bruno
Unfortunately not. Celonis customer service is, to be honest, quite poor.
Best Regards,
Bruno
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.