Вычет НДС по налоговому агенту, формир. записей книги покупок, виснет ...

Всем привет!
версия 43.12 (и в 43.6 тоже), платфрма 8.2.17.153 (и на 8.2.16 тоже)
формирую записи книги покупок, закладка Вычет НДС по налоговому агенту, висим ...
место зависа - модуль объекта документа
Процедура ПолучитьДанныеОДокументахОплаты(ТаблицаРезультатов)
в ней единственный запрос
в нем есть подзапрос

|ВЫБРАТЬ | ХозрасчетныйОбороты.Субконто1 КАК Поставщик, | ХозрасчетныйОбороты.Субконто2 КАК ДоговорКонтрагента, | ХозрасчетныйОбороты.Субконто3 КАК СчетФактура, | ВЫБОР | КОГДА ХозрасчетныйОбороты.КорСубконто3 ЕСТЬ NULL | ТОГДА ХозрасчетныйОбороты.Регистратор | ИНАЧЕ ХозрасчетныйОбороты.КорСубконто3 | КОНЕЦ КАК ДокументОплаты, | ДанныеПервичныхДокументов.ДатаРегистратора КАК ДатаОплаты, | ХозрасчетныйОбороты.КорСчет КАК КорСчет, | ХозрасчетныйОбороты.СуммаОборотДт КАК СуммаБезНДС |ПОМЕСТИТЬ ОборотыРасчеты |ИЗ | РегистрБухгалтерии.Хозрасчетный.Обороты(, &Дата, Регистратор, НЕ Счет В (&СчетаИсключения), &ВидыСубконто, Организация = &Организация, , ) КАК ХозрасчетныйОбороты | ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДанныеПервичныхДокументов КАК ДанныеПервичныхДокументов | ПО (ДанныеПервичныхДокументов.Организация = &Организация) | И (ВЫБОР | КОГДА ХозрасчетныйОбороты.КорСубконто3 ЕСТЬ NULL | ТОГДА ХозрасчетныйОбороты.Регистратор = ДанныеПервичныхДокументов.Документ | ИНАЧЕ ХозрасчетныйОбороты.КорСубконто3 = ДанныеПервичныхДокументов.Документ | КОНЕЦ) |ГДЕ | ВЫБОР | КОГДА ХозрасчетныйОбороты.КорСубконто3 ЕСТЬ NULL | ТОГДА ХозрасчетныйОбороты.Регистратор | ИНАЧЕ ХозрасчетныйОбороты.КорСубконто3 | КОНЕЦ <> ХозрасчетныйОбороты.Субконто3 | И ХозрасчетныйОбороты.СуммаОборотДт > 0

(здесь конечно нечитабельно выглядит)

виснет на операции ЛЕВОЕ СОЕДИНЕНИЕ с условием

И (ВЫБОР | КОГДА ХозрасчетныйОбороты.КорСубконто3 ЕСТЬ NULL
| ТОГДА ХозрасчетныйОбороты.Регистратор = ДанныеПервичныхДокументов.Документ
| ИНАЧЕ ХозрасчетныйОбороты.КорСубконто3 = ДанныеПервичныхДокументов.Документ
| КОНЕЦ)

если пробовать это соединение по отдельным условиям - то работает, зависов нет

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

в первом выборка хозрасчетному регистру и ЛЕВОЕ СОЕДИНЕНИЕ только по  условию

ХозрасчетныйОбороты.КорСубконто3 ЕСТЬ NULL  
и тогда  ХозрасчетныйОбороты.Регистратор = ДанныеПервичныхДокументов.Документ

во втором таже выборка и ЛЕВОЕ СОЕДИНЕНИЕ только по условию
ХозрасчетныйОбороты.КорСубконто3 = ДанныеПервичныхДокументов.Документ

потом объединил все

заработало

так что же получается - это ошибка платформы? Исходную конструкцию с оператором ВЫБОР в СОЕДИНЕНИИ
нельзя использовать, иначе результат непредсказеум?

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

Возможно не верно получатся данные таким объекдинением. Лучше уж добавить еще промежуточный пакет с помещением данных во временную таблицу ВТ_ХозОбр, в котором выбрать данные из "ХозрасчетныйОбороты" и определить связи "Поле3" через функцию ЕстьNull(ХозрасчетныйОбороты.КорСубконто3, ХозрасчетныйОбороты.Регистратор) и в исходном пакете "ОборотыРасчеты" заменить таблицу ХозрасчетныйОбороты на ВТ_ХозОбр. К сожалению нет возможности проверить эффективность на реальной базе, а на Демке все быстро работает.

задачу сдал бухгалтеру, в данном случае с ее ожидаемыми данными сошлось (всего то 2 строки получилось),
но для запасного варианта попробую с вашим предложением разобраться, спасибо
интересно, как у других по данной теме, если только у меня висел исходный запрос, то может быть какой-то
косяк в данных образовался, бывало такое

> то может быть какой-то косяк в данных образовался, бывало такое

Потому я сразу и написал, что вопрос производительности надо смотреть на конкретной базе (желательно еще и на конкретном "железе").

> Потому я сразу и написал, что вопрос производительности надо смотреть на конкретной базе
Не думаю что дело в данных - я тоже запрос переписывала.

> Не думаю что дело в данных - я тоже запрос переписывала.
спасибо за сообщение, бальзам на раны

Вопрос производительности - это всегда "дело в данных". На демке с 10-ю документами ничего не "тормозит".

> Вопрос производительности - это всегда "дело в данных".
Не могу сказать за vladak955 , но я, говоря что проблема не в данных, имела ввиду про ошибки в данных.

> На демке с 10-ю документами ничего не "тормозит".
Т е ты считаешь что разработчики 1С пишут запросы из расчет что в базе 10 документов ?
Изменили запрос давно, где-то в 40 релизах, потому как на тех же данных  запросом из 2.0.37.14 релиаза выполняется без зависания.

> Т е ты считаешь что разработчики 1С пишут запросы из расчет что в базе 10 документов ?

Я не знаю этого, но на практике уже бывало ни один  раз, что код в новом релизе может быть не оптимизирован по производительности. И это не удивительно, т.к. 1С как и любая другая организация подвержена "текучке кадров", а новые работники не всегда сразу "умными" приходят.