Всем привет!
Любопытная задача есть, подскажите ребята как ее лучше реализовать. Что бы это было удобно реализовано в интерфейсе.
В общем есть справочник в нем куча папок (групп), Справочник выстроен в определенной иерархии. Мне нужно избавиться от зависимости этой т.е. затащить понятие иерархии в реквизиты.
например, Справочник состоит из 3 вложенностей иерархии (в самой последней расположен элемент): Верхняя группа - "Класс", группа в классе называется например "ПОдкласс", в подклассе группы называются "Типы".
На элементе нужно создать три реквизита: "Класс", "Подкласс", "Группа". так что бы у группы была зависимость от выбранного подкласса, а у подкласса зависимость от класса.
Каким механизмом правильнее реализовать такое?

Кто что думает?

(0) >Каким механизмом правильнее реализовать такое?

нанять программиста

Можно сделать через иерархические теги, можно через существующие поля (наверное, даже артикул).

зачем?

Реквизит Родитель?

(0) программное формирование Дерева значений на форме

Просто так не получится. Придется справочник новый создать, где будет указана настройка той самой новой иерархии трех видов элементов. В нем описать все зависимости одних элементов от других (я так понимаю "Класс", "Подкласс", "Группа" не так часто меняются). А в исходном справочнике настроить динамический список так, чтобы при отображении все это учитывалось. Довольно непросто все это будет.
Проще фильтры сделать по трем составляющим на форме списка.

Есть хороший инструмент. Правда, сторонний, не 1сный...

Называется hands.exe. Он может сделать любые преобразования.

Правда, часто к нему нужен особый драйвер... barin.sys

*brain.sys

(7) у некоторых они вытеснены conceit.dll огромного размера

(0) Не надо три реквизита. Достаточно одного.

На самом деле у меня 5 иерархий))))
Основная цель - при выборе верхнего уровня - система должна предлагать пользователю варианты нижестоящего уровня.
При заполнении реквизита : "Класс", в списке реквизита "Подкласс" должны отобразиться именно те подклассы, которые связаны с конкретным классом.
(2) - нужно что бы у пользователя гемороя был минимум при заполнении всего этого
(4) - реквизит родитель
(7) - нужно стандартными

(11) подчиненные справочники, не?

(11) у подкласса должна быть ссылка на класс
а ля контрагенты - договоры

(13) - аля также надо сделать или аналогично

(12) как вариант

(0) Твоя иерархия полностью укладывается в стандартную. Поэтому не надо никаких "доп-реквизитов" и прочей ереси. Ты хочешь просто удобную для пользователя форму подбора. Ее и делай.
Можно так, например: слева - дерево групп, справа - список элементов. Пользователь слева кликает на группе любого уровня - справа отображаются все элементы в иерархии выбранной группы.

(11) в чём смысл в отдельных реквизитах указывать каждый уровень?

(0) У меня похожая задача была. Или может не то....
И так. Суть вопроса была адрес контрагента разложить по полочкам  (вернее вводить). На форме справочника Контпгенты отдельные реквизиты; АдрессОбласть, АдресРайон, АдрессНасПункт, АдрессУлица, АдрессДом, АдрессКвартира.
Улицы находятся в иерархии Обл/район/НасПункт.
На форме когда пользователь выбирает населенный пункт. То улицу может выбрать только из нужной папки (которая автоматически открывается в нужном месте иерархии. А вышестоящее реквизиты при этом автоматически заполняются с учетом иерархии.
Для пользователей это удобно, и ошибок в полном адресе небудет.

(17) расскажи как реализовал. Задача точно такая же.

(16) долгая история.

(18) Да уже все почти рассказал. Справочник Адреса. В нем папки (верхней уровень- Область. В каждой области папки Районы.....) (Для папки нужен создать дополнительный реквизит, чтобы понимать на коком уровне иерархии находишься и не дать ваыбрать в реквизит Область например район).
А дальше все просто. На форме справочника Выбрал например район (если облать не заполнена, то выбирается с корня справочника, а если заполнена то по событию "НачалоВыбора"

Группа=Справочники.Адреса.НайтиПоКоду(адрОбласть.Код);
        Если Не Группа=Справочники.Адреса.ПустаяСсылка() тогда    
            СтандартнаяОбработка = Ложь;
            ФормаВыбора = Справочники.Адреса.ПолучитьФормуВыбора(, Элемент);
            ФормаВыбора.ЭлементыФормы.ТабличноеПоле1.ИерархическийПросмотр = Истина;
            ФормаВыбора.ЭлементыФормы.ТабличноеПоле1.ТекущийРодитель = Группа;
            ФормаВыбора.ЭлементыФормы.ТабличноеПоле1.ТекущаяСтрока=адрРайон;
            //ФормаВыбора.ОткрытьМодально();    
            ФормаВыбора.Открыть();    
        КонецЕсли;

попадаем в нужное место иерархии. А дальше при выборе нужного элемента заполняем вышестояшие реквизиты в форме Контрагента.

А чем фильтры не подходят? Тем более у вас 3 отдельных реквизита. Это может быть 1, а могут быть 3 разных справочника, описывающих разные свойства. Добавьте на форму списка 3 реквизита и по ним фильтруйте при изменении. Получится своего рода иерархия, у которой уровни не зависят друг от друга. И на реализацию минут 15 с перекуром.

-Значит итог таков, делаю 5 справочников плоских, которые подчинены друг другу
-Добавляю  5 реквизитов на форму элемента справочника.
-реализовываю механизм отбора при условии заполнения первого реквизита, отбор во втором осуществляется и выводится ограниченный список и так далее

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

Ну вот, поправьте меня.

(24) поправляю..ересь.
Как будете элементы из "группы" в группу тащить ? Владельца менять ?

И.. чем обычный справочник с группами не подходит ? Если это всё нужно, чтоб потом быстро иерархию иметь, то храни иерархию папок в отдельной табличке. В запросе имей её, будет мгновенно.

(24) ты описал обычный иерархический справочник, в чем профит?

(27) описала ;)

(28) тем более )))

