Maximich, спасибо, любопытный момент!

Sanja, последние годы в отпуск только в горы и ездим с компанией друзей: началось в 22-ом с Армении, 23 - Камчатка, 24 - Кыргызстан. Сплошной кайф!
П.С. Сорри за оффтоп, больше не буду

pani_v,  приведите пример таблицы данных, пару сотен строк будет достаточно. Можете все данные изменить, от примера и будем плясать. Пока нет смысла наугад решения делать. Еще вопрос: "ID" уникален в периоде? Или в разных днях, месяцах или годах может повторяться?

Понимаю, DAX умеет делать невероятные вещи в области аналитики. Если у Вас много сложных и кажущихся не выполнимых задач, то потратьте время на изучение DAX, откроются новые горизонты и возможности. Можно сделать сразу правильный выбор и купить вот это

Ну так все ваши файлы со столбцами положите в одну папку. Затем создайте отдельный файл, который и подключите к этой папке. Как подключить папку и объединить файлы в один в power query ищите н просторах интернета. Информации куча, в том числе с видео

Добрый день, вариант:

значение параметра можно передать в меру, но никак не в вычисляемый столбец таблицы. Поэтому этот путь решения проблемы не сработает. Вы сейчас присваиваете категорию магазину заранее, а нужно сделать так, чтобы категория присваивалась динамически. Это непростая задача, к сожалению времени сделать ее за вас у меня нет. Но суть такая: отдельно создаете таблицу категорий, но связи делать НЕ нужно. Теперь в матрицу бросаете категории и магазины. Конечно, у Вас будет дублирование всех магазинов в каждой категории, но тут Вы должны написать меру, которая в виртуальной таблице распределит магазины по категориям и если категория совпадает с нужной, то выводите результат, если нет - blank(). В мере Вы сможете делать расчет от параметра.

Очень интересно, ничего подобно не видел раньше. Не корректно работает при некоторых комбинациях чисел, но только если 2 строки. При 3-ех и более работает нормально. Похоже баг какой-то в Power Pivot.

похоже на рекурсию. В DAX такое не сделать

не нужно создавать вычисляемый столбец на листе Экселя непосредственно. Сделайте это на этапе загрузки в Power Query или уже в самой модели данных Power Pivot. Без уник. ключа в такой ситуации никак.
П.С. файл не смотрел

Ильсур Шакиров, если Вы копируете сводную, созданную на на основе модели данных, то скопируется вся модель данных, а не только то, что отфильтровали. Делайте для заказчика отдельную оптимизированную модель данных с уже ограниченным набором данных в power pivot

grigju, добавьте в область значений какое-нибудь поле, например, кол-во строк и заработает. Пока нет ни единого вычисляемого значения, Power pivot не может корректно отобразить зависимые справочники.

отставить панику, я просто ослеп! Я увидел 29 563,1309Р как 29,5 млн и не понимал, откуда эта сумма, если во всей таблице 30,5 млн.)) Бывает. А по поводу все логично, ведь CALCULATETABLE() и CALCULATE() могут менять как угодно контекст фильтров. Но в изначальных мерах ТС они не используются, поэтому там контексты (внешний и внутренний) просто накладываются друг на друга. Вот в Вашем примере можно рассуждать, что внутренний контекст "перебивает" внешний", а в примере ТС нет.

я честно говоря вообще не понимаю, почему в данной мере получается такой результат:

Надо бы прочитать книгу еще разок.

Дмитрий Никитин, добрый день, я книжку читал по диагонали пару лет назад, поэтому могу ошибаться, но мне кажется Вы ошибаетесь в том, что считаете, что контексты внутренний и внешний перебивают друг друга. Они же накладываются друг на друга, отсекая все лишнее. Поэтому не могу понять вот эту фразу: это как? Вы в мере 'Max Sales Date' на входе группируете всю таблицу sales по дням VALUES('Date'[Date]) образно говоря (хотя это ненужная операция, но я так понимаю это эксперимента ради), но еще не считается, перед вычислением она принимает внешний контекст в виде даты "02,01,2007" к примеру и остается только одна строка внутри VALUES('Date'[Date]) для вычисления, что успешно и вычисляется. На уровне месяца января, соответственно 31 дата для вычисления в VALUES('Date'[Date]) и.т.д. Т.е. контексты внутренний и внешний накладываются друг на друга. Где они перебиваются, я не понимаю.

странно, я когда тестил у себя - работало

Потому что я уже писал с самого начала про это, вот вижимка:
Теперь на картинках тогда:

Чтобы Ваша мера заработала в том виде, котором Вы ее написали, добавьте третью связь с Date по столбцам Sales[OrderDate] и Date[Date] и сделайте активной по умолчанию. Теперь типы данных активной связи и неактивной (DeliveryDate) будут одинаковыми и мера заработает.
Я ушел в отпуск, это мое последнее сообщение в данной теме.

как это должно выглядеть? В вашей же модели данных все нормально! таблица sales  и мера [Multiple Sales] отрабатывают корректно. В матрице сумма разбивается по брендам? Разбивается. Так почему Вы продолжаете писать одно и тоже, что Вы прочитали и таким образом понимаете. Может все же Вы просто что-то неправильно поняли? Еще раз, Вы не привели ни одно факта, что у Вас мера [Multiple Sales] работает некорректно (не учитывает контекст по Product[Brand]), но упорно продолжаете про это писать, потому что Вы так поняли цитату. Напишите страницу, откуда цитата. А то пока....ладно, не буду писать. О чем Вы пишите?  столбец Sales[OrderDate] не учувствует ни в одной из связей (активная, неактивная), ни в функции USERELATIONSHIP(). По умолчанию связь активная по sales[OrderDataKey] и Calendar[DateKey], отсюда и фильтр и агрегация по годам. В чем проблема я не понимаю. Про поведение Вашей "некорректно" написанной меры [Delivered Amount] я пытался объяснить в сообщение #2. Если не понятно, извините, по другому объяснить не могу. Пишу последний раз: приведите примеры, какой результат Вы ожидаете получить в 1-ом и 2-ом случае работы мер, тогда можно конкретно о чем то говорить. Пока я вижу, что у Вас все-таки каша в голове. А меры отрабатывают ровно так, как и написаны.

