Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 99 След.
Расчет графика финансирования из Графика работ
 
Если устроит решение в PQ и PP (не преобразование текущего файла!), то можем созвониться для уточнения ТЗ.
В ЛС напишу по условиям.
Как "прилепить" две схожих таблицы, полученных SQL-запросом?
 
sasch78,
Я что-то хз, Как у Вас работают такие запросы :) По идее ? - это плейсхрлдер для параметра.
То есть запрос должен быть вида … where [Дата] <= ?d …
А d - какой-то параметр, значение которого берется, к примеру, из ячейки.
А просто ? какая-то странная вещь, на мой взгляд.
Особо больше не подскажу.


P.S. Лучше бы PQ попробовали, Вам бы давно реализовали :)

upd: Вроде, далее в коде у Вас должны перечисляться параметры, которые будут подставляться вместо плейсхолдера ?
Вот тут можете почитать.
Изменено: surkenny - 24.05.2024 20:42:30
DAX. Функция HASONEVALUE., Помогите понять как она работает в приведенном примере.
 
Цитата
0033s написал:
Или может "одно" относится к ячейке, а не ко всему столбцу ?
Да. Для каждой "ячейки" проверяется единственность уникальных значений 'Table1[Type] в текущем контексте фильтра.
В строках конкретных Type задает контекст фильтра именно по этому Type, то есть в них HASONEVALUE( 'Table1[Type] ) будет true.
По сути эта функция эквивалентна COUNTROWS ( VALUES ( 'Table1[Type] ) ) = 1

Почему просто не почитать про функцию? :)
Игнорирование фильтра TOP N для меры RANKX
 
Цитата
zrbite написал:
Решение и правда очень простое
На самом деле не простое :(
ALLSELECTED нельзя использовать в итераторах. Вроде, ALLSELECTED похожа на ALL, но на самом деле гораздо более сложная функция.
А иногда в RANKX очень хочется использовать ALLSELECTED :)
Одна странность VAR в DAX
 
0033s, у Вас название неверное, это НЕ странность.
Нужно запомнить одно: переменные в DAX - это константы.
Переменная вычисляется ОДИН раз.
В перовой мере M вычислится один раз (при первом ее вызове) и от значения месяца в строках таблицы 'Table[Month] зависеть не будет.
Во второй же мере будет еще преобразование контекста строки таблицы (списка месяцев) в контекст фильтра. И для каждого месяца будет вычислено свое значение.
условие для отрицательного значения
 
Цитата
GGR написал:
к сожалению результат получается не верный
Вы троллите что ли? В столбце R у Вас просто суммы. Или с чем Вы сравниваете? Какой результат должен быть и почему?

P.S.
Цитата
GGR написал:
результат получается не верный
В данном случае неверный пишется слитно.

P.P.S
Цитата
GGR написал:
которые должны получится
А тут неопределенная форма глагола. Поэтому правильно "получиться"

Сорри, не могу остановиться :) Запятых еще подарю ТС: ",,,,,,,,,,,," :)
Изменено: surkenny - 22.05.2024 22:42:36
Power Query. Объединение таблиц с множеством условий, Power Query. Объединение таблиц с множеством условий
 
voler83, думаю тут ТС просто должен разместить тему (перенести текущую) в платном разделе.
AlienSx реализует :)
Сводная таблица. Power Pivot, Помогите пожалуйста со сводной таблицей
 
Дмитрий Никитин, да я не свою правоту пытаюсь доказать, а ТС подсказать. Поэтому и спрашиваю мнение, какой из вариантов правильнее использовать, если прочитать задачу в файле из #8.
Мера в Pivot, Вытянуть данные из другой таблицы по иерархии выше
 
Цитата
Alex написал:
Вы правы, что в конкретном случае вычисляемый столбец будет предпочтительней.
Он предпочтительнее только с точки зрения оптимальности в текущей модели.
Если делать связку по сконкатенированным нескольким столбцам - то Вам вариант будет не хуже (так как функция RELATED по сути ничего не делает, этот столбец уже будет в база_списаний - читаем про расширенные таблицы). Только что связь по длинному тексту на больших объемах будет медленной.