(29) редиска ты)))))

(30) вот ни разу не похож )

А если пользователь скажет, как в фильме,- "Огласите весь список, пожалуйста". Как будешь выкручиваться? Как, например в моем случае, я точно непомню в коком именно районе находится населенный пункт, или занесли не тот район. То просто могу открыть и перенести в нужный район со всеми улицами. При выборе из Справочника.Контрагенты также.
Твоя схема сработает в идеальном мире, когда ненужно создавать новых элементов, и менять переподчинение. Но ведь в 1С такого не бывает

+(32)  Кроме этого твоя схема не позволит "Перескакивать" через владельцев. Например не заполняя область и район, а сразу выбрать населенный пункт, так как при открытии этого справочника - он просто будет пуст.

(0) Если я правильно понял суть задачи, а я в отпуске поэтому думаю и понимаю с трудом) то нужно два справочника - первый иерархия элементов, которая будет содержать структуру Классы/подклассы/группы/и миллион иерархических сущностей. У справочника должен быть реквизит Тип элемента. это справочник который будет содержать тип сущности - класс/группа/подкласс. его тоже можно сделать иерархическим, а можно сделать одноуровневый с реквизитом родитель, что бы можно было жестко ограничить значение не только по родителю но и по типу.
Допустим имеем иерархию 1 Класс подкласс 1.1, Группа 1.1.1, подкласс 1.2,  Группа 1.2.1 и так далее. таким образом, человек выбирает Класс 1, ему отбираются подчиненные элементы Подклассы с типом только подкласс. Таким образом соблюдается условие - ограничение "сверху" по родителю, ограничение снизу по типу. При этом не нужно плодить реквизиты и справочники и иерархию можно изменить в любой момент, вдруг нужно будет разделить класс или подгруппу. Так же, в случае необходимости можно будет дать выбрать пользователю "через   уровень" элемент.

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

(35) так я понял им нужна "параллельная структура".

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

(36) +у  меня была похожая задача. Организовали справочник и жестко привязали - родитель верхнего уровня Поставщик- родитель нижнего уровня - тип товара - элемент сам товар. И они перестраивали учет по всем товарам по такой структуре. а нужно было для разных групп товаров свои иерархии. для части товара три уровня, для части 5 уровней, где то вообще один уровень. Поэтому и придумали сделать "иерархию реквизитов", но справочник товаров оставили иеархическим. удобненько получилось, жаль внедрить не успели - начался переход на другую конфу)))

(35) скорее параллельную вселенную))))))))))))

(39) так какой вариант решила реализовать?

Мне интересно чем типовой механизм выбора родителя у элемента справочника не устраивает?

(41) ну видать, иеррархия отключена и в "плоском" списке не понятно, чья группа.

(42) что значит "не понятно, чья группа"?

(41) ну я так понял, что группы должны быть определенного типа. Например, ты не можешь сделать родителем Группы группу-класс, только подкласс. аналогично подкласс нельзя давать выбрать родителем класса. а в классе вообще не должно быть родителя.

(44) заводится реквизит с типом элемента/группы и на программном уровне контроль осуществляется.
хотя в (11) такая задача не ставится

(7) barin.sys звучит круче)

(40) - в сторонке сижу кофе пью по этой теме(((

(47) это правильное решение )))

в типовых на БСП реализована произвольная иерархия(несколько сразу) по свойствам объектов с видом справочник "ЗначенияСвойствОбъектовИерархия"

(7) barin.sys - мне нравится )))