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

Управляемая валидация согласования | все статьи цикла Настраиваемые контроли, три режима выполнения, HTML-ошибки — механизм, реализованный в типовой поставке МЕДЕРП. Сравнительный анализ функциональности с другими системами.

В медицинских организациях процесс согласования документов снабжения требует не только маршрутизации, но и содержательной проверки бизнес-данных. Корректная валидация заявок, договоров и спецификаций является важным элементом внутреннего контроля и управления рисками при закупках, а также способствует соблюдению 44-ФЗ, 223-ФЗ и внутренних регламентов.

В зависимости от архитектуры и целевого назначения, разные системы — от ERP-решений до специализированных систем — реализуют валидацию по-разному. Рассмотрим основные подходы, включая системы, которые чаще всего используются в медицинских организациях федерального уровня. Особое внимание уделим тому, как эти системы взаимодействуют друг с другом и где возникают классические «разрывы» в управленческом контуре.

Важное уточнение: В контексте данной статьи под «управляемой валидацией согласования» понимается механизм настраиваемой проверки бизнес-данных на этапах согласования документов снабжения. В других системах, например в 1С:Медицина, термин «валидация» используется для обозначения технической проверки структуры электронных медицинских документов (СЭМД) и не относится к процессам снабжения.

О целях статьи: Материал представляет собой обзор функциональности «Управляемая валидация согласования» в МЕДЕРП в контексте интеграции с другими системами, используемыми в медицинских организациях. Сведения о функциональности систем получены из открытых источников с применением средств искусственного интеллекта. Статья не является нормативным требованием и не заменяет официальную документацию вендоров.

1. Значимость управляемой валидации в медицинских организациях

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

Корректность валидации зависит от следующих ключевых факторов:

• Настройка правил проверки без разработчика: возможность создавать новые контроли через интерфейс, а не через код конфигурации;
• Дифференциация по этапам и группам пользователей: привязка контролей к конкретным этапам маршрута и группам исполнителей;
• Информативность ошибок: вывод не просто системного сообщения, а таблиц с некорректными данными и кодом ошибки.

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

2. Цикл управления валидацией в российском медицинском ERP-контуре

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

• Стандартные проверки документа: → встроенные проверки в системе (заполнение реквизитов, корректность спецификации);
• Определение контекста: → система определяет текущий этап маршрута, группу пользователя и предмет согласования;
• Сбор и выполнение контролей: → из маршрута извлекаются контроли для данного этапа и группы;
• Реакция в зависимости от режима: → «Блокировать», «Уведомлять», «Игнорировать»;
• Фиксация результата: → документ переходит на следующий этап, факт согласования фиксируется в логе.

Ключевая проблема: эти процессы часто изолированы друг от друга. Данные из контрактов не попадают в проверки автоматически, а ручная настройка контролей требует привлечения разработчиков. Именно эти «разрывы» и определяют сегодня повестку в управлении валидацией согласования.

3. Подход МЕДЕРП: настраиваемая валидация через справочники и запросы

МЕДЕРП реализует управляемую валидацию согласования как часть сквозного процесса — от формирования заявки до фиксации результата согласования. Ключевое отличие типовой поставки — возможность настройки правил проверки без разработчика через справочник «Настраиваемые контроли согласования».

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

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

Каждый контроль в МЕДЕРП включает шапку (наименование, описание, вид маршрута), текст запроса на языке 1С с поддержкой «Конструктора запроса», параметры запроса (включая «ПредметСогласования»), HTML-шаблон ошибки с макросом {{РезультатЗапроса}}, а также переопределяемую функцию для сценариев, нереализуемых через запрос. Принцип работы запроса: пустая таблица в ответе интерпретируется как успех, непустой результат — как ошибка.

Три режима выполнения и дифференциация по этапам

МЕДЕРП поддерживает три режима выполнения контроля:

• «Блокировать»: при ошибке согласование прерывается с выводом HTML-сообщения;
• «Уведомлять»: ошибка выводится, но согласование может быть продолжено;
• «Игнорировать»: контроль пропускается.

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

Таким образом, МЕДЕРП в типовой отраслевой поставке обеспечивает настраиваемую систему контроля согласования документов. При этом переопределяемые функции требуют привлечения разработчика 1С для сценариев, нереализуемых через запрос. В других системах аналогичные сценарии могут быть реализованы через доработки и интеграции.

4. Подход БАРС.Здравоохранение: регламентное согласование без гибкой логики

Роль в цикле: БАРС.Web-ГосЗаказ — система для прохождения бюрократических процедур размещения заказов, а не инструмент для гибкого управления логикой проверок.

