Ну штош, садись поудобнее, дай мне пару минут

Платформенный метод "ПредопределенныйЭлемент()", вызываемый на клиенте, использует кэш предопределенных (вероятно, из файлового клиентского кэша, а уж кэш конфигурации это или кэш настроек - не знаю) на протяжении всего сеанса независимо ни от чего, т.е. результат первого вызова этого метода будет совпадать со всеми последующими вызовами в текущем сеансе всегда.
Чем это плохо? А тем, что это т.н. "логическая бомба" в случае, когда за время клиентского сеанса изменился состав предопределенных элементов в данных - какой-то ссылке справочника / ПВХ привязку к предопределенному поменяли, кому-то добавили, кому-то убрали (через реквизит ИмяПредопределенныхДанных). Привязку изменили, а твой вызов платформенного метода будет возвращать тебе - сюрпрайз, мазафака! - старую ссылку.

И нет способа сбросить кэш предопределенных на клиенте в текущем сеансе (только перезапускать сеанс).

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

Такие дела.

вах. спасибо за исчерпывающее разъяснение

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

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

Всё равно полезно знать такое. А уж тем более полезно выдать такой ответ в том числе.

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

Это ещё как?

Слушайте, ну быстрее можно подготовиться к собеседованию в гугле мне кажется, чем к 1С

@Labotamy ловил. Берёшь ссылку на предопределенное из менеджера перечисления и из функции ПредопределенноеЗначение. Сравниваешь их в отладчике и получаешь Ложь

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

И в бсл лс мы его тоже затянули

Жуть

Видимо, на сервере оно точно так же работает, как и на клиенте - рабочий процесс лезет в файловый кэш платформы пользователя ОС, от имени которого работает. И тоже может протухать.
А через менеджер перечисления - всегда православный запрос к БД.

Угу это зареганая бага была. Та которую я ловил связана с расширениями. Но такая же была и давным-давно еще до появления расширений(но это не точно).

@theEvilBeaver гоняй людей по БСП. Найдешь человека, знающего названия более чем 5ти подсистем - бери +)

ОбщегоНазначения
ОбщегоНазначенияКлиент
ОбщегоНазначенияВызовСервера
ОбщегоНазначенияКлиентПовтИсп
ОбщегоНазначенияПереопределяемый

Я принят?

Или нужно прямо подсистемы?