Есть "производственная необходимость" не монопольно добавлять записи в справочник, а потом в коде обращаться к этим элементам. Так же есть мнение что
```1c
    Справочники.КакаятоЕрунда.НайтиПоКоду(10582)
```
 типичный индусский код.

Прошу помощь зала: как быть?

PS. Если не понятна проблема, спросите, попробую уточнить.
---
Я всегда завожу справочник "Константы" среквизитом Значение со всеми типами. Если надо, то делаю предопределнные элементы, если надо, то в режиме пользователя. Права на изменение только у админа, у остальных только чтение. Тут можно искать по наименованию. Почти у всех клиентов так веду. Ниразу не попадался на подводных камнях.
Иногда добавляю ТЧ Значения, куда в одну "константу" пихаю сразу список. Иногда добавляю реквизит "ЗначениеХранилище" и "ЗначениеНеограниченнаяСтрока", чтобы хранить, например, файлик или настройку какую.

При этом, пусть юзверь хоть запереименовывается и пусть хоть каждый день код элемента меняет.
И при обновлении новый справочник "Константы" никак не мешает.
Да и ваще... ))
---
Win98, ну как индусский... Просто поменяв код у справочника, потом нужно будет лезть в программный код, поправлять строки с "НайтиПоКоду". Проблема-то какая? Создать элемент и потом как-то его найти?
---
RocKeR_13, а с какого перепугу он вдруг изменится? Так и предопределенный элемент можно изменить/удалить и тоже придется править код. Понятно что для правки предопределенного потребуется монопольный доступ к базе и сделать это нечаянно трудно. Но ведь к данном справочнику можно применить "повышенные меры безопасности" (ограничить ролью, например) и нечаянно его изменить будет трудно.
---
Win98, возникает другая ситуация: а если элемент удалят? Тогда НайтиПоКоду вернет пустой элемент
---
RocKeR_13, а с кого перепугу его удалят? Кто? Кто посмеет?
А потом, можно предусмотреть реакцию системы и на отсутствие элемента с заданным кодом.
---
Win98, ну так а я откуда знаю? Этого не было описано в теме. Или ты наивно думаешь, что пользователи никогда ничего не удаляют из справочников?)
---
RocKeR_13, если программно и ролью пользователю запрещено удалять элементы этого справочника, как он сможет удалить?
---
Win98, если программно и ролью пользователю запрещено удалять элементы этого справочника, как он сможет удалить?
В исходных данных об этом речи не шло, было лишь:Есть "производственная необходимость" не монопольно добавлять записи в справочник, а потом в коде обращаться к этим элементам. Так же есть мнение что
Код

Справочники.КакаятоЕрунда.НайтиПоКоду(10582)

типичный индусский код.

Прошу помощь зала: как быть?

PS. Если не понятна проблема, спросите, попробую уточнить.
---
RocKeR_13, совершенно верно, в СТ было: PS. Если не понятна проблема, спросите, попробую уточнить.
Все возможные (возможно будущие) требования с ходу предусмотреть не возможно.

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

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

в первом случае есть "предопределенные критерии" и поиск нужно делать именно по ним а не по мифическому коду или названию

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

```1c
    Если МойЭлемент1 = НайденоеЗначение Тогда ......
```
 ну тут поиск по любому перебором идет
