В процессе разработки на платформе 1С:Предприятие часто возникают задачи, связанные с обеспечением неизменности данных после их ввода. Типичный пример — регистрация результатов метрологических испытаний, фиксация температурных режимов или протоколирование событий. В таких случаях бизнес-логика требует: создавать новые записи можно, а изменять уже существующие или удалять их — категорически запрещено. Рассмотрим подробнее, как реализовать этот механизм различными способами, от простых манипуляций с формами до использования низкоуровневых механизмов платформы.
Самый очевидный способ — заблокировать поля ввода для пользователя на уровне интерфейса. Проанализируем ситуацию: когда пользователь открывает форму существующей записи, мы должны сделать все элементы управления недоступными для редактирования. Выясним причину, по которой простого перебора элементов может быть недостаточно, и как сделать это правильно.
Автор темы предложил использовать дополнительный реквизит Редактирование. Однако в системе 1С уже есть механизмы, позволяющие определить, является ли запись новой. Разберем пример реализации через стандартное свойство формы ТолькоПросмотр. Это более лаконичный и надежный метод, так как он автоматически отключает не только поля ввода, но и стандартные команды записи и удаления на форме.
В модуле формы записи регистра рекомендуется использовать обработчик ПриЧтенииНаСервере. Посмотрим на пример кода:
&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
// Если ключевые поля (измерения) заполнены, значит запись уже существует в базе
// Проверим заполненность основного измерения, например "Период" или "Отдел"
Если ЗначениеЗаполнено(Запись.Период) И ЗначениеЗаполнено(Запись.Отдел) Тогда
ЭтаФорма.ТолькоПросмотр = Истина;
КонецЕсли;
КонецПроцедуры
Использование свойства ТолькоПросмотр предпочтительнее, чем ручное управление свойством Доступность каждого элемента (как Элементы.Температура.Доступность = Ложь), поскольку оно исключает человеческий фактор при добавлении новых реквизитов в регистр в будущем.
Интерфейсные ограничения легко обойти с помощью групповых обработок или внешних соединений. Для обеспечения стопроцентной гарантии неизменности данных необходимо внедрить проверку на уровне сервера приложений. Рассмотрим вариант использования Подписки на событие или модуля набора записей регистра.
Суть метода заключается в том, чтобы перед каждой попыткой записи в базу проверять, существуют ли уже данные с такими измерениями. Если данные найдены — мы прерываем операцию. Проанализируем пример кода для обработки ПередЗаписью:
Процедура РегистрСведенийПередЗаписью(Источник, Отказ, Замещение) Экспорт
// Важно проверять флаг ОбменДанными.Загрузка, чтобы не блокировать перенос данных
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Создаем набор записей для проверки существования данных в БД
НЗ = РегистрыСведений.УсловияПоверки.СоздатьНаборЗаписей();
// Переносим отбор из текущего источника
Для каждого СтрокаОтбора Из Источник.Отбор Цикл
Если СтрокаОтбора.Использование Тогда
НЗ.Отбор[СтрокаОтбора.Имя].Установить(СтрокаОтбора.Значение);
КонецЕсли;
КонецЦикла;
НЗ.Прочитать();
// Если в базе уже есть записи по этому отбору, а мы пытаемся их перезаписать
Если НЗ.Количество() > 0 Тогда
// Разрешаем запись только в том случае, если это реально НОВАЯ запись
// В независимых регистрах с Замещение = Истина запись всегда считается изменением,
// если ключ записи уже существует.
Сообщить("Редактирование существующих записей запрещено локальной политикой безопасности.");
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Важный нюанс: В независимых регистрах сведений при записи набора с включенным флагом Замещение старые данные удаляются автоматически. Поэтому проверка должна происходить до того, как физически сработает механизм замещения.
Самый "чистый" с точки зрения архитектуры платформы метод — использование механизма Row Level Security (RLS). В настройках роли для конкретного регистра сведений можно разделить права на "Добавление" и "Изменение". Рассмотрим, как это настроить по шагам:
РегистрСведений.ГДЕ ЛОЖЬ. Это заблокирует любую попытку модификации уже существующей строки.Этот метод хорош тем, что он не требует написания сложного программного кода и работает на уровне СУБД, что обеспечивает максимальную производительность системы.
Если бизнес-процесс позволяет, можно изменить структуру хранения данных. Вместо независимого регистра сведений используйте регистр, подчиненный регистратору (документу). В этом случае:
Это решение идеально подходит для метрологических служб (как в примере автора темы), так как данные о температуре, давлении и влажности обычно привязаны к конкретному событию поверки, которое логично оформлять документом.
Если ваша конфигурация основана на Библиотеке Стандартных Подсистем (БСП), разберем использование механизма ДатыЗапретаИзменения. Вы можете включить ваш регистр в состав объектов, проверяемых при записи. Настроив дату запрета "на текущий день", вы добьетесь того, что записи прошлых периодов нельзя будет изменить. Для реализации запрета "секунда в секунду" можно использовать программную установку даты запрета или расширение логики проверки.
Выбор конкретного метода зависит от требований к надежности и трудозатратам:
Проанализировав все варианты, мы видим, что наиболее сбалансированным решением для независимого регистра является сочетание ТолькоПросмотр = Истина в форме (для удобства пользователя) и проверки в ПередЗаписью в модуле набора записей (для обеспечения целостности данных).