Но и тут есть один нюанс, лучше всего загружать результат запроса в модель данных и на её базе уже строить сводную. Если сводную строить на базе подключения на основе запроса PQ, то нельзя переименовывать файл чем либо кроме как менюшкой Экселя "Сохранить как". В противном случае подключение поломается.

Hugo, в модель данных можно вывести до ярда строк, если мне не изменяет мой склероз. сам выводил в модель до 60 млн строк. Ничо, работало. Памяти правда надо много. Еще можно в SQL БД. Опять же Андрей VG тут как-то показывал вариант запроса с возможностью вывода результата в csv, но это уже изврат.  

Вагон уроков прямо у вас под носом, здесь и здесь.Теоретически можно, нужно только четко понимать, что есть исходные данные, как выглядит форма, и как вы себе представляете процесс "разнесения по формам". У PQ значительно более слабые возможности по сравнению с VBA на тему генерации контента, если поверхностно, то он позволяет относительно легко считывать данные из вагона разных источников, как-то их преобразовать и дальше выгрузить на лист, в модель данных Power Pivot, кэш сводной таблицы, ну, если знать JS, SQL, то можно выгружать еще в текстовые файлы и в БД. Но нельзя управлять форматами ячеек, нельзя программно указывать в какое место на листе выгружать и т.д. Т.е. работа только с данными.

Seregin, все исходники хранить в отдельных файлах (лучше текст, но можно и xlsx), затягивать это все Power Query в модель данных Power Pivot и там производить все нужные расчеты. 5-10 млн строк на локальном компе - полет нормальный. При том что локальный комп это средненький нубук 2013 года выпуска.
Что можно так считать?
Прогнозирование расходования серьезного ассортимента 3000 позиций на нескольких десятках объектов.
Расчет заказа для пополнения складов без превышения товарного запаса с учетом плана, факта, остатков, приходов.
Факторный анализ всяких отклонений.
Вагон еще всякого, на что хватит фантазии вашего руководства.

у вас в примере результат запроса выгружается в модель данных, это вы хотите в модель данных такую структуру погрузить? Зачем?
Решение было предложено для примера, Это значимое условие, но легко преодолимое, почему сразу об этом нельзя написать?
Ага, оперативка ведь резиновая, такую махину для вычисляемых столбцов писать. А потом при очередном обновлении модели ошибки ловить.
"На фиг, на фиг, к терапевту!" ©

lostandleft, вот не доверяю я этим всем курсам. Есть, блин, 2 мега-книги. Бери, да учи. Чего не понятно задай вопрос на профильных форумах. Зачем вам эти курсы?
Какие ваши доказательства? Здесь на форуме уже раз 5 плакались люди, т.к. создали календарь ДАКСом и локаль замерла, с русской на английскую никак. Это было про Эксель. Как там в PBI устроено не знаю.
2 пункт. Создайте вычисляемый столбец в таблице фактов, сохраните и проверьте увеличился ли размер файла?   Аналогично с календарем.
А еще обратите внимание, что когда вы открываете файл с моделью данных, то в ней не пересчитываются вычисляемые даксом объекты. Как вы думаете где хранятся вычисленные ранее значения? В оперативной памяти?

А нужно чтобы он был выгружен в модель данных, а не в таблицу.

valchik, а в чем проблема делать все джойны и промежуточные вычисления в запросе PQ и без загрузки в модель выгружать на лист нужное количество столбцов?

valchik, сколько строк в нужной таблице из модели? Каким образом таблица в модель загружена?
Где показывать? Зачем вообще в умной таблице показывать столбцы из модели?
Давайте начнем сначала. Что у вас есть и что нужно получить в итоге?

В модель в качестве таблицы фактов нужно выгружать запрос №2 из моего описания выше, который ссылается на запрос 1.
Если помещать в оперативку результат запроса, который выгружается в модель, то там кэширование как-то криво срабатывает и для справочника произойдет повторное считывание, если же сделать промежуточный запрос, а в модель выгружать другой, который ссылается на первый, то все сработает как надо. По крайней мере такая фигня у меня была раньше в 2016. Может сейчас и пофиксили чего, но я во избежание все равно делаю так.