А вообще, интересен вот этот вопрос: "списание бюджет" установлен на каждый артикул (такого же уровня, в тот же период и тд) или на все артикулы такого уровня?
Если предположить, что это бюджет на каждый артикул, то как посчитать бюджет на группу артикулов? Допустим, бюджет уровня5 = "111" - 100. Есть 5 артикулов. Но списания (строки в таблице база_списаний) содержит только 3 из этих артикулов. Общий бюджет на уровень 5 (для подытогов по артикулам) 500 же? А нашими способами вычислится 300.
Поэтому нужен справочник артикулов. Более того, наверное, эти артикулы "активны" не всегда, то есть в какие-то периоды, когда по ним списаний не было, они должны влиять на общий бюджет группы, а в какие-то нет.
Но это все мои домыслы...

И подытожим: плохое ТЗ - результат ХЗ :)
Изменено: surkenny - 22.05.2024 11:11:11
Сводная таблица. Power Pivot, Помогите пожалуйста со сводной таблицей
 
Alezx, только не обижайтесь, тогда Вам рано на эту должность :)
Чисто по заданию мера DIVIDE ( SUM ( sales[Сумма продаж] ); SUM ( sales[Кол-во] ) ) будет корректной.
Дмитрий Никитин, согласны?
Изменено: surkenny - 22.05.2024 11:13:10
Мера в Pivot, Вытянуть данные из другой таблицы по иерархии выше
 
Цитата
Alex написал:
Не увидел в Вашем примере каких-то сложностей создать связь между таблицами по Уровню5 и дальше простая мера.
стоп!!! :) Это кривой пример от ТС.
Там связь будет не только по уровню. Но и по периоду, организации.
Короче, в бюджете столбец Уровень 5 не будет уникальным :)
Была бы норм модель со справочниками - написал бы меру.
Можно еще сконкатенировать все эти столбцы и по такому столбцу связь делать.
Изменено: surkenny - 22.05.2024 10:41:09
Мера в Pivot, Вытянуть данные из другой таблицы по иерархии выше
 
Цитата
ponrussell написал:
почему то формулы removefilters не существует
Не формулы, а функции. И она существует, просто ее нет в Power Pivot, но есть в Power BI.

Цитата
ponrussell написал:
Вроде аналогичная мера это calculate (_____, removefilters(values))
Эм... Тут какая-то хрень написана, если честно :)

Цитата
ponrussell написал:
сделал в обход, создал справочник, куда через суммесли посчитал бюджеты, и потом в исходнике создал столбец, в который вытянул эти бюджеты. но чем дальше, тем больше проблем. Нужна именно мера.
Почему именно мера? Почему не сделать вычисляемый столбец
Код
=
VAR mnth = 'база_списаний'[Месяц]
VAR week = 'база_списаний'[Неделя]
VAR org = 'база_списаний'[Организация]
VAR lvl = 'база_списаний'[Уровень5]
VAR result =
    CALCULATE (
        SUM ( 'бюджет'[списание бюджет] );
        'бюджет'[месяц] = mnth;
        'бюджет'[Неделя] = week;
        'бюджет'[Организация] = org;
        'бюджет'[Уровень5] = lvl
    )
RETURN
    result

А потом простая мера суммы по этому столбцу?

* Вы бы хоть в примере в бюджете с тем же уровнем 5, что и в базе списаний, данные приложили...
Ну и описание очень плохое. Поменьше эмоций и побольше пишите по делу...
Например, "списание бюджет" установлен на каждый артикул (такого же уровня, в тот же период и тд) или на все артикулы такого уровня?
Когда в данных не даты, а тестовые месяца, недели - это уже признак того, что модель данных плохая :)
Сводная таблица. Power Pivot, Помогите пожалуйста со сводной таблицей
 
Дмитрий Никитин, полностью поддерживаю. Я же так и написал, что Вы сделали согласно "ТЗ". Вернее, я так понял это "ТЗ" :)
Но кто мне может пояснить смысл такого показателя? По манере объяснения, ТС сам(-а) не понимает задачу...

