Время пришло? Уже несколько релизов это пережило.

---------------------
ДокументыКОтражению КАК ДокументыКОтражению
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ТрудозатратыНезавершенногоПроизводства КАК СтрокиДт
        ПО ДокументыКОтражению.Ссылка = СтрокиДт.Регистратор
            И (СтрокиДт.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход))
            И (СтрокиДт.Активность)
            И (НЕ СтрокиДт.Сторно)
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ДвиженияПоПрочимАктивамПассивам КАК СтрокиКт
        ПО ДокументыКОтражению.Ссылка = СтрокиКт.Регистратор
            И (СтрокиКт.Организация = СтрокиДт.Организация)
            И (СтрокиКт.Период = СтрокиДт.Период)
            И (СтрокиКт.НастройкаХозяйственнойОперации = СтрокиДт.НастройкаХозяйственнойОперации)
            И (СтрокиКт.ИдентификаторФинЗаписи = СтрокиДт.ИдентификаторФинЗаписи)
            И (СтрокиДт.ИдентификаторФинЗаписи <> "")
            И (СтрокиКт.Активность)
            И (НЕ СтрокиКт.Сторно)
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВтОтражениеЗарплатыВФинансовомУчете КАК ОтражениеЗарплаты
        ПО ДокументыКОтражению.Ссылка = ОтражениеЗарплаты.Ссылка
            И (СтрокиДт.Организация = ОтражениеЗарплаты.Организация)
            И (СтрокиДт.Подразделение = ОтражениеЗарплаты.Подразделение)
            И (СтрокиДт.Период = ОтражениеЗарплаты.Период)
            И (СтрокиДт.ВидРабот = ОтражениеЗарплаты.ВидРабот)
            И (СтрокиДт.ГруппаПродукции = ОтражениеЗарплаты.ГруппаПродукции)
            И (СтрокиКт.Аналитика = ОтражениеЗарплаты.ТипНалога)
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ПартииПроизводства КАК ПартииПроизводства
        ПО (СтрокиДт.ПартияПроизводства = ПартииПроизводства.Ссылка)
------------------
Оно зависает намертво при попытке отражения в учете.

Или только для меня такая каша соединений выглядит необычно.

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

ЗЫ
Обычно легко детектится что код ИИ по кривому форматированию с включенной галкой "Отображать пробелы и табуляции"

(1) Соединяем во втором соединении
СтрокиКт с ДокументыКОтражению. Что там забыли СтрокиДт?

Такая же история в третьем соединении. По мне так просто бредогенерация.

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

(3) таблицы оборотов не сработают, если там будет период выборки не кратный месяцу. Точно также запрос пойдет в реальную таблицу.

(0) Почему сразу "каша"?

(5) Не нравится мне многоэтажные условия использования строк одного соединения в условиях другого.
(3) Да это добро глухо зависает на часы в реальных базах.

(6) Не нравится мне ... условия использования строк одного соединения в условиях другого.

Это вопрос восприятия. По факту каждая следующая таблица соединяется с результатом предыдущего соединения и в условиях могут быть поля из любых таблиц. Требуется такое не часто, и часто так делают по ошибке. Но не в данном случае)

(7) не совсем так
в случае одинаковых внутренних соединений (их тут три) порядок не особо важен
вот в случае разных видов соединений да (еще одно левое в конце)

условно можно считать что все внутренние соединения рядом выполняются одновременно

(6) >> Не нравится мне многоэтажные условия использования строк одного соединения в условиях другого.

Ну это фишка, в ERP часто используется довольно-таки, без каких-либо катастрофических последствий.

(6) Хуже, когда "лапша" ступеньками из вложенных соединений, там не всегда очевиден результат.

По итогу: Без изменений на маленькой базе получили по 20 счету х5 от нужного. На больших базах просто зависон. Проблемный запрос выше, в базе НомерФрагмента 1884 среди большого объединения таблиц.
Решение - взял текст запроса ТекстЗапросаНачисленоСдельно из 25 релиза и добавил одну тестовую колонку. Бухгалтера проверили, вроде все норм. Пока так.

(11) про задвоение проводок в отражениях ЗП помню был косяк в 25 релизах и кажется патч выпускали.
И сейчас посмотрел обновления ЕРП - и 26-ые релизы все отозваны. Рано вы обновились )

(8) Бред. В данном случае получишь синтаксическую ошибку, если поменяешь первое и второе соединение например.

"условно можно считать" - возможно это про оптимизации и внутрянку SQL, тут спорить не буду. Но синтаксически порядок важен, и в (0) идеальный тестовый пример на этот случай

(13) Ну да проверка синтаксиса по идее не пропустит использование алиаса выше его места объявления

А по сделке в отражениях ЗП в ЕРП согласен что жесть. Они запихнули распределение сделки по партиям в проведение отражений и при больших данных документы проводятся часами. А если изменили выработки, то надо и перепровести отражения, иначе вообще данные поедут после расчета себестотимости.
А недавно еще обнаружил что чем больше строк со сделкой в документе, тем пропорционально дольше проводится документ, видимо за подобных соединений реальных таблиц регистров. Так что теперь предварительно сворачиваем строки отражения по ключевым полям после загрузки из ЗУПа.

(12) Вот только куча обновлений по НДС и рег. формам в них вышло. Но так то засада. Три обновления накатили - и на тебе все отозвали.

(15) Свернуть можно если у вас нет направлений деятельности и дележки сделки по ней...

(17) на то и отметил, что по ключевым полям. У нас из ЗУП в ЕРП несколько подразделений сливается в одно производственное, поэтому и строк идентичных получается несколько.