Dyroff, это еще не все. Я правильно понял что у вас есть запрос, который собирает данные в таблицу фактов, после чего еще один запрос обращается к нему же и из столбца город создается справочник для модели данных?
Если так, то лучше всего сделать такую схему:
1 Сбор данных - Последний шаг обернуть в Table.Buffer и результат никуда не выгружать
2. запрос факт - обращается к сбору данных и без изменений льет таблицу в модель данных
3. запрос справочник - обращается к сбору данных, потом дистинкт и результат льется в модель данных без изменений
В такой схеме результат 1 запроса сохраняется в оперативке и для расчета двух других не требуется 2 раза обращаться к исходникам.

Yerlan, в дополнение к решению от Андрей VG, если вагонов очень много и строчек получится много миллионов, то для оптимизации перед в загрузкой модель данные можно сгруппировать. Например, если в отчете данные требуются в разрезе месяцев, то для каждого вагона/ месяца сгруппировать данные с подсчетом количества дней. Тогда моделька будет просто летать.
P.S. и вам надо с вашими формулами определиться, в июле вы корректно посчитали, а в августе/сентябре как-то не очень - дни теряете.

Я ж написал
Смотрите запрос, который грузит таблицу в модель.

Xel, тут проблема скорее с конкретной книгой. Если этот же запрос перетащить в другую книгу, то там все загрузится в модель как надо?

t330, а прямо вот принципиально в DAX? На сколько мне известно в DAX вы такое не сделаете.
В PQ такое сделать и загрузить в модель не покатит?

Основная ошибка здесь - это рассматривать PQ в отрыве от РР. Все таки это два кусочка паззла, и PQ это всего лишь ETL инструмент для выковыривания данных из откуда угодно и выпрямления всякого кривого перед загрузкой в модель данных. То что с его помощью можно сделать и не такое это уже отдельная история и, скорее, нестандартное применение.
Любые мои попытки использовать только PQ в качестве замены именно VBA постоянно упираются в быстродействие. Инструмент выполняющий расчеты из 20+ источников на VBA будет работать сильно быстрее. А вот PQ + PP это сила. Но все равно это не замена VBA.

Dyroff, настоятельно рекомендую загружать в модель данных время (если оно действительно нужно) и даты в раздельных столбцах. Так и модель будет меньше в размерах, и памяти будет меньше кушать и Time Intelligense  можно будет прикрутить, если нужно. И еще время грузить лучше с детализацией до минуты, или еще меньше гранулярность делать в зависимости от задачи.

А так?

А еще лучше так:

Можно на RANKX еще расчет прикрутить, на фига вы такие простые манипуляции делаете ДАКСом? Гораздо проще это все сделать в PQ и в таком состоянии уже грузить в модель. На память нагрузка будет значительно меньше.
И самый главный вопрос, зачем вам вообще доп.столбец с номером покупки? Какую задачу он решает? Если его не нужно выводить в измерения отчета или в фильтры, то наверняка можно без него. Короче говоря, как написано в правилах форума, покажите что у вас за проблема, а не просите помочь с вашим видением её решения.

Можно через PQ реализовать, но как классифицировать даты из листов с приходами, к какому месяцу они относятся? Та же формула Михаила чудесно подставляет данные с листа 22 как к 22 июля, так и к 22 августа.
А вообще я бы затащил все приходы в модель данных в виде плоской таблицы, туда же справочник номенклатур, календарь и нужный вам отчет выводил бы в виде сводной таблицы. Это вот прямо напрашивается.

Что есть? Картинка? Ну так тут не по фотошопу форум и даже не по пэйнту. Может все таки файлик с табличками/моделью данных и связями в ней накидаете для примера?

