Добрый день, уважаемые знатоки!
Подскажите, пожалуйста, в чем может быть ошибка:
Использую меру для подсчета нарастающего итога по продажам (sales) в разрезе продукта (truck_id).
В таблице sales около 300.000 строк (продажи), в неё добавлен столбец [Index]
Мера вычисляет очень долго - порядка 40-60 секунд.
Если поставить в 3-й строке вместо VAR car_index = SELECTVALUE(sales[Index]) (использовал и MAX(sales[Index]) - разницы нет) любое число (пробовал даже 300000) - работает быстро. Загвоздка именно в использовании индекса.
Может сможете подсказать, как можно ускорить её работу?

Текст меры:
sales_runn_total =
VAR cur_truck_id = SELECTVALUE(sales[truck_id])
VAR cur_index = SELECTVALUE(sales[Index])
VAR run_total = CALCULATE(SUM(sales[Стоимость]), FILTER(ALL(sales), sales[Index]<=cur_index))
RETURN
       SWITCH(TRUE(),
                       ISINSCOPE(sales[Index] && cur_truck_id <> BLANK(), run_total,

                       TRUE(), BLANK()
       )  

Добрый день!
Помогите, пожалуйста, решить вот такую задачу:
У меня три таблицы: Партии, Товары, Продажи.
В таблице Партии информация о закупленных партиях товара (IDпартия).
Есть таблица связи товара по IDПартия. И есть таблица продаж с товарными позициями (IDтовар).
Партия была закуплена за определенную сумму (Закупка) с доп.расходами (ДопРасходы) в определенную дату (ДатаПоставки). Партия поступает в продажу, и товар начинает продаваться (в таблице Продажи есть количество, стоимость и дата продажи конкретного IDТовара).Себестоимость партии высчитывается легко, прибыль тоже.
Нужно рассчитать рентабельность в %% и окупаемость каждой партии в днях.
У меня возникла проблема с окупаемостью - мера считает оооочень долго - может подскажете, в чем ошибка и как можно ускорить ее работу?

Меру для подсчета окупаемости использую такую:
breakeven_days_new =
VAR id = MAX(Партии[IDПартия])
VAR items_table = SELECTCOLUMNS(FILTER(ALL(Партии),  Партии[IDПартия] = id), [IDПартия])
VAR sale_table = FILTER(ALL(Продажи), Продажи[IDТовара] in items_table)
VAR sales_table = FILTER(ADDCOLUMNS(sale_table, "run_total",
              VAR ind = [Index]
              VAR sale_table_small = FILTER(sale_table, [Index]<ind)
              RETURN
              SUMX(sale_table_small, [Стоимость])
                      ),
                          [run_total]>='Партии'[СебестоимостьПартии])
VAR date_diff = DATEDIFF( MIN(Партии[ДатаПоставки]), MINX(sales_table, [ДатаПродажи]), DAY )
RETURN
date_diff


Таблицы с исходными данными прилагаю.

Заранее благодарю за помощь!

Добрый день!
Помогите, пожалуйста, решить вот такую задачу:
Есть 3 таблицы: Партии, Товары, Продажи.
В таблице Товары информация по закупленным партиям товаров (IDпартии),
В таблице Товары - связь между партией и проданной единицей товара.
В таблице Продажи - проданные товарные позиции (IDтовар) с датой, количеством и стоимостью.
Партия была закуплена за определенную сумму (Закупка) с доп.расходами (ДопРасходы) в определенную дату (ДатаПоставки). Партия поступает в продажу, и товар начинает продаваться (таблица Продажи).
Себестоимость партии высчитывается легко, прибыль тоже.
Нужно рассчитать рентабельность в %% и окупаемость каждой партии в днях.
У меня возникла проблема с окупаемостью - мера считает оооочень долго - может подскажете, в чем ошибка и как можно ускорить ее работу?

Меру для подсчета окупаемости использую такую:
breakeven_days_new =
VAR id = MAX(Партии[IDПартия])
VAR items_table = SELECTCOLUMNS(FILTER(ALL(Партии),  Партии[IDПартия] = id), [IDПартия])
VAR sale_table = FILTER(ALL(Продажи), Продажи[IDТовара] in items_table)
VAR sales_table = FILTER(ADDCOLUMNS(sale_table, "run_total",
              VAR ind = [Index]
              VAR sale_table_small = FILTER(sale_table, [Index]<ind)
              RETURN
              SUMX(sale_table_small, [Стоимость])
                      ),
                          [run_total]>='Партии'[СебестоимостьПартии])
VAR date_diff = DATEDIFF( MIN(Партии[ДатаПоставки]), MINX(sales_table, [ДатаПродажи]), DAY )
RETURN
date_diff


Таблицы с исходными данными прилагаю.

Заранее благодарю за помощь!

Уважаемые коллеги, доброго времени суток!
Столкнулся с такой проблемой - при загрузке таблицы из потока в desktop приложение происходит изменение общего количества строк, а точнее задвоение/затроение и т.д. некоторых из них, не всех. Никаких преобразований при этом в десктопе не делаю. Может кто-то подскажет, в чем может быть проблема и как её решить?

Уважаемые коллеги, помогите решить следующую проблему: у меня есть таблица с закупками и таблица-календарь, они не связаны. Мне нужно для каждой даты рассчитать количество закупленного товара (по конкретному id номенклатуры) с первой даты до каждой даты включительно т.е. по сути сделать нарастающий итог на дату. На первом скрине получается создать таблицу, содержащую даты и количество товара на каждую дату, но там я не использую фильтр по дате, т.е. ADDCOLUMNS считает на каждую дату все закупки. Формула вот такая:

Table =
VAR date_table = VALUES('calendar'[Date])
VAR min_purch_date = CALCULATE(MIN(items_purch_title1[Дата]), items_purch_prod1[IDНоменклатуры] = "15A16925-A17C-11E0-AD08-005056C00008")
RETURN
ADDCOLUMNS(SUMMARIZE('calendar', 'calendar'[Date]), "num", CALCULATE(sumx(items_purch_prod1, items_purch_prod1[Количество]), items_purch_prod1[IDНоменклатуры] = "15A16925-A17C-11E0-AD08-005056C00008"))


На втором скрине собственно ошибка - я не могу обратиться к виртуальному столбцу [Date] - мера его не видит, т.е. вроде таблица создана функцией SUMMARIZE , как учат везде  я обернул ее в ADDCOLUMNS, но внутренний CALCULATE наглухо отказывается обращаться к столбцу [Date] и фильтровать все поступления до конкретной даты:

Table =
VAR date_table = VALUES('calendar'[Date])
VAR min_purch_date = CALCULATE(MIN(items_purch_title1[Дата]), items_purch_prod1[IDНоменклатуры] = "15A16925-A17C-11E0-AD08-005056C00008")
RETURN
ADDCOLUMNS(SUMMARIZE('calendar', 'calendar'[Date]), "num", CALCULATE(sumx(items_purch_prod1, items_purch_prod1[Количество]), items_purch_prod1[IDНоменклатуры] = "15A16925-A17C-11E0-AD08-005056C00008", items_purch_title1[Дата]<=[Date]))

Может кто-то подскажет, как это можно решить?

Добрый день коллеги.

Вот столкнулся с такой задачей, для меня она не тривиальная, но я честно гуглил и готовых решений не нашел, суть такая что есть база клиентов интернет магазина, 35.000 номеров, есть спарсенная при помощи PQ база кодов операторов по регионам, при помощи нее сопоставляю кусок номера (не всегда одинаковой длины) можно определить точно город регистрации сим карты. Сложность в том что кода из 3 первых цифр номера, префикса недостаточно, есть масса номеров, которые распределены между разными регионами, т.е. если номер PPP-NNNNNNN, то номера с префиксом PPP могут быть например Билайн тут же Мегафон, и тут же еще и разные регионы внутри одного оператора, поэтому где то совпадает PPP-N где-то PPP-NN и так далее.

Я саму задачу решил тупым джонойном выделил префикс каждого номера, сджойнил табличку всех возможных вариантов кодов к этому префиксу и далее тупым перебором нашел соответствия , при каждой итерации я отрезал от искомого номера такой кусок впереди, который будет равен по длине тому что есть в базе кодов операторов. Затем просто фильтрация, все решено, но остались вопросы, вот кусок этого решения

   
Так же удалось решить при помощи List.Transform, сджойненную таблицу напротив каждого номера, я пытался обработать, но решение очень медленное, я так и не дождался загрузки в отчет ни разу
Оба решения не изящные, в рамках тренировки и расширения опыта я хотел бы попробовать решить его при помощи List.Generate или List.Accumulate или каким-либо еще способом в рамках PQ можно в рамках PBI.
Буду очень благодарен за пинок, в сторону быстрого решения что называется по Фэн Шую))

