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

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

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

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

В медицинской ERP-системе МЕДЕРП реализован принципиально иной подход. Функциональность «Управляемая валидация согласования» представляет собой универсальный механизм настройки правил проверки. Один и тот же инструмент работает для любых типов документов — заявок, заказов, технологических карт, платёжных документов, приёмки, а также для всех задач, связанных с управлением снабжением. Бизнес-аналитики и администраторы самостоятельно создают, изменяют и отключают правила проверки — без единой строки кода, без остановки работы системы и без ожидания релизов.

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

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

• Многообразие документов. Закупки, заявки, приёмка, технологические карты, платёжные поручения — у каждого своя структура и своя логика проверки. Каждый новый тип документа — потенциально новый набор правил, что напрямую влияет на организацию снабжения в целом.
• Частота изменений. Лимиты, источники, регламенты, требования регуляторов, зоны ответственности, условия договоров меняются постоянно. Иногда несколько раз в месяц, и работа снабжения должна успевать за этими изменениями без потери качества.
• Разнородность проверок. Одни проверки критичны и должны блокировать согласование, другие — носят рекомендательный характер, третьи — зависят от контекста (суммы, подразделения, типа документа, источника, направления работы организации). В процессах снабжения такой контекст играет решающую роль.
• Необходимость контроля. Каждое решение должно быть обоснованным и прозрачным — для управления рисками, для внутренней отчётности, для аудита. Особенно это касается участков, где цена ошибки особенно высока.

При классическом подходе разработчики вынуждены программировать каждую проверку индивидуально для каждого типа документа. Это приводит к:

• росту кодовой базы и усложнению конфигурации;
• риску регрессий при каждом изменении;
• проблематике описания — необходимо отдельно вести документацию по каждой процедуре;
• длительным циклам внедрения (заявка → разработка → тестирование → релиз);
• зависимости бизнеса от квалифицированных 1С-программистов даже для незначительных правок.

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

Справочник «Настраиваемые контроли согласования»

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

• текст запроса на языке 1С — описывает, какие данные и при каком условии считаются ошибочными;
• параметры запроса — позволяют переиспользовать один контроль с разными входящими значениями (например, «Лимит подразделения»);
• HTML-шаблон ошибки — определяет, как будет выглядеть сообщение при срабатывании контроля;
• код ошибки — для интеграции с внешними системами и аналитики.

Важно, что один и тот же контроль можно использовать для разных типов документов. Например, контроль «Превышение лимита» работает и для заявки подразделения, и для закупки, и при приёмке — просто в разных запросах проверяются разные суммы и разные лимиты. Это особенно ценно для управления снабжением, где одни и те же правила применяются к заявкам, заказам и отгрузкам. Это и есть универсальность.

Для работы с запросом доступно использование механизма платформы 1С — «Конструктор запросов». Чтобы им научиться, достаточно обладать знаниями по архитектуре документов, а также пройти базовые курсы по работе с системой компоновки данных — СКД.

Пример: требуется добавить контроль, чтобы закупки на сумму свыше 1 млн рублей требовали дополнительного согласования с определёнными участниками. Для этого создаётся новый контроль с запросом:

ВЫБРАТЬ
	МЕДЕРП_Закупка.СуммаДокумента КАК СуммаДокумента
ИЗ
	Документ.МЕДЕРП_Закупка КАК МЕДЕРП_Закупка
ГДЕ
	МЕДЕРП_Закупка.СуммаДокумента > 10000
 И МЕДЕРП_Закупка.Ссылка = &ПредметСогласования

Правило готово. Для его создания достаточно базовых навыков работы с системой компоновки данных (СКД). Программирование не требуется. А если завтра понадобится аналогичный контроль для другого документа, связанного с материальным снабжением, — просто копируем и меняем источник данных.

Ключевая особенность: запрос считается пройденным, если возвращает пустую таблицу. Если таблица не пуста — это ошибка. Такая логика интуитивно понятна: «ищем ошибки — нашли — сообщаем».

В перспективе планируется интеграция с сервисом ЕРП (единого ресурсного планирования) от КБФИТ. Это сервис, из которого организации смогут загружать готовые, предварительно настроенные контроли в свой справочник «Настраиваемые контроли согласования». Типовые сценарии — проверка лимитов, контроли ценообразования технологических карт, контроль норм времени и другие — будут доступны для загрузки, донастройки и немедленного использования. Это позволит не только создавать правила самостоятельно, но и пользоваться наработанной базой лучших практик в области комплексного снабжения, сокращая время на внедрение.

Настройка контролей в маршруте согласования

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

Для каждого этапа маршрута и группы пользователей можно зафиксировать:

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

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

Пример из практики: при приёмке настроен контроль в режиме «Блокировать» в случае, если в разрезах источника финансирования и КОСГУ есть превышения лимита плана ФХД. Экономист видит детализацию по какому КОСГУ и источнику есть превышение. Согласование недоступно. Происходит переброска финансирования. Такой подход защищает и процессы материального снабжения от необеспеченных закупок.

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

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

• Блокировать — при срабатывании контроля согласование прерывается. Пользователь видит HTML-сообщение с расшифровкой ошибки. Документ не переходит на следующий этап до устранения нарушений. Режим используется для критичных проверок, которые не могут быть пропущены. Например, в работе снабжения это могут быть проверки превышения утверждённого бюджета.
• Уведомлять — контроль выполняется, но его срабатывание не блокирует согласование. Пользователь видит предупреждение и может самостоятельно принять решение: продолжить согласование или вернуть документ на доработку. Система не фиксирует это действие в журнале — излишний аудит здесь не требуется.
• Игнорировать — контроль не выполняется на данном этапе. Режим позволяет временно отключать проверки без удаления из маршрута (например, на время отладки или сезонных изменений). Контроль остаётся в маршруте, но система его пропускает.

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

