Предисловие
Наверное, на каждом предприятии есть работник, который постоянно забывает/забивает при создании элемента справочника либо документа про один или несколько неважных (по его мнению) реквизитов, но, в это же время они могут быть важными для его руководителя.
В таких случаях есть 2 решения проблемы:
- Руководитель несколько раз наказывает данного человека морально/материально/физически и после этого работник делает выводы, что все же лучше заполнить необходимые поля.
- Руководитель обращается к программисту, чтобы тот сделал реквизиты обязательными для заполнения.
Мы рассмотрим второй случай, так как в первом они сами справляются с проблемой, и без нашего участия.
Так вот, приходит к нам заказчик/клиент и говорит: "Мой сотрудник Вася Пупкин вообще обнаглел, никак его не могу научить заполнять Реквизит1 в карточке номенклатуры. Сделайте это поле обязательным для заполнения."
Какие наши действия? Естественно, по зову сердца сразу же лезем в конфигуратор и, если это типовая конфа, снимаем реквизиты с поддержки, выставляем им свойство, или же правим свойства элементов формы, ну или, в крайнем случае, в коде вставляем проверку на заполненность реквизита (есть еще множество способов выполнить проверку, но это уже совсем другая история©).
И мы прекрасно понимаем, что ни один из этих способов не является реальным выходом, так как последующие обновления конфигурации будут усложняться.
Так и какой же выход?!
Сабж
Предлагаю вам своё решение данной проблемы.
Не нужно никакие объекты снимать с поддержки, необходимо добавить несколько новых объектов в конфигурацию.
А именно:
- 2 роли
- Общий модуль
- Подписку на событие
- Регистр сведений
После переноса данных объектов в конфигурацию, все уже готово к работе.
Исходный код является открытым, весь механизм можно будет изучить изнутри. Останавливаться на нем особо не будем.
Вкратце, для чего нужны все эти объекты:
- 2 роли: для пользователя - Чтение настроек из регистра, для администратора - Администрирование регитра
- Общий модуль: содержит процедуру (сам механизм) проверки реквизитов
- Подписка на событие: срабатывает на событии ОбработкаПроверкиЗаполнения
- Регистр сведений: хранит настройки проверки реквизитов
Настройка
Давайте все же более подробно остановимся на работе с настройками данного механизма, так как это, пожалуй, самая важная его часть.
Сразу обусловимся, что список записей регистра - это набор правил, а каждая отдельная запись - это правило проверки того или иного ревизита.
В файлах лежит архив, внутри которого находится конфигурация (исключительно с необходимыми объектами) и демо-база (включает несколько справочников и документ). На примере демо-базы рассмотрим настройку правил.
Открыв демо-базу и нажав на команду Настройка обязательных полей, мы попадаем в список правил. Представлен он в виде иерархического списка: на верхнем уровне расположен Тип (Справочник/Документ), на следующем уровне сам Объект, и самый нижний уровень - Реквизит (в нашем случае - правило).
Нажмем кнопку Создать и посмотрим, как выглядит "карточка" правила:
Давайте разберем каждое из полей правила:
- Проверка активна - признак, указывающий на то, будет ли учитываться конкретное правило при проверке реквизита.
- Тип - указывает на тип объекта метаданных, для которого создается правило (Справочник/Документ)
- Объект - в зависимостри от выбранного типа, список справочников или документов
- Реквизит - список реквизитов выбранного объекта
- Сообщение - текст, который будет отображаться, если реквизит не пройдет проверку на заполнение
- Условия - (заполнять не обязательно) дополнительные условия на языке платформы. Выражение должно обращаться в ИСТИНУ или ЛОЖЬ (более подробно рассмотрим далее).
- Параметры - при необходимостри передачи параметра в условие, его нужно добавить в таблицу. Таблица состоит из двух колонок: Имя и Значение. Имя всегда предопределено и нет возможности его редактировать. Значение необходимо выбрать из базы.
Также на форме присутствует кнопка Проверить, которая на конкретном объекте выполняет проверку синтаксиса и, собственно, самого правила. Перед проверкой правило записывается.
Все правила можно поделить на три вида:
- Безусловные
- Условные
- Параметрические
Безусловное
Для данного вида правила характерно то, что поле Условие не заполнено. Тем самым это указывает на то, что условие выполняется всегда.
Условное
Данное правило должно содержать условие на встроенном языке. Есть возможность обращаться к функциям глобального контекста и общим модулям, у которых возвращаемое значение типа Булево. Так же есть возможность обращаться непосредственно к Объекту, имя у него в данном контексте - Источник.
Параметрическое
В этом виде правил в условиях используются параметры. Значение параметров указываются в таблице, имена присваиваются автоматически программой. Для использования параметра в условии, необходимо указать его имя.
Для условий также можно использовать предопределённые данные, причем их можно передавать двумя способами: и через параметр, и напрямую (например, Справочники.Валюты.ОсновнаяВалюта).
Собственно, на этом всё. Ваши предложения и пожелания пишите в комментарии.
ВНИМАНИЕ. Если будете внедрять данный функционал, не забудьте назначить роли пользователям и администраторам.
Вступайте в нашу телеграмм-группу Инфостарт