Добрый день, пытаюсь посчbтать в DAX вот такую вещь.
Есть таблица изменения состояний с активного на неактивное, по идее активность длится 10 дней , то есть я вижу ID, в таблице и вижу что статус "Активен" значит он теперь будет активен 10 дней, правда внутри могут быть сбои, т.е. ID активировался 01.01.2022, 03.01.2022 может прийти что он "Неактивен", потом снова 04.01.2022 наприме, "Активен". Это технический сбой, мне нужно его игнорировать.
Задача на каждый день, мерой (что бы потом можно было фильтровать по связанным таблицам) посчитать сколько было активных ID всего в этот день, но именно сумму всех активных на день, а не только тех которые стали активными в этот день, т.е. сумму всех активных на этот день включая все те что стали активными 1-2-3 и до 10 дней назад. По сути мне надо взять предыдущие 10 дней, из большой таблицы статусов, взять внутри нее все ID которые пришли со статусом "Активен", хотя бы один раз, это будет означать, что я получил все ID которые могли быть активны на эту дату, все что было раньше не может быть активным, так как макс срок активности 10 дней, все что было позже, разумеется, не анализируем, оно для текущей даты еще не наступило, сгруппировать, что-бы убрать ошибочные двойные, тройниые и проч активации и я должен по идее получить сумму всех ID которые за период пред 10 дней были активированы, т.е. получу сумму активных ID на этот день.