БАРС.Здравоохранение — это система для регламентного согласования заявок на закупку, планов закупок, планов-графиков, извещений и договоров. В отличие от МЕДЕРП, которое фокусируется на настраиваемой валидации бизнес-данных, БАРС решает задачи статусного согласования между заказчиком, ГРБС и уполномоченным органом.

Объекты согласования и роли

В БАРС.Web-ГосЗаказ согласуются заявки на закупку, планы закупок, планы-графики, извещения и договоры. Ролевая модель включает Заказчика, ГРБС и Уполномоченный орган. Каждый этап предполагает смену статуса («На согласовании», «Утверждено», «На доработке»).

Автоматические контроли и режимы реакции

Система выполняет только встроенные проверки — контроль сроков размещения заказа, контроль сроков внесения изменений, контроль соответствия заявок сумме утверждённого лимита. Режимы реакции: только два — «Принято» (согласовано) или «Доработка» (возврат). Поддерживается ЭЦП для фиксации решений.

• Пример 1: согласование плана-графика закупок с ГРБС;
• Пример 2: утверждение извещения об осуществлении закупки с единственным поставщиком.

БАРС даёт регламентное согласование, но в типовой поставке не позволяет настраивать логику проверок внутри медицинской организации. Это система для размещения заказов, а не ERP-система снабжения.

Границы системы

Согласно открытым источникам, БАРС не позволяет создавать новые проверки через интерфейс. Её задача — обеспечить статусное согласование для прохождения бюрократических процедур. Без интеграции с ERP-контуром данные о согласовании остаются изолированными.

Таким образом, БАРС является системой для размещения заказов, но не инструментом гибкой валидации бизнес-данных. Она выступает ценным источником данных для ЕИС, но требует интеграции с управленческим контуром.

5. Подход 1С:Управление холдингом: Workflow без валидации

Роль в цикле: 1С:УХ — мощный Workflow-движок для маршрутизации согласования, но не инструмент гибкой валидации бизнес-данных.

1С:Управление холдингом — это ERP-система с подсистемой «Универсальные процессы» класса Workflow. В отличие от МЕДЕРП, которое фокусируется на настраиваемой валидации, 1С:УХ решает задачи маршрутизации документов с условными переходами на основе реквизитов.

Визуальный конструктор маршрутов и условные переходы

1С:УХ предлагает визуальный конструктор маршрутов с последовательным и параллельным согласованием, переходами по условию и по выбору. Условные переходы настраиваются на основе реквизитов документа (например, при сумме документа > 10 млн рублей маршрут переключается на этап «Согласование с Зам. Генерального директора»).

Блоки процесса и ролевая адресация

Доступны блоки: «Согласование», «Переход по условию», «Вложенный процесс», «Обработка» (запуск кода 1С), «Оповещение», «Пауза», «Ожидание события». Поддерживается ролевая адресация и контроль сроков с эскалацией.

Ключевой нюанс, подтверждённый открытыми источниками и практическими кейсами: создание новых видов проверок в 1С:УХ требует кастомных доработок силами разработчика. В одном из кейсов по настройке перехода по условию с группировкой видов операций потребовалась доработка типового функционала.

Границы системы

Согласно открытым источникам, 1С:УХ не позволяет создавать новые проверки через интерфейс — условные переходы работают только на основе существующих реквизитов документа. Её задача — маршрутизация, а не валидация бизнес-данных. Без доработок нетривиальная логика проверок недоступна.

Таким образом, 1С:УХ является инструментом маршрутизации, но не инструментом гибкой валидации. Она выступает ценным источником для настройки потоков работ, но для содержательной проверки данных может потребоваться интеграция с другими системами.

6. Подход 1С:Медицина: техническая валидация без отношения к снабжению

Роль в цикле: 1С:Медицина — система для валидации структурированных электронных медицинских документов (СЭМД) для выгрузки в РЭМД и ФНСИ.

1С:Медицина — это специализированное решение для медицинских организаций. В отличие от МЕДЕРП, которое фокусируется на снабжении, 1С:Медицина решает задачи технической валидации медицинских документов для соответствия форматам РЭМД и ФНСИ. Здесь термин «валидация» используется в ином смысле — как техническая проверка структуры документа, а не как настраиваемая проверка бизнес-правил закупок.

Что валидируется в 1С:Медицина

Валидация СЭМД включает проверку структуры документа, обязательных элементов, форматов данных (адреса, GUID ФИАС, коды), атрибутов @nullFlavor и соответствие справочникам ФНСИ. Валидируются: сведения о результатах медико-социальной экспертизы, протоколы телемедицинских консультаций, медицинские свидетельства о смерти, медицинские заключения и протоколы лабораторных исследований.

