Обзор
Запросить PowerBI довольно сложно, поэтому найти аккуратный подход может быть сложно.
Самая большая проблема заключается в том, что данные PowerBI Модель не поддерживает концепцию бегущего счета - по крайней мере, не так, как в Excel. В Excel столбец может ссылаться на значения, которые встречаются в «предыдущей строке» этого же столбца, а затем корректироваться с помощью некоторых «ежедневных изменений», перечисленных в другом столбце.
PowerBI может имитировать это только путем сложения все ежедневные изменения в некотором подмножестве строк. Мы берем значение даты в нашей текущей строке и создаем отфильтрованную таблицу, в которой все даты меньше даты текущей строки, а затем суммируем все ежедневные изменения из этого подмножества. Может показаться, что это небольшая разница, но она довольно значительна:
Это означает, что нет способа "переопределить" наш промежуточный итог. Единственная математика, которая выполняется, - это столбец, содержащий ежедневные изменения - столбец, содержащий «промежуточный итог», является только результатом - он никогда не используется в вычислениях последующих строк.
Мы должны отказаться от концепции «перезагрузки» и вместо этого представить себе создание столбца, который содержит значение «корректировки». Наша корректировка будет представлять собой значение, которое можно включить, чтобы при выполнении описанных условий общая сумма ежедневных сальдо и корректировок составила бы 1.
Если мы посмотрим на рассчитанный пробег, заданный OP, мы увидим что значение нашего промежуточного итога в «нерабочий» день непосредственно перед «рабочим» днем дает нам ту необходимую сумму, которая, если ее обратить в обратном порядке, будет равна нулю и приведет к увеличению промежуточного итога в каждый следующий рабочий день на единицу , Это наше желаемое поведение (с одной проблемой, которая будет описана позже).
Результат
Most Recent Date Prior to Work =
CALCULATE(
Max(Leave[Date]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] = EARLIER(Leave[Date]) -1 && Leave[Type] <> "Working" && Earlier(Leave[Type]) = "Working"
))
Это помогает узнать разницу между контекстами строки и фильтра и тем, как EARLIER работает, чтобы следовать этим вычислениям. В этом сценарии вы можете думать о «РАННЕЕ» как о значении «эта ссылка указывает на значение в текущей строке», а в противном случае ссылка указывает на всю таблицу, возвращаемую «ALLEXCEPT (Leave, Leave [Id])». В этом Таким образом, мы находим места, где текущая строка имеет тип «Рабочая», а строка предыдущего дня имеет какой-то другой тип.
Most Recent Date Prior to Work Complete =
CALCULATE(
Max(Leave[Most Recent Date Prior to Work]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] <= EARLIER(Leave[Date])
))
Этот расчет имитирует операцию «заполнения». Он говорит: « При просмотре всех строк, дата которых предшествует дате в ЭТОЙ строке, верните наибольшее значение в «Самая последняя дата перед началом работы».
Daily Balance Adjustment =
CALCULATE(
SUM(Leave[Running Daily Balance]),
FILTER(
ALLEXCEPT(Leave, Leave[Id]),
Leave[Date] = EARLIER(Leave[Most Recent Date Prior to Work Complete])
))
Теперь, когда в каждой строке есть поле, объясняющее, куда go чтобы найти дневной баланс для использования в качестве нашей корректировки, мы можем просто go найти его из таблицы.
Adjusted Daily Balance = Leave[Running Daily Balance] - Leave[Daily Balance Adjustment]
И, наконец, применить корректировку к нашему промежуточному итогу для окончательного результата.
Проблема
При таком подходе не учитывается, что счетчик не должен сбрасываться, если текущий дневной баланс не станет меньше нуля. Например, раньше, но я бы сказал, что этого нельзя достичь только в DAX, поскольку это создает циклическую зависимость. По сути, вы предъявляете требование: используйте агрегированное значение, чтобы определить, что следует включить в агрегацию.
Так вот, как далеко я могу вас привести. Надеюсь, это поможет.