Например, когда у одной разновидности номенклатуры свои 10 реквизитов, у другой - другие 20, и так штук 6-10 видов. Это может быть бытовая техника или продукция разных видов.

Понятно, что есть характеристики, свойства и категории, только их неудобно редактировать в табличном виде, хочется чтоб были для каждого вида товара свои формы редактирования, потому что на первом месте удобство для операторов/продавцов.

Какой вариант лучше или "методически правильнее" ? :)  

1) Создать все реквизиты в одном справочнике Номенклатура, но с префиксами по видам товаров. На форме сделать закладки/страницы под каждый вид, активировать нужную программно при открытии.
2) Создать для каждого вида свой справочник, в отдельном регистре сопоставить группу номенклатуры и эти справочники. При открытии товара, открывать форму соответствующего справочника.

Бред какой-то.

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

(0) механим такой есть, называется, как ты правильно сказал, свойства.
Напиши свою форму. Все свойства хранятся в регистре "значения свойств объектов".

Если набор переменных реквизитов известен заранее и не будет изменяться/дополняться "по ходу жизни" - в справочник основных реквизитов - фишку для определения набора дополнительных. И по одному подчиненному справочнику на каждый набор переменных.

Если набор переменных заранее не определен - тогда характеристики и регистр сведений.

Связывать удобство хранения и редактирования - на то наймите программиста.

(4) Зачем издеваться над программистом и над собой? Кто-то способен анализировать неструктурированный бред и на основе этого принимать управленческие решения?

(0) нельзя решать задачу отображения путем подгонки метаданных под интерфейс. Храни это все в свойствах и категориях, а для редактирования нарисуй свои формы, в которых эта бадяга буд отображаться в виде полей ввода (ты же в курсе, что поля ввода можно генерить на форме на лету, да?)

(6) А вот бывают конторы, которые торгуют всем, что б торговать хоть чем нибудь. И получается в справочнике "номенклатура" лежат телеки с холодильниками вперемешку с весовыми пельменями и женскими прокладками.
Сам, блин, на такой работаю.

>> характеристики, свойства и категории

Для изменения внешние обработки. Программно дорисовать кнопочки в журналы, справочники и документы.

+(6) итого, задача на самом деле такая:
1. нарисовать формы
2. придумать, у кого будут открываться эти формы, а у кого типовые
3. придумать, как отличать свойства и категории, которые нужно отображать на твоих формах, от тех, которые не нужно (тут реквизита в ПВХ свойстваОбъектов достаточно)

+(7) И потому бывает нужно в зависимости от того если это бытовуха - указать габарит. Если крышки для домашнего консервирования - есть цветная накатка или нет. Городить все реквизиты для всех наименований - есть бред. Потому заводятся подчиненные справочники с переменными реквизитами. Для каждого вида набор свой.

(10) В семерке?

(11) Какая такая глубокая разница? Тот же подход был реализован еще в Фоксовской программе.

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

(13) Нихрена. Никаких форм подчиненных справочников. Закладки без заголовков на форме основного справочника - наше Фсе.

(14) тогда надо все реквизиты надо пихать в один справочник или извращаться с характеристиками

(13) Подчиненный справочник более неудобно для юзера если их Неграмотно  привязать к владельцу.

(16) Юзер будет видеть простую форму для номенклатуры, с наименованием которое сам введет ранее, а все остальные параметры можно открыть в отдельном окне по кнопочке.

(16) см. последнее предложение из (4).
Можно посмотреть банальную форму редактирования реквизитов контрагента из любой типовой (взависимости он - юрлицо или физлицо).

(15) Если у тебя  сто тыщ. миллионов элементов тогда стоит подумать над там чтобы не загружать  справочника реквизитами.

И еще если сделаешь подчиненные справочники то потом отчеты по ним будешь мучатся делать

(13) подчиненный справочник в итоге засрется ненужными элеменатми и пользователям он будет совсем неудобен. Кроме того, не понятно зачем городить огород, когда годное архитектурное решение уже есть в виде свойств и характеристик
(10) какой толк обсуждать семерошные решения в восьмерошной ветке?

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

(20)
1. Для стопицот элементов справочника "номенклатура" в подчиненных справочниках будут лежать только нужные "выжимки" с заранее известным набором реквизитов. Что даст выигрыш в скорости получения этих самых "допреквизитов"
2. Связывать набор данных в форме элемента - всего лишь указать "связь по владельцу".

Напряг остается только с открытием нужной вкладки в зависимости от фишки, которая определяет нужный набор допреквизитов. Если это кому не под силу - тому в 1С лезть не нужно.

Все, что указано в (22) справедливо только если наборы переменных реквизитов известны на этапе разработки. Если "по ходу жизни" они могут меняться - тогда только характеристики и региср сведений. Более трудоемко, более тормознуто - но зато универсально.

Читаю доки по БСП, про внедрение подсистемы "Свойства". Кажется там уже реализовано что надо - создаются поля на форме и можно создавать разные наборы доп. реквизитов для разных видов товаров

(0) Я решала эту проблему следующим образом: Сделала справочник "Типы объектов", в котором хранились набор характеристик с описанием, который описывал набор реквизитов и табличных частей, справочник "Объекты", с реквизитом "Тип объекта", в зависимости от которого строилась формы и регистр сведений, хранящий значения характеристик для каждого объекта. Кода около 400 строк.

В принципе уже все сделал, работает неплохо :) Автоматически генерятся поля на форме. Кода около нуля строк :)))

Задумался тут. А как хранить цены, если тут нет единого подчиненного справочника Характеристики. В регистре Цены никак не укажешь ведь все значения свойств. Придется дополнительно прикручивать Характеристики, а в БСП их оказывается нет. А потом программно создавать и обновлять Характеристики, не давая юзеру их править вручную