Согласование заявок на оплату: как автоматизировать маршрут и передачу в учётную систему
Содержание 10 разделов
Согласование оплаты часто начинается в письме или сообщении: сотрудник присылает счёт, руководитель отвечает, бухгалтер уточняет статью и реквизиты, а казначей повторно собирает решения перед отправкой в банк. Пока заявок мало, участники помнят контекст. С ростом потока появляются потерянные вложения, платежи без владельца, повторные счета и споры о том, кто согласовал сумму.
Автоматизация переводит процесс в электронную заявку с заданными полями, маршрутом и историей. После финального решения данные могут перейти в 1С, ERP, CRM, Pyrus или другую рабочую систему, а затем связаться с платёжным поручением и банковской операцией. Цель проекта — ускорить понятные заявки и сделать исключения заметными.
Начните с процесса, а не с интерфейса
Перед настройкой формы полезно описать текущий путь на одной странице: кто создаёт заявку, какие документы прикладывает, кто проверяет договор и бюджет, кто выбирает счёт, кто подписывает платёж и кто узнаёт об исполнении. Для каждого шага фиксируют условие входа, решение, допустимый срок и заменяющего сотрудника.
Маршрут должен отражать реальные полномочия. Если руководитель всегда подтверждает заявки своего подразделения, система определяет его по оргструктуре. Если согласующий зависит от суммы, проекта или статьи расходов, правило использует эти поля. Ручной выбор фамилии при каждой заявке создаёт ошибки и усложняет кадровые изменения.
Какие данные должна содержать заявка
Платёж и получатель
В форме указывают юридическое лицо плательщика, получателя, ИНН, банковские реквизиты, сумму, валюту, дату и назначение платежа. Контрагента лучше выбирать из проверенного справочника. Изменение реквизитов после согласования отмечается явно и обычно возвращает заявку на необходимый этап.
Основание и подтверждающие документы
К заявке связывают договор, счёт, заказ, акт или другой документ-основание. Одного файла иногда недостаточно: системе полезны номер, дата, сумма и срок договора, чтобы проверить дубликат и показать согласующему контекст. Версии вложений сохраняют, а финальная заявка указывает, какой вариант был одобрен.
Управленческие признаки
Статья ДДС, подразделение, проект, центр финансовой ответственности и приоритет нужны для маршрута и отчётности. Обязательность полей зависит от типа платежа. Простая покупка расходных материалов и оплата по капитальному проекту могут использовать разные наборы данных в одном шаблоне.
Системная история
Платформа записывает автора, время создания, переходы, решения, комментарии, изменения ключевых полей и идентификаторы связанных документов. История должна читаться без восстановления переписки: кто увидел какую сумму и на каком основании принял решение.
Как устроить маршруты согласования
Последовательный маршрут
Заявка проходит этапы по очереди: руководитель, владелец бюджета, финансовый контроль, бухгалтерия. Он понятен и подходит, когда каждое решение зависит от предыдущего. Цена такого порядка — длительное ожидание, поэтому уведомления и замещение важны.
Параллельное согласование
Юридическая и техническая проверка могут идти одновременно, если они независимы. Следующий этап начинается после всех обязательных решений либо по заданному кворуму. Интерфейс показывает, чьё решение ещё ожидается.
Условный маршрут
Состав участников определяется суммой, статьёй, подразделением, типом договора или срочностью. Условия делают явными и тестируют на границах: ровно пороговая сумма, пустое поле, несколько совпавших правил. Для нестандартной заявки предусматривают владельца процесса, который выбирает корректный путь с записью причины.
Возврат на уточнение
Возврат отличается от отказа. Инициатор получает конкретный вопрос, исправляет данные, а система показывает изменённые поля. Если затронута сумма, получатель или основание, маршрут повторяет нужные этапы. Незначительное уточнение комментария может продолжить текущий путь по принятому регламенту.
Бюджет, дубли и реквизиты проверяются до оплаты
Автоматическая проверка сравнивает заявку с доступным лимитом по статье, подразделению и периоду. Результат должен объяснять расчёт: утверждённый лимит, уже согласованные обязательства, фактические расходы и остаток. При превышении заявка получает отдельный маршрут или требует решения владельца бюджета.
Проверка дублей ищет совпадения по контрагенту, номеру и дате счёта, сумме, договору и хешу файла. Найденный кандидат показывается пользователю до отправки. Система не обязана запрещать каждое совпадение: авансовый и окончательный платежи могут иметь похожие данные, поэтому решение фиксируется вместе с объяснением.
Реквизиты сверяются со справочником и документом-основанием. Изменение счёта получателя после предыдущих оплат становится заметным событием. Для критичных сценариев можно добавить отдельное подтверждение, сохраняя разделение ролей между инициатором, согласующим и исполнителем.
Интеграция с 1С, ERP, банком или CRM
После финального согласования заявка передаётся в учётную систему с внутренним ID. Там создаётся документ или черновик платёжного поручения, а внешний ID возвращается в карточку. Платформа 1С предоставляет REST, HTTP- и web-сервисы для подобных интеграций. Pyrus API также поддерживает REST-вызовы и вебхуки, а его формы описывают поля и правила маршрутизации.
Карта полей и статусов
Для каждого поля указывают источник, формат, обязательность и направление обмена. Статусы согласования отделяют от банковских: «одобрена» означает разрешение на оплату, а «исполнена» появляется после подтверждённой операции. Таблица соответствий хранит исходные значения обеих систем.
Защита от повторов
Каждая передача использует уникальный ключ заявки и версии. Повтор после таймаута возвращает уже созданный документ, а не создаёт второй. В журнале видны время запроса, система-получатель, внешний ID и результат без избыточного раскрытия платёжных данных.
Обратные статусы
Учётная система сообщает номер документа, отправку в банк, исполнение, отклонение или отзыв. Обновление проверяет допустимость перехода. Например, позднее уведомление «отправлена» не должно заменить уже подтверждённый статус «исполнена». Периодическая контрольная сверка дополняет оперативные вебхуки.
Доступы и журнал решений
Инициатор видит свои заявки, руководитель — свой контур, бухгалтерия — реквизиты и документы, администратор — настройки без автоматического права на все финансовые сведения. Сервисные учётные записи получают минимальный набор API-прав. Токены хранятся в защищённой конфигурации и регулярно обновляются.
Журнал содержит изменения маршрута и справочников, действия пользователей и результаты интеграции. Экспорт наследует права интерфейса. Для замещения сотрудника задают срок и основание, чтобы заявка продолжила движение, а история сохранила реального участника.
Как запустить процесс без остановки платежей
Сначала выбирают один распространённый тип заявки и ограниченную группу участников. Несколько недель новый маршрут можно сверять с текущим порядком, отмечая причины возвратов и ручных обходов. Затем правила уточняют и подключают следующие категории.
- Соберите реальные обезличенные примеры обычных и спорных заявок.
- Согласуйте обязательные поля и владельца каждого справочника.
- Нарисуйте маршруты и проверьте пороговые значения.
- Настройте роли, замещение и сроки уведомлений.
- Подключите тестовый обмен с учётной системой.
- Проведите пилот и разберите все ручные исключения.
- Зафиксируйте регламент изменения формы и маршрутов.
Критерии приёмки
Проверка строится на сценариях. Обычная заявка проходит ожидаемый путь. Сумма выше порога добавляет нужного согласующего. Недостаток бюджета показывает расчёт. Изменение реквизитов запускает повторную проверку. Повторный запрос интеграции сохраняет один документ. Уволенный или отсутствующий сотрудник корректно заменяется.
- каждый статус имеет понятное значение и владельца;
- ключевые поля невозможно незаметно изменить после решения;
- дубликат обнаруживается до создания второго платежа;
- связанные документы открываются из заявки и обратно;
- история отвечает, кто, когда и какие данные согласовал;
- сбой интеграции создаёт видимую очередь повторов;
- отчёт показывает просрочки и узкие места маршрута.
После запуска измеряют время от создания до решения, долю возвратов на уточнение, количество дублей и время ожидания на каждом этапе. Метрики нужны для улучшения процесса, а не для оценки сотрудника без контекста.
Что подготовить для проекта
Полезны текущая форма заявки, матрица полномочий, примеры счетов, перечень статей и подразделений, правила бюджетного контроля, список учётных систем и несколько историй с ошибками. По этим данным можно выбрать готовый модуль, настроить существующую платформу или разработать интеграцию двух систем по API и вебхукам.
Удачный процесс ощущается спокойно: сотрудник заполняет понятную форму, каждый участник видит нужный контекст, согласованная заявка один раз попадает в учёт, а исполнение возвращается в ту же карточку. Руководитель получает прозрачный реестр без ручного сбора переписки.