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