Как программно добавить новый раздел в механизм даты запрета изменения данных в 1С:ERP

Программист 1С v8.3 (Управляемые формы) 1С:ERP Управление предприятием
← На главную

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

Анализ структуры механизма дат запрета

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

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

Шаг 1: Определение нового раздела в коде

Для того чтобы система «узнала» о существовании нового раздела, нам необходимо внести изменения в общий модуль ДатыЗапретаИзмененияПереопределяемый. Найдем в нем процедуру ПриЗаполненииРазделовДатыЗапретаИзменения. Именно здесь мы регистрируем новые разделы.

Рассмотрим пример добавления раздела «Снабжение и закупки». Важным моментом является использование уникального идентификатора (GUID). Рассмотрим программный код:


Процедура ПриЗаполненииРазделовДатыЗапретаИзменения(Разделы) Экспорт

    Раздел = Разделы.Добавить();
    Раздел.Имя = "СнабжениеИЗакупки";
    Раздел.Заголовок = НСтр("ru = 'Снабжение и закупки'");
    // Использование фиксированного GUID критично для сохранения настроек при обновлениях
    Раздел.Идентификатор = Новый УникальныйИдентификатор("c7546388-0906-4c52-b4fb-e6598523407e");

КонецПроцедуры

Важное замечание: Идентификатор (GUID) должен быть постоянным. Если вы будете генерировать его динамически функцией Новый УникальныйИдентификатор() без параметров, то при каждом перезапуске или обновлении системы настройки дат запрета для этого раздела будут обнуляться, так как система не сможет сопоставить сохраненные данные в регистре с новым разделом.

Шаг 2: Привязка объектов метаданных к разделу

После того как мы создали «заголовок» раздела, нам нужно указать системе, какие именно документы, справочники или регистры будут к нему относиться. Если объект не привязан к конкретному разделу, на него будет действовать только «Общая дата» (если она установлена). Привязка осуществляется в процедуре ПриЗаполненииОбъектовДатыЗапретаИзменения того же модуля.

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


Процедура ПриЗаполненииОбъектовДатыЗапретаИзменения(Объекты) Экспорт

    Объект = Объекты.Добавить();
    Объект.Объект = Метаданные.Документы.ПриобретениеТоваровУслуг;
    Объект.Раздел = "СнабжениеИЗакупки";

    Объект = Объекты.Добавить();
    Объект.Объект = Метаданные.Документы.ЗаказПоставщику;
    Объект.Раздел = "СнабжениеИЗакупки";

КонецПроцедуры

Здесь поле Объект.Раздел должно строго соответствовать значению Раздел.Имя, которое мы указали на предыдущем шаге.

Шаг 3: Настройка связи с Организациями (если необходимо)

В 1С:ERP даты запрета часто устанавливаются не просто на раздел, а в разрезе конкретных организаций. Чтобы система понимала, по какому реквизиту документа проверять запрет, необходимо прописать логику в процедуре ПриОпределенииИсточниковДанныхДатыЗапретаИзменения.

Выясним, как указать системе источник данных для проверки:


Процедура ПриОпределенииИсточниковДанныхДатыЗапретаИзменения(ИсточникиДанных) Экспорт

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

КонецПроцедуры

Шаг 4: Работа с параметрами сеанса и кэшем

Одной из проблем, с которой сталкиваются разработчики (как было отмечено в обсуждении), является то, что изменения в коде не отображаются на форме сразу. Это происходит из-за кэширования метаданных подсистемы ДатыЗапретаИзменения в параметрах сеанса.

Параметр сеанса ДействующиеДатыЗапретаИзменения содержит фиксированную структуру. Мы не можем и не должны записывать данные в него напрямую. Чтобы обновить настройки, рассмотрим следующие действия:

  1. Обновление конфигурации: После внесения изменений в код обязательно выполните сохранение и обновление конфигурации базы данных.
  2. Перезапуск сеанса: Параметры сеанса инициализируются при входе пользователя. Перезапустите клиентское приложение.
  3. Обновление через обработку: В некоторых случаях требуется запустить процедуру обновления вспомогательных данных БСП. Это можно сделать через консоль кода или специальную обработку, вызвав метод ДатыЗапретаИзменения.ОбновитьВсеДатыЗапрета().

Типичные ошибки при реализации

Проанализируем основные сложности, которые могут возникнуть:

1. Ошибка поиска раздела: Если вы добавили документ в Объекты, но не зарегистрировали Раздел, или ошиблись в написании имени раздела (регистр имеет значение), система выдаст ошибку при открытии формы настроек или при попытке записи документа.

2. Игнорирование GUID: Как уже упоминалось, если поле Идентификатор заполнено некорректно или меняется, вы потеряете связь с уже введенными пользователями датами в регистре сведений ДатыЗапретаИзменения.

3. Отсутствие прав: Убедитесь, что у пользователя, выполняющего настройку, достаточно прав на изменение регистра сведений ДатыЗапретаИзменения, иначе нижняя таблица может быть доступна только для чтения.

Используя данный подход, мы получаем гибкий инструмент контроля данных, позволяющий разграничить ответственность между различными подразделениями компании внутри единой базы 1С:ERP.

← На главную