Каталог решений - Обход указания ссылок на конкретные элементы по реквизитам в коде

Код наподобие следующего мешает получить удовольствие от проделанной работы:

ЦенаПродажи = Справочники.ТипыЦен.НайтиПоНаименованию("Розничные");

Это решение чревато ошибками в случае изменения ссылочных реквизитов, и неверно методологически: в случае перенумерации справочника надо лезть в код. Что делать?

Я предлагаю решение, которое не требует модификации стандартных объектов конфигурации, но подразумевает включение возможности внесения изменений в саму конфигурацию. Это решение опробовано на многочисленных типовых и самописных конфигурациях клиентов как в ОП, так и в УП (обычное и управляемое приложения).

В конфигурацию добавляем справочник СсылкиНаОбъекты:

• — Без кода. Он не мешает, но это лишняя информация.
• — С реквизитами:
  • «СсылкаНаОбъект» типа «Любая ссылка» или с множественным значением нужных типов;
  • «Описание» тип Строка (неогр.) для описания параметра;
• — С предопределёнными элементами.

В качестве предопределённых элементов задаём те самые объекты, на которые бывает нужна ссылка:

В Наименовании указываем краткое описание параметра. Затем в режиме предприятия дообавляем в реквизит «Описание» более подробное описание параметра с указанием механизмов, в которых он используется. В значении выбираем тип и нужный объект:

Ну и теперь то, ради чего весь этот механизм создавался. Из кода можно сослаться на значение такого элемента следующим образом:

СвойствоСрокГарантии = Справочники.СсылкиНаОбъекты.СвойствоСрокГарантии.СсылкаНаОбъект;

Т.о. обеспечивается корректность ссылки при изменении любых реквизитов объекта и внесение каких-либо изменений при замене значения в код не требуется.

Добавлю для тех, кому лень читать комментарии:
* В (4) я признаю, что методологически этот способ не совсем правильный, т.к. именного для этих задач предназначен ПВХ. Этот механизм я использую в тех случаях, когда бюджет проекта не подразумевает выделения средств для программирования конструкций ПВХ + РС + общий модуль.
* Там же, в (4) я комментирую аналогичную статью на эту тему, автор которой не предлагал описываемый мной вариант. «Баянистов» прошу указывать пруф: до сих пор его нет.
* Решение не предусматривает ведения хронологии. Я до сих пор не сталкивался с такой необходимостью. Нужна хронология — периодический РС + ПВХ.
* Не считаю минусом то, что приходится выгонять всех пользователей ради применения изменений. Подразумевается, что программист ведёт разработку в тестовой базе и уже отлаженный механизм  применяет в боевую. Следовательно, выгонять пользователей нужно будет в любом случае и этот случай один.