Вячеслав Давидьянц, перед загрузкой справочника с наименованиями в модель данных нужно при помощи PQ обнаружить все совпадающие наименования и по нарастающей накидать им непечатных символов в хвост (первому ни одного, второму один символ и т.д.), только не пробелов, чтобы не получилось как здесь.

ivanka, отвечу за Андрея - да. Причем, подозреваю, что в отличие от Экселя в PBI не получится организовать, например, сравнение полученных данных с тем, что уже имеется в модели. Можно только доливать в модель новое. Но, возможно, Максим меня поправит.

Максим Зеленский, у меня и без этого залетает диапазон в модель только в путь. При этом он автоматом преобразуется в умную таблицу.
DemonAMT, было бы неплохо узнать версию 2016-го ибо управление моделью данных доступно только для PRO Plus.

Можно в pq слепить ещё одну таблицу дат ограниченную данными из таблиц фактов. Загрузить её в модель и связать с вашим календарем, чтобы он был на стороне 'ко многим'. И срез делайте уже из этой таблицы. Другие способы лично мне неизвестны.

Конечно, скажем так имею один файлик с одной и той же моделью и идентичными источниками, но в одной детализация сводной ограничена товарами, а в другой добавлена детализация по объектам расходования этих товаров.
В первой порядка 2,5к строк и обновляется полторы минуты
Во второй порядка 90к строк и обновляется 5-7 минут.
А это вопрос с подковыркой, имел и такой опыт, т.к. в обычную сводную могу загнать только одну таблицу, а источников много, то для создания такой таблицы приходится накручивать все связи и группировки в PQ - это по сравнению со связями в РР мягко говоря не быстро. В результате обновление сводной на базе РР по источнику около 5кк строк занимало минуты 3-4, обновить же сводную с точно таким же результатом и на тех же исходниках, но на базе обычной сводной с источником - подключение к запросу PQ - 15-20 минут, и иногда все зависало нафиг, приходилось перезапускать.
Работа с самой сводной (фильтрация, нафигация, пересчет области значений) в принципе происходило на тех же скоростях. Другой вопрос что в РР помимо сумм и мин/максов в области значений присутствовали и меры с нетривиальными расчетами, и тут конечно скорость проваливалась, но зато какой на выходе результат, пока ты трескаешь в столовке!  

Посмею не согласиться.
Клины из-за этой галки могут начаться даже если все запросы в файле не выгружают ничего ни в модель ни в на лист. Сам факт открытия файла запускает процесс Mashup.Container и при активной галке эксель их начинает все время обновлять по кругу. В PBI может и починили эту беду, а вот в 2016 Экселе все по-старому. В О365 не проверял. Во всех новых книгах отключаю эту галку по-умолчанию и никаких клинов на моем древнючем нотбуке не наблюдаю. Так что: "береженого бог бережет, сказала монашка, и натянула презерватив на свечку".  

1. делаете запрос из таблицы и выгружаете результат в модель
2. еще раз открываете меню выгрузки и добавляете также выгрузку в таблицу на лист, выгружаете где-нибудь рядом с исходной таблицей
3. копируете имя исходной таблицы
4. удаляете исходную таблицу
5. переименовываете выгруженную запросом таблицу в имя исходной
6. собственно все, далее запрос сначала обращается к таблице считывает данные, и результат пишет в неё же.

Загрузил таблицу в модель через PQ. Результат меры обновляется как при обновлении сводной, так и при обновлении самой таблицы без обновления всей сводной. Это полезно, когда вся модель обновляется долго.

DrillPipe, если табличку выгружать через PQ в саму себя и одновременно в модель, то рефрешить можно просто ПКМ по табличке и обновить, без залезания в модель   При этом в код запроса можно еще и добавить всякие проверки от дураков при вводе. Очень удобно получается.

DrillPipe, тогда теряется удобство в использовании. Управлять параметрами в табличке на листе все же проще чем лазить в модель и редактировать меры. Особенно, когда параметров много.
Но тут на вкус и цвет все фломастеры разные. На истину в последней инстанции не претендую.