Что под капотом: управляемая валидация согласования в МЕДЕРП

Управляемая валидация согласования | узнать больше Автоматизируйте проверки документов, настраивайте правила согласования без разработчиков и управляйте доступными действиями в реальном времени

В системе управленческого учёта медицинской организации корректное прохождение документов по этапам согласования — основа соблюдения регламентов и финансовой дисциплины. Часто возникает ситуация, когда встроенных в конфигурацию проверок недостаточно, а доработка программы под каждое новое требование занимает дни, а иногда и недели.

Механизм «Управляемая валидация согласования» решает именно эту задачу, позволяя аналитикам совместно с кураторами бизнес-процессов медицинской организации самостоятельно создавать правила проверки документов без привлечения разработчиков.

Назначение и ценность механизма

Механизм предназначен для формализации и автоматизации проверок данных на этапах согласования документов. Он объединяет инструменты динамической валидации через запросы и переопределяемые функции, а также механизм фиксации контролей в маршрутах согласования с выбором режима выполнения.

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

Функциональная роль: система хранит утверждённые правила проверки (контроли), которые автоматически выполняются при нажатии кнопок «Согласовать» или «Согласовать с замечаниями», и в зависимости от результатов динамически управляет доступными действиями пользователя.

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

Архитектура и принципы работы

Механизм хранения данных: в основе лежат два справочника — «Настраиваемые контроли согласования» (хранилище правил проверки) и «Маршруты согласования» (определяет, какие контроли и на каких этапах выполняются).

• Хранение правил проверки: каждый контроль содержит текст запроса на языке 1С, параметры выполнения, html-шаблон предупреждения и код ошибки из «Реестра ошибок» портала mederp.ru.
• Поддержка различных режимов: для каждого контроля может быть задан режим «Блокировать», «Уведомлять» или «Игнорировать».
• Автоматизация проверок: контроли вызываются автоматически в момент принятия решения по документу.
• Интеграция с маршрутами согласования: контроли привязываются к конкретным этапам и группам пользователей.

• Список настраиваемых контролей
• Фиксация общих сведений
• Заполнение текста запроса контроля

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

• Последовательный вызов проверок: сначала выполняются стандартные встроенные проверки документа, затем — управляемые контроли.
• Пустая таблица = успех: контроль считается пройденным, если запрос вернул пустую таблицу значений. Непустой результат интерпретируется как ошибка.
• HTML-формат ошибок: все ошибки выводятся в формате html с поддержкой макросов подстановки.

• Указание параметров контроля
• Визуализация предупреждения
• Заполнение предупреждения в HTML

Устройство настраиваемого контроля медицинской ERP

Каждый элемент справочника «Настраиваемые контроли согласования» представляет собой правило проверки. Рассмотрим его устройство.

Пример настройки контроля, где требуется участие заместителя генерального директора по цифровой трансформации национального медицинского исследовательского центра (НМИЦ).

В разделе «Шапка» фиксируется общая информация о производимом контроле.

• Контроли можно группировать в папки для удобства поиска.
• В наименовании рекомендуется делать осмысленную префиксацию.
• В описании указывать суть производимого контроля.
• При необходимости неактуальные контроли можно помещать в архив для сохранения истории.
• Если контроль должен быть жёстко привязан к маршруту согласования, его можно привязать к виду маршрута.
• Для применения внешних процедур следует фиксировать данные в полях «Идентификатор» и «Переопределяемая функция» — в таких случаях необходимо привлекать специалистов 1С для написания соответствующих функций в расширениях к МЕДЕРП.

В разделе «Текст запроса» указывается выполняемый текст на языке 1С; при необходимости можно использовать «Конструктор запроса».

Для написания запросов требуются базовые знания работы с СКД (системой компоновки данных), а также понимание архитектуры решения МЕДЕРП. Мы рекомендуем привлекать специалистов наших партнёров, которые прошли сертификацию от КБФИТ и получили документ о подтверждении знаний «КБФИТ: Разработчик». Более подробно о сертификации можно ознакомиться здесь: «Сертификация специалистов партнёров КБФИТ».

Раздел «Параметры запроса» используется для фиксации предопределённых параметров, которые применяются в запросе.

• Доступна возможность автоматического заполнения списка параметров.
• В качестве значения могут быть использованы различные типы данных: от строки и ссылки до списка значений.
• В качестве предопределённого параметра в запрос всегда передаётся «ПредметСогласования» — он содержит ссылку на проверяемый документ.

Раздел «Расшифровка ошибки» применяется для визуального оформления предупреждения в формате HTML.

• Для просмотра текста предупреждения, который будет выдан пользователю, используется подраздел «Отображение».
• Для редактирования текста применяется подраздел «Редактор», где необходимо указывать исходный код HTML с соответствующим оформлением тегов.
• Для вывода расшифровки ошибки в тексте исходного кода необходимо указать ключевые слова: {{РезультатЗапроса}}.
• При необходимости можно воспользоваться встроенной справкой к редактору HTML в подразделе «Подсказка».

Интеграция с маршрутом согласования

Контроли не вызываются сами по себе. Они должны быть зафиксированы в маршруте согласования. Для этого в справочнике «Маршруты согласования» предусмотрен раздел «Управляемые контроли», где для каждого этапа и группы пользователей настраивается перечень контролей.

Принцип иерархии: система поддерживает назначение контролей на различных уровнях. Контроль может быть привязан к конкретному этапу и группе пользователей (например, только для «Экономистов») либо назначен для всех участников этапа (в таком случае «Исполнитель» не заполняется).

Настройка управляемых контролей маршрута согласования в современной медицинской ERP