Делаю это мерой, она прекрасно считает все, что было активировано, но когда я раскидываю ее по датам она упорно не ссумирует, а считает именно активации в этот день, а предыдущие 9 игнорирует )) как ее заставить ссумировать или мера вообще так делать не умеет?  

В PQ задача решилась несложно, но получивщуюся таблицу уже не отфильтровать связанными табличками. Возможно эту меру надо городить в отдельно таблице где не повторяются даты? тогда она сможет аккумулировать на каждую дату, надо тогда связь между ними делать?

Добрый день коллеги.

Не бейте сильно, если где-то уже данный вопрос обсуждался, но я курил и Chris Webb и все такое, прямого решения н нашел, хотя много полезных идей около моей проблемы прочитал.
Итак есть таблица по сути три столбца Index - просто порядковый номер продажи в рамках системы, ID товара, Сумма продажи, необходимо на каждый товар, на каждую продажу подсчитать накопленную по нему сумму, по сути простой нарастающий итог, но посегментно, для каждого товара свой итог, а не общую сумму продаж. При этом желательно не использовать операции прерывающие Query Folding, по сути, ка кодин из вариантов решения, я сджойнил таблицу саму на себя и новом столбце получил вложенную таблицу с продажами по данному товару, но теперь вот незадача, надо отфильтровать вложенную таблицу, т.е. убрать все продажи с индексом (порядковым номером, Index из начала постановки задачи) больше чем у текущей строки, т.е. убрать все более поздние продажи, чем в текущей строке

https://prnt.sc/t1jI9XH2_JN5

Я пробовал Table.TransformColumns но она не принимает значение Index из внешнего окружения, моего понимания принципов работы PQ пока не хватает что-бы либо изобрести другое решение не прерывающее Query Folding либо довести это решение до ума, помогите плиз!  

Добрый день коллеги.

Есть таблица  со звонками клиентов, задача сделать Table.Join саму на себя со сдвигом , для нахождения предыдущего звонка клиента, происходит джойн по номеру клиента + столбец индекса. Всегда для этого использовал столбец индекса + второй столбец со сдвигом +1 или - 1, но всегда работало медленно.
Таблица 1 млн щаписей примерно и скорость становится критичной, плюс эта табличка дальше поступает в другую, и поскольку она не свернута, она отрубает сворачиваение второй таблички, поэтому прерывать Query Folding очень не хотелось бы.
Вопрос: можно ли сварганинть в Power Query столбец индекса (тупо пронумеровать строки в табличке подряд) любой функцией не прерывающей Query Folding.

Само по себе добавление и удаление столбцов с простой логикой, по моему опыту Query Folding не перывает, а вот кокнретно Table.AddIndexColumn - как раз недопустимо.

Заранее спасибо, ответ по теме гуглил, но не нашел ничего пкроме индексирование по сгруппированым данным, но это не то что мне нужно.