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