Примеры настройки контролей в маршруте:

• Этап «Расчёт ПЭО»
  • Контроль: «Закупка. Соответствие счетов учёта и КЭК» → Режим: Блокировать
• Этап «Обработка бухгалтером»
  • Контроль: «Приёмка. Привязка к основным средствам» → Режим: Блокировать
• Этап «Формирование»
  • Контроль: «Приёмка. Привязка услуг к основным средствам» → Режим: Блокировать
  • Контроль: «Приёмка. Не заполнен бухгалтер» → Режим: Блокировать
  • Контроль: «Закупка. Валидация маршрутов согласования» → Режим: Блокировать
  • Контроль: «Закупка. Валидация данных документа» → Режим: Блокировать
  • Контроль: «Закупка. Валидация участников согласования» → Режим: Блокировать
• Этап «Ответственный за направление»
  • Контроль: «Закупка. Наличие служебных записок» → Режим: Уведомлять
  • Контроль: «Закупка. Наличие обоснования с расчётами целесообразности закупки» → Режим: Уведомлять

Алгоритм вызова при согласовании

Когда пользователь нажимает «Согласовать» или «Согласовать с замечаниями», запускается следующий алгоритм.

Шаг 1. Стандартные проверки документа:

• Система выполняет встроенные проверки (заполнение обязательных реквизитов, корректность спецификации, превышение плана ФХД, заполненность технического задания).
• Если проверка не пройдена — согласование прерывается с системным сообщением.

Шаг 2. Определение контекста:

• Система определяет текущий этап маршрута согласования.
• Определяет группу пользователя, инициировавшего согласование.
• Определяет предмет согласования (ссылку на документ).

Шаг 3. Сбор контролей:

• Из раздела «Допустимые действия» маршрута извлекаются все контроли, назначенные на текущий этап и группу пользователя.
• Проверяется необходимость выполнения: если указано «Игнорировать», контроль пропускается.

Шаг 4. Выполнение контролей:

• Для каждого контроля выполняется запрос (или вызывается переопределяемая функция).
• Если контроль в режиме «Блокировать» сработал — согласование прерывается, пользователь видит html-сообщение.
• Если контроль в режиме «Уведомлять» сработал — пользователь видит предупреждение, согласование может быть дальше продолжено.

Шаг 5. Завершение:

• Если все блокирующие контроли пройдены — документ передаётся на следующий этап.

Получение ошибки при управляемом контроле в момент согласования в ERP-решении для медицины

Режимы выполнения контролей ERP-решения

Для каждого зафиксированного в маршруте контроля может быть задан один из трёх режимов выполнения. Выбор режима определяется критичностью проверки для бизнес-процесса.

Режим «Блокировать»:

• Контроль выполняется в обязательном порядке.
• При срабатывании согласование невозможно, документ не переходит на следующий этап.
• Пользователь видит html-сообщение с расшифровкой ошибки.
• Типовые сценарии: не заполнены обязательные реквизиты, превышение лимитов, отсутствие связи с основными средствами, некорректная маршрутизация.

Режим «Уведомлять»:

• Контроль выполняется, но его срабатывание не блокирует согласование.
• Пользователь видит предупреждение, но может продолжить согласование.
• Типовые сценарии: некритичные отклонения, рекомендации, информирование.

Режим «Игнорировать»:

• Контроль не выполняется на данном этапе.
• Позволяет отключать проверку для целевых пользователей с расширенными правами.
• Типовые сценарии: отладка, изменение регламентов, расширенные возможности для координатора согласования.

Работа запроса контроля мед. ERP системы — МЕДЕРП

Как работает запрос контроля: запрос выполняется непосредственно в момент согласования. Если запрос возвращает пустую таблицу значений — контроль считается пройденным. Если таблица непустая — каждая её строка интерпретируется как нарушение и попадает в html-отчёт.

В нашем разбираемом примере происходит следующее:

• Анализируется состав спецификации закупки на предмет вхождения в зону ответственности заместителя генерального директора по ЦТ:
  • Выбираются позиции спецификации.
  • Проверяется их вхождение в целевую группу закупаемой позиции — она входит в «ЦО, Отдел информационных технологий».
• Проверяется раздел «Участники согласования» закупки на наличие этапа «Утверждение заместителя генерального директора по ЦТ».
• Данные двух подзапросов совмещаются — в результате выдаётся состав позиций, которые входят в зону ответственности заместителя генерального директора.

Другие сценарии применения контролей в ERP-решении для медицины:

• Соблюдение регламентов отражения в ФРМО: автоматическая проверка в момент приёмки основных средств на предмет привязки к инвентарным номерам и отражения в Федеральном реестре медицинских организаций.
• Соблюдение регламента бизнес-процессов: контроль корректности выбора маршрута согласования в соответствии со спецификой обработки приёмки, согласования заявки или обработки закупочных процедур.
• Контроль валидности данных: проверка зафиксированных значений с целевыми; в частности, могут быть настроены проверки на указанные значения в документе «Закупка»:
  • При закупке медикаментов: склад — «Аптека», тип исполнения — «Поступление ТМЦ и ОС», источник данных исполнения закупки — «Приёмка из ФГИС МДЛП».
  • При закупке в рамках 44-ФЗ: источник данных исполнения закупки — «Приёмка из ЕИС».
  • Если технический исполнитель — склад: склад — «Центральный склад», тип исполнения — «Поступление ТМЦ и ОС».
• Контроль финансовой аналитики: валидация кодов КЭК и счетов учёта (для 105.31 допустимо 341 КОСГУ).