Как применить дату запрета изменения данных без перезапуска программы 1С?

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

Почему дата запрета не обновляется у других пользователей сразу?

Для понимания проблемы проанализируем, как в платформе 1С устроена работа с границами запрета редактирования. В типовых конфигурациях (в частности, в 1С:Бухгалтерии предприятия редакции 2.0) даты запрета считываются из информационной базы и помещаются в параметры сеанса при старте программы.

Здесь вступают в силу ключевые архитектурные особенности платформы:

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

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

Вариант 1. Штатное обновление системной информации через интерфейс

В конфигурациях на обычных формах предусмотрено штатное действие для очистки кэша и повторного чтения системных настроек без закрытия базы.

Пользователю достаточно выполнить команду меню:

Сервис → Обновить системную информацию

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

Вариант 2. Контроль версии настроек через константу («ленивая» синхронизация)

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

Разберем логику реализации по шагам:

1. Создаем новую константу (например, ВерсияНастроекДатыЗапрета с типом Число или Дата) и аналогичный параметр сеанса.
2. В обработчике записи регистра сведений границ запрета увеличиваем значение константы на единицу (или фиксируем текущее время).
3. В подписке на событие ПередЗаписью для документов или в общем модуле контроля даты запрета проверяем соответствие версии в сеансе и константе.

Посмотрим на пример кода серверной функции проверки:

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

При таком подходе сеанс пользователя вообще не расходует ресурсы СУБД во время простоя или чтения отчетов. Но как только бухгалтер пытается нажать кнопку Записать или Провести, система сверяет версию, перезаполняет границы в параметре сеанса и блокирует проведение задним числом.

Вариант 3. Использование обработчика ожидания

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

Схема работы выглядит следующим образом:

1. При начале работы системы подключаем клиентский обработчик с интервалом, например, 300 секунд: ПодключитьОбработчикОжидания("ПроверитьАктуальностьДатыЗапрета", 300);
2. В процедуре обработчика выполняем быстрый контекстный серверный вызов: считываем константу изменения настроек и сравниваем ее со значением в сеансе.
3. Если обнаружено расхождение, вызываем процедуру пересчета границ запрета для текущего пользователя.

Важно: не ставьте слишком малый интервал опроса (например, 1–5 секунд), чтобы не создавать избыточных сетевых пакетов и блокировок в высоконагруженных многопользовательских базах.

Вариант 4. Проверка даты прямым запросом к регистру сведений

Еще один путь доработки — отказ от хранения даты запрета в объекте ПараметрыСеанса в пользу точечного запроса к регистру сведений в момент проведения документа.

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