Если устроит решение в PQ и PP (не преобразование текущего файла!), то можем созвониться для уточнения ТЗ.
В ЛС напишу по условиям.
В ЛС напишу по условиям.
24.05.2024 20:21:39
sasch78,
То есть запрос должен быть вида … where [Дата] <= ?d … А d - какой-то параметр, значение которого берется, к примеру, из ячейки. А просто ? какая-то странная вещь, на мой взгляд. Особо больше не подскажу. P.S. Лучше бы PQ попробовали, Вам бы давно реализовали upd: Вроде, далее в коде у Вас должны перечисляться параметры, которые будут подставляться вместо плейсхолдера ?
Изменено: |
|
|
24.05.2024 11:54:43
В строках конкретных Type задает контекст фильтра именно по этому Type, то есть в них HASONEVALUE( 'Table1[Type] ) будет true. По сути эта функция эквивалентна COUNTROWS ( VALUES ( 'Table1[Type] ) ) = 1 Почему просто не |
|||
|
23.05.2024 10:02:28
0033s, у Вас название неверное, это НЕ странность.
Нужно запомнить одно: переменные в DAX - это константы. Переменная вычисляется ОДИН раз. В перовой мере M вычислится один раз (при первом ее вызове) и от значения месяца в строках таблицы 'Table[Month] зависеть не будет. Во второй же мере будет еще преобразование контекста строки таблицы (списка месяцев) в контекст фильтра. И для каждого месяца будет вычислено свое значение. |
|
|
22.05.2024 22:28:14
P.S.
P.P.S
Сорри, не могу остановиться Запятых еще подарю ТС: ",,,,,,,,,,,,"
Изменено: |
|||||||
|
22.05.2024 19:18:30
Дмитрий Никитин, да я не свою правоту пытаюсь доказать, а ТС подсказать. Поэтому и спрашиваю мнение, какой из вариантов правильнее использовать, если прочитать задачу в файле из #8.
|
|
|
22.05.2024 11:10:45
Если делать связку по сконкатенированным нескольким столбцам - то Вам вариант будет не хуже (так как функция RELATED по сути ничего не делает, этот столбец уже будет в база_списаний - читаем про расширенные таблицы). Только что связь по длинному тексту на больших объемах будет медленной. А вообще, интересен вот этот вопрос: "списание бюджет" установлен на каждый артикул (такого же уровня, в тот же период и тд) или на все артикулы такого уровня? Если предположить, что это бюджет на каждый артикул, то как посчитать бюджет на группу артикулов? Допустим, бюджет уровня5 = "111" - 100. Есть 5 артикулов. Но списания (строки в таблице база_списаний) содержит только 3 из этих артикулов. Общий бюджет на уровень 5 (для подытогов по артикулам) 500 же? А нашими способами вычислится 300. Поэтому нужен справочник артикулов. Более того, наверное, эти артикулы "активны" не всегда, то есть в какие-то периоды, когда по ним списаний не было, они должны влиять на общий бюджет группы, а в какие-то нет. Но это все мои домыслы... И подытожим: плохое ТЗ - результат ХЗ
Изменено: |
|||
|
22.05.2024 10:43:24
Alezx, только не обижайтесь, тогда Вам рано на эту должность
Чисто по заданию мера DIVIDE ( SUM ( sales[Сумма продаж] ); SUM ( sales[Кол-во] ) ) будет корректной. Дмитрий Никитин, согласны?
Изменено: |
|
|
22.05.2024 10:39:58
Там связь будет не только по уровню. Но и по периоду, организации. Короче, в бюджете столбец Уровень 5 не будет уникальным Была бы норм модель со справочниками - написал бы меру. Можно еще сконкатенировать все эти столбцы и по такому столбцу связь делать.
Изменено: |
|||
|
22.05.2024 10:37:09
А потом простая мера суммы по этому столбцу? * Вы бы хоть в примере в бюджете с тем же уровнем 5, что и в базе списаний, данные приложили... Ну и описание очень плохое. Поменьше эмоций и побольше пишите по делу... Например, "списание бюджет" установлен на каждый артикул (такого же уровня, в тот же период и тд) или на все артикулы такого уровня? Когда в данных не даты, а тестовые месяца, недели - это уже признак того, что модель данных плохая |
|||||||||
|
22.05.2024 09:17:55
Дмитрий Никитин, полностью поддерживаю. Я же так и написал, что Вы сделали согласно "ТЗ". Вернее, я так понял это "ТЗ"
Но кто мне может пояснить смысл такого показателя? По манере объяснения, ТС сам(-а) не понимает задачу... Будем использовать 2 меры:
Ситуация 1. У Пети одна продажа, у Маши две продажи того же товара по такой же цене (просто двумя счетами). Почему разный показатель-то? И сумма и количество одинаковое. Пользователь, смотря отчет, не видит строки данных. Для меня показатели у обоих должны быть одинаковыми. Ситуация 2. Маша продала 10 дорогих товаров и всего один дешевый. Петя же всего один дорогой и много дешевых. Сумма продаж одинакова, а количество совсем разное - по идее средняя цена продажи должна отличаться. Но нет, одинаковый результат меры [хрень] Такой расчет не позволяет делать верные выводы. Он явно ошибочный.
Изменено: |
|||||
|
21.05.2024 23:11:56
Вы можете отобразить нужный результат? Дмитрий Никитин, вроде, по ТЗ выполнили. Но не считаете ли Вы, что сумма цен - бессмысленный показатель? Почему не тупо тупо средняя цена?
|
|||||
|
21.05.2024 12:03:24
cityfox, если данные у Вас не выгружены на лист, то из другого файла Вы доступ не получите. PQ не умеет получать текст запроса в другом файле.
По Вашему описанию Вы вообще ничего не можете получить из Ваших трех файлов. Вам в новый файл можно скопировать (ручками) все запросы. Или создать новый на загрузку и объединение из нескольких файлов. Без примера не подскажу. |
|
|
16.05.2024 16:35:54
VladimirVSh, Вашу "структурированную" таблицу нужно привести (можно в PQ) к нормальному виду для аналитики.
1. Убрать все строки, не являющиеся конечными (вы их фильтром убираете, они по сути не нужны для сводной, там агрегация сама будет делаться) 2. Не должно быть отдельных столбцов с месяцами. При добавке нового месяца будете новые меры создавать? Должна быть плоская таблица, а не сводная (как у Вас). Вместо n столбцов с n месяцами 2 столбца: с месяцем (месяц лучше датой, а формат отображения изменить на нужный Вам - тогда не будет проблем с сортировкой) и со значением. 3. Теоретически лучше значение так же разбить на 2 столбца (сумма и затраты). Тогда меры будут попроще. Но в принципе, и так вычислить можно. Я Вам теорию расписал. Задача комплексная. Возможно, кто-то поможет, но рекомендовал бы попросить модераторов перенести в платный раздел. |
|
|
16.05.2024 15:46:06
1.
Как думаете, что нужно убрать в выражении, чтобы получить сумму (а не больше/не больше эта сумма 60)?
Мне кажется, очевидно, что следующий столбец - именно то, что Вам нужно. Найдите 3 отличия (кроме наименования столбца и пробелов).
3. Я же даже расписал, что нужно сделать в PQ. В чем проблема?
Изменено: |
|||||||||||||
|
15.05.2024 20:40:34
Sviman144,
1. Есть более быстрый вариант: группировка по id, в агрегации 2 столбца: сумма по минутам и просто вся таблица. Затем фильтруете по сумме > 60 и разворачиваете из столбца с таблицей дату и сумму. 2. Не у компа. Но такую меру попробуйте:
3. Производительнее будет все-таки с допстолбцом. Он вычислится один раз. А не каждый раз динамически в мере пересчитывать.
И мера
Изменено: |
|||||||
|
15.05.2024 18:38:11
Aneta, одна тема - один вопрос.
Вы не конкретный вопрос задаете, а просите весь процесс описать. Вы можете в разделе работа создать тему и Вам реализуют отчет. Подключиться к 1С можно, вроде бы с помощью odbc. Но только, как мне известно, нарушает лицензионное соглашение 1С + нужно знать структуру регистров 1С (что та еще задница). Наиболее приемлемое решение - настройка выгрузки по расписанию плоских данных в csv/txt (можно и в excel, но считывать оттуда медленнее) из 1С. |
|
|
15.05.2024 18:16:44
В PP нельзя создавать вычисляемые таблицы, кроме календаря.
Такой функционал есть только в PBI. Вы пишете выражение для меры! Мера может возвращать только скалярное значение (какое-то одно значение: цифру, дату, текст…), но не список/таблицу и тп. Вы можете с легкостью создать такую таблицу в PQ. Другой вопрос, нужно ли Вам это Чуть позднее приложу вариант. upd: Может быть, Вам будет достаточно такого варианта: - создаем вычисляемый столбец
- просто вытаскиваем этот столбец в фильтр сводной и выбираем ИСТИНУ. Ну или в срез такой столбец вытащить.
Изменено: |
|||
|
15.05.2024 15:08:34
Aneta, полностью рассказывать не буду, но суть:
1. Таблица данных: дата, код статьи, …, сумма 2. Создаете справочник со столбцами Статья_ур1, Стать_ур1_sort, Статья_ур2, Статья_ур2_sort,.. Стаья_урN,.. Строки только с конечными статьями. .._sort - это некий столбец (допустим числовой) для корректной сортировки. Так же в этом справочнике отдельный столбец с id конечного уровня (для связи с данными). У разных Статей_ур1 может быть разная вложенность. Далее у этому справочнику добавляете строки с заполненным ур_1 и ур_1_sort со значениями Ваших показателей (margin profit, gross profit, net profit и тп) Будет таблица типа такой Как можно заметить у маржи специально отрицательное значение id статьи (строк с такой "статьей" вообще в данных нет) 3. Создаете меры для расчетных показателей:
и тд. Эти меры можно скрыть. 4. Создаете конечную меру, например
Все. Можно строить нужную сводную. Единственный минус в PP (для PBI есть кастомные визуалы с расчетом фин показателей) это то, что "+" для разворачивания статей до следующего уровня будут и у расчетных (к примеру, у маржи). Хотя там вложенности нет. |
|||||||
|
13.05.2024 18:57:55
mechanix 85, попробуйте выбрать не один филиал, а несколько. То есть эту часть я вообще не понял: if(ISFILTERED('Диапазон'[filial]);...
И лучше не использовать меру ТС. А то излишние итераторы внутри итераторов... Neostt, у Вас в данных одинаковое количество дней для разных филиалов и одинаковых sku. А если это не так будет? Как считать нужно? Тогда у Вас и мера day неверно отработает. Если число дней продаж sku в разных филиалах на один период всегда одинаково - то оставляйте свою. Только попроще ее перепишите:
По идее так (чтобы мера была аддитивной - в подытогах/итогах значение равнялось сумме по всем строкам в детализации) так:
Если же не бывает разного числа дней для разных филиалов у одного sku/периода, то будет чуть пошустрее:
Изменено: |
|||||||
|
13.05.2024 15:01:25
AlienSx,
так просто в группировке по скю делать заполнение вниз Вот Для продаж ранее назначенной цены я еще заполнение вверх делал. |
|
|
13.05.2024 10:33:35
Наверное, так корректнее:
Изменено: |
|||
|
08.05.2024 19:24:58
Более того, данные на 1+ млн строк тогда хранить в csv без ограничения числа строк. Одна из таблиц маленькая, джоин шустро отработает. Возможно, быстрее будет из "маленькой" (к которой "ВПРим") сделать запить rec = [xxxx_xxxx = true, xxxx_xxxy = true, ...] и фильтровать строки "большой" таблицы
*Если ТС согласится, что данные будут в csv, то реализуем.
Изменено: |
|||||
|
07.05.2024 10:25:25
Вернее, даже не так: если бы ключи были уникальными, то строки не размножились бы. То есть результат явно говорит о дублировании ключей во второй таблице. |
|||
|