ищу файл с запросом для поисков правды

PooHkrd, создал тестовый файл - ситуация повторяется.

Что смотреть.
1. Запрос и лист - Минимальный закуп. Например у 1 позиции определился минимальный закуп = 4.
2. Запрос и лист - Минимальная цена. Например у 1 позиции определилась минимальная цена = 9.
3. Итоговый лист, где я объединяю запросы "Минимальная цена" и "Минимальный закуп" - данные там не такие, как в самих запросах.

Дмитрий Щербаков, можете дать скрин Итоговой таблицы?
Не то, что бы я вам не доверяю, просто охота убдеиться, что говорим об и тех же данных)

PooHkrd, фух. Пронесло. Я думал, что у меня начинаются танцы с бубном по обновлению экселя...

Продолжаем изучать эту мистику.

PooHkrd, спасибо за рабочее решение.
Но действительно надо как-то теперь держать это в голове, так как часто пользуюсь это функцией.

может неправильно выразился. Имел в виду сортировку. Если и так непонятно, то буду более детально описывать)

Получается, при использовании Table.Distinct нет смысла разворачивать столбцы?

Получается, что вы не правильно решаете задачу. Фактически вам нужно для каждой подгруппы и подтаблицы, задаваемой набором столбцов в Table.Distinct выбрать единственную запись, определяемую набором и правилами упорядочивания. Так это будет правильно. Как это реализовать мышиным хардкодом - не знаю, так как им не пользуюсь.
Пример, как лучше находить таблицы с минимальными ценами и закупами, с учётом того, что в вашем случае можно просто выбирать такие записи подгрупп по минимуму Цены/Закупа.
Успехов.
P. S. И спасибо за демо ошибки - всегда чувствовал, что в Power Query следует соблюдать SQL подход, а не надеяться, что данные будут следовать друг за другом в неизменном виде.

Как выше писал этоПример для минимальной цены

Это не баги. Это неправильное понимание и не знание структур и алгоритмов

всё же соглашусь с ТС, наверное баг. PQ же не на прямую выполняется, а как и SQL, проходит цепочку преобразований через анализатор, оптимизатор, компилятор перед выполнением. Видимо где то на этих этапах для nestedjoin теряется использование сортировки перед distinct. Типа - а зачем? Если любой первый? Можно писать баг отчёт разработчикам. Говорят, что подобные вещи они быстро исправляют.
А где ещё есть, не знаю. Стараюсь делать детерминированные решения. Хотя и тут бывают баги. Например у меня вылетало отправляемое на сортировку соединение сделанная через list.generate таблица нарастающего итога по столбцу исходной таблицы с исходной таблицей по общему столбцу индекса с сообщением о нехватки памяти. То есть если не вкючать сортировку итоговой таблицы по индексу исходного порядка, то всё хорошо и вывод есть. Но стоит только добавить - сообщение об ошибке.

А вот это натолкнуло меня на идею. Попоробовал - взлетело!
Table.Buffer -вот еще одно решение, и еще одно объяснение, почему я раньше не натыкался на такой баг - месяца 4 назад начал все промежуточные запросы закидывать в память - и работает быстрее и, как оказывается, глюков с очередностью шагов меньше.
Для ТС - каждый последний шаг в двух сливаемых запросах запихиваем в функцию Table.Buffer и вуаля.
1. Сделали группировку по минимальному значению
2. Сливаем результат с таблицей, которая была до группировки по двум ключевым столбцам "код номенклаутры" и "значение минимальной цены"
3. Разворачиваем столбец с минимальной ценой по получившемуся столбцу отфильтровываем все строки со значением <> null
На выходе получили только строки с минимальной ценой
Ну а как вы поставщиков с одинаковой минимальной ценой отсеивать будете я логики не видел.

Здесь не в этом дело. Обычно буфером я заканчиваю запросы, к которым обращаюсь более одного раза из-за корявого кэширования в Экселевском PQ. Но в данном случае Буфер ограничивает запрос в отдельную структуру для оптимизаторов, про которые писал Андрей VG. Т.е. выполнение действий с данными происходит не как с единой цепочкой от последнего запроса к первому. А сначала отдельно вычисляются два запроса, результаты запихиваются в оперативку, и последний запрос работает уже с результатами, а не разворачивает цепочки.

Ну, на сколько вам оперативки хватит. Все же массивы по нескольку миллионов строк закидывать в оперативку я бы не рекомендовал .

Денис, я уже упоминал ранее что не умею обращаться к запросам из других книг. К таблицам, да, но не к запросам. Соответственно, если вы затащили в книгу данные с сайта чтобы сохранить в таблицу, а потом используете полученную таблицу в других книгах, то зачем её еще и в буфер размещать?

Подведем итог этого тикета, может кому-то будет также полезно при использовании PQ.

Правило.
Если в рамках одной книги вы используете промежуточные запросы PQ для расчета данных, то необходимо в этих запросах последним шагом делать Table.Buffer.

Пример.
Предположим, что в рамках одной книги у вас есть следующие запросы: Поставщик1, Поставщик2, Обработка1, Обработка2, Обработка3, Итоговый результат.
Запросы Поставщик1, Поставщик2 - это обращение к внешним файлам (в нашем случае прайсы поставщиков).
Обработка1, Обработка2, Обработка3 - это промежуточные запросы, где вы делаете операции на основании данных из запросов Поставщик1, Поставщик2.
Итоговый результат - объединяете запросы Обработка1, Обработка2, Обработка3 в один запрос.
Таким образом в запросах Обработка1, Обработка2, Обработка3 последний шаг должен быть Table.Buffer.

Инструкция по шагам.
Для того, чтобы сделать расчет данных в Обработка1 на основании запроса Поставщик1, то необходимо навести мышкой на запрос Поставщик1, нажать правой кнопкой мыши и выбрать "Ссылка". У вас откроется новый запрос, где источник данных будет запрос "Поставщик1". Можно сразу открыть Расширенный редактор и вставить шаг Table.Buffer. Далее переходите в стандартное окно и между шагами Источник и Buffer вставляете нужные операции - код сам будет модифицироваться. Если система будет спрашивать "Вы действительно хотите вставить шаг?" отвечайте "Вставить".

Код получится такой:

P.S. Это никак не претендует на правду, но в рамках пользовательского опыта показало, что данное правило просто необходимо, а не просто рекомендуемо.