gifts2017

Механизм контроля заполнения реквизитов

Опубликовал Yuri_V _____ (yur4ik9408) в раздел Программирование - Практика программирования

Механизм позволяет в пользовательском режиме настраивать контролируемые реквизиты, тем самым помогает справиться с невнимательностью пользователей. Не требует снятия с поддержки типовых объектов, внося минимум изменений в конфигурацию. Не привязан ни к конкретным конфигурациям, ни к БСП.

Предисловие

Наверное, на каждом предприятии есть работник, который постоянно забывает/забивает при создании элемента справочника либо документа про один или несколько неважных (по его мнению) реквизитов, но, в это же время они могут быть важными для его руководителя.

В таких случаях есть 2 решения проблемы: 

  1. Руководитель несколько раз наказывает данного человека морально/материально/физически и после этого работник делает выводы, что все же лучше заполнить необходимые поля.
  2. Руководитель обращается к программисту, чтобы тот сделал реквизиты обязательными для заполнения.

Мы рассмотрим второй случай, так как в первом они сами справляются с проблемой, и без нашего участия.
Так вот, приходит к нам заказчик/клиент и говорит: "Мой сотрудник Вася Пупкин вообще обнаглел, никак его не могу научить заполнять Реквизит1 в карточке номенклатуры. Сделайте это поле обязательным для заполнения."

Какие наши действия? Естественно, по зову сердца сразу же лезем в конфигуратор и, если это типовая конфа, снимаем реквизиты с поддержки, выставляем им свойство, или же правим свойства элементов формы, ну или, в крайнем случае, в коде вставляем проверку на заполненность реквизита (есть еще множество способов выполнить проверку, но это уже совсем другая история©).

И мы прекрасно понимаем, что ни один из этих способов не является реальным выходом, так как последующие обновления конфигурации будут усложняться.

Так и какой же выход?!

Сабж

Предлагаю вам своё решение данной проблемы.
Не нужно никакие объекты снимать с поддержки, необходимо добавить несколько новых объектов в конфигурацию.

А именно:

  • 2 роли
  • Общий модуль
  • Подписку на событие
  • Регистр сведений 

После переноса данных объектов в конфигурацию, все уже готово к работе.
Исходный код является открытым, весь механизм можно будет изучить изнутри. Останавливаться на нем особо не будем.
Вкратце, для чего нужны все эти объекты:

  • 2 роли: для пользователя - Чтение настроек из регистра, для администратора - Администрирование регитра 
  • Общий модуль: содержит процедуру (сам механизм) проверки реквизитов
  • Подписка на событие: срабатывает на событии ОбработкаПроверкиЗаполнения
  • Регистр сведений: хранит настройки проверки реквизитов

Настройка

Давайте все же более подробно остановимся на работе с настройками данного механизма, так как это, пожалуй, самая важная его часть.

Сразу обусловимся, что список записей регистра - это набор правил, а каждая отдельная запись - это правило проверки того или иного ревизита.

В файлах лежит архив, внутри которого находится конфигурация (исключительно с необходимыми объектами) и демо-база (включает несколько справочников и документ). На примере демо-базы рассмотрим настройку правил.

Открыв демо-базу и нажав на команду Настройка обязательных полей, мы попадаем в список правил. Представлен он в виде иерархического списка: на верхнем уровне расположен Тип (Справочник/Документ), на следующем уровне сам Объект, и самый нижний уровень - Реквизит (в нашем случае - правило). 

Список правил

 

Нажмем кнопку Создать и посмотрим, как выглядит "карточка" правила:

Создание правила

 