Будем использовать 2 меры:
Код
хрень:= SUMX ( sales; DIVIDE ( sales[Сумма продаж]; sales[Кол-во] ) )

Код
Ср ар:=DIVIDE ( SUM ( sales[Сумма продаж] ); SUM ( sales[Кол-во] ) )


Ситуация 1. У Пети одна продажа, у Маши две продажи того же товара по такой же цене (просто двумя счетами).

Почему разный показатель-то? И сумма и количество одинаковое. Пользователь, смотря отчет, не видит строки данных. Для меня показатели у обоих должны быть одинаковыми.

Ситуация 2. Маша продала 10 дорогих товаров и всего один дешевый. Петя же всего один дорогой и много дешевых. Сумма продаж одинакова, а количество совсем разное - по идее средняя цена продажи должна отличаться. Но нет, одинаковый результат меры [хрень] :)

Такой расчет не позволяет делать верные выводы. Он явно ошибочный.
Изменено: surkenny - 22.05.2024 09:30:12
Ошибка OLE DB или ODBC: [Expression.Error] Не удается преобразовать значения null в тип Table., Ошибка OLE DB или ODBC: [Expression.Error] Не удается преобразовать значения null в тип Table.
 
Никогда не использовал Ваш способ ссылок на запросы.
Что-то мне подсказывает, что в глобальной среде (содержимое которой выводит #shared) запросы существуют только в редакторе.
Честно, хз. Нужно изучать :)
Сводная таблица. Power Pivot, Помогите пожалуйста со сводной таблицей
 
Цитата
Alezx написал:
Я не понимаю как вычислить стоимость одной единицы товара, если столбцы с количеством товара и сумма суммируются (автоматически SUM идет). Потому как столбец с количеством товара подвергается формулам,  то невозможно высчитать 1 единицу товара, так как один товар стоит дороже, другой дешевле, а в свободной таблице столбец со значением «количество товара» числа суммируются
Если честно, какой-то поток мыслей... Как будто Вы сами не особо понимаете, что нужно.
Вы можете отобразить нужный результат?
Дмитрий Никитин, вроде, по ТЗ выполнили. Но не считаете ли Вы, что сумма цен - бессмысленный показатель? :)
Почему не тупо тупо средняя цена?
Код
DIVIDE ( SUM ( 'Исходная'[Сумма продаж] ); SUM ( 'Исходная'[Кол-во] ) )
PQ Объединение запросов /подключений из 3-х и более в один.
 
cityfox, если данные у Вас не выгружены на лист, то из другого файла Вы доступ не получите. PQ не умеет получать текст запроса в другом файле.
По Вашему описанию Вы вообще ничего не можете получить из Ваших трех файлов. Вам в новый файл можно скопировать (ручками) все запросы. Или создать новый на загрузку и объединение из нескольких файлов. Без примера не подскажу.
Как в сводной PP с помощью МЕРЫ рассчитать разность (маржу) и долю (рентабельность)?, есть структурированная таблица продаж и затрат, как в сводной таблице с помощью МЕРЫ рассчитать маржу и рентабельность?
 
VladimirVSh, Вашу "структурированную" таблицу нужно привести (можно в PQ) к нормальному виду для аналитики.
1. Убрать все строки, не являющиеся конечными (вы их фильтром убираете, они по сути не нужны для сводной, там агрегация сама будет делаться)
2. Не должно быть отдельных столбцов с месяцами. При добавке нового месяца будете новые меры создавать?
Должна быть плоская таблица, а не сводная (как у Вас). Вместо n столбцов с n месяцами 2 столбца: с месяцем (месяц лучше датой, а формат отображения изменить на нужный Вам - тогда не будет проблем с сортировкой) и со значением.
3. Теоретически лучше значение так же разбить на 2 столбца (сумма и затраты). Тогда меры будут попроще. Но в принципе, и так вычислить можно.

Я Вам теорию расписал. Задача комплексная. Возможно, кто-то поможет, но рекомендовал бы попросить модераторов перенести в платный раздел.
Создание "промежуточной" сводной таблицы в Power Pivot, получить промежуточные сводные данные для последующей фильтрации и агрегирования
 
