Заявки на оплату в Битрикс24: как сделать расходы видимыми руководителю

Согласованный счёт ещё не объясняет расход

Руководитель одобрил счёт в переписке, сотрудник передал его бухгалтеру, а через неделю никто не может уверенно сказать, оплатили ли поставщика и почему сумма отличается от первоначальной просьбы. Повторное сообщение выглядит как новая заявка. Если его снова отправить в работу, компания потеряет связь между своим решением и исполнением. Разберём небольшую сервисную компанию, где сотрудники заказывают услуги поставщиков и передают внутренние заявки на оплату в Битрикс24. Руководитель согласует расход, бухгалтер проводит платёж в своей рабочей системе, а CRM показывает, на каком шаге находится просьба.

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

Я выберу отдельную карточку просьбы, связанную со счётом поставщика, вместо согласования только в чате. Переписка удобна для обсуждения, но следующий сотрудник ищет решение среди сообщений и не всегда понимает, какая версия суммы одобрена. Общая запись сохраняет предмет разговора. Из неё видно, что ещё требуется для движения заявки и кто отвечает за этот шаг.

Ошибка: вместо заявки передали только вложение

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

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

Вложение сохраняет основание просьбы. Его название не заменяет описание расхода.

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

Ошибка: одобрение приняли за подтверждение платежа

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

«Разрешено к оплате» выражает решение руководителя. «Оплачено» сообщает о выполненной операции, которую подтвердил назначенный сотрудник, а не о хорошем намерении её провести.

Смена стадии вручную ещё не является банковским подтверждением. В выбранном процессе бухгалтер отмечает исполнение по сведениям своей платёжной системы и сохраняет ссылку или документ, который компания использует для сверки. Автоматический обмен можно заказать отдельно. Тогда подрядчик объясняет источник подтверждения и поведение при задержке или отказе передачи. Пока такого обмена нет, руководитель видит состояние внутренней заявки, а сведения о движении денег уточняет у ответственного за платёж.

Ошибка: сумму исправили после согласования

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

В таком случае я верну изменённую просьбу на рассмотрение. Прежнее одобрение относится к старым условиям. Его нельзя автоматически перенести на другое предложение поставщика.

Допустим, на демонстрации первоначальный счёт заменяют документом с большей суммой. Руководитель открывает обновлённую заявку, видит причину изменения и принимает новое решение. Бухгалтер не проводит её по старому разрешению. Испытание показывает, различает ли отдел две версии просьбы и решение по каждой из них.

Ошибка: стадия известна, следующий участник — нет

Карточка находится на рассмотрении, но ни руководитель, ни инициатор не считают её своей текущей задачей. Общий список этого не исправит. Заявке нужен сотрудник, который отвечает за ближайший переход и получает вопрос при возврате, чтобы просьба не оставалась в колонке, которую инициатор, руководитель и бухгалтер считают чужой очередью. Если бухгалтеру не хватает основания расхода, просьба возвращается инициатору с конкретным вопросом, чтобы тот дополнил материалы и снова передал их на рассмотрение. Руководитель видит задержку вместе с её причиной и может отличить ожидание ответа от уже принятого решения, которое ещё не передали на исполнение.

Инициатор объясняет покупку, руководитель решает по расходу, бухгалтер подтверждает выполнение. Эти роли можно совмещать в небольшой компании, но их действия всё равно стоит разделить.

В настройках смарт-процесса доступ сотрудников определяется через права CRM. Поэтому участники демонстрации выполняют свои действия под рабочими учётными записями, с видимостью материалов и полномочиями, которые получат после запуска. Инициатор открывает свою просьбу и отвечает на уточнение. Согласующий видит материалы для решения. Бухгалтер находит одобренную версию и может отметить результат в пределах выданных прав.

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

Ошибка: очередь решений назвали планом платежей

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

В смарт-процессе доступны режимы «Канбан», «Список» и «Дела», как описано в справке настройки. Канбан показывает движение по стадиям, список удобен для сопоставления нескольких заявок. Экран удобен, когда руководитель по нему находит состояние нужной заявки и понимает причину ожидания.

В режиме «Список» можно выгрузить элементы в CSV или Excel. Такая выгрузка сохраняет сведения на момент её подготовки и не становится автоматически актуальной после изменения карточек.

Для ежедневного обзора я оставлю живую очередь в CRM, а выгрузку использую там, где нужен отдельный разбор состава. Иначе несколько файлов с разными датами быстро превратятся в спор об актуальном состоянии. Выгрузку сверяют перед обсуждением. Бухгалтер сообщает, какие сведения подтверждают исполнение, а руководитель отделяет их от просьб, которые ещё ожидают рассмотрения.

Ошибка: уведомление стало заменой решения

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

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

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

Возьмите заявку с изменившейся суммой

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

Руководитель видит предмет расхода и условия своего решения? Бухгалтер понимает, какая версия готова к оплате и на основании чего заявка будет закрыта?

Ответы входят в задание на доработку Битрикс24 для внутренних заявок вместе с примером счёта, составом ролей и правилом значимых изменений. Необязательно описывать программные действия подрядчика. Достаточно связать каждый рабочий исход с понятным действием сотрудника и способом проверить его в карточке. Тогда состояние заявки помогает продолжать работу, а расход перестаёт жить только в переписке.