Почему электронное согласование сохраняет старые ошибки
Счёт загружают в систему, руководителю приходит уведомление, он нажимает «согласовать». Процесс стал быстрее, но решение по-прежнему принимается без контекста: какой заказ оплачивается, менялась ли сумма и не находится ли тот же документ в другой заявке.
Автоматизация полезна, когда собирает основание решения. Маршрут уведомлений — лишь часть задачи. До него нужны идентификация документа, связь с заказом или договором и проверка истории.
Основание оплаты в рабочем процессе — набор сведений, по которым уполномоченный сотрудник принимает решение. Его состав определяет компания. Ни статус в системе, ни автоматическое сравнение не подменяют финансовую или юридическую оценку специалиста.
Разделите счёт, заявку на оплату и платёж
Счёт — входящий документ с определёнными реквизитами и суммой. Заявка на оплату — внутреннее предложение выполнить операцию. Платёж — отдельное событие расчётов, подтверждаемое согласованным источником.
Один счёт может оплачиваться частями, поэтому у него бывает несколько заявок. Одновременно один файл могут загрузить несколько сотрудников. Смешение сущностей превращает любой повтор файла в новую потребность в деньгах.
В первой версии системы зафиксируйте связи: какая заявка относится к какому счёту, какую сумму она запрашивает и в каком состоянии находится. Факт оплаты храните отдельно от одобрения и подготовки.
Если счёт используется только как один из документов основания, не делайте его единственным центром процесса. Важна связь с реальным заказом или другим утверждённым объектом.
Условный пример частичной оплаты
Вымышленная компания получила счёт на 120 000 условных рублей по согласованному заказу. Ранее оплачено 50 000. Ещё одна операция на 40 000 подготовлена и находится в обработке, но её исполнение пока не подтверждено.
Неоплаченный остаток составляет 120 000 − 50 000 = 70 000. Однако для новой заявки доступно не обязательно 70 000. Если внутреннее правило исключает повторное выделение уже обрабатываемой суммы, свободный остаток для новой операции равен 120 000 − 50 000 − 40 000 = 30 000.
При этом 40 000 нельзя назвать оплаченными. На экране нужны отдельные значения: подтверждённые оплаты, открытые операции и остаток для нового запроса. Если подготовленная операция отменена, её сумма освобождается по подтверждённому событию отмены.
Пример показывает организационную модель, а не универсальное правило бухгалтерского учёта. Конкретные состояния и расчёты согласуют финансовые специалисты компании.
Соберите карточку, достаточную для проверки
Согласующему не нужен весь архив закупок, но он должен видеть происхождение суммы и связь с деятельностью компании. Минимальная карточка зависит от вида операции.
Рабочий шаблон для нашего примера:
- Счёт: номер, дата, контрагент, сумма и исходный файл.
- Основание: заказ ЗК-318 с доступным описанием предмета.
- Запрошено сейчас: 30 000.
- Оплачено ранее: 50 000, подтверждённые события.
- В обработке: 40 000, ссылка на действующую операцию.
- Отклонение: отсутствует либо описано инициатором.
- Ответственный: владелец заказа.
- Решение: по определённой заявке и определённой версии счёта.
Если основание отсутствует, маршрут должен быть явным: вернуть инициатору за связью, направить на отдельную проверку или применить другой установленный порядок. Пустое поле не стоит обходить вымышленным номером договора.
Ищите похожие документы, а не только одинаковые файлы
Один счёт может поступить как исходный файл и как скан распечатки. Названия и содержимое файлов на техническом уровне различаются, а бизнес-документ один.
Для поиска возможных дублей сравнивают сочетание контрагента, номера, даты, суммы и других значимых признаков. Формат номера полезно нормализовать, сохраняя оригинал. Но полное совпадение признаков не всегда означает, что запись нужно автоматически удалить.
Поставщик мог прислать исправленную версию. Тогда сотруднику нужно увидеть различия и решить, заменить ли действующий документ, связать ли редакции или зарегистрировать самостоятельный счёт.
Показывайте основание подозрения: «совпадают контрагент, номер и дата; сумма отличается». Это помогает принять решение быстрее, чем общий красный значок «возможен дубль».
Не переносите одобрение на изменённую сумму
После согласования счёта поставщик присылает новый файл с другой суммой. Если прикрепление заменяет документ в прежней карточке, согласующий выглядит одобрившим то, чего не видел.
Создавайте новую версию и показывайте изменение. Компания определяет, когда требуется повторное рассмотрение и какие участники его выполняют. Решение всегда связывается с конкретной суммой, основанием и версией.
Если часть уже оплачена, изменение особенно важно. Сначала финансовый специалист определяет корректное дальнейшее действие. Система должна показать факты и не создавать отрицательные остатки или новые операции без объяснения.
Аналогично изменение банковских или иных платёжных реквизитов требует установленного компанией процесса проверки. Нельзя считать его обычным косметическим редактированием карточки.
Защитите процесс от повторов и параллельных действий
Два сотрудника могут одновременно открыть остаток 30 000 и создать по заявке на всю сумму. Проверка только при показе страницы не предотвращает конфликт.
Если компания использует контроль выделенных сумм, проверка доступного остатка и выделение суммы должны выполняться как единая защищённая операция: две заявки не могут одновременно занять один остаток. Повторная отправка той же заявки не должна создавать новую независимую запись. Необходим устойчивый идентификатор действия и понятный результат повторного запроса.
После технического сбоя сотрудник должен видеть: заявка создана, результат ещё проверяется или операция не была принята. Без этой информации он будет повторять действие вслепую.
Первая версия: один маршрут и ясные исключения
Начните с одного типа закупки и небольшой группы участников. Включите регистрацию, связь с основанием, поиск похожих счетов, решение согласующего и получение подтверждённого состояния расчётов.
Отдельно опишите повторный файл, новую сумму, частичную оплату, отменённую заявку, отсутствие основания и потерянный ответ обмена. Эти сценарии важнее красивой общей диаграммы маршрутов.
Очередь исключений должна показывать владельца следующего действия. Инициатор уточняет основание, финансовая роль разбирает расхождение суммы, ответственный за интеграцию проверяет технический отказ. Не отправляйте все проблемы одному администратору.
Готовая система или заказная разработка
Готовое решение стоит оценивать на реальном обезличенном сценарии с частичной оплатой и новой редакцией счёта. Если нужные связи и проверки поддерживаются настройками, собственная система может быть избыточной.
Разработка оправдана, когда основания связаны с несколькими внутренними процессами, нестандартными правилами распределения сумм или существующими системами, которые трудно согласовать готовыми средствами. Иногда достаточно отдельного интеграционного модуля.
Сравнивать предложения полезно по проверяемым сценариям, как описано в статье о сравнении предложений на разработку.
Сделайте возврат понятным инициатору
Согласующий должен иметь возможность вернуть заявку с конкретным вопросом: отсутствует связь с заказом, изменена сумма или не объяснено совпадение с зарегистрированным документом. Общая формулировка «не согласовано» заставляет участников начинать отдельную переписку.
После ответа инициатора сохраняйте первоначальный вопрос и приложенное объяснение. Повторное рассмотрение относится к обновлённой заявке, а прежнее решение остаётся в истории. Это помогает разобрать ситуацию, когда один сотрудник считает замечание закрытым, а другой не видел внесённого изменения.
Уточните также, какие изменения требуют повторного запуска маршрута. Исправление описания и замена получателя платежа не должны обрабатываться одинаково только ради простоты интерфейса.
Чеклист перед обсуждением проекта
Проверьте, что вы различаете документ, заявку и платёж; знаете источник подтверждённых оплат; определили владельца решения по дублю; сохраняете версии; можете объяснить расчёт доступного остатка.
Для разговора с ExtentLab подготовьте один обезличенный счёт, связанный заказ и историю частичной оплаты. На таком примере можно определить маршрут проверок, необходимые интеграции и границы первой версии без обещания автоматизировать все финансовые решения.