|
22.11.2023 15:35:09
nilske, благодарю за информацию, изучу. Но, насколько понимаю, наличие токена не обязательно для решения этой задачи. Достаточно много раз исполнял код, но проблем с капчой не было
Изменено: - 22.11.2023 15:38:09
|
|
|
|
|
|
22.11.2023 15:12:50
AlienSx, я написал в своем сообщении, на чьем коде формировал свой. Правда, Илья Назаров свой пример строил на базе пагинации перечня файлов, лежащих на Яндекс-диске. Несколько раз просмотрел его пример и на его базе сформировал свой. Но сусликов правда не хватает, тут вы правы, поэтому и обратился за помощью. Пока яснее не стало.
Изменено: - 22.11.2023 15:18:02
|
|||||
|
|
|
|
29.09.2022 17:10:16
Вроде как нашел решение. Возможно, не очень оптимальное, но работает. Выкладываю, вдруг кому пригодится:
|
|||
|
|
|
|
29.09.2022 10:31:57
Уважаемые форумчане, приветствую вас! Есть потребность в помощи при расчете коэффициента сезонности продаж. Имеется таблица продаж ("Операции"), в которой приведены строки ежедневных продаж за несколько лет. Коэффициент сезонности рассчитываю по следующему алгоритму:
1. Агрегатирую количество продаж за несколько лет по номеру месяца продаж. 2. Вычисляю среднее количество продаж по агрегатированным 12 месяцам. 3. Вычисляю коэффициент сезонности в помесячной разбивке, как деление агрегатированных продаж в конкретном месяце к среднему (п.2).
Первые два пункта описал в коде, а как вывести сумму агрегатированных продаж в конкретном месяце и соотнести к пункту 2 не понимаю. Буду благодарен за помощь в данном вопросе
Изменено: - 29.09.2022 12:15:46
|
|||
|
|
|
|
02.09.2022 15:13:02
понял. Не туда вносил фильтрацию по датам. Код должен выглядеть так:
Теперь всё работает. , спасибо за помощь! |
|||
|
|
|
|
02.09.2022 12:43:16
, понял, в чем была моя ошибка в предыдущем посте. Для функции AVERAGEX требовалось добавить ссылку на столбец (квадратные скобки), а я вставлял без них. Конечный код выглядит так:
, спасибо! На всякий случай выкладываю файл с данным кодом, вдруг кому пригодится. И еще вопрос по теме. Этот код работает по внешним фильтрам дат. Как сделать так, чтобы он брал данные только за последние 6 месяцев вне зависимости от внешних фильтров дат на визуализации? Попытался это сделать, внедрив фильтрацию в момент формирования таблицы:
Изменено: - 02.09.2022 13:46:11
|
|||||
|
|
|
|
01.09.2022 23:57:28
, код ваш, а то, что он продублирован в коде - это уже моё творчество. Month - да, это столбец с наименованием месяца, принимаю, что нужно брать YearMonth, ценное замечание, спасибо.
Алгоритм расчета понятен, но попробовал по вашему примеру рассчитать среднее, не получилось:
Изменено: - 02.09.2022 00:03:56
|
|||
|
|
|
|
01.09.2022 16:44:26
Уважаемые форумчане, добрый день! Выявилась потребность в расчете коэффициента вариации. Как мы все знаем, это соотношение стандартного отклонения к среднему значению. В исходных данных детализация оборота - по дням, требуемое значение вариации необходимо рассчитать с помесячной агрегацией. Написал такой код (подсмотрел у , спасибо):
Код работает, но только в случае, когда во всех месяцах есть строки с данными по обороту. Если в каком-либо месяце оборота нет (нет строк в исходнике), код не воспринимает этот месяц. А для корректности требуемой задачи должен принимать исходные данные, как нулевые по этому месяцу и производить расчет стандартного отклонения, среднего значения и коэффициента вариации с учетом всех этих нулевых месяцев. Буду благодарен, если кто-нибудь сможет подсказать решение данной задачи.
Изменено: - 01.09.2022 16:44:56
|
|||
|
|
|
|
30.05.2022 09:44:33
, прошу прощения за задержку с ответом. Да, согласен, моя цитируемая вами фраза некорректна. Попытался на реальной модели посчитать ежедневную оборачиваемость каждой номенклатуры (соотношение продаж за предыдущий месяц к среднему остатку), рассчитанному по вышеуказанной методологии, но 64 Гб оперативной памяти не хватило для данного действия. Хотя, если таблица остатков на каждый день не расчетная из двух таблиц, как у меня в примере, а загружаемая единая, он с ней справляется. Наверное, очень большой объём информации приходится держать в оперативке. Одну номенклатурную позицию считает быстро и нормально, при 300 позиций говорит, что не хватает памяти. Буду думать. В любом случае, ваша помощь в расчете конечных остатков и открытие по обработке мер через SUMX были очень ценны для меня, за что я вам крайне благодарен.
|
|
|
|
|
|
22.05.2022 21:18:02
, спасибо! Ранее я пытался создать, подобную конструкцию, но не с SUMX, а с SUM. У меня ничего не получилось и я сделал для себя вывод, что этот вариант не работает и всё нужно загонять в меру. Оказывается, я ошибался с оператором и, на самом деле, всё считает. Если SUMX считает, значит, по идее, и CALCULATE может считать скользящую оборачиваемость на каждую дату (отношение продаж за промежуток с текущей даты до даты минус 30 дней к среднему остатку за этот же промежуток времени). Хотя, возможно, не CALCULATE, а CALCULATETABLE, судя по обсуждаемому коду.
|
|
|
|
|
|
20.05.2022 10:54:10
, спасибо за дополнительную информацию! В коде сообщения #3 при тестировании выявил неточность - если смотреть по одной номенклатурной позиции, считает правильно, если несколько - нет. Для себя выявил, что MIN необходимо заменить на SUM, т.е.
Вроде бы и по логике правильно. По вопросам - результат итогов не нужен (меру использую для формирования графика остатков по дням - отдельных позиций и номенклатурных групп), Данные по промежуточному остатку на первое число каждого месяца присутствуют, но всегда держу в уме - а вдруг по какой-то позиции данных не будет (пропущен месяц). Правильно ли при этом посчитает мера. И, если будет возможность ответить, задам ещё один вопрос. Мера сейчас рассчитывает остаток на каждый день. А как получить сумму этих значений по каждому дню (чтобы в дальнейшем использовать данные для расчета оборачиваемости)? Какой-то цикл надо организовывать? |
|||||
|
|
|
|
20.05.2022 01:01:27
, благодарю за помощь! В коде разобрался, понял в чем была ошибка моей логики. Особенно приятно, что код дополнен "невыводом" данных, лежащих за пределами временного среза. Это мелочь, но однозначно показатель работы эксперта - профессионала. Ну и из кода вы убрали MAXX+FILTER, значит не будет хмурить на меня брови))).
|
|
|
|
|
|
19.05.2022 21:42:55
Уважаемые форумчане, добрый день! Выявилась проблема с расчетом ежедневных остатков. Есть промежуточные ежемесячные данные по остаткам на 1-й день месяца (1 января, 1 февраля и т.д.) и есть оборот (приходы, расходы) по каждому дню в отдельной таблице. Необходимо рассчитать начальный и конечный остаток каждого дня.
Логику расчета конечного остатка понимаю - надо вычислить ближайшую, более раннюю дату промежуточного остатка к минимальной дате установленного срезом временного промежутка. И затем к вычисленному на эту дату промежуточному остатку прибавить обороты за промежуток с даты этого промежуточного остатка до максимальной даты среза. Попытался создать меру по этому алгоритму.
Но она считает неправильно. Просьба помочь в решении вопроса. |
|||
|
|
|
|
05.05.2022 21:11:21
, решил не выдумывать велосипед, но на мере так же споткнулся. Если просто перегнать код столбца в меру, то ругается на переменную
В вычисляемом столбце он эту конструкцию принимает. Пока не пойму, как это победить. Если не трудно, помогите с данной проблемой. |
|||
|
|
|
|
04.05.2022 21:22:08
, благодарю за помощь! Да, как Вы верно подметили, я пытаюсь организовать расчеты в вычисляемых столбцах, чтобы видеть этапы вычисления и обезопасить себя от возможных логических ошибок. Но, с Ваших слов я понял, что "подружить" вычисляемые столбцы внутренних таблиц с внешним параметром (движком) не получится. Буду думать про перенос расчета из вычисляемых столбцов в меры. Про SELECTEDVALUE я знал, пробовал применить для этой задачи, но решения не получилось.
Ранее видел в каком-то источнике, что организовывают связь между таблицей параметра и таблицей, в вычислениях которой требуется использование данного параметра. Сейчас его не нашел. Если найду, выложу в текущую ветку. |
|
|
|
|
|
04.05.2022 12:01:24
Добрый день! Есть необходимость в организации анализа "What if" в Power BI. Для этого в Моделировании создал параметр "Множитель расхода" и создал формулу расчета в таблице Тест (2) РасходМножитель:
Но на изменение движка "Множитель расхода" никак не происходит вывод данных и их изменение в таблице. Подчеркну, что изменение необходимо именно в таблице Тест (2). Возможно требуется другая формула, но я не знаю, какая. Просьба помочь по данному вопросу.
Изменено: - 04.05.2022 12:02:04
(Вложение)
|
|||
|
|
|
|
25.04.2022 09:49:07
, понял, спасибо! Возник ещё вопрос. Данный расчет прихода производится с учетом расхода следующего месяца. А если требуется, чтобы конечный остаток текущего месяца составлял какую-то долю (например, 50% от расхода следующего месяца или 150%), как это можно организовать?
Я в блок вычисления расхода ввёл коэффициент 0.5, но расчет воспринял это как просто уменьшение расхода в 2 раза и пересчитал не так, как было необходимо. Конечный ежемесячный остаток ушел в минус
Изменено: - 25.04.2022 09:50:39
(Корректировка)
|
|||
|
|
|
|
24.04.2022 22:33:31
, благодарю и за это решение. Не совсем понял блок программного кода в расчете Прихода:
Если не трудно, оцените, возможно ли его так заменить.
Изменено: - 24.04.2022 22:36:10
(Вложение файла)
|
|||||
|
|
|
|
22.04.2022 15:36:10
, потревожу ещё с вопросом по теме.
1. Этот расчет приведен для варианта без начального остатка. А если он есть (например, 200) на начало расчетов. Где он должен в коде присутствовать? 2. Сейчас расчет прихода и остатков показывает только необходимый объём расхода с кратностью 50. А если нужен запас (остаток) в размере следующего месяца расходов, как это в коде организовать? |
|
|
|
|
|
22.04.2022 12:33:45
, спасибо, понял. Замена ALL на ALLEXCEPT дает необходимый эффект. Но математика расчета не бьется почему-то. Январь - нормально (Приход 200, Расход -181, Остаток - 19).
Но февраль (Остаток предыдущего месяца - 19, Приход - 250, Расход - 206) должен выводить 63, а выводит 13 (разница 50). Март - (Остаток предыдущего месяца - 63, Приход - 350, Расход - 293) должен выводить 120, а выводит 20 (разница 100). Апрель - (Остаток предыдущего месяца - 120, Приход - 450, Расход - 418) должен выводить 152, а выводит 2 (разница 150). Май - (Остаток предыдущего месяца - 152, Приход - 350, Расход - 329) должен выводить 173, а выводит 23 (разница 150) и т.д. Где-то в коде захватывает дополнительное количество кратности (округления). Не совсем понятно где, логики н вижу. Приход рассчитывается в увеличенном объёме. А остаток получается правильным (тем, который необходим для данной задачи - не более количества кратности) |
|
|
|
|
|
22.04.2022 10:10:16
спасибо за ваш вариант! Но мне требуется получить данные не в сводной таблице визуализации, а в самой таблице. На основании вашего кода создал в таблице дополнительно 2 столбца (Прих и ОстатКонМес), но он выдает в каждой ячейке итоговое значение. Это проблема календаря? Создал отдельно календарь, но как получить данные в таблице, как и в итоговой визуализации пока не пойму.
|
|
|
|
|