Дмитрий Никитин, у Вас по-моему каша в голове. Все фильтры действуют в мере и внешние (бренд, год) в матрице, и внутренние ('Sales'[Quantity] > 1).
В данном случае расчет идет по активной связи календаря (OrderDateKey - DateKey) и в матрице внешний контекст фильтров срабатывает как нужно (Product[Brand] и КалендарьГод.

Если еще не понятно, давайте от обратного: вот Вы на скрине пишите
, что product[Brand] не фильтрует первую часть выражения. Докажите, какие результаты по Вашему должны получиться? (проверьте в Excel) формулами например.
как откуда? Отсюда

USERELATIONSHIP() на то и нужен, чтобы "забить" на установленные активные связи и рассчитать по другой не активной.

я перечитал несколько раз, но так и не понял, в чем проблема у Вас? Почему Вы считаете, что внешний фильтр не действует? Вот ваши же меры в разрезе брендов, что в их поведении вызывает смущение?

Дмитрий Никитин, добрый день. Я конечно когда-то читал умные книжки, но бол-во уже позабыл, поэтому я так, своими словами попробую.
1. CALCULATE - самая мощная функция, которая позволяет менять контексты фильтров с помощью других вложенных функций. То же и про CALCULATETABLE(), только она не значение дает, а таблицу, которую дальше нужно считать. вот то, что Вы написали, честно говоря, бессмыслица какая-то. Если цель стоит посчитать продажи по дате доставки, то тогда достаточно написать:

Теперь объясняю, почему не срабатывает Ваш вариант. Внутри CALCULATETABLE() вы используете USERELATIONSHIP() и изменили связь. По сути вы сделали таблицу, где есть столбец "Quantity" и "Delivery Date" в формате даты. Далее Вы хотите посчитать сумму по данной измененной таблице внутри CALCULATE(). Тут возникает одно НО. В функцию CALCULATE() не передан модификатор USERELATIONSHIP(), она только внутри CALCULATETABLE() и соответственно CALCULATE() продолжает считать по текущей активной связи с датой "OrderDataKey". А теперь обратите внимание, что в этих двух столбцах форматы дат абсолютно разные  "OrderDataKey" и "Delivery Date". Поэтому CALCULATE() и выдает BLANK(), т.к. форматы дат абсолютно не совпадают. Если продолжить Вашу логику рассуждения, то Вам нужно было бы написать так: но это бессмысленно, потому что проще делать так, как я выше уже сделал. Результат одинаковый.

ничего не понятно. Попробуйте на картинке стрелками что-ли объяснить, что Вы хотите и как.

так там самое интересное, что в многопоточность могут только:
- Все унарные и двоичные операторы в Excel.
- Почти все встроенные функции листа, начиная с Excel 2007
- Функции надстроек XLL, которые явным образом зарегистрированы как потокобезопасные.
Как я понимаю, ни VBA, ни PQ, ни PP сюда не попадают. А значит используют при работе только 1 процессор. Поправьте меня, если я не правильно понял статью.

не должно так быть. А где файлы лежат, на сервере или на локальном диске? Если на серваке, то нужно копать в сторону скорости потока данных по сети. Думаю, такой объем данных (400 файлов суммарно на миллион строк) обновились бы за 10-20 минут. Если только в самом запросе нет "выкрутасов" с ДЖОЙНАМИ, сворачиваниями и прочего, что может съесть оперативку.
П.С. интереса ради наклепал 400 одинаковых файлов на 60 столбцов и 2500 строк в каждом. (30 текстовых и 30 числовых столбцов). Простая загрузка данных этих 400 файлов без каких-либо преобразований заняло всего-лишь 2 минуты.

intel® hd graphics 630 - вроде ниочем.

Я тоже работаю с большими объемами данных в Excel и Power BI (до 100 млн строк).

Вот этого мне хватает, + SSD.

нет, не лучше. Excel в большей степени работает как однопоточная программа, ну т.е. есть различные функции, которые умеют многопоточность использовать, но в большей степени нет. (хотя могу наврать, но я так понимаю работу программы) И в таком случае более важным будет производительность 1 процессора, и не их кол-ва. А так для Ваших потребностей важность комплектующих я бы отранжировал так:
1. Оперативка (самое важное для PQ и PP). 32 ГБ должно хватить на обработку десятков миллионов строк данных.
2. SSD
3. Процессор.

Lari, вот тут была схожая проблема с кросс-фильтрами в Power BI. Суть в том, что в PBI все элементы друг на друга по умолчанию под капотом накладывают кросс-фильтрацию, т.е. в Вашем случае фильтр "полугодие" так же влияет на фильтр "год" оставляя половину дат за бортом для "года" и уже фильтр "год" далее взаимодействует с матрицей уже в усечённом на полгода состоянии. Как проверить: убираете фильтр "год" с вашего макета, можете его (год) добавить в матрицу и далее смотрите за общим итогом при использовании оставшегося фильтра "полугодие" - должно корректно считать.