Подскажите, почему получается такая ситуация, как на условном примере, который я нарисовал ниже.

https://i.imgur.com/NhqkMOM.png

Поясните ВТОРОЙ случай, что это ?

На реальной базе в реальном запросе убил пол дня, чтобы понять, что запрос выдаёт различные данные в СКД в зависимости от того, из вложенного запроса получаем данные или из ВТ. ПРИ ЭТОМ в консоле запросов всё работало нормально при любых вариантах, как при использовании временной таблицы или вложенного запроса.

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

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

Объясните

(0) оптимизатор

(0) когда правила обмена будете писать, он тоже вам встретится

Тестовое задание чтоли?

(3) нет, рабочая задача. Меня в подробности не посвящали, но это формула оценочная для расчета потерянной выручки.
https://i.imgur.com/b4CS6Gl.png
(рассчитанная потребность рассчитывается в других временных таблицах, это оценочный показатель, сколько нужно товара заказать, в КА2 есть похожий механизм типовой)

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

Но вообще получилась бы неплохая учебная задача, если убрать всё лишнее.

(1)
Это я догадывался, но для меня это просто чёрный ящик. Это документированное поведение вообще или нет. Как понять, почему СКД выбирает такую стратегию оптимизации, что я теряю данные.

что-то не получается у меня такое сделать... покажи запрос

(5) Я сейчас подготовил тестовую конфу, где в справочник все данные запихал один. Там наглядно показано, в чём проблема.

Запрос такой:
https://i.imgur.com/iOYn5nS.png

DT файл с тестовой базой, ничего лишнего, никаких регистров, только один справочник. 2 запроса уже созданы одинаковых: в одних из ВТ берутся данные, в другой из вложенного запроса + консоль запроса в базе есть, там из ВТ и из вложенного одни и те же данные. То есть результат такой, как у меня на картинке в шапке. СКД вообще какую-то дичь творит, он не так считает...

https://dvfustud-my.sharepoint.com/:f:/g/personal/atamanov_ius_students_dvfu_ru/EuVUqalXNfhBqtHbVXtDI4kBlkLl0MHgpNVVj2ra-soHZQ?e=HPTiQB

(6) "Номенклатура.Ссылка" - это сильно
У тебя сгруппировать по Номенклатура, такой запрос не может возвращать несколько записей по номенклатуре нигде (запрос/построитель/СКД).

(6) Сделал по-человечески без СУММА и группировок в запросе, убрал автозаполнение, заполнил ресурсы, в настройках указал поле группировки - все ок.

+(8) Два отчета стали идентичные данные выводить.

В СКД есть оптимизатор - это его работа, по хорошему группировок в текстах запросов СКД во избежании этой проблемы надо издегать

(7)  я здесь и не возвращаю несколько записей по номенклатуре, я их уже сгруппировал. Иллюстрация в шапке очень условна же, я как-бы показываю, что СКД при расчете кол-ва дней только одну запись видит в этом случае, если из ВТ её достаю  
(9)(8)
На реальном запросе, где 10+ временных таблиц попробовали бы итоги собрать в ресурсах...
К тому же внутри запроса будет более быстро.
Можно, конечно, с извращениями в ресурсах это собрать, но мне бы пришлось реструктуризацию многоэтажного запроса делать, заменить ВТ на вложенный запрос оказалось легче.
Это не итоговый запрос, эти данные идут дальше собираться.
К тому же не всегда есть возможность СКД использовать, если это не отчёт.

Там итоговые данные различные, а запрос ОДИНАКОВЫЙ. В моей выгрузке это видно.

(10) да, вы правы, но уже слишком поздно было изменять логику запроса, тк я начал его формировать так изначально

(11) хотя я сам себе сейчас противоречу. Если это не СКД, то и данные будут собраны верные. Да, нужно СКД изучать. Но там слишком нетривиальные формулы, казалось через запрос легче собрать это. А так остатки и срез последних на дату только через несколько наборов данных получать

(13) *на каждую дату (каждый день) имеется ввиду. И потом еще на один коэффициент умножать. 3 набора данных минимум.

(11) что вы скинули, мы разобрали и объяснили. Исходный запрос показывайте

(15) Если это что-то даст.

Вот так рассчитывается потерянная выручка https://i.imgur.com/b4CS6Gl.png

А сам коэффициент количества рассчитанной потребности вот так по шагам (1- красная, 2- зеленая, 3- голубая) https://i.imgur.com/jKUOF9U.png.

Кто в КА2 с механизмом статистического обеспечения потребностей знаком, то суть будет ясна (тут похожая идея, но не совсем).

Запрос: https://pastebin.com/M4hkehe3
файл запроса: https://dvfustud-my.sharepoint.com/:i:/g/personal/atamanov_ius_students_dvfu_ru/ESuSnDXW69lEkHWLZYNUNxYBMwXNH6207gYwmAVQph2clw?e=dd3Ucz
ЧТоб в конструкторе открыть нужна КА~2.4.8

Суть в том, что У меня прочие расчёты идут с детализацией до номенклатуры, поэтому я в запросе группирую номенклатуру и считаю кол-во дней, когда она отсутствовала и среднюю цену на эти дни отсутствия.

Наверное, можно через СКД в одном наборе рассчитать потребность, а в другом данные с детализацией до дней. И в ресурсах через ВЫчислитьВыражениеСГруппировкойМассив считать по номенклатурам часть показателей, но непонятно, как наборы данных соединятся, там же умножатся записи...