AlienSx, ожидаемый результат в новой версии.
Не получалось реализовать отключение итогов с IF, сделал при помощи SWITCH, поскольку выше пришлось с ним разобраться подробнее.

Еще раз огромное спасибо за мастер-класс! Подход со расчётом всех атрибутов (столбцов) строк в рамках одной меры мне бы точно не пришел в голову, ковырялся бы с мерами для каждого атрибута.

AlienSx, bingo! Я Ваш должник.

Хотел бы к решению добавить итог только по одному столбцу стоимость. Это в принципе возможно? Так чтобы итог по остальным столбцам отсутствовал.

AlienSx, да, с CALCULATE надо было мне повнимательнее скобки посчитать, чтобы самому разобраться к чему это относится  Теперь понятно.

Начал переносить запросы и меру в рабочий файл и понял, что схему данных в примере наврал. Столбец Требуемое кол-во на торговой точке в реальности не существует, а подсчет ведется по кол-ву записей одинакового товара в одной и той же Тор. точке.

Переделал исходные данные (лист Исх. данные (2)), продублировал код запросов под новую схему данных и создал новую меру (measure2) с учётом всех этих изменений. Но я её так переделал, что неверно считается столбец "стоимость" - в нём дважды перемножается "сумма" и результат потом умножается на цену за ед.
Не могу понять из-за чего эта ошибка(

AlienSx, спасибо большое! Моё текущее знание DAX не позволило бы самому написать такую меру.

Разбираюсь с решением, в целом логика ясна. Не могу только разобраться с её частью. Для чего предназначено выражение data[Тор. точка] = col в конце оператора SWITCH?

measure

measure := VAR col = MAX('columns'[name]) RETURN    SWITCH(           col;            "Цена за ед." ; MAX(data[Цена за ед.]);            "Размер"; MAX(data[Размер]);            "Цвет"; MAX(data[Цвет]);            "сумма"; SUM(data[Требуемое кол-во на торговой точке]);            "стоимость"; SUMX(data; data[Требуемое кол-во на торговой точке] * data[Цена за ед.]);            CALCULATE(SUM(data[Требуемое кол-во на торговой точке]); data[Тор. точка] = col)            )

Всю логику сразу мне сложно воспринять, поэтому последовательно прошу уточнения: "динамическое добавление в PQ" это значит что число столбцов в запросе PQ определяется исходя из фактических данных по товарам? Т.е. если в Торг. точке 5 есть товар из группы Товар 1 и Товар 2, то этот столбец попадет в эту "простую таблицу со списком характеристик"?

В принципе кол-во торговых точек меняется редко и можно их все сразу перечислить в шапке. Если в этих столбцах будут пустые ячейки это нормально.

AlienSx, спасибо, попробую.

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

Спасибо! Не знал про подобный способ создания иерархии.

Если я правильно понял идею, предлагаете последовательно проиндексировать значения на каждом из 3х уровней агрегации (вид монтажа > товарная группа > название товара) при помощи В результате получим фиксированный по кол-ву строк грид, в который записывать атрибуты для каждого названия товара. Правильно я понял?

Если да, то подход мог бы быть условно рабочим: кол-во уровней агрегации фиксированное (три), кол-во значений в уровнях вид монтажа и товарная группа можно считать константами. Но как быть с названиями товара? Это значение переменное и проиндексировать его в запросе PQ проблематично(

Добавил исх. данные в прикрепленный файл в моём вопросе. Вставил их не в PQ, а на лист, но в PQ они лежат в такой же схеме.

ДАНО
Есть таблица товаров, собранная в виде запроса Power Query. У товаров несколько столбцов характеристик: название товара, цвет, размер, цена за ед., требуемое кол-во на разных торговых точках, товарная группа, вид монтажа (наружный, скрытый).

ЗАДАЧА
Из таблицы необходимо получить отчёт (спецификацию для закупки) с иерархической группировкой строк по виду монтажа > товарной группе > названию товара и агрегированием кол-ва однотипных товаров на нескольких торговых точках. При этом необходимо, чтобы помимо агрегированного кол-ва товара в каждой торговой точке, в каждой строке для данного названия товара присутствовали все остальные его характеристики (цвет, размер и т.д.). Плюс к этому нужен еще один вычисляемый столбец, в котором указана итоговая сумма по каждой позиции (цена за ед. * общее кол-во по всем торговым точкам).

ИДЕИ РЕАЛИЗАЦИИ
Была идея использовать для отчёта сводную таблицу, но разобраться как в строках разместить характеристики товара помимо его названия и добавить вычисляемый столбец не смог.

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

Есть идея попробовать проиндексировать все строки исходной таблицы и использовать этот индекс, чтобы вставить соответствующее значение характеристики товара в таблицу целевого отчёта. В эту сторону подтолкнула идея вспомогательной сводной из примера Сводная таблица с текстом в значениях. Но не знаю, сработает ли он и ещё интуиция подсказывает, что должен быть более короткий путь. -> Проверил не подходит: при изменении значений атрибутов или их кол-ва, придется перелопачивать всю трансформацию данных.

Если в Excel такой отчёт нереализуем и нужно смотреть в сторону в сторону Power BI это тоже приемлемый вариант. Просто Excel как средства отчёта в данном случае предпочтительнее с точки зрения пользователя.

Прошу подсказки. Спасибо!

Конечную структуру отчёта отразил в файле.

Поскольку задача возникла в связи с освоением PQ, рассматриваю её как лабораторное упражнение без претензии на транспортно-логистическое моделирование. Поэтому упрощение, которое Вы упомянули, я также использую и применяю только условия, описанные мной выше.
Синтаксиса List.Generate, чтобы в внутри этого цикла формировались данные в разных столбцах, я пока не знаю. Собственно в этом и был смысл моего вопроса: узнать опыт других, чтобы выбрать для себя подходящий.
Поэтому пока выбрал вариант, который я знаю: сформировать список дат между начальной и конечной датой, преобразовать его в таблицу и далее в настраиваемых столбцах попробовать реализовать условия алгоритма. Пока еще не получилось.

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

1. Остаток на конец дня текущего = Остаток на конец предыдущего дня - Дневное потребление + Поступление питания в текущий день от молочной кухни + Закупка питание в магазине. (Реализация алгоритма в столбце B.)
   
2. Закупка в магазине происходит при след. условии: ЕСЛИ (Остаток на конец дня + Поступление от молочной кухни ) <= Дневного потребления
   
3. СУММ (Остаток на конец дня + Поступление от молочной кухни + Закупка питание в магазине) <= Дневное потребление * Минимальный срок годности питания, т.е. 24 единицы
   

Недавно начал использовать PQ, но знаний и практического опыта еще очень мало, поэтому стараюсь разбираться на бытовых задачах.

Задача
Младенцу необходимо 4 пачки молочного продукта в сутки. На практике минимальный срок хранения пачки - 6 суток, т.е. общий остаток макс. запаса пачек не должен превышать 24 шт. Пополнение запаса происходит из двух источников: молочная кухня и детский магазин. График выдачи (дата и кол-во) на молочной кухне свой на каждый месяц (так она у нас работает .

Цель отца

• минимизировать кол-во закупок в теч. месяца, создавая запас с учётом срока хранения
  
• знать заранее сколько пачек и в какой день покупать, чтобы к концу дня у младенца не оставался нулевой запас.
  

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

1) Как с помощью PQ сформировать график закупок (ГрафикЗакупок), соответствующий условиям выше?
2) Как параметризировать вычисления PQ начальными условиями (вкладка Исх. данные). Это опциональный вопрос. Если сложно - мне будет достаточно пока разобраться с вариантом ответа на первый. Спасибо!

P.S. Если PQ не лучший способ для этой задачи - посоветуйте, пожалуйста, альтернативный способ.