Маялся я несколько дней с культурным заполнением регистра сведений. В ходе разработки вплотную познакомился с планами видов характеристик. Оказалось,удобная штука, но... В одном плане можно определить только один тип значений. А мне нужно два. Пришлось извращаться создавать ещё один план видов характеристик. Делать у первого реквизит, который содержит второй план. А если типов нужно будет больше?

Что-то ты не докурил... Составной тип значения же

(0) эээ, о каких типах речь?

Может ты не с тем планом знакомился?

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

(0) Там можно использовать 2 и более типов в одном плане.
Ветку топлю.

(5) Можно для нескольких полей.

(0) посмотри план видов характеристик ВидыСубконтоХозрасчетные в любой типовой бухне.
Там определены типы всех возможных значений субконто. И их там точно больше чем один.

(5) опиши детально проблему

а то пока только понятно что у тебя некий регистр и некий пвх

Я толком не понял, при чем здесь регистр. Понял только, что он в регистре хранит значения характеристик...

Очередной велосипед?
См. регистр ЗначенияСвойствОбъектов в типовых, у него у ресурса "Значение" тип "Характеристика.СвойстваОбъектов"

Есть регистр сведений характеристики договоров.
измерения
договор (справочник типовой)
характеристика (мой план видов характеристик)
объект (ещё один план видов характеристик)
значение (пока число и строка)

(12)+Мне надо, чтобы при выборе характеристики контролировались типы(и вводились значения только этих типов) у объекта и значения.

(13) одна характеристика имеет два типа?
это как?

живой пример есть?

(15)В том-то и дело, что нет. Пришлось заводить два плана. И один у другого делать реквизитом.
То есть у меня в плане видов характеристик ХарактеристикиДоговоров есть реквизит типобъекта, который является планом видов характеристик.

(16) я не о том

характеристики идут парой: хар-ка - значение
например, цвет - синий
размер - 8

но нет такого, что цветоразмер - синий - 8

(17)Я знаю, что нет. А хотелось бы. В 1С не предусмотрели такого варианта. Вот и проходится извращаться. .

(18) и правильно что не предусмотрели

а то потом в ваших цветоразмерах никто не разберется

(18)+Это как в 7.7 одна табличная часть.

(19)Да ну. Если тебе надо один - заводи один.

(21) для автоматизации абсурда используйте другие языки программирования

(22)
Смотри. Есть договор с контрагентом на аренду помещений.
Характеристика/ Объект/ значение
площадь/аренда офисных помещений/50(м2)
арендная ставка/аренда офисных помещений/500(рублей)
номера офисов/аренда офисных помещений/10,15,17
Другой договор. Займы.
процент/1-я линия(объект строительства)/10
И хотелось, чтобы всё это достаточно просто масштабировалось. То есть, чтобы я без особого напряга добавлял характеристики, а пользователи легко заносили значения в регистр. Я это сделал, но потребовалось два плана видов характеристик.

(23) с характеристикой и значением все ок

причем тут объект?

и какая цель такого странного регистра?

а если характеристика "площадь" у договора займа?
то все? рушится система?
ведь тип объекта будет отличаться.

(24)Объект в одном случае - номенклатура, в другом - объект строительства. Для некоторых характеристик он вообще не заполняется.
(25)Цель - хранение характеристик договоров. Они потом используются в отчётах и документах.
(26)Не порушится. Просто занесённые данные будут лежать мёртвым грузом.