1.
Цитата
Sviman144 написал:
слышал, что добавление столбцов вместо мер менее правильный вариант, т.к. производительность "мер" гораздо выше нежели "доп. столбцов"
Вы где-то слышали, даже не приводите источник, но игнорируете написанное мной?
Цитата
surkenny написал:
Производительнее будет все-таки с допстолбцом. Он вычислится один раз. А не каждый раз динамически в мере пересчитывать.
2.
Цитата
Sviman144 написал:
А можно, в принципе, получить еще один столбец в таблице PP, где бы для каждой строки рассчитывалась общая сумма выполнения заявки?
Еще раз, Вы мои ответы читали? Пробовали применить?
Как думаете, что нужно убрать в выражении, чтобы получить сумму (а не больше/не больше эта сумма 60)?
Код
moreThen60 =
CALCULATE (
    SUM ( 'Таблица1'[Итого, мин.] );
    ALLEXCEPT ( 'Таблица1'; 'Таблица1'[StageId] )
) > 60

Мне кажется, очевидно, что следующий столбец - именно то, что Вам нужно. Найдите 3 отличия (кроме наименования столбца и пробелов).
Код
sumById =
CALCULATE (
    SUM ( 'Таблица1'[Итого, мин.] );
    ALLEXCEPT ( 'Таблица1'; 'Таблица1'[StageId] )
)

3. Я же даже расписал, что нужно сделать в PQ. В чем проблема?
Цитата
surkenny написал:
Есть более быстрый вариант: группировка по id, в агрегации 2 столбца: сумма по минутам и просто вся таблица. Затем фильтруете по сумме > 60 и разворачиваете из столбца с таблицей дату и сумму.
Если попробуете сделать, но у Вас не получится, можете создать отдельную тему с вопросом.
Изменено: surkenny - 16.05.2024 15:47:22
Создание "промежуточной" сводной таблицы в Power Pivot, получить промежуточные сводные данные для последующей фильтрации и агрегирования
 
del
Изменено: surkenny - 15.05.2024 21:24:17
Создание "промежуточной" сводной таблицы в Power Pivot, получить промежуточные сводные данные для последующей фильтрации и агрегирования
 
Sviman144,
1. Есть более быстрый вариант: группировка по id, в агрегации 2 столбца: сумма по минутам и просто вся таблица. Затем фильтруете по сумме > 60 и разворачиваете из столбца с таблицей дату и сумму.
2. Не у компа.
Но такую меру попробуйте:
Код
Сумма мин :=
VAR sumByIDs =
    ADDCOLUMNS (
        VALUES ( 'Таблица1'[StageId] );
        "@sum"; CALCULATE ( SUM ( 'Таблица1'[Итого, мин.] ) )
    )
VAR filterIDs =
    FILTER ( visibleIDs; [@sum] > 60 )
VAR result =
    SUMX ( filterIDs; [@sum] )
RETURN
    result

3. Производительнее будет все-таки с допстолбцом. Он вычислится один раз. А не каждый раз динамически в мере пересчитывать.
Код
moreThen60 =
=
CALCULATE (
    SUM ( 'Таблица1'[Итого, мин.] );
    ALLEXCEPT ( 'Таблица1'; 'Таблица1'[StageId] )
) > 60

И мера
Код
Сумма мин:=
CALCULATE ( SUM ( 'Таблица1'[Итого, мин.] ); 'Таблица1'[moreThen60] )
Изменено: surkenny - 15.05.2024 21:23:51
БДР в Power Pivot, БДР в Power Pivot
 
Aneta, одна тема - один вопрос.
Вы не конкретный вопрос задаете, а просите весь процесс описать.
Вы можете в разделе работа создать тему и Вам реализуют отчет.

Подключиться к 1С можно, вроде бы с помощью odbc.
Но только, как мне известно, нарушает лицензионное соглашение 1С + нужно знать структуру регистров 1С (что та еще задница).
Наиболее приемлемое решение - настройка выгрузки по расписанию плоских данных в csv/txt (можно и в excel, но считывать оттуда медленнее) из 1С.
Создание "промежуточной" сводной таблицы в Power Pivot, получить промежуточные сводные данные для последующей фильтрации и агрегирования
 
