Два руководителя одновременно согласуют заявки по одной статье расходов. Каждому система показывает достаточный остаток. Обе заявки проходят, а их общая сумма уже превышает бюджет. Проблема не в маршруте согласования: проверка увидела деньги, но не зарезервировала их для конкретного обязательства.
Чтобы согласование платежей в Битрикс24 стало инструментом контроля, нужно определить движение суммы от заявки до факта оплаты. Одного поля «лимит» и сравнения перед сменой стадии недостаточно. Ниже рассмотрена архитектура возможного решения; это не описание готовой финансовой функции, которая автоматически появляется после создания смарт-процесса.
Сначала выбираем, какой бюджет проверяем #
Лимит может относиться к юридическому лицу, проекту, статье движения денежных средств и периоду. Если взять только название статьи, расходы разных организаций смешаются. Если не учитывать период, перенос даты платежа даст непонятный результат.
Поэтому бюджетная строка должна иметь определённый ключ: например, организация, проект, статья и месяц. Правило не обязано быть именно таким: оно зависит от модели заказчика. Важно, чтобы заявку можно было однозначно связать с нужным лимитом, а неизвестную статью нельзя было использовать для обхода проверки.
Отдельно определяют смысл бюджета: это план выплат, лимит обязательств или иной показатель. Договор на год и заявка на ближайший платёж не должны автоматически уменьшать один остаток дважды. Правила финансового учёта согласуются до настройки интерфейса.
Заявка, резерв и фактическая оплата #
Для контроля полезно различать запрошенную сумму, зарезервированный лимит и оплаченный факт. Заявка может быть отклонена, перенесена или оплачена частично. Каждое событие должно однозначно менять состояние резерва.
Предлагаемая модель: при переходе к определённому этапу согласования система проверяет доступный лимит и создаёт резерв. При отказе резерв освобождается. При оплате соответствующая часть резерва заменяется фактом. Это проектное правило, а не универсальная бухгалтерская формула; точный момент резервирования определяет компания.
Если по заявке зарезервировано 100 условных единиц, а оплачено 40, оставшиеся 60 либо продолжают удерживаться, либо освобождаются по согласованному основанию. Это условный пример поведения. Главное — не вычитать одновременно все 100 резерва и 40 факта как независимые расходы.
Почему проверка должна выполняться вместе с резервированием #
При двух одновременных запросах нельзя сначала прочитать остаток, а потом независимо записать результаты. Между этими действиями другой процесс может занять тот же лимит. Операция должна обеспечивать согласованное изменение в системе, которая отвечает за бюджет.
Если бюджет ведёт отдельный сервис, он может выполнять проверку и создание резерва в одной защищённой операции хранения. Если владельцем является 1С или ERP, нужен предусмотренный для проекта механизм подтверждения резерва. Несколько последовательных REST-запросов к CRM сами по себе не дают гарантии общей транзакции между системами.
У операции нужен устойчивый идентификатор. Повтор после сетевого сбоя должен вернуть результат первой обработки, а не создать второй резерв. Эта защита особенно важна, когда пользователь не увидел ответ и нажал «согласовать» ещё раз.
Как использовать Битрикс24 в этой схеме #
CRM может быть рабочим местом инициатора и согласующих. В карточке заявки показывают организацию, статью, проект, договор, сумму, дату и состояние проверки. Смарт-процессы позволяют настроить поля, стадии и автоматизацию; официальная справка описывает их параметры . Доступность функций проверяется на конкретном портале.
Расчёт лимита не стоит скрывать за одним зелёным индикатором. Сотруднику полезно видеть основание: установленный бюджет, уже оплаченный факт, действующие резервы и сумму текущей заявки. Финансовый руководитель сможет объяснить отказ, а не искать его причину в нескольких таблицах.
Настройка маршрута зависит от организации, статьи и суммы. Для отсутствующего согласующего заранее определяют замещение. При изменении суммы после одобрения прежнее решение нужно пересмотреть в предусмотренном объёме. Иначе сотрудник сможет согласовать малую сумму, а затем заменить её большей.
Превышение лимита и корректировка бюджета #
Не всякое превышение должно обрабатываться одинаково. По одной статье компания может запретить дальнейшее движение, по другой — потребовать дополнительного решения. Эти режимы задаются явно, вместе с правом на исключение.
Увеличение бюджета должно сохранять автора, основание и момент изменения. Просто переписать число в поле недостаточно: потом нельзя будет объяснить, почему ранее отклонённая заявка стала допустимой. Сам инициатор платежа не должен получать право увеличивать свой лимит только ради удобства работы.
Отдельно контролируют смену статьи и периода. Если заявка переносится в следующий месяц, старый резерв освобождается, новый создаётся по правилам нового периода. При ошибке нельзя оставлять одновременно два активных резерва или ни одного, сохраняя статус «согласовано».
Откуда приходит факт оплаты #
Если оплата выполняется вне CRM, факт получают из согласованного источника: учётной системы либо другого финансового контура проекта. Не стоит считать кнопку «отправлено бухгалтеру» подтверждением перечисления денег. Нужна связь между заявкой и конкретным результатом исполнения.
Для обмена определяют частичную оплату, отмену, возврат, повторную передачу и исправление. При недоступности источника сотрудник должен видеть давность данных. Старый остаток без отметки времени опаснее честного сообщения, что актуальный лимит временно не подтверждён.
Если проект включает бюджетирование и казначейство в учётной системе, задача шире интерфейса согласования в CRM. Её стоит связать с автоматизацией бюджетирования и казначейства , сохранив одного владельца финансовых данных.
Что обязательно проверить до запуска #
- — Две заявки одновременно претендуют на последний доступный лимит.
- — Пользователь повторяет запрос после потери соединения.
- — Заявку отклонили, а затем отправили заново.
- — Изменили сумму, статью или месяц уже согласованной заявки.
- — Поступила частичная оплата или повтор того же события оплаты.
- — Бюджет скорректировали, пока заявка находилась на согласовании.
- — У сотрудника есть право смотреть заявку, но нет права менять лимит.
Результатом пилота должен стать воспроизводимый расчёт остатка и объяснимая история каждого движения. Количество настроенных роботов не заменяет эту проверку. Только после неё имеет смысл расширять процесс на другие организации и виды расходов.
Поможем связать согласование платежей с бюджетом #
Если штатного согласования недостаточно для контроля лимитов, NetLab поможет спроектировать решение под ваш порядок платежей. Разберём бюджетные статьи, резервы и фактические оплаты, определим источник финансовых данных и настроим взаимодействие с Битрикс24. Обсудить автоматизацию платёжных заявок .
