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

Скажите, пожалуйста, будет ли хорошим тоном добавлять префикс к своим предопределенным элементам?

Скажем, префикс П. Тогда код будет чем-то вроде П00000001.

На сайте ИТС есть Руководство по стилю для типовых конфигураций на платформе 1С:Предприятие 8.2 "Управляемое приложение". Но этот момент обойден вниманием почему-то.

есть крамольная мысль, что предопределенные данные есть зло

(1) НайтиПоКоду("000000123") - большее зло.

А существующий в БД элемент совсем никак не перекодировать что ли?

(2) согласен, но есть более приятные альтернативы ))

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

(4) Ну если это не НайтиПоКоду, наименованию и не получитьСсылку, то поделись.
Пусть всем станет приятно

(0) не сцы. поцаны одобряют

(4) Константы? Перечисления? ...

p.s.: НайитПоКоду() иногда позволяет не делать реструктуризацию базы.

(6) почему не использовать константы, недоступные для изменения простым смертным?
при первом запуске после обновления заполняем такую константу свеже созданным элементом

(8) а потом огрести кучу проблем при изменении кода

(6) Справочник

(11) Что, справочник?

(9) И в чем гешефт?

Ну, немного подумайте дальше...

(10) Согласен, что огрести можно , но вот вопрос как часто у тебя меняется код у элемента справочника?

(14) справочник с предопределнными элементами разве чем-то отличается от констант?

разве, что при хранилище захватывать можно не корень, а только справочник.

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

(16) Настраивать удобнее

(15) Тебе больше подойдет получитьСсылку

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

(20) Т. е. от создания предопределенных элементов можно уйти способом создания предопределенных элементов? Я правильно понял?

(19) ну типа замена ссылок тоже все поломает... :)

(21) Да )
Но только в одном, служебном справочнике!

(23) Константа проще, т.к. с отдельным справочником различные соединения надо будет делать в запросе.

(2) если базу не менять то не такое уж и зло)

(25) хуже где Наименование = "Первая    группа затрат"

(24) А с константами, типа, соединения не надо будет.
(19) Это чтобы повеселиться как следует, когда из этого CF новую базу сделают?

(0) а какая проблема при добавлении предопределенного элемента присваивать актуальный код?

(27) соединиться без условий с таблицей из 1 записи думаю не критично будет

проще, имхо, держать ПВХ с предопределенными элементами описания параметров + РС для хранения значений параметров

(24) Никаких соединений!
"И ТвоёЗначение = Справочник.ЭтотСлужебный.ИмяНастройки.Реквизит"

Забыл: Значение(...)

А как 1С в типовых решает эту проблему? Обновляются конфы ведь у многих людей.

(33) Никак - живут себе элементы с одинаковыми кодами...

При создании базы предопределённые элементы получают первые коды

Ну а в чем гешефт хранения всех предопределенных элементов в одном справочнике?

Послушайте, а чем плохо решение с префиксами кодов справочника? Уникальность кодов будет, что еще надо.

(37) код может быть не текстовым, в справочнике уже могут присутствовать коды с таким префиксом. Да мало ли.

Ну будут дубли кодов, в чём проблема? При обмене через конвертацию тоже иногда появляются. Потом можно исправить руками/обработкой.

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

(40) что, простите?..

(41).. я тоже споткнулся...

(40) еще бы она не отругалась, если ее вовсю впердоперделяют...

"Предопределил" это, предопределил. Хотел Впредопределил написать... 00