Давайте разберем каждое из полей правила:

  • Проверка активна - признак, указывающий на то, будет ли учитываться конкретное правило при проверке реквизита.
  • Тип - указывает на тип объекта метаданных, для которого создается правило (Справочник/Документ)
  • Объект - в зависимостри от выбранного типа, список справочников или документов
  • Реквизит - список реквизитов выбранного объекта
  • Сообщение - текст, который будет отображаться, если реквизит не пройдет проверку на заполнение
  • Условия - (заполнять не обязательно) дополнительные условия на языке платформы. Выражение должно обращаться в ИСТИНУ или ЛОЖЬ (более подробно рассмотрим далее). 
  • Параметры - при необходимостри передачи параметра в условие, его нужно добавить в таблицу. Таблица состоит из двух колонок: Имя и Значение. Имя всегда предопределено и нет возможности его редактировать. Значение необходимо выбрать из базы.

Также на форме присутствует кнопка Проверить, которая на конкретном объекте выполняет проверку синтаксиса и, собственно, самого правила. Перед проверкой правило записывается.

 

Все правила можно поделить на три вида:

  1. Безусловные
  2. Условные
  3. Параметрические
Безусловное

Для данного вида правила характерно то, что поле Условие не заполнено. Тем самым это указывает на то, что условие выполняется всегда.

Безусловное правило

Условное

Данное правило должно содержать условие на встроенном языке. Есть возможность обращаться к функциям глобального контекста и общим модулям, у которых возвращаемое значение типа Булево. Так же есть возможность обращаться непосредственно к Объекту, имя у него в данном контексте - Источник.

Условное правило

Параметрическое

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

Параметрическое правило

Для условий также можно использовать предопределённые данные, причем их можно передавать двумя способами: и через параметр, и напрямую (например, Справочники.Валюты.ОсновнаяВалюта).

Собственно, на этом всё. Ваши предложения и пожелания пишите в комментарии.


ВНИМАНИЕ. Если будете внедрять данный функционал, не забудьте назначить роли пользователям и администраторам.

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
МеханизмПроверкиРеквизитов.zip
.zip 53,58Kb
24.10.15
21
.zip 1.0.1 53,58Kb 21 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Иван Белокаменцев (1c-intelligence) 26.10.15 10:44
Прикольно, но проверка заполненности - лишь малая часть проверок, которые надо делать. Правда, такое ограничение решаемых задач позволяет использовать обработку проверки заполнения, а не перед записью.
Как вариант с большим функционалом - http://infostart.ru/public/290094/.
2. Алексей Ларин (roofless) 26.10.15 12:58
Не нужно никакие объекты снимать с поддержки, необходимо добавить несколько новых объектов в конфигурацию.

немного лукавите)
3. Yuri_V _____ (yur4ik9408) 26.10.15 13:01
4. Алексей Ларин (roofless) 26.10.15 16:44
(3) yur4ik9408, полностью снимать с поддержки не нужно, но придется поставить "редактируется с сохранением поддержки"
5. Yuri_V _____ (yur4ik9408) 26.10.15 16:49
(4) roofless, только корень конфигурации. другие объекты это не затронет.
6. Алексей Драчков (Bassgood) 26.10.15 23:31
(0) Не вникал в публикацию, поэтому могу ошибиться, но на ИС есть публикация (или несколько), в которой более широкий аналогичный функционал реализован при помощи механизма расширений конфигурации, поэтому для конфигураций, работающих на платформе 8.3.6 будет более актуально использовать именно функционал проверок на расширениях.
Anubis23; +1 Ответить
7. Константин Перминов (Perk0n) 28.10.15 13:05
Прошу прощения заранее, но можно предложить такой способ.. для облегчения обновления.
Создаем подсистему в виде иерархии конфигурации и в веточках создаем реквизиты на которые "Проверка заполнения" установлена в "Выдавать ошибку". И мы всегда знаем чтО мы изменили.
Ну и что, что геморроя столько же.. зато способ.
8. Александр Савостин (savostin.alex) 28.10.15 13:50
А не нужно ли это в БСП добавить?
9. Алексей Драчков (Bassgood) 03.11.15 16:15
(8) savostin.alex, этот вопрос лучше адресовать разработчикам БСП :)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа