Письмо со вложением отвечает только на вопрос «какой файл прислали». Для оплаты этого мало. Бухгалтеру нужны основание, статья расходов, подразделение, срок, договор и подтверждение людей, которые вправе принять решение.
Автоматизация убирает поиск согласующего и ручное напоминание, но не принимает управленческое решение вместо него. Если сумма, реквизиты или основание изменились, заявка должна вернуться на понятный этап, а не продолжить старый маршрут незаметно.
Как автоматизировать согласование счетов на оплату?
Создайте единую заявку с обязательными полями, проверяйте её до запуска, определяйте маршрут по правилам суммы и бюджета, сохраняйте каждое решение и передавайте утверждённую версию бухгалтеру. Счёт остаётся приложением к заявке, а не единственным источником данных.
- Инициатор заполняет заявку и прикладывает основание.
- Система проверяет поля, дубли и доступный лимит.
- Правила выбирают маршрут и срок каждого решения.
- Согласующие утверждают, отклоняют или возвращают заявку.
- Замещение включается по роли и периоду отсутствия.
- После финального решения фиксируется утверждённая версия.
- Бухгалтер проверяет платёжные данные и ставит выплату в план.
- 1С получает заявку или черновик учётного документа с тем же ID.
- Журнал связывает исходную заявку, решения и итог оплаты.
Сначала убедитесь, что этот поток подходит для пилота. Критерии выбора разобраны в чек-листе приоритизации процессов.
За что отвечает инициатор заявки?
Инициатор объясняет деловую потребность и указывает данные, без которых нельзя проверить расход. Он не выбирает согласующих вручную и не назначает себе исключение из правил. Маршрут строится по данным заявки и справочникам компании.
| Участник | Ответственность | Чего не делает |
|---|---|---|
| Инициатор | Цель, основание, сумма, срок и приложение | Не утверждает собственный расход |
| Владелец бюджета | Допустимость расхода и источник лимита | Не проверяет банковские реквизиты |
| Функциональный согласующий | Потребность, объём и условия закупки | Не проводит платёж |
| Бухгалтер или казначей | Платёжные данные, календарь и подготовка операции | Не подменяет решение владельца бюджета |
| Администратор процесса | Правила маршрута, справочники и разбор сбоев | Не меняет решение участника |
Если заявку создаёт помощник или закупщик, в карточке всё равно сохраняют автора ввода и реального владельца потребности. Это разные роли для аудита и обратной связи.
Какие поля заявки обязательны?
Обязательность задаётся правилами компании и типом расхода. Хорошая форма запрашивает данные, которые влияют на маршрут, бюджет и подготовку платежа. Остальные сведения подтягиваются из справочников или появляются только для конкретного исключения.
| Группа | Поля | Зачем нужны |
|---|---|---|
| Потребность | Инициатор, подразделение, назначение расхода | Понятны владелец и деловая цель |
| Основание | Поставщик, договор, заказ или другое основание | Расход связан с утверждённым обязательством |
| Сумма | Валюта, сумма, налог, график или доля оплаты | Выбираются лимит и порог согласования |
| Бюджет | Статья, центр затрат, проект, период | Проверяется доступный источник |
| Срок | Желаемая дата и объяснение срочности | Платёж попадает в календарь без скрытого приоритета |
| Документы | Счёт и необходимые приложения | Согласующий видит подтверждение заявки |
| Контроль | Внутренний ID и признак повторной подачи | Версии и дубли не смешиваются |
Реквизиты поставщика лучше выбирать из проверенной карточки контрагента. Свободный ввод банковских данных повышает риск ошибки и требует отдельной проверки изменения.
Как проверять бюджетные лимиты?
Проверка бюджета должна вернуть объяснимый результат: лимит найден и достаточен, нужен перенос или дополнительное решение, либо расход нельзя отправить дальше. Одного сигнала «красный» недостаточно - инициатору нужно понимать, что исправить и кто вправе разрешить исключение.
| Результат проверки | Следующий шаг | Что фиксируется |
|---|---|---|
| В пределах лимита | Обычный маршрут | Статья, период и доступная сумма на момент проверки |
| Лимит есть, но средств недостаточно | Возврат или заявка на перенос | Недостающая сумма и владелец решения |
| Расход вне бюджета | Отдельный маршрут исключения | Причина, источник покрытия и дополнительные согласующие |
| Аналитика не заполнена | Возврат инициатору | Конкретное отсутствующее поле |
| Данные бюджета недоступны | Техническая очередь | Ошибка проверки без ложного статуса «согласовано» |
Повторную проверку выполняют перед финальным решением или постановкой в платёжный календарь, если между этапами мог измениться доступный остаток. Уже использованный лимит нельзя незаметно считать свободным только потому, что первая проверка была успешной.
Как построить маршрут согласования?
Маршрут определяется ролью и условиями заявки, а не списком фамилий в коде. Обычно на него влияют подразделение, статья расходов, сумма, наличие договора, тип поставщика и выход за лимит. После старта система сохраняет версию правил, по которой выбраны участники.
| Условие | Вариант маршрута | Причина |
|---|---|---|
| Типовой расход в пределах лимита | Руководитель и владелец бюджета | Короткий поток без лишних участников |
| Сумма выше порога | Дополнительный финансовый уровень | Более высокая цена решения |
| Нет действующего основания | Возврат до согласования | Маршрут не исправляет отсутствие документа |
| Новый поставщик или изменённые реквизиты | Проверка контрагента и бухгалтерии | Изменение платёжного риска |
| Расход вне бюджета | Владелец исключения и финансовый руководитель | Нужно явно определить источник средств |
| Несколько независимых проверок | Параллельный этап | Сокращается ожидание без потери решений |
Последовательное согласование нужно только там, где следующее решение зависит от предыдущего. Независимые проверки можно запускать одновременно, но финальный статус появляется после всех обязательных ответов.
Как настроить замещение и сроки?
Замещение привязывают к роли, периоду отсутствия и допустимому уровню решения. Система должна заранее знать, кто получает задачу, если основной согласующий недоступен. Ручная пересылка письма не создаёт надёжного замещения.
- плановое замещение на период отпуска или командировки;
- резервный участник после установленного срока ожидания;
- разные заместители для разных подразделений и сумм;
- запрет передавать задачу инициатору собственной заявки;
- уведомление основного участника о выполненном замещении;
- явная отметка в истории, кто принял решение и на каком основании;
- возврат полномочий после окончания периода замещения.
Срок задачи измеряют в рабочих или календарных днях по единому правилу. Напоминание и эскалация не должны создавать вторую независимую задачу: у заявки остаётся одно текущее состояние.
Какие исключения нужно описать до запуска?
Исключения определяют надёжность процесса сильнее типового маршрута. Для каждого случая задают статус, ответственного и безопасное продолжение. Неизвестная ситуация останавливает заявку и попадает к владельцу процесса.
| Исключение | Что делает система | Кто решает |
|---|---|---|
| Не хватает поля или приложения | Возвращает с точной причиной | Инициатор |
| Похожий счёт уже зарегистрирован | Показывает возможный дубль и блокирует автопередачу | Бухгалтер или владелец процесса |
| После согласования изменилась сумма | Создаёт новую версию и перезапускает нужные этапы | Участники по новым условиям |
| Согласующий отклонил заявку | Фиксирует причину и завершает маршрут | Инициатор создаёт исправленную версию при необходимости |
| Платёж срочный | Добавляет обоснование и специальный маршрут | Роль, уполномоченная на исключение |
| Срок договора истёк | Останавливает заявку до подтверждения основания | Владелец договора |
| 1С или справочник недоступны | Ставит передачу в техническую очередь | Поддержка интеграции |
Признак срочности не должен обходить контроль бюджета или полномочий. Он меняет срок и маршрут, но не стирает обязательные решения.
Как хранить решение по заявке?
Решение относится к конкретной версии заявки. В записи сохраняются участник, роль, действие, время, комментарий и набор данных, который он видел. После существенного изменения прежнее согласование нельзя переносить автоматически.
| Статус | Смысл | Допустимый переход |
|---|---|---|
| Черновик | Данные ещё меняются | На проверку комплектности |
| Возвращена | Нужны исправления инициатора | В новую версию или отмену |
| На согласовании | Есть активные задачи участников | Утверждение, отклонение или возврат |
| Утверждена | Все обязательные решения получены | На подготовку оплаты |
| Отклонена | Маршрут завершён отрицательным решением | Только новая заявка или версия |
| Передана бухгалтеру | Зафиксирована версия для оплаты | В план, на уточнение или отмену |
| Оплачена | Есть подтверждённая операция учётной системы | Закрытие и сверка |
Комментарии «ок» недостаточно, если решение содержит условие. Условное согласование лучше представить отдельным ответом с обязательным полем: что выполнить, кто проверяет и до какого этапа.
Что передавать бухгалтеру и в 1С?
После утверждения бухгалтер получает неизменяемый снимок заявки: основание, сумму, бюджетную аналитику, срок и историю обязательных решений. В 1С можно создать заявку на расходование денежных средств или черновик учётного документа. Фактический тип зависит от конфигурации и правил компании.
- Присвоить заявке стабильный внутренний ID.
- Зафиксировать номер утверждённой версии.
- Проверить поставщика и платёжные реквизиты по справочнику.
- Передать статью расходов, центр затрат, проект и плановую дату.
- Создать объект в тестовом или рабочем контуре 1С.
- Вернуть внешний ID и статус в карточку заявки.
- Показать бухгалтеру ошибки, которые требуют уточнения.
- После оплаты связать заявку с подтверждённой операцией.
Передача в 1С не равна автоматической оплате. На пилоте система готовит проверенный объект, а бухгалтер подтверждает платёж и его место в календаре. Общие принципы устойчивого обмена вынесены в отдельный материал об интеграции по API.
Если нужный объект доступен только через интерфейс старой конфигурации, сравните допустимые варианты в статье «RPA или API».
Что должно оставаться в журнале аудита?
Журнал отвечает на четыре вопроса: кто сделал действие, когда, с какой версией данных и почему. История дополняется событиями, а не переписывается. Чувствительные реквизиты и содержимое приложений не нужно копировать в технические сообщения.
- создание и отправка заявки;
- результат автоматических проверок;
- выбранный маршрут и версия правила;
- назначение, замещение и эскалация задачи;
- решение участника с ролью и комментарием;
- изменение суммы, срока, бюджета или основания;
- возврат, отклонение, отмена и повторная подача;
- передача в 1С, внешний ID и ошибки;
- фактическая оплата и итоговая сверка.
Права на просмотр журнала и приложений могут различаться. Согласующий видит сведения, необходимые для своего решения, а техническая поддержка получает коды и идентификаторы без лишних финансовых данных.
Какие метрики показывают результат?
Смотрите не только среднее время согласования. Оно скрывает заявки, которые неделями ждут одного участника. Для управления нужны медиана, длинный хвост, причины возвратов и фактический результат после передачи бухгалтеру.
| Метрика | Что показывает | Как разбирать |
|---|---|---|
| Время полного цикла | Скорость от подачи до передачи бухгалтеру | Медиана и 90-й процентиль |
| Ожидание по этапам | Где образуется очередь | По роли, подразделению и сумме |
| Доля возвратов | Качество формы и инструкций | По конкретной причине |
| Просроченные задачи | Работу сроков и замещения | Основной участник, заместитель, эскалация |
| Изменения после решения | Надёжность версий | Сумма, реквизиты, основание, дата |
| Возможные дубли | Риск повторной оплаты | Подтверждённые и ложные совпадения |
| Оплата к нужной дате | Итог процесса, а не только согласования | По приоритету и типу расхода |
| Ручные уточнения | Оставшиеся разрывы вне системы | Почта, мессенджер, звонок |
Исходные показатели снимают до пилота на том же типе заявок. Подход к расчёту эффекта и полной стоимости описан в статье о стоимости автоматизации.
Как провести пилот согласования счетов?
Начните с одного подразделения, одного типа расходов и ограниченного диапазона сумм. На пилоте нужен реальный маршрут с возвратами и замещением, но платёж остаётся под контролем бухгалтера. Расширение начинается после сверки решений и записей в 1С.
- 01
Исходная линия
Собрать примеры, сроки, возвраты и ручные уточнения текущего процесса.
- 02
Форма и правила
Зафиксировать обязательные поля, лимиты, роли и пороги маршрута.
- 03
Тестовые случаи
Пройти типовую заявку, дубль, превышение бюджета и отсутствие согласующего.
- 04
Теневой режим
Сравнить автоматический маршрут с текущим решением без передачи на оплату.
- 05
Ограниченный поток
Передавать утверждённые заявки бухгалтеру и создавать черновики в 1С.
- 06
Сверка
Проверить версии, решения, внешний ID, ошибки и фактические платежи.
- 07
Решение
Расширять подразделения и суммы только после приёмки первого контура.
Границы пилота стоит описывать как процесс «до и после», а не как список экранов. Базовая рамка есть в статье о запуске первой автоматизации.
Частые вопросы
Нужно ли согласовывать каждый счёт на оплату?
Нет. Правила зависят от суммы, статьи бюджета, подразделения, договора и риска. Небольшие типовые заявки могут идти по короткому маршруту, а исключения и превышения лимита требуют дополнительных участников.
Можно ли согласовать счёт в почте или мессенджере?
Уведомление можно доставить в удобный канал, но решение лучше сохранять в единой карточке заявки. Иначе письмо, комментарий и актуальная версия суммы легко расходятся.
Что происходит, если согласующий в отпуске?
Система применяет заранее заданное замещение по роли и сроку. Передача решения должна сохраняться в журнале, а заместитель получает только те полномочия, которые нужны для конкретного маршрута.
Нужно ли сразу создавать платёжное поручение в 1С?
Не обязательно. На первом этапе безопаснее передавать утверждённую заявку или создавать черновик для проверки бухгалтером. Автоматическое проведение и отправку платежа добавляют только после отдельной приёмки.
Как понять, что автоматизация согласования работает?
Сравните время полного цикла, долю возвратов из-за неполных данных, просроченные задачи, число ручных уточнений, повторные счета и долю платежей, подготовленных к нужной дате.
Источники и границы материала
- 1С:ERP: казначейство и заявки на расходование денежных средств
- 1С:ERP: контроль расходов и бюджетные лимиты
- 1С:Управление холдингом: процессы, задачи и оповещения
- 1С:Документооборот: согласование, утверждение и контроль исполнения
- Microsoft Learn: типы и последовательность согласований
- Microsoft Learn: замещение по сроку и отсутствию
Материал носит информационный характер. Конкретная архитектура, бюджет, режим работы с данными и уровень человеческого контроля зависят от процесса и требований компании.
Разберите один маршрут оплаты
Покажите форму заявки, правила бюджета, роли согласующих и способ работы с 1С. Мы поможем отделить типовой поток от исключений и собрать границы пилота.