Алгоритм работы проверок

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

• Шаг 1. Стандартные проверки документа
  • система выполняет встроенные в конфигурацию проверки (заполнение обязательных реквизитов, корректность ссылок, права доступа);
  • если стандартная проверка не пройдена — согласование прерывается.
• Шаг 2. Определение текущего этапа и группы пользователя
  • система определяет текущий этап маршрута согласования;
  • определяет группу пользователя, инициировавшего согласование.
• Шаг 3. Выбор контролей из раздела «Управляемые контроли»
  • из раздела «Допустимые действия» маршрута извлекаются все контроли, назначенные на данный этап и группу пользователя;
  • набор контролей зависит от типа документа, но механизм их настройки — единый. Это ключевое преимущество для комплексного снабжения, где циркулируют десятки видов документов.
• Шаг 4. Цикл по контролям
  • режим «Игнорировать» → контроль пропускается, проверка не выполняется;
  • режим «Уведомлять» → контроль выполняется. При срабатывании пользователь видит предупреждение и принимает решение самостоятельно: согласовать документ или вернуть на доработку. Действие не фиксируется в журнале — система доверяет пользователю;
  • режим «Блокировать» → контроль выполняется. При срабатывании согласование немедленно прерывается, пользователь видит HTML-сообщение с расшифровкой ошибки.
• Шаг 5. Проверка прохождения блокирующих контролей
  • если все блокирующие контроли пройдены → согласование завершается успешно;
  • если хотя бы один блокирующий контроль сработал → согласование останавливается.

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

Переопределяемые функции для сложных сценариев

Несмотря на всю мощь языка запросов, в реальной практике встречаются сценарии, которые невозможно описать одним SELECT'ом. Особенно часто это происходит в сложных цепочках материального снабжения, где данные разбросаны по разным учётным контурам, а логика зависит от множества параметров. Для таких случаев в МЕДЕРП предусмотрен механизм переопределяемых функций:

• вызвать внешний веб-сервис:
  • проверить наличие дебиторской / кредиторской задолженности по договору в регламентированном учёте;
  • проверить, что принятые обязательства и принимаемые обязательства — закрыты;
  • проверить, что реквизиты карточки номенклатуры в регламентированном учёте не отличаются от данных МЕДЕРП. Это критично для материального снабжения, где ошибка в единицах измерения может привести к некорректной инвентаризации и подписанию требований накладных в ЭДО (например, 1С: ДГУ).
• реализовать сложный алгоритм, который невозможно выразить на языке запросов:
  • обойти все строки табличной части трудовых затрат, выполнить нормативный расчёт затрат и сверить с данными, указанными в документе;
  • произвести расчёт цен материальных затрат технологической карты и сверить их со средневзвешенной ценой позиции.

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

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

Практические кейсы

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

Самая частая реакция на сработавший контроль: «Это просто техническая мелочь, почему система не пускает?». Если контроль сработал — значит, есть нарушение, которое кто-то должен увидеть и оценить. Это и есть прозрачность, особенно важная в управлении снабжением.

Кейс №1. Превышение потребности на незначительный объём

Звонок от центра ответственности: «Не можем привязать позицию к потребности. По договору остаток — 90, а приёмка пришла на 100. Превышение — всего на 10. У нас поставка на 1000000 и отделения ждут — надо срочно отдавать в оплату! Отключи контроль, пропусти, я потом внесу изменения в закупку».

Система, следуя настройкам маршрута, не пропускает документ — контроль в режиме «Блокировать». Исполнитель центра ответственности вынужден внести изменения в закупку, после этого экономист подтвердит изменения, и только после этого доступна будет привязка к потребности и документ пойдёт дальше. В системе снабжения такая дисциплина предотвращает кассовые разрывы и нецелевое использование средств.

Кейс №2. Расхождение норм времени в технологических картах

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

Экономист видит уведомление, но принимает обоснованное решение с учётом специфики процесса. В контексте организации снабжения это позволяет гибко реагировать на отклонения в нормативах, не останавливая весь процесс. Такая гибкость особенно ценна для организации снабжения, где нормативная база постоянно обновляется, а любое ужесточение требований не должно останавливать текущие поставки.

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

Кейс №3. Назначение ответственного бухгалтера при приёмке

В маршруте согласования приёмки ТРУ (товары, работы, услуги) настроен контроль наличия бухгалтера в режиме «Блокировать». Контроль проверяет заполненность поля «Бухгалтер» в документе «Исполнение закупки» и не даёт согласовать, если поле не указано.

В HTML-сообщении содержится пояснение, кого следует выбирать, кто отвечает за определённый участок, а кто в отпуске. При необходимости настраивается более детальный анализ (кто центр ответственности, какой склад, кто технический исполнитель). В работе снабжения это гарантирует, что каждая поставка закрепляется за конкретным сотрудником учётной службы.

Кейс №4. Выбор корректного маршрута согласования

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

Резюме: один механизм для всех сценариев

Управляемая валидация согласования — это универсальный инструмент, который:

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

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

Сравнительная таблица: классический подход vs управляемая валидация

Таблица наглядно демонстрирует, почему управляемая валидация становится стандартом для современных ERP-систем, особенно в сфере комплексного снабжения медицинских организаций