Где хранить настройки в 1С: обзор способов и рекомендации

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

Ключевой критерий выбора — кто владеет настройкой и как часто она меняется. Персональные параметры пользователя (состав колонок отчёта, вариант печатной формы) не должны смешиваться с общесистемными константами вроде префикса организации. А технические параметры интеграций, которые не должны светиться в интерфейсе, логично держать отдельно от пользовательских данных.

Ниже разобраны основные способы хранения настроек, их ограничения и практические рекомендации по выбору. Материал ориентирован на платформу 8.3 и типовые конфигурации на БСП (Библиотека стандартных подсистем), но общие принципы применимы и к самописным решениям.

Системное хранилище настроек: где живут пользовательские параметры

Когда пользователь меняет состав колонок динамического списка, вариант отчёта или настройки формы, платформа автоматически сохраняет эти данные в системное хранилище настроек. Физически это таблицы информационной базы (в клиент-серверном варианте — таблицы СУБД), недоступные для прямого редактирования через конфигуратор.

Разработчику доступны три стандартных хранилища: ХранилищеОбщихНастроек, ХранилищеПользовательскихНастроекОтчетов и ХранилищеНастроекДанныхФорм. Сохранение и загрузка выполняются методами Сохранить() и Загрузить() с указанием ключа объекта, ключа настроек и имени пользователя.

Важная особенность: настройки привязаны к имени пользователя информационной базы. При переименовании пользователя или переносе базы между платформами настройки могут «потеряться» — на самом деле они остаются в хранилище, но под старым именем. Для таких случаев в типовых конфигурациях есть обработка копирования настроек между пользователями.

// Сохранение произвольной настройки
ХранилищеОбщихНастроек.Сохранить("МояПодсистема", "ОсновнойСклад", СкладСсылка);
// Загрузка с значением по умолчанию
Склад = ХранилищеОбщихНастроек.Загрузить("МояПодсистема", "ОсновнойСклад");
Если Склад = Неопределено Тогда
    Склад = Справочники.Склады.НайтиПоНаименованию("Основной");
КонецЕсли;

Константы: единые значения для всей базы

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

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

Практическое правило: константа подходит для параметров, которые меняются редко (раз в месяц и реже) и одинаковы для всей базы. Если настройка требует разреза или истории — нужен регистр сведений.

Регистры сведений: настройки с разрезами и историей

Регистр сведений — универсальный инструмент, когда настройка зависит от измерения: организации, пользователя, контрагента, склада. Периодический регистр дополнительно даёт историю изменений, что критично для учётных параметров вроде курсов валют или учётной политики организации.

Типовые конфигурации активно используют этот подход: «Настройки подключения к сервисам», «Учетная политика организаций», «Настройки обмена». Преимущества очевидны: полноценные права доступа через роли, возможность включения в планы обмена, стандартные механизмы списков и форм.

Недостаток — необходимость проектировать структуру метаданных и формы. Для одного-двух параметров это избыточно, но для набора связанных настроек подсистемы регистр сведений — правильный выбор. Кроме того, через запросы регистр легко читается в отчётах и произвольных алгоритмах.

Реквизиты справочников и документов

Если настройка логически принадлежит объекту — складу, кассе, договору, номенклатурной группе — её место в реквизитах этого объекта. Пример: признак «Ордерный склад» у склада, счёт учёта по умолчанию у договора, вариант округления цен у вида цен.

Такой подход даёт естественный интерфейс редактирования (форма элемента), автоматическое участие в обменах и правах, а также понятную структуру для пользователя. Ошибка — выносить объектные настройки в константы или общие регистры: тогда при добавлении нового склада придётся не забыть завести запись в отдельном месте, что неизбежно приводит к рассинхронизации.

Для наборов параметров, которые повторяются у многих объектов, удобны шаблоны: справочник «Настройки...» с набором реквизитов и ссылка на него в объекте. Так в типовых реализованы, например, настройки ЭДО у контрагентов.

Где хранить пароли и параметры интеграций

Отдельная тема — секреты: пароли к веб-сервисам, токены API, ключи шифрования. Хранить их открытым текстом в константах или регистрах нельзя: любой пользователь с правом чтения (а часто и любой, кто получил выгрузку базы) увидит значения.

В типовых конфигурациях на БСП есть подсистема «Работа в модели сервиса» и механизм безопасного хранения данных — функции ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище() и ОбщегоНазначения.ПрочитатьДанныеИзБезопасногоХранилища(). Данные сохраняются в специальном регистре, доступ к которому закрыт ролями, а в формах вместо значения показываются звёздочки.

Альтернативы: хранение секретов в защищённом хранилище операционной системы, во внешних файлах с ограниченными правами на уровне файловой системы, либо во внешних сервисах управления секретами для крупных внедрений. Для файловой базы на общем сетевом ресурсе безопасное хранилище внутри базы — минимально приемлемый вариант, но помните: файл базы 1Cv8.1CD можно скопировать целиком.

Файлы и внешние хранилища: когда настройки вне базы

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

Типичные варианты: XML- или JSON-файл в каталоге сервера 1С, параметры в реестре Windows для толстого клиента, переменные окружения. Прочитать такой файл из кода можно средствами ЧтениеXML или ЧтениеJSON. Недостаток — отсутствие контроля прав средствами 1С и необходимость документировать расположение файлов для администраторов.

Для клиентских настроек тонкого клиента платформа сама хранит часть параметров в файлах профиля пользователя (каталог %APPDATA%\1C\1cv8), например списки баз и настройки подключения. Эти файлы редактировать вручную не рекомендуется — платформа может перезаписать их при выходе.

Очистка, перенос и обслуживание настроек

Хранилище настроек со временем накапливает «мусор»: настройки удалённых пользователей, старые варианты отчётов, параметры форм переименованных объектов. В типовых конфигурациях есть стандартные инструменты очистки — обработка настроек пользователей в разделе администрирования. Для самописных конфигураций очистку выполняют методами Удалить() соответствующего хранилища.

При переносе настроек между базами учитывайте, что системные хранилища не участвуют в планах обмена. Для переноса пользовательских настроек используют выгрузку через методы хранилища с сериализацией значений или штатные обработки копирования. Константы и регистры сведений переносятся обычными средствами выгрузки данных.

Признак проблемы — жалобы пользователей на «слетевшие» настройки после обновления. Чаще всего причина в изменении ключей объектов метаданных при реструктуризации или в переименовании пользователей. Проверить можно, загрузив настройку программно под старым ключом: если значение вернулось — настройки на месте, сломалась только связка ключей.

Частые вопросы