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

```1c
    "ВЫБРАТЬ
    |ВЫБОР
    | КОГДА ПродажиОбороты.АналитикаУчетаПоПартнерам.Партнер.Родитель = ЗНАЧЕНИЕ(Справочник.Партнеры.ПустаяСсылка)
    | ТОГДА ПродажиОбороты.АналитикаУчетаПоПартнерам.Партнер
    | ИНАЧЕ ВОТ ТУТ НАДО УКАЗАТЬ САМОГО ВЕРХНЕГО РОДИТЕЛЯ , КОЛИЧЕСТВО УРОВНЕЙ НЕИЗВЕСТНО
    |КОНЕЦ КАК Партнер
```

Есть идеи у кого-то?
---
В общем кому интересно, то решил так.
Не стал изобретать всякие регистры и промежуточные таблицы значений и всякие другое, а пошел по самомму простому пути и добавил реквизит ПартнерВерхнегоУрвня в спр.Партнеры и создал процедуру которая при записи или выборе головного партнера, дает самого верхнего партнера в иерархии и уже потом в запросе проверяю на заполненность "партнер.ПартнерВерхнегоУровня".
Всем огромное спасибо за участие.
---
Если не подходит вариант на ИТС, где необходимо обозначать некий предполагаемый будущий максимум, то, наверное, определять максимальное количество уровней и собирать текст запроса. Можно добавить реквизит в партнера и записывать туда родителя верхнего уровня.
---
Необходимо находить родителей транзитивным замыканием, 6 пакетов запроса - 64 уровней вложенности, думаю вам этого хватит
---
Ну если иерархия элементов, то попробуйте так. (напиши метод, где на входе есть &Партнер)

Шаг 1 .
```1c
    Если НЕ ЗначениеЗаполнено(&Партнер.Родитель) тогда
    Возврат &Партнер;
    КонецЕсли;
```

Далее шаг 2.

```1c
    Запрос = Новый Запрос;
    Запрос.УстановитьПараметр("Ссылка", &Партнер);
    Запрос.текст =
    "ВЫБРАТЬ
    | СправочникПартнеры.Ссылка КАК Ссылка
    |ИЗ
    | Справочник.СправочникПартнерыКАК СправочникПартнеры
    |ГДЕ
    | СправочникПартнеры.Ссылка = &Ссылка
    |ИТОГИ ПО
    | Ссылка ТОЛЬКО ИЕРАРХИЯ";

    Выборка = Запрос.Выполнить().Выбрать();
    Выборка.Следующий();
    Возврат Выборка.Ссылка;
```

Я написал по аналогии со справочником "ПодразделенияОрганизаций" в ЗУПе. Ваш справочник, судя по описанию, такой же.

Суть в чем. Запрос возвращает всю иерархию элементов, начиная с высшего.
Поэтому делаем один раз "Следующий()" и этот высший элемент получаем.

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

Если взлетит, тогда вам надо будет соединить это с вашим запросом, тут уж вы сами
---
В ЗУПе же эта задача как раз решается очень просто для подразделений в связи с наличием регистра "Подчинённость подразделений", из которого родитель верхнего уровня получается прямым запросом, без всяких доп.проверок, соединений и прочего
---
Это я знаю, и активно пользуюсь.
Но то, что описал выше, я начал применять давно в ЗУПе 2.5, где такого регистра не было и в помине.
Тут я просто идею подал, вдруг она пригодится.
---
Зачем транзитивное замыкание..? Во временной таблице получите все элементы, у которых Родитель = ПустаяСсылка и ЭтоГруппа = Истина - это будет верхний уровень. В ИНАЧЕ выводите этот элемент, в соединении условие на В ИЕРАРХИИ.
---
в соединении условие на В ИЕРАРХИИ
Вы сами-то пробовали так делать?
Зачем транзитивное замыкание..?
Затем, что в условиях 1С по-другому тока рекурсивный запрос сможет найти родителя самого верхнего уровня
---
вот я тоже думаю на счет реализации подобного в ИНАЧЕ.
Далее в запросе, я могу отфильтровать Партнеров в Иерархии по верхнему родителю и таблицу верхних родителей я получил, но как соединить Текущего партнера, не зная его уровень в иерархии по верхнему уровню родителя, не совсем понятно
---
но как соединить Текущего партнера, не зная его уровень в иерархии по верхнему уровню родителя, не совсем понятно
Никак, нужно знать все связи родитель-потомок
---
Нет, редко пользовался условием В ИЕРАРХИИ, поэтому забыл, что его нельзя использовать в соединении. А если также сделать временную таблицу с верхнем уровнем, а с ней соединиться условием Родитель = Ссылка ИЛИ Родитель.Родитель = Ссылка Или Родитель.Родитель.Родитель = Ссылка... Те же условные 6 раз, которые вы предлагали транзитивно замкнуть?
---
6 соединений дадут декартово произведение в результате, не дадут 64 уровня вложенности и соединение таблиц - медленнее
---
<Удалено>
---
ну, мы-же разработчики, 1 этап - реализация, чтобы заработало, 2 этап оптимизация, как раз тут все ускоряем
---
Лень было уже красоту наводить) Вроде бы там можно без ВЫБОР КОГДА написать только условие + еще добавить условие на Ссылка <> РодительВерхнегоУровня (т.к он сам в своей иерархии), но это условие только для отчета с моей логикой подходит. Если у вас в таблице не может быть групп, то и без него норм.
---
Это тестовое задание? нужно чтобы шашечки или чтобы ехало? Может отказаться от запроса, раз так все в него уперлось, и попробовать через Выбрать в цикле? скорость потом оценивать будем
---
это лишь фрагмент запроса, причем практически вначале, там еще несколько подзапросов. Идет вычисление и данные передаются из запроса в запрос в виде временных таблиц. Поэтому устраивать цикл по среди запроса и далее перекидывать в запрос не оч.хочется
---
мне кажется, вы все сильно усложняете, через цикл не надо ни куда ничего пихать, но простора для программного анализа куда больше, но не настаиваю, ИМХО, я бы попробовал
---
Можно создать допсвойство РодительВерхнегоУровня для справочника Партнеры и перезаполнять при запуске открытии отчета, любым доступным кодом (маловероятно что количеству записей он большой), далее все просто
---
ну вот - мудрое и простое решение
---
да, но это был крайний вариант, не хотелось изменять справочник Партнеры.
---
его не надо изменять, это доп. реквизит или доп. свойство
---
В ДО есть регистр для иерархии подразделений, можно регистр создать соответствия партнер и его верхний уровень или в запросе " транзитивными замыканиями"
---
В общем кому интересно, то решил так.
Не стал изобретать всякие регистры и промежуточные таблицы значений и всякие другое, а пошел по самомму простому пути и добавил реквизит ПартнерВерхнегоУрвня в спр.Партнеры и создал процедуру которая при записи или выборе головного партнера, дает самого верхнего партнера в иерархии и уже потом в запросе проверяю на заполненность "партнер.ПартнерВерхнегоУровня".
Всем огромное спасибо за участие.
---
Ну, молоток! оно же главное чтоб работало, но ты не говорил, что конфу можно менять, поэтому мы тебе регистры и советовали
---
я и не хотел менять, но и мудрить сильно тоже не хотел. Чем проще тем надёжней. Через расширение прилепил автозаполнение и реквизит и подправил пару строк в запросе и взлетело