使用if和max值DAX运行总计

Question

我想创建一个关于休假的表格,需要一个累积总计.

年假栏2 DAX是

Annual Leave Column2 = 
CALCULATE (
    SUM (Sheet1[Debit/Credit]),
    ALL ( Sheet1 ),
    FILTER(Sheet1, SUM(Sheet1[Debit/Credit])>20), Sheet1[Date] <= EARLIER ( Sheet1[Date] )
) 

对于第3列是

column 3 = IF( Sheet1[Annual Leave Column2]>20, 20, Sheet1[Annual Leave Column2] )

但结果是它已经20并且在下一个日期有一个-1它仍将计数20并且在20中停留.我需要的结果是:

我想,如果价值已经是20,我们可以停止计算吗？并且如果遇到-1则继续计算.或者还有另一种方法可以做到这一点？看起来如果我使用IF,它只是将可视化设为20但不将数据设置为20,这就是为什么它被卡在20中因为所有总和都超过20.

Answer 1

最好的办法是让源系统不允许年度积分超过年度上限，或者直接为您提供上限年假金额（而不是尝试在 Power BI 中计算）。

即使源系统不存储上限年假金额，使用 SQL 在查询中计算它也可能比使用 Power BI 更容易。（我建议为此提出一个单独的问题。）

我为什么这么说？

在 Excel 中，运行（或累积）总计是根据上一行的值逐行计算的。这使得“覆盖”运行总计并将该覆盖应用于每个后续行变得容易。例如，您可以将运行总计上限设置为 20，并且下面的单元格会表现得好像运行总计为 20。上限下面的单元格并不知道运行总计实际上不是 20。

在 DAX 中，运行总计是在每行上独立计算的（意味着每行查看当前行日期之前的所有行并计算实际运行总计）。这使得不可能覆盖运行总计（例如，将其限制为 20）并将调整后的运行总计输入到下一行。下一行总是知道实际运行总计是多少。

无法告诉 DAX 查看之前计算的运行总计并添加到其中，因为列无法引用自身（正如 user5226582 提到的，这是循环依赖）。与 Excel 不同，DAX 逐列运行计算，而不是逐个单元格运行计算，因此它不能使用列的输出作为同一列的输入。

肮脏和不完整的解决方法

肮脏的解决方法取决于年度积分可以被忽视的次数。每次忽略全部或部分年度信用时，它都会调整所有后续单元格的运行总计。

例如，2017 年 5 月 1 日，真实运行总计为 20.5，但您丢弃了 0.5。这意味着所有未来行均基于 2017 年 5 月 1 日的总计 20 行，而不是 20.5。

您当然可以创建一个计算列来标识运行总计第一次达到上限的时间（2017 年 5 月 1 日）。然后，您将使用之前计算的 2017 年 5 月 1 日之前计算的运行总计来计算调整后的运行总计，但在 2017 年 5 月 1 日之后忽略之前的运行总计，而是对 2017 年 5 月 1 日的 [借方/贷方] 列进行求和。 17 只加 20。（加 20 是因为我们知道 2017 年 5 月 1 日的运行总计为 20，并且这不会反映在 [借方/贷方] 列的总和中。）

Running Total Is Capped = IF([Annual Leave Column2] > 20, 1, 0)

Running Count of Capped =
CALCULATE (
    SUM ( Sheet1[Running Total Is Capped] ),
    ALL ( Sheet1 ),
    FILTER ( Sheet1, Sheet1[Date] <= EARLIER ( Sheet1[Date] ) )
)

Adjusted Running Total =
IF (
    [Running Count of Capped] = 0,
    [Annual Leave Column2],
    20
        + CALCULATE (
            SUM ( Sheet1[Debit/Credit] ),
            ALL ( Sheet1 ),
            FILTER (
                Sheet1,
                Sheet1[Date] <= EARLIER ( Sheet1[Date] )
                    && Sheet1[Running Count of Capped] > 1
            )
        )
)

但这个解决方案并不成立，因为它只在第一次达到上限时有效。每次达到上限时，您都需要以相同的方式调整运行总计，并使用一组新的计算列来调整调整后的运行总计。如果您可以达到上限 20 次或 50 次，则还需要将上述一组计算列重复 20 或 50 次。

您无法同时调整所有行的上限，因为第一次调整会影响下一次调整的时间。在您的示例数据中，2017 年 8 月 5 日的真实运行总计为 21，这意味着我们希望将其减少到 20。但是，由于我们之前已超过上限 3 次，因此我们已经缩短了 3.5 天结果，调整后的运行总计为 17.5，因此不需要上限。

除了您需要的计算列的数量之外，该模型也无法很好地适应不断增加的数据量。EARLIER 函数是迭代的，这意味着它为每一行运行一次计算。行数越多，花费的时间就越长。一遍又一遍地使用 EARLIER 函数，因为这种快速而肮脏的解决方法确实会成为性能杀手。我强烈建议寻找另一种解决方案，最好是在数据到达 Power BI 之前。

旁注：如果您要使用 EARLIER 函数，我建议对每一行建立索引，以便保证它们具有唯一的数字，而不是依赖日期字段作为索引。如果您在同一日期有多个贷项/借项，则使用日期字段作为索引可能会导致意外结果。