Что нельзя хранить в константе 1С

Константа в 1С — это объект метаданных для хранения единственного значения, которое меняется редко: наименование организации, ставка НДС по умолчанию, признак ведения учёта по складам. Однако разработчики нередко используют константы не по назначению — как универсальное хранилище для всего подряд. Это приводит к ошибкам блокировок, потере данных, проблемам с обменом и невозможности масштабирования решения.

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

Как устроены константы и почему это важно

Все константы конфигурации размещаются в единой таблице СУБД с одной строкой. Когда транзакция записывает значение любой константы, блокируется эта строка целиком — фактически блокируются все константы сразу. Если константу записывают часто (например, счётчик обращений при каждом документе), возникают конкурентные блокировки и ошибки «Конфликт блокировок при выполнении транзакции».

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

Пароли, токены и ключи доступа

Хранение паролей от внешних сервисов, API-ключей и токенов в константах — одна из самых опасных ошибок. Константа доступна для чтения любому пользователю с правами на неё, отображается в форме настроек, попадает в выгрузки конфигурации и копии базы, которые расходятся по разработчикам и тестовым стендам. Значение хранится в открытом виде в таблице СУБД — администратор базы увидит его прямым запросом.

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

Файлы, изображения и большие тексты

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

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

Списки, таблицы и множественные значения

По определению константа хранит одно значение. Попытки обойти это — сериализация списка в XML или JSON в строковой константе, хранение таблицы значений в ХранилищеЗначения — создают неподдерживаемую конструкцию. Такие данные нельзя нормально редактировать пользователю, нельзя использовать в запросах и отчётах, нельзя контролировать ссылки на удаляемые объекты.

Если значений несколько, нужен другой объект:

• перечень простых строковых настроек — регистр сведений с измерением «Настройка» и полем «Значение»;
• список объектов (склады, кассы, шаблоны) — справочник;
• наборы параметров, различающиеся по организациям или пользователям, — регистр сведений с соответствующим измерением.

Сравнение вариантов хранения

Константа

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

Регистр сведений

Множество значений, разрезы по измерениям, периодическая история. Требует продуманного состава измерений.

Справочник

Список объектов с реквизитами, иерархией и ссылочной целостностью. Избыточен для простых флагов.

Безопасное хранилище

Пароли и ключи в зашифрованном виде. Только для секретов, не для произвольных данных.

Часто изменяемые данные и счётчики

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

Для оперативных счётчиков и статусов подходят регистры сведений, а для нумерации — штатные механизмы нумерации документов. Дату последнего обмена в типовых механизмах синхронизации хранят в регистрах сведений узлов обмена, а не в константах.

Данные с историей и периодические значения

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

Признак простой: если к данным когда-либо понадобится вопрос «а какое значение было на дату Х», это не константа, а периодический регистр сведений. В типовых конфигурациях именно так устроены курсы валют, ставки, учётная политика организаций.

Значения, различающиеся по пользователям, организациям и базам

Константа одна на всю информационную базу. Если в базе несколько организаций и у каждой своё значение настройки — константа не подходит: понадобится регистр сведений с измерением «Организация». То же относится к персональным настройкам пользователей — для них в БСП существует отдельный механизм пользовательских настроек.

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

Маршрут решения

Как выбрать место хранения

Значение одно, меняется редко, не секретное и без историиОставьте константу — это её законный сценарий

Значений несколько или нужны разрезы по организациям и пользователямСоздайте регистр сведений с нужными измерениями

Нужна история значения по датамИспользуйте периодический регистр сведений

Это пароль, токен или ключПеренесите в безопасное хранилище или внешнюю конфигурацию

Это файл или большой текстИспользуйте присоединённые файлы, макеты или тома хранения

Как проверить конфигурацию на злоупотребление константами

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

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

1. 1
   Определите, какие данные реально хранятся в константе и кто их читает
2. 2
   Подберите целевой объект: регистр сведений, справочник, безопасное хранилище
3. 3
   Напишите обработку переноса текущего значения в новый объект
4. 4
   Замените все обращения к константе в коде на чтение из нового объекта
5. 5
   Проверьте обмены, отчёты и права доступа к новому объекту
6. 6
   Удалите константу после тестирования на копии базы

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

Можно ли хранить в константе строку неограниченной длины?

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

Что произойдёт, если два пользователя одновременно изменят разные константы?

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

Подходит ли константа для хранения даты запрета редактирования?

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

Можно ли узнать, кто и когда изменил константу?

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

Чем плохо хранение внешней обработки в константе типа ХранилищеЗначения?

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

Нужно ли удалять неиспользуемые константы из конфигурации?

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