Как реализована дата запрета редактирования в 1С и как обойти ограничение для конкретного реквизита?

← На главную

Приветствуем вас, коллеги! Сегодня мы детально и всесторонне разберем одну из самых популярных и важных тем в администрировании и разработке на платформе 1С:Предприятие — механизм даты запрета изменения данных. Этот функционал ежедневно спасает учетные данные компаний от случайных корректировок в уже закрытых и сданных налоговых периодах. Но как часто перед нами встает задача: «Период закрыт, но нам жизненно необходимо изменить один маленький реквизит в документе без перепроведения всей цепочки»? Выясним, как это сделать правильно, красиво и без нарушения целостности базы данных.

В рамках этой статьи мы разберем по шагам архитектуру подсистемы в современных конфигурациях, заглянем «под капот» механизма БСП (Библиотеки стандартных подсистем), сравним его со старыми решениями (например, в УПП 1.3) и рассмотрим безопасные методики обхода запрета как для пользователей, так и для разработчиков.

Архитектура подсистемы: платформа или конфигурация?

Начнем с базового вопроса, который часто вызывает путаницу у начинающих специалистов: реализована ли дата запрета редактирования на уровне технологической платформы 1С или же это чисто прикладное решение? Как справедливо отметили участники обсуждения, данный механизм является функционалом конфигурации (приложения), а не жестко зашитым свойством платформы.

Платформа 1С:Предприятие предоставляет разработчикам богатый инструментарий (объектную модель, подписки на события, параметры сеанса, регистры), на базе которого в конфигурациях создается логика проверки. В современных типовых решениях (таких как 1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей, 1С:Бухгалтерия) за это отвечает стандартная подсистема БСП «Даты запрета изменения». В старых конфигурациях (УПП, УТ 10.3, КА 1.1) использовался собственный аналогичный код, но общий принцип работы остался схожим.

Проанализируем ситуацию и посмотрим, из каких кирпичиков строится этот механизм в современных конфигурациях на БСП.

Как устроена дата запрета в БСП «под капотом»

Давайте заглянем внутрь подсистемы БСП, чтобы понять, как система мгновенно понимает, что документ редактировать нельзя:

Хранение настроек (Регистр сведений): Все правила, исключения, даты для конкретных пользователей, групп или разделов учета записываются в регистр сведений ДатыЗапретаИзменения. Это таблица, к которой система обращается для вычисления актуальной границы запрета.
Оптимизация производительности (Параметры сеанса): Если бы система при каждом открытии формы или записи объекта делала прямой запрос к таблице регистра, производительность базы данных сильно бы просела. Чтобы избежать этого, БСП выполняет кэширование. При начале работы системы или при изменении настроек даты запрета для текущего пользователя рассчитываются актуальные границы и записываются в параметр сеанса ПараметрыСеанса.ГраницыЗапретаИзмененияДанных. Обращение к параметрам сеанса происходит мгновенно в оперативной памяти сервера.
Проверка при открытии формы: Когда пользователь открывает документ, в модуле его формы в процедуре ПриЧтенииНаСервере срабатывает вызов метода ДатыЗапретаИзменения.ОбъектПриЧтенииНаСервере(ЭтотОбъект, ТекущийОбъект). Если дата документа попадает в закрытый период, БСП программно переводит всю форму в режим ТолькоПросмотр = Истина.
Защита на уровне СУБД (Подписки на события): Блокировка формы — это лишь визуальная защита. Если злоумышленник или внешняя обработка попытается изменить документ программно, сработает второй эшелон защиты. В системе зарегистрированы глобальные подписки на события, например, ПроверитьДатуЗапретаИзмененияПередЗаписьюДокумента. При попытке записи объекта в закрытом периоде транзакция прерывается, и система выдает ошибку.

Можно ли менять конкретный реквизит при установленной дате запрета?

В сообщениях форума (4) и (6) прозвучал категоричный ответ: «Нет, нельзя». Действительно, стандартная логика формы полностью блокирует объект. Но реальный бизнес требует гибкости. Например, нам нужно разрешить менеджеру менять комментарий, статус отправки оригинала или трек-номер доставки даже в закрытом периоде. Рассмотрим подробнее, какими методами можно решить эту задачу архитектурно правильно.

Способ 1. Использование механизма дополнительных сведений (БСП)

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

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

Способ 2. Вынос реквизитов в независимые регистры сведений (Собственная разработка)

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

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

Посмотрим на пример кода для записи такого значения:


НаборЗаписей = РегистрыСведений.СтатусыДокументовДляЛогистики.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ДокументСсылка.Установить(ТекущийДокумент);

НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.ДокументСсылка = ТекущийДокумент;
НоваяЗапись.СтатусДоставки = Элементы.СтатусДоставки.Значение;

НаборЗаписей.Записать(Истина);

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

Способ 3. Штатное редактирование комментариев в современных версиях БСП

Знаете ли вы, что в современных версиях типовых конфигураций 1С (начиная с «1С:Бухгалтерия 8» версии 3.0.170 и аналогичных версий ERP/КА) разработчики добавили штатную возможность редактировать комментарии в закрытых периодах? Для этого администратору достаточно зайти в настройки дат запрета изменения данных и установить соответствующий флаг, разрешающий изменение комментариев без перепроведения документов. Механизм БСП сам позаботится об обходе защиты для этого реквизита.

Программный обход проверки дат запрета (Для разработчиков)

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

В сообщении (9) прозвучал совет использовать параметр ОбменДанными.Загрузка = Истина. Внимание: это крайне опасный метод! Установка режима загрузки отключает абсолютно всю бизнес-логику объекта, включая расчеты сумм, проверки заполнения, связанные транзакции и другие подписки на события. Это может привести к тяжелым последствиям для целостности базы данных.

Как сделать это правильно в рамках БСП? Разберем безопасный программный способ:


// Шаг 1. Отключаем проверку дат запрета изменений глобально для текущего потока кода
ДатыЗапретаИзменения.ОтключитьПроверкуДатЗапрета(Истина);

Попытка
    // Шаг 2. Выполняем необходимые действия с документами
    ДокументОбъект = ВыбраннаяСсылка.ПолучитьОбъект();
    ДокументОбъект.Комментарий = ДокументОбъект.Комментарий + " [Проверено аудитом]";
    
    // Записываем документ в режиме обычной записи, бизнес-логика отработает штатно, но дата запрета будет проигнорирована
    ДокументОбъект.Записать(РежимЗаписиДокумента.Запись);
Исключение
    // Шаг 3. Обязательно возвращаем проверку дат запрета назад в случае ошибки!
    ДатыЗапретаИзменения.ОтключитьПроверкуДатЗапрета(Ложь);
    ВызватьИсключение КраткоеПредставлениеОшибки(ИнформацияОбОшибке());
КонецПопытки;

// Шаг 4. Обязательно возвращаем проверку дат запрета назад при успешном завершении операции
ДатыЗапретаИзменения.ОтключитьПроверкуДатЗапрета(Ложь);

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

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

Важное различие: «Запрет изменения дат» vs «Запрет редактирования реквизитов»

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

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

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