Правила проверки

Правила проверки (edit checks) — это автоматический контроль качества данных прямо в момент ввода. Они ловят пропущенные обязательные поля, значения вне диапазона и логические несоответствия между полями и формами. Правила — часть версии дизайна: они создаются и правятся в блоке Проверки вкладки Логика конструктора CRF (а при переносе дизайна между системами приезжают вместе с импортом JSON). Правило принадлежит открытой форме и правится на месте — готовую проверку можно изменить, не удаляя и не создавая заново.

0:000:00

Проверки в конструкторе: «запрос» принимает значение, «блок» отклоняет невозможное.

Правила бывают двух происхождений: системные (их система создаёт сама из свойств полей) и межполевые / межформенные (их пишете вы).

Системные проверки

Системные проверки платформа порождает автоматически из того, что вы уже задали в свойствах полей:

поле отмечено Обязательное → проверка «поле не должно быть пустым»;
у числового поля задан диапазон (Мин / Макс) → проверка «значение должно попадать в диапазон».

Их не пишут вручную — платформа выводит их из свойств поля. Во вкладке «Логика» они собраны в отдельном блоке «Из свойств полей» — только для чтения: удалить или изменить такую проверку здесь нельзя. Чтобы изменить, поправьте само свойство поля в инспекторе конструктора (снимите «Обязательное» или измените диапазон), и проверка изменится вместе с ним.

Межполевые и межформенные правила

Это правила, которые нельзя вывести из одного поля: «если А, то Б обязательно», «дата окончания не раньше даты начала», «пульс ниже 40 при незаполненном поле причины». Такие правила заводятся кнопкой Добавить проверку в блоке Проверки вкладки Логика. Правило принадлежит открытой форме (относительно неё разрешаются имена полей — отдельно её выбирать не нужно), а стабильный OID конструктор присваивает сам. В редакторе задаются:

условие — при каком значении проверка срабатывает; истина — проверка сработала;
сообщение — текст, который увидит координатор при срабатывании;
серьёзность — «Инфо», «Предупреждение» или «Ошибка»;
действие при срабатывании — «Открыть запрос (query)» или «Блокировать сохранение» (block) — см. следующий раздел.

Условие собирается визуально — строками «поле — оператор — значение», объединёнными союзом И / ИЛИ. Для полей-дат операторы читаются словами: раньше · не позже · позже · не раньше. Правую часть можно сравнить не только с константой, но и с другим полем формы (число с числом, дату с датой) — так «дата окончания не раньше даты начала» собирается мышью, без формул. Что визуальным конструктором не выражается (арифметика, ref() на другие формы, скобки), задаётся формулой в расширенном режиме на языке выражений. Основные функции:

is_empty(...) — поле пустое;
num(...) — числовое значение поля;
days_between(...) — число дней между двумя датами;
round(..., n) — округление до n знаков;
ref('ФОРМА', 'ПОЛЕ') — ссылка на поле другой формы; форма ref('ВИЗИТ', 'ФОРМА', 'ПОЛЕ') дополнительно уточняет визит — так получаются межформенные проверки.

Поля якорной формы адресуются в выражении напрямую по их OID. Пример выражения:

num(HR) < 40 and is_empty(ref('F.DM', 'SEX'))

Полная справка по языку — сравнения, арифметика и чем «истина» в проверке отличается от «истины» в условии отображения — в статье Скип-логика и автозаполнение.

Два типа поведения: «block» и «query»

Когда правило срабатывает при вводе данных, оно ведёт себя одним из двух способов. Это принципиальная развилка, и выбирать её нужно осознанно.

Тип	Что происходит при вводе	Когда применять
block (стоп)	Значение не сохраняется, поле подсвечивается, показывается сообщение правила	Только для заведомо невозможных значений: дата в будущем, значение вне физически допустимого диапазона
query (запрос)	Значение сохраняется, но система автоматически открывает запрос (query) на это поле	Для всего спорного: подозрительное, но возможное значение, требующее уточнения у центра

Философия платформы: block останавливает только то, что не может быть правдой. Всё остальное — это query. Данные из первичного источника важнее немедленной «чистоты» экрана: если значение странное, но в принципе возможное, его нужно принять и открыть управляемый запрос, а не заставлять координатора «подгонять» ввод под правило.

Проверка на данных

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

Помимо этого, правила можно прогнать на данных реального субъекта — например, чтобы оценить новое правило поправки на уже собранных данных. Такой прогон лишь сообщает, сколько правил и на каких полях сработало бы, — он не открывает запросы и не меняет данные.

Что происходит при вводе данных

Когда исследование уже идёт, правила выполняются на каждом сохранении значения:

правило block не даёт сохранить значение — поле подсвечено, показано сообщение;
правило query сохраняет значение и открывает авто-запрос — он появляется в панели запросов сразу.

Так контроль качества встроен в поток ввода, а не откладывается на этап очистки.

Что дальше

Конструктор CRFВкладка «Логика», инспектор свойств и превью формы.

Скип-логика и автозаполнениеПолная справка по языку выражений.

ЗапросыКак выглядят и решаются запросы, открытые правилами.

Публикация и запускПроверка дизайна и передача версии на ревью.

Юридическая информацияПолитика обработки персональных данных