В стандартных конфигурациях 1С механизм даты запрета изменений работает радикально: если дата документа попадает в закрытый период, объект полностью блокируется для редактирования. Однако в реальной практике часто возникают задачи, когда необходимо оставить возможность редактировать отдельные поля (например, «Комментарий», «Статус доставки» или «Ответственный»), не открывая при этом доступ к финансово значимым реквизитам. Рассмотрим, какими способами можно реализовать такой функционал.
Самый очевидный способ — это визуальное ограничение прав пользователя непосредственно в интерфейсе. Мы проанализируем состояние объекта при открытии и программно установим признак «Только просмотр» для конкретных полей.
Разберем, как это реализовать в процедуре ПриСозданииНаСервере модуля формы. Нам необходимо проверить, попадает ли дата документа в запрещенный период, и если да — заблокировать все элементы, кроме разрешенных.
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Если Объект.Дата <= ПараметрыСеанса.ДатаЗапретаИзменения Тогда
// Проходим по всем элементам формы
Для Каждого Элемент Из ЭтаФорма.Элементы Цикл
// Список разрешенных реквизитов
Если Элемент.Имя = "Комментарий" Или Элемент.Имя = "ГруппаСтатус" Тогда
Элемент.ТолькоПросмотр = Ложь;
Иначе
Попытка
Элемент.ТолькоПросмотр = Истина;
Исключение
// Для элементов, не имеющих свойства ТолькоПросмотр
КонецПопытки;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Важный нюанс: управление только на уровне формы не является надежной защитой. Опытный пользователь может изменить данные через обработку «Групповое изменение реквизитов» или программно. Поэтому этот метод всегда должен дополняться серверной проверкой.
Чтобы гарантировать сохранность данных, необходимо внедрить проверку на уровне модуля объекта или, что более правильно с точки зрения чистоты архитектуры, через подписку на событие ПередЗаписью. Это позволит нам контролировать изменения вне зависимости от того, откуда они пришли — из формы или через обмен данными.
Проанализируем алгоритм проверки: мы должны сравнить текущие значения реквизитов с теми, что уже записаны в базе данных.
Процедура ПроверитьИзмененияПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если Источник.Дата <= ПолучитьДатуЗапрета() Тогда
// Получаем старые данные из базы
СтарыеДанные = Источник.Ссылка.ПолучитьОбъект();
// Список запрещенных к изменению реквизитов
ЗапрещенныеРеквизиты = "СуммаДокумента, Контрагент, Организация, Склад";
Для Каждого Реквизит Из СтрРазделить(ЗапрещенныеРеквизиты, ",") Цикл
ИмяРеквизита = СокрЛП(Реквизит);
Если Источник[ИмяРеквизита] <> СтарыеДанные[ИмяРеквизита] Тогда
Сообщить("Нельзя изменять реквизит " + ИмяРеквизита + " в закрытом периоде!");
Отказ = Истина;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Этот подход позволяет гибко настраивать список "неприкосновенных" полей, сохраняя возможность редактирования вспомогательной информации.
Если ваша конфигурация построена на БСП, в ней уже есть мощный механизм даты запрета. Вместо того чтобы писать свою систему с нуля, мы можем интегрироваться в типовую. В БСП предусмотрена возможность программно отключить проверку даты запрета для конкретной записи объекта.
Для этого в модуле объекта (в обработчике ПередЗаписью) используется структура ДополнительныеСвойства. Если мы определили, что изменены только "безобидные" поля, мы можем подать сигнал системе контроля:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ЭтоНовый() Тогда
Возврат;
КонецЕсли;
// Проверяем, были ли изменены только разрешенные поля
Если ТолькоРазрешенныеИзменения() Тогда
// Устанавливаем свойство, которое считывает типовой механизм даты запрета БСП
Источник.ДополнительныеСвойства.Вставить("ПроверитьДатуЗапретаИзменения", Ложь);
КонецЕсли;
КонецПроцедуры
Внимание: При использовании этого метода крайне важно убедиться, что изменение этих реквизитов не влияет на проведение документа. Если реквизит используется в модуле проведения, то после его изменения данные в регистрах могут стать неактуальными, что приведет к расхождениям в отчетах.
Рассмотрим еще один специфический метод: автоматическое восстановление запрещенных данных. Суть заключается в том, что мы позволяем пользователю менять любые поля на форме, но в момент записи принудительно заменяем значения «запрещенных» полей на те, что хранятся в базе (в Ссылка).
Хотя этот метод технически прост, он имеет существенный минус — плохой UX (пользовательский опыт). Пользователь может потратить время на заполнение полей, нажать «Записать», программа не выдаст ошибок, но данные фактически не сохранятся. Поэтому, если вы выбираете этот путь, обязательно выводите предупреждение пользователю.
Разберем основные опасности, с которыми можно столкнуться при реализации частичного запрета:
Источник.ОбменДанными.Загрузка = Истина или блокировать запись движений через Движения.Записывать = Ложь.Таким образом, наиболее правильным и современным подходом является сочетание визуального ограничения на форме (для удобства пользователя) и жесткой проверки в подписке на событие ПередЗаписью с использованием механизмов БСП для корректного обхода системных блокировок.