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

Сделать элементы справочника предопределенными?

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

(0) Предопределнные элементы справочника

(1) я чую, что это неправильно здесь

(0) Подробнее лучше описать. Возможно тут речь вообще о Бизнес-процессах.

(4) Я чую что задача вообще безумная :) Ну или понимание ее ТС безумное.

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

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

У меня на номенклатуре справочник виды услуг. Тоже начинал с 5 .. сейчас их штук 15. В общем справочник и никаких перечислений.
Но если конфа специальная то и такого справочниа быть не должно.

(7) Сочинять ты можешь, что угодно. Можно и перечисления а значения доп реквизитов хранить в регистре сведений.

Вопрос как это пересекается с типовыми механизмами.

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

(8) (7) Может просто взять конфу ТСЖ и посмотреть?

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

конфа в принципе работает, просто хотелось понять как правильно

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

Так как все же обратиться к предопределенному элементу справочника? Через НайтиПоКоду() или есть готовый механизм?

(14) На мой взгляд у меня все же это явно не номенклатура и именно вид/тип услуг.

(0) Не трогая конфу просто вынеси (сохрани) эти свои элементы справочника услуг (ссылки на них) куда то с именами для поиска.

И затем в коде просто используй самописную функцию ПолучитьУслугу("ИмяУслуги").

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

Почему не оставить как есть? Работает же.

А вообще вариантов может быть масса:
Самый простой, если это одна организация - завести 5-6 констант.

Если много организаций, и у каждой свой набор - завести регистр сведений с Измерением - "Тип услуги" (можно перечисление, можно строку) и Организация, ресурс - ВидУслуги.
Соответственно, в любой момент из регистра можно по типу получить нужный вид услуги для организации.

У него есть имя. При программировании вы его будете видеть при написании кода.
Я понимаю, что это некая типизация, но хочу сказать, что если она не определена в момент проектирования, то она так и останется не конкретной, т.е. границы ее использования будут не четкие. А вот если они четкие, то практически всегда лучше использовать перечисление.

Для ТСЖ я не очень понимаю зачем там лезть вне списка номенклатуры. Вы ведь не можете продать больше чем вам разрешено. У вас должен быть фиксированный справочник , с каким то перечнем расчетов. (я уже таким давно занимался)

(12) > вид услуг

Вот и ответ на Ваш вопрос :)

в типовых, вроде, номенклатура -> вид номенклатуры (справочник) -> тип номенклатуры (перечисление), не?

хотя в БП только номенклатура -> вид есть

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

Справочник хорош тем,что в него потом можно добавить новые элементы.
Еслм услуги имеют какие то спец поля и т.п.то нужно прежде всего подумать,как этр хранится в документе,а если спецполя,только характеристики услуг,то дополнительные реквизиты вам в помощь.
перечисление имеет смысл только тогда,когда его содержимое явно определено и не прменяется с изменением бизнес процессов,например,ставки ндс фиксированы,поэтому заданы как перечисления.
типы номенклатуры тоже фиксиррваны,т.к.ничего другого быть не может.
а видов может быть много,поэтому и справочник.
предопределенные элементы при обращении как перечисления по имени

(25) "ставки ндс фиксированы" - совсем не смешно

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

Что касается технической стороны вопроса (15) "Так как все же обратиться к предопределенному элементу справочника?"
Ответ: по имени, как этот элемент назван в конфигураторе.
[МенеджерСправочников].[МенеджерСправочника].[ИмяПредопределенногоЭлемента]

Например, в конфигурации есть справочник Номенклатура, в котором создан предопределенный элемент с именем ГвоздьДесятка. Тогда обратиться к нему можно будет так.

СсылкаНаЭлементГвоздь = Справочники.Номенклатура.ГвоздьДесятка;

(0) надо перестать хотеть обращаться к конкретным товарам из кода

(28) +100500

(0) Я такую задачу тоже начинал на справочнике и искал по коду. Для теплосети. Осознал, что это гемор. Переделал на предопределенные. Тоже сомневался правильно или нет. Посмотрел на типовые план счетов, справочник статей расходов... И успокоился. Очень удобно в сопровождении. Это не торговля, где номенклатура может достигать сотен тысяч. Четыре...шесть услуг. Все. Причем расчет допустим "тепловая энергия" и "технические услуги" абсолютно разные. А выполнены должны быть в одном документе, где тысячи абонентов.

+ (30) Или взять для примера виды расчетов в ЗУП. Тысячи их предопределенных. Ситуация с услугами примерно та же. Те же графики подачи, снятые счетчики на госповерку (и расчет расчетным путем), температурные графики... Так почему нужно быть умнее разработчиков ЗУП-а?