В PP нельзя создавать вычисляемые таблицы, кроме календаря.
Такой функционал есть только в PBI.
Вы пишете выражение для меры! Мера может возвращать только скалярное значение (какое-то одно значение: цифру, дату, текст…), но не список/таблицу и тп.
Вы можете с легкостью создать такую таблицу в PQ.
Другой вопрос, нужно ли Вам это :)
Чуть позднее приложу вариант.

upd:
Может быть, Вам будет достаточно такого варианта:
- создаем вычисляемый столбец
Код
Общая длительность более 60 мин =
=
CALCULATE (
    SUM ( 'Таблица1'[Итого, мин.] );
    ALLEXCEPT ( 'Таблица1'; 'Таблица1'[StageId] )
) > 60

- просто вытаскиваем этот столбец в фильтр сводной и выбираем ИСТИНУ. Ну или в срез такой столбец вытащить.
Изменено: surkenny - 15.05.2024 18:29:58
БДР в Power Pivot, БДР в Power Pivot
 
Aneta, полностью рассказывать не буду, но суть:
1. Таблица данных: дата, код статьи, …, сумма
2. Создаете справочник со столбцами Статья_ур1, Стать_ур1_sort, Статья_ур2, Статья_ур2_sort,.. Стаья_урN,..
Строки только с конечными статьями.
.._sort - это некий столбец (допустим числовой) для корректной сортировки.
Так же в этом справочнике отдельный столбец с id конечного уровня (для связи с данными). У разных Статей_ур1 может быть разная вложенность.
Далее у этому справочнику добавляете строки с заполненным ур_1 и ур_1_sort со значениями Ваших показателей (margin profit, gross profit, net profit и тп)
Будет таблица типа такой

Как можно заметить у маржи специально отрицательное значение id статьи (строк с такой "статьей" вообще в данных нет)
3. Создаете меры для расчетных показателей:
Код
Выручка = 
CALCULATE (
    SUM ( 'P&L_данные'[Сумма] ),
    REMOVEFILTERS ( 'спр_P&L_Статья' ),
    'спр_P&L_Статья'[Статья_ур1] = "Выручка"
)

Код
MARGIN PROFIT (TOTAL) abs = 
[Выручка]
    + CALCULATE (
        SUM ( 'P&L_данные'[Сумма] ),
        REMOVEFILTERS ( 'спр_P&L_Статья' ),
        'спр_P&L_Статья'[Статья_ур1] = "ПРЯМЫЕ РАСХОДЫ"
    )

и тд.
Эти меры можно скрыть.
4. Создаете конечную меру, например
Код
Показатель = 
SWITCH (
    SELECTEDVALUE ( 'спр_P&L_Статья'[Статья_ур1] ),
    "MARGIN PROFIT (TOTAL) abs", [MARGIN PROFIT (TOTAL) abs],
    "GROSS PROFIT (TOTAL) abs", [GROSS PROFIT (TOTAL) abs],
    "EBITDA (TOTAL) abs", [EBITDA (TOTAL) abs],
    "NET PROFIT (TOTAL) abs", [NET PROFIT (TOTAL) abs],
    SUM ( 'P&L_данные'[Сумма] )
)


Все. Можно строить нужную сводную.
Единственный минус в PP (для PBI есть кастомные визуалы с расчетом фин показателей) это то, что "+" для разворачивания статей до следующего уровня будут и у расчетных (к примеру, у маржи). Хотя там вложенности нет.
Ошибка при создании календаря в Power BI Desktop
 
aplana, приложить вордовский файл со скрином - 5 баллов :) Пришлите хоть сам код, чтобы его не переписывать.
DAX. Мера вычисления среднедневных продаж в разных контекстах
 