• Пример 1: проверка структуры протокола лабораторного исследования;
• Пример 2: валидация медицинского свидетельства о смерти перед выгрузкой в РЭМД.

Все эти документы относятся к медицинской деятельности, а не к снабжению. Валидация проверяет соответствие форматам РЭМД и ФНСИ, а не бизнес-правила закупок.

Границы системы

1С:Медицина не имеет отношения к управлению закупками и снабжением. Её задача — техническая проверка медицинских документов для выгрузки в ЕГИСЗ. Без интеграции с ERP-контуром данные о валидации СЭМД остаются изолированными от процесса снабжения.

Таким образом, 1С:Медицина является системой для технической валидации медицинских документов, но не инструментом управления закупками. Она выступает ценным источником для ЕГИСЗ, но не решает задачи валидации согласования закупок.

7. Матрица покрытия этапов управления валидацией согласования

Условные обозначения: ✅ — реализовано в типовой поставке; ⚠️ — требует доработок или реализуется через интеграцию; ❌ — не входит в функционал.

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

8. Место МЕДЕРП в экосистеме: устранение разрывов между контурами

МЕДЕРП не заменяет БАРС, 1С:УХ или 1С:Медицину. В типовой отраслевой поставке при наличии интеграции с этими системами его задача — связать эти системы в единый управленческий контур.

• Разрыв 1: БАРС → управленческий контур. БАРС даёт статусное согласование для ЕИС, но в типовой поставке не позволяет настраивать логику проверок внутри медицинской организации. МЕДЕРП может закрыть этот разрыв, обеспечивая гибкую валидацию на стороне медицинской организации.
• Разрыв 2: 1С:УХ → содержательная проверка данных. 1С:УХ даёт мощный Workflow-движок, но создание новых видов проверок требует доработок. МЕДЕРП предоставляет справочник настраиваемых контролей, позволяя создавать проверки без разработчика.
• Разрыв 3: 1С:Медицина → снабжение. 1С:Медицина валидирует медицинские документы для ЕГИСЗ, но не имеет отношения к снабжению. При необходимости МЕДЕРП может интегрировать данные из медицинского контура в процесс согласования закупок за счёт использования возможностей переопределяемых функций и привлечения квалифицированных специалистов интегратора системы МЕДЕРП. Это позволяет, например, учитывать потребности отделений в медизделиях или остатки при формировании заявок.

Таким образом, МЕДЕРП в типовой поставке при наличии указанной интеграции выступает интеграционной платформой, превращая разрозненные контуры в единый конвейер: от заявки до фиксации результата согласования с настраиваемой валидацией.

9. Выводы: переход от жёстко зашитых проверок к настраиваемой системе контроля

• 
  Управляемая валидация согласования — функциональность, реализованная в типовой поставке МЕДЕРП, которая в типовых поставках других систем, имеющих отношение к снабжению, отсутствует или требует доработок.

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

• МЕДЕРП предлагает настраиваемые контроли через справочник, три режима выполнения и информативные HTML-ошибки; переопределяемые функции требуют привлечения разработчика 1С;
• БАРС.Здравоохранение даёт регламентное согласование заявок и планов для прохождения бюрократических процедур, но в типовой поставке не позволяет настраивать логику проверок внутри медицинской организации;
• 1С:Управление холдингом даёт мощный Workflow-движок для маршрутизации согласования с условными переходами, но создание новых видов проверок требует кастомных доработок;
• 1С:Медицина имеет валидацию СЭМД, но она относится к медицинским документам для выгрузки в РЭМД и ФНСИ, а не к снабжению.

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

Для подтверждения статуса российского ПО и наличия отраслевой сертификации рекомендуется проверять записи в Реестре российского ПО Минцифры. В реестре содержатся сведения о версиях, классах ПО и сертификатах соответствия, актуальных на дату внедрения.

Рекомендация по проверке функциональности: Для подтверждения заявленных возможностей МЕДЕРП и других систем рекомендуется запросить демонстрационный стенд или провести тестирование на типовой конфигурации с использованием собственных сценариев.

Источники и нормативные документы

Анализ подходов к управляемой валидации согласования в медицинских организациях, приведённый в статье, выполнен с использованием технологий искусственного интеллекта (анализ и структурирование открытых данных), а также с учётом экспертного опыта автора в области автоматизации управленческого и регламентированного учёта в медицинских организациях федерального уровня. Сведения о функциональности систем (БАРС, 1С:УХ, 1С:Медицина) получены из открытых источников; для подтверждения актуальности функционала рекомендуется обращаться к официальной документации вендоров. Информация актуальна на момент публикации; для применения в конкретной ситуации рекомендуется сверяться с действующей редакцией документов.

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