Связана с отображением элементов справочника Номенклатура. Справочник содержит группы, соответвующие моделям автомобилей, например Хундай Акцент и Хундай Соната. Каждая из этих групп содержит фиксированный набор подгрупп, например Двигатель, Трансмиссия, Электрооборудование и т.д. В какую-то из подгрупп (например, Хундай Акцент/Двигатель) пользователь заводит конкретную запчасть, и указывает ее применяемость (это регистр сведений) - запчасть применяема и к модели Хундай Акцент, и к модели Хундай Соната. Требуется чтобы когда пользователь заходил в дальнейшем и в группу Хундай Акцент/Двигатель, и в группу Хундай Соната/Двигатель он мог видеть и в той и в другой группе эту запчасть, причем элемент справочника должен оставаться один.
Кому-то приходилось что-то подобное решать?

Версия платформы?

8.1. Конфигурация Рарус Автосалон.

а если вместо справочника выводить в дерево значений, полученное из запроса?

(1) а что версия платформы изменит?
(0) очевидно, что если это сделано для того чтобы уйти от дублирования, то нужно создать дополнительный справочник "Группы номенклатуры" и соответствующим образом изменить формы справочника Номенклатура

(4) на УФ можно в демоническом списке извращаться

(4) сразу динамический список в голову пришел, вот и спросил

1. отказаться от групп в Номенклатуре
2. завести РС "ГруппыНоменклатуры"
3. эмулировать на этом регистре иерархию
4. делать самопальный вывод в список Номенклатуры через РС

(7) зачем РС, чтобы потом с иерархией иметь много секса?

(5) (6) да тут концепция, как мне кажется важнее, чем реализация интерфейса

(9) дык концепцию он изложил уже

(4) как может помочь этот дополнительный справочник "Группы номенклатуры"?

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

(8) чтобы иметь меньше секса при указании у одного элемента нескольких родителей

(11) справочник содержащий группы описанные в (0)
(13) справочник про который я писал в (4) лучше чем рс

(11) в нем ты можешь задать свою собсвенную иерархию

Если такой вариант - ПриСменеРодителя формировать списоск необходимый элементов (вопрос как этот список оптимальней сформировать не рассматриваем), и их в отбор?

(16) как ты его будешь формировать?

(17) может для этого потребуются какие-то дополнительные справочники, на данном этапе не важно. Надо бы понять принцип и по возможности не менять существующий интерфейс.

(17) а как ты будешь хранить у одного элемента несколько родителей?

(19) Ну пусть будет какой-то вспомогательный регистр сведений.

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

(18) я бы сначала нарисовал схему, как все это будет работать, а потом бы уже думал об интерфейсе

(20) а нафига тогда мутить 2 справочника и РС когда можно обойтись одним справочником и одним РС?

(23) где было про 2 справочника?

(24) в (4)
ты же вроде к этому варианту склонялся.