mechanix 85, попробуйте выбрать не один филиал, а несколько. То есть эту часть я вообще не понял: if(ISFILTERED('Диапазон'[filial]);...
И лучше не использовать меру ТС. А то излишние итераторы внутри итераторов...

Neostt, у Вас в данных одинаковое количество дней для разных филиалов и одинаковых sku. А если это не так будет? Как считать нужно? :)
Тогда у Вас и мера day неверно отработает.
Если число дней продаж sku в разных филиалах на один период всегда одинаково - то оставляйте свою. Только попроще ее перепишите:
Код
day :=
SUMX (
    SUMMARIZE ( 'Диапазон'; 'Диапазон'[date]; 'Диапазон'[sku] );
    CALCULATE ( MIN ( 'Диапазон'[n_day] ) )
)

По идее так (чтобы мера была аддитивной - в подытогах/итогах значение равнялось сумме по всем строкам в детализации) так:
Код
av_sale :=
SUMX (
    SUMMARIZE ( 'Диапазон'; 'Диапазон'[filial]; 'Диапазон'[sku] );
    VAR sales_amount = [sale_]
    VAR days_cnt =
        SUMX ( VALUES ( 'Диапазон'[date] ); CALCULATE ( MAX ( 'Диапазон'[n_day] ) ) )
    VAR av_s =
        DIVIDE ( sales_amount; days_cnt )
    RETURN
        av_s
)

Если же не бывает разного числа дней для разных филиалов у одного sku/периода, то будет чуть пошустрее:
Код
av_sale_2 :=
SUMX (
    VALUES ( 'Диапазон'[sku] );
    VAR sales_amount = [sale_]
    VAR days_cnt =
        SUMX ( VALUES ( 'Диапазон'[date] ); CALCULATE ( MAX ( 'Диапазон'[n_day] ) ) )
    VAR av_s =
        DIVIDE ( sales_amount; days_cnt )
    RETURN
        av_s
)
Изменено: surkenny - 13.05.2024 19:15:08
PowerQuery - подстановка значения по поиску в диапазоне дат - как оптимизировать
 
AlienSx,
так просто в группировке по скю делать заполнение вниз :)

Вот моя тема старая
Для продаж ранее назначенной цены я еще заполнение вверх делал.
PowerQuery - подстановка значения по поиску в диапазоне дат - как оптимизировать
 
PrALX, а пример данных-то где?
Можете просто поискать "интервальный поиск PQ" на форуме
Power BI: вывести список лучших сотрудников за период
 
Наверное, так корректнее:
Код
Мера = 
VAR cnt_months_selected =
    DISTINCTCOUNT ( 'Calendar'[YM_number] )
VAR cnt_coeff_with_cond =
    COUNTROWS (
        FILTER ( 'Таблица1', 'Таблица1'[Коэф.] >= 0.8 && 'Таблица1'[Коэф.] <= 1 )
    )
VAR result = INT ( cnt_coeff_with_cond = cnt_months_selected )
RETURN
    result
Изменено: surkenny - 13.05.2024 10:46:57
ВПР большого массива к большому массиву, Самы быстрый способ собрать данные между двумя большими массивами
 
Цитата
Jack Famous написал:
voler83 , ну, как-то вы прям необъективно подошли.
Да отличный подход.
Более того, данные на 1+ млн строк тогда хранить в csv без ограничения числа строк.
Одна из таблиц маленькая, джоин шустро отработает.

Возможно, быстрее будет из "маленькой" (к которой "ВПРим") сделать запить rec = [xxxx_xxxx = true, xxxx_xxxy = true, ...] и фильтровать строки "большой" таблицы
Код
Table.SelectRows ( data, (r) => Record.FieldOrDefault ( rec, r[1], false ) )
.

*Если ТС согласится, что данные будут в csv, то реализуем.
Изменено: surkenny - 08.05.2024 19:30:01
При объединении двух таблиц с помощью Table.NestedJoin и JoinKind.LeftOuter через общий для них столбец в левую таблицу добавляются записи. Разве так должно быть?
 
Цитата
AlexDen написал:
по логике, 2-я таблица как раз должна иметь уникальность по Key_1
А сразу это проверить? :) У Вас же строки размножились, первое, что каждый человек сделает, проверит, уникальные ли ключи во второй таблице.
Вернее, даже не так: если бы ключи были уникальными, то строки не размножились бы. То есть результат явно говорит о дублировании ключей во второй таблице.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 99 След.
Наверх