---
vde69, в первом случае есть "предопределенные критерии" и поиск нужно делать именно по ним а не по мифическому коду или названию В данном случае - частный случай: код и есть тот самый "предопределенный критерий". Изращенный случай ;)
---
Психологически есть ощущение, что код у элемента может измениться, откуда такое ощущение не понятно.
Можно же заполнять реквизит уникальным значением и использовать НайтиПоРеквизиту(), если так психологически "удобнее".
---
Win98, ну если Психологически есть ощущение, что код у элемента может измениться тогда сними доступность поля, или выводи его в виде надписи, чтобы не редактировали + поставь контроль уникальности, если конечно по каким-то причинам впоследствии не нужно будет изменить код (допустим, если этот код регламентирован, как код валюты)
---
RocKeR_13, в данном случае это порядковый номер.
Меня больше теория интересует почему НайтиПоРеквизиту() и/или НайтиПоКоду() это плохой стиль программирования?
---
Назначу-ка вознаграждение, может обсуждение пойдет веселей?
---
Тут немного нужно конкретики: как часто будут удаляться элементы, нужно ли будет потом править код, есть ли возможность добавлять предопределенные (тогда и не нужно искать по коду, а можно обращаться через точку)
---
RocKeR_13, элементы вообще удалятся не будут, т.е. не предусмотрено, не возникает ситуации, когда когда возникает необходимость удалить элемент. Например, этот код есть регистрационный номер письма, в справочнике исходящих писем. Контроль уникальности возможен средствами системы, возможность добавить элемент есть, возможности удалить - нет.
---
У нас решено таким образом(да и вообще не раз видел подобный механизм в других организациях): есть некий периодический регистр сведений Соответствия. Где хранятся пара СтроковыйКлюч и ссылка на элемент инф.базы(ну или любое другое значение) + краткое описание для чего (где) данный ключ используется. Получается этакий аналог констант с быстрым доступом и свободным составом.
---
mymyka, а как из кода идет обращение к... "константе"?
---
через предопределенную функцию получения значения по строковому ключу, в которой по сути один запрос + возврат 0, если значение не найдено(для единой логики обработчика ошибок в коде).
---
mymyka, ИМХО это сложнее чем НайтиПоКоду() а запись в регистре так же могут удалить/поменять, т.е. "устойчивость" не чуть не выше.
---
Win98,
Данный регистр даёт быстрый доступ к изменением. Допустим был элемент справочника с уникальным ключём таким-то для того-то, его удалили, зато в регистре можно сразу поменять связку.
О Регистре можно никому не говорить, дать доступ на изменение только себе любимому и никто туда не влезет.
Идея очень даже ничего :)
---
Sevens, так и к справочнику ни кому кроме избранных (себя любимого) доступа не будет, да и вообще удаление элементов из него запрещено ролью и программно.
---
Win98,
Ну так с чего тогда сомнения?) или вы не уверены в себе, что не забудете?)
В комментарии тогда пишите, что вот этот элемент используется в коде=)
(34) Тогда вообще странно.
---
Sevens, мож я чего не знаю и уже есть более элегантный способ?
---
Win98, Ну даже не знаю... Если подытожить всё сказанное я б сделал такие выводы:
1.Я уверен, что кроме меня никто не поменяет код в справочнике и не удалит элемент справочника, и он будет использоваться всегда. Тогда НайтиПоКоду();
2. Я уверен, что кроме меня никто не поменяет код в справочнике и не удалит элемент справочника, но не уверен, что он будет использоваться всегда. НайтиПоКоду() или регистр как предложили в (13) для быстрого изменения связки без влезания в программный код.
3. Я не в чем не уверен. Тогда Регистр с правами только на себя или предопределенный элемент.

В случаях 1 и 2, в комментариях в элементе писать, что используется в коде для того-то. В коде писать, после НайтиПоКоду(), что за элемент и для чего.
---
Sevens, с комментами все ок, сейчас тоже все комментится и код выглядит примерно так: Справочники.ИсходящиеПисьма.ПисьмоНомер11225 // Бла-бла-бла
А будет выглядеть так Справочники.ИсходящиеПисьма.НайтиПоКоду(11225) // Бла-бла-бла
---
Это делает код отвязанным от базы данных. Если судить таким образом, то любая настройка не защищена, т.к., если кто-то может установить какую-либо галочку, то он же ее может и снять.
Определенным плюсами являются так же:
1) повышаемость читабельности кода(все же РегистрыСведений.н_Соответствия.ПолучитьСоответствие(, "Свойство_Объем"); читается лучше, нежели ПланыВидовХарактеристик.СвойстваОбъектов.НайтиПоКоду("12312312");
2) возможность изменения "на лету"
3) возможность установки периодческого значения "на будущее", + ведение истории.
4) устойчивость к перенумерации, перенаименованию
5) возможность программной установки значения(!!!)
и это только на первый взгляд.
---
mymyka,
1) Совсем не факт: РегистрыСведений.н_Соответствия.ПолучитьСоответствие(, "Свойство_Объем") и Справочники.ИсходящиеПисьма.НайтиПоКоду(КН-11225) или Справочники.ИсходящиеПисьма.НайтиПоРеквизиту("Номер",КН-11225)
2) Что значит возможность изменения "на лету"? Добавить элемент в справочник я могу "на лету", из-за чего собственно и сыр-бор, чтобы можно было добавить "на лету" а не добиваться монопольного доступа.
3) А чем справочник-то отличается?
4) Не пойму за счет чего получается устойчивость к изменению "Свойство_Объем"? Справочник так же устойчив к изменению всех полей кроме кода или ключевого реквизита.
5) Так и в справочнике можно программно установить код, это как раз минус :( исходя из условий задачи.
---
Win98, Так и в справочнике можно программно установить код, это как раз минус
Программно можно всё, но программно работают только программисты ;) соответственно они знают, что они делали и что за их программным установлением кода может последовать. Хотя опять же, перед записью проверяйте изменился код или нет и если он изменился выдавайте сообщение об ошибке.
Что значит возможность изменения "на лету"? в (31) описан пример. Сегодня для решения задачи используется один элемент справочника, завтра другой. В регистре можно сразу изменить привязку "уникальный код"- элемент справочника.
---
Sevens, Программно можно всё, мож я чего пропустил, но не могу программно создать предопределенный элемент :( Научите?
Сегодня для решения задачи используется один элемент справочника, завтра другой. В регистре можно сразу изменить привязку "уникальный код"- элемент справочника.Так и в справочнике можно поменять код, вот только именно этого делать и не надо. Эту возможность, пока, как не актуальную, рассматривать не будем.
---
Win98,

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

Предопределенные элементы создаются в конфигураторе, соответственно - программистами (или я что-то путаю).
Но всё же соглашусь "программно" звучит не корректно, заменить на "программисты" и всё ок)
---
Sevens, даже Вы в первом случае сделали два шага, во втором - три и куча геморроя с третьим шагом :( ИМХО, конечно.
Если не создавать себе сложности то в первом случае достаточно просто поменять значение реквизитов элемента справочника не трогая его код, и все, один шаг, одно простое и понятное действие.

Но вопрос остался:
в чем преимущество конструкции с предопределенным элементом

Справочники.ИсходящиеПисьма.11225

над конструкцией

Справочники.ИсходящиеПисьма.НайтиПоКоду(11225)
---
Win98, Преимущество в том, что в случае предопределенного элемента вы уверены что не поменяется код и он не удалится. Так же можно обращаться напрямую через точку в коде и в запросе сразу. А не лезть в сам справочник и смотреть нужный код, а потом вставлять его в НайтиПоКоду();
Вот, имхо, и вся разница.
В случае (46) Справочник - сродни регистру из (13).
Не знаю, где вы там увидели гемор в смене связки уникальный код- элемент справочника.
---
Win98, первая конструкция (Справочники.ИсходящиеПисьма.11225) быстрее второй (в большинстве случаев).
Предлагаю выдать мне 10$ и закрыть на этом тему, т.к. это чистая теория.
---
Sevens, программно предопределенный элемент создать нельзя!
(42) Win98, складывается мнение, что Вы ерундой какой то занимаетесь! Если нужно обратиться в элементу, то это нужно делать уже точно не через его Код, а через явный вызов. Если же нужно, то есть права и роли, учите матчасть, все можно ограничить и самому всем управлять!
---
DoctorRoza, Если нужно обратиться в элементу, то это нужно делать уже точно не через его Код, а через явный вызов.
Расскажите как?
---
Что значит возможность изменения "на лету"?
Значит, что если завтра основной организацией станет не ИП Пупкин, а ИП Тяпкин, то не надо будет лихорадочно перебирать все обработки и модули, где используется явная привязка к основной организации, а достаточно завести новую запись с ключем ОсновнаяОрганизация и новым значением ИП Тяпкин.
Не пойму за счет чего получается устойчивость к изменению "Свойство_Объем"?
Устойчивость в том, что как бы мы не поменяли наименование элемента ПланыВидовХарактеристик.СвойстваОбъектов.НайтиПоКоду("12312312"), как бы мы не перенумеровывали ПланВидовХарактеристик, код работать не перестанет, т.к. в регистре по ключу Свойство_Объем всегда будет доступна ссылка на искомое свойство.
Так и в справочнике можно программно установить код, это как раз минус
Установив программно код элемента, вы получите неработающий программный код. Установив программно значение в регистре, вы получите программный код, использующий другой предопределенный элемент, если в этом возникла необходимость.
---
Если все равно остается "очучение", тогда перечитываем (13), (15) и (16)
---
В общем и целом: если задача позволяет добавлять предопределенные - добавляй именно их. К ним можно обращаться непосредственно через точку (Справочники.Номенклатура.Моя_номенклатура), если нужно менять код - меняй на здоровье, на программном коде это не отразиться (если обращаться к ним Справочники.Номенклатура.Моя_номенклатура), если нужно изменить наименование (не путай с именем предопределенного элемента) - меняй и это опять-таки не вызовет ошибок в программном коде
---
Я всё же стараюсь пользоваться перечислениями или предопределенными элементами. Риск того что эти объекты поменяются или удалятся минимален. Но всё же иногда приходится использовать НайтиПоКоду(). в этих случаях я предупреждаю пользователей и руководителей, что б эти элементы справочников оставались неизменными(не удалялись, не меняли код и наименование), можно менять только внутренности. Но "Психологически есть ощущение, что код у элемента может измениться" и никуда от этого не денешься.

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

...проблем не возникнет, если только не захотите вдруг очистить всю базу/справочник и начать с 0
---
RocKeR_13, тогда откуда ну как бы психология, все программисты с опытом говорят что код может поменяться. Мои замечания что не может, во всяком случае вероятность такого события не выше чем изменение/удаление предопределенного элемента, либо игнорируются либо поднимаются насмех.
---
Win98, без аргументов насмехаться - это повод усомниться в их профессиональности.
---
Win98, все программисты с опытом говорят что код может поменяться(с)
И я так скажу, у меня код может поменяться, но вот я не знаю вашу конфу и не работал на вашей фирме, соответственно как это происходит у вас я не знаю. Если вы уверены на 100% что заблокировали код и пометку на удаление, то чего вы их слушаете? они ж у вас не работают.
---
Sevens, работают, работают :)
---
Win98, код либо меняется вручную пользователями, либо программистом (обработкой, либо при обновлении, если того требует логика обновления). Мистическим образом ничего не происходит. И как сказано в (29), если вы уверены что пользователи не смогут изменить код/состав справочника и никто программно не сможет изменить ситуацию, то используйте НайтиПоКоду и не слушайте "профессионалов"
---
РС заведи - проще всего.
Или возьми готовый из конфы, типа настройки рег заданий.
---
Я всегда завожу справочник "Константы" среквизитом Значение со всеми типами. Если надо, то делаю предопределнные элементы, если надо, то в режиме пользователя. Права на изменение только у админа, у остальных только чтение. Тут можно искать по наименованию. Почти у всех клиентов так веду. Ниразу не попадался на подводных камнях.
Иногда добавляю ТЧ Значения, куда в одну "константу" пихаю сразу список. Иногда добавляю реквизит "ЗначениеХранилище" и "ЗначениеНеограниченнаяСтрока", чтобы хранить, например, файлик или настройку какую.

При этом, пусть юзверь хоть запереименовывается и пусть хоть каждый день код элемента меняет.
И при обновлении новый справочник "Константы" никак не мешает.
Да и ваще... ))
---
kilo81, поподробнее, плиз.
Итак, справочник "Константы", в режиме пользователя только админ может добавить/удалить/исправить элемент?
Дальше что? В коде Вы как находите нужный элемент? Как из текста программы Вы к нему обращаетесь?
---
Справочник "Константы" имеет один реквизит "Значение" с типами (Число,Строка,Булево,Дата,ЛюбаяСсылка). В режиме пользователя добавляем элемент в этот справочник, делаем ему Наименование "Основная организация" например, В значение выбираем организацию "ИП Пупкин" . Теперь в своих обработках:

ТекОрг = Справочники.Константы.НайтиПоНаименованию("Основная организация").Значение;

Но я обычно делаю предопределенные (как-то красивее)
В итоге:
ТекОрг = Справочники.Константы.ОсновнаяОрганизация.Значение;
---
kilo81, Справочники.Константы.НайтиПоНаименованию Те же яйца только в профиль: НайтиПоКоду, НайтиПоРеквизиту и т.д. А что будет если, вдруг, изменится наименование?
Спасибо, за то что поделились, опытом отсутствия сколько-нибудь существенных проблем с подобным справочником.
---
Наименование чего изменитя? Константы? Имя элемента справочника Константа меняет только админ, остальные чтение. А в реквизите "Значение" хранится ссылка на ИП Пупкин, а не его код! Хоть заменяйся код ИП Пупкин, ссылка не изменится!
---
kilo81, а если удалить ИП Пупкин? По идее не должно удалиться, так имеется ссылка в справочнике Константы.
Как вариант двойного контроля, при добавлении элемента в справочник "Исходящие письма" в справочник "Регистрация исходящих писем" так же добавляется элемент и дается ссылка на элемент "Исходящие письма", теперь удалить элемент из справочника "Исходящие письма" не получится до тех пор пока не удалится запись из справочника "Регистрация исходящих писем".
Вот только нафига весь этот геморрой...
---
Я перестал Вас понимать.....
---
Увы, многим не нравится мысль о том, что в коде будет конструкция опирающаяся на НЕ предопределенный элемент.
Так же, увы, никто толком не смог выдвинуть сколько-нибудь существенные плюсы или минусы предопределенных элементов.
Данная информация все больше убеждает меня в том, что использование НЕ предопределенных элементов ничем страшным не грозит.(55)
Самым ценным, для меня, оказался опыт kilo81, если общественность не возражает отдам вознаграждение ему.
---
Та помечайте на удаление сколько душе угодно =)
Ссылка на элемент от этого не пропадёт и связь со справочником "констант" останется, если она вам не нужна можете:
А. Пометить эту связь на удаление
Б. Поменять связь
Удалить начисто из базы конечно не даст, так как сомневаюсь что этот "ИП Пупкин" будет только в справочнике константы, наверняка ещё проходит в куче документов ;)
Но мне кажется вам всё это не нужно, так как доступ к справочнику "Исходящие письма" (на удаление и изменение кода) есть только у вас, соответственно для вас нет разницы предопределенный элемент или стандартный.
---
Ну если охота через одно место, то получи внутренний идентификатор объекта в виде строки. Потом в своей обработке прямо переводи эту строку в ссылку. Но это как-то совсем не полюдски.
---
Считаю методически неправильным привызявать код к данным, но реалии жизни показывают что периодически приходится так делать.
Для преодоления "психологического ощущения" привязывайтесь к ссылке - она то вряд ли поменяется, если не будут бездумно выполнять замену ссылок.

Использую вот такой шаблон даже

```1c
    UUID = Новый UUID("<?"Укажите GUID объекта">"); //"<?"Укажите представление объекта(обычно наименование)">"
    СсылкаПоGUID = Справочники.<?"На какой справочник ссылка?", Справочник>.ПолучитьСсылку(UUID);//
    // Если нихрена не нашли объект по ссылке
    Если СсылкаПоGUID.ПолучитьОбъект()= Неопределено Тогда
    Сообщить("Не найден объект по ссылке.", СтатусСообщения.Важное);
